GSB@MIT-ML 04/04/81 21:32:37 Re: shaft, shaft
To: (BUG LISP) at MIT-ML
CC: KWC at MIT-ML, PSZ at MIT-ML, WAM at MIT-ML
It seems that grindef defines some rather useful names, like PREDICT.
PREDICT's name should be a little bit more specific about who or
what it is predicting for.


Date:  4 APR 1981 1621-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: CASEQ doesn't do MEMQ
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

It would be even more confusing than it already is if it did MEMQ.
Eg, CASEQ allows the form

	(CASEQ q ((item1) consequent) ...)

to contract to

	(CASEQ q (item1 consequent) ...)

except in the case of item1=T, where (CASEQ ... (T ...)) has special
meaning and hence if you want to compare to T you have to do 
(CASEQ ... ((T) ...)). If you allowed arbitrary things to compare against,
you'd see

	(CASEQ '(FOO BAR) ((FOO BAR) X) (((FOO BAR) Y) XX) ...)

and you'd have even more special cases to worry about.

As with the recent discussion with DOLIST, I Have to say that I think the
right thing is simplicity. While perhaps CASEQ should allow any kind of atomic
things, I don't buy its accepting arbitrary forms. That destroys the sense of
simplicity it meant to achieve. If its syntax gets so hairy that you
can't see what it is doing at a glance, you oughta be using COND or
write your own GCASEQ, I think.

-kmp

ps As a side note, (CASEQ '(FOO BAR) '((X) 8)) reads in as
   (CASEQ '(FOO BAR) (QUOTE ((X) 8)))
   so I suspect you didn't mean the second "'" in your example.


Date:  4 APR 1981 1526-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: PRATT;BUG 1
To: (BUG LISP) at MIT-MC
CC: PRATT at MIT-MC, GJC at MIT-MC

Shows a bug where GETCHARN is called by the compiler on
something that is not a symbol. This used to show up
as a normal unused-lambda-variable message the last time
CGOL was compiled.

Date:  4 APR 1981 1414-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

(CASEQ '(FOO BAR) '((X) 8)) gives a WRNG-TYPE-ARG error for
its first argument. Says it wants a SYMBOL or a FIXNUM.
I thought the definition of CASEQ was that it used MEMQ
to test the cases except that "=" is used in maclisp if the
cases are all fixnums.

There are three ways to look at this
[1] Extra error checking provided in the interpreter.
[2] Foolishly introduced incompatibility between the interpreter
    and compiler.
[3] some other way?

what I'm wondering about is number 3.


Date: 4 April 1981 14:12-EST
From: Carl W. Hoffman <CWH at MIT-MC>
To: KST at MIT-MC, GJC at MIT-MC
cc: BUG-LISP at MIT-MC

I haven't seen anybody answer this yet, so I'll give it a try.  My apologies
if someone has already responded to this.

    Date:  3 APR 1981 1048-EST
    From: KST at MIT-MC (Kim Stefan Theilhaber)

    My GRTOOL program still gets PDL-OVERFLOW's ...

    Let me give the general picture.  I have an s-exp of graphics
    commands. X, I do (EVAL X) to print the graph. For a given X sometimes
    it will PDL-OVERFLOW, and sometimes it will not.  In other words,
    evaluating the SAME unchanging S-EXP does not produce repeatable
    results. 

    There is nothing much on the stack, just want you would expect
    from evaluating an expession like (ARDS-SET-POINT 100 100),
    for some reason the PDL-OVERFLOW happens inside +TYO.

My guess as to what is going on here is that X is a list of forms like
(SET-POINT 100 100) with a PROGN at the head of the list.  [GJC later
confirms this.]  Since PROGN is an LSUBR and not a special form, the pdl
will grow as each form in the list is evaluated and the graph is printed.
I'm not sure what would cause the inconsistencies in repeated evaluations
the same form.  Being at a break level versus top level?  GC in the middle?

A simple solution to your problem would be to use MAPC rather than applying
PROGN.

I suspect there are more efficient ways of representing your data and
drawing your graph than using lists and calling EVAL.  (In general, user
programs should rarely need to call EVAL.)  If you are just drawing points,
then you can use a 2 by N fixnum array to store point coordinates and
iterate over the array when drawing.  Or you can make the first dimension 3
if you need an "op code" field, i.e. to distinguish between drawing a point,
drawing a line, and pen displacement.

Date:  4 APR 1981 0816-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

The loading message of HERALD, e.g. "Loading DEFMAX 91", is getting
put onto the GCPSAR array.

Date:  3 APR 1981 2227-EST
From: JONL at MIT-MC (Jon L White)
Subject: "BIBOP" 
To: (BUG LISP) at MIT-MC

Would anyone object if this symbol just "went away", i.e. we
no longer support it as a "feature" on the (STATUS FEATURES) list?

Date:  3 APR 1981 2103-EST
From: JONL at MIT-MC (Jon L White)
Subject: MULTIPLE-VALUE expander
To: gsb at MIT-ML
CC: (BUG LISP) at MIT-MC

Seems I've failed to note the correction made to MULTIPLE-VALUE ocasioned
by your note:
    GSB@MIT-ML 03/23/81 21:35:42 Re: why not flush this check entirely?
    To: (BUG LISP) at MIT-ML
    ;(MULTIPLE-VALUE (ANEW ACHANGEP) (IF (EQ (CAR ARG) (QUOTE QUOTE)) (READER-BQ (CADR ARG)) (READER-BQ-FUNFORM ARG))) Most System funs don't return multiple-values

    (COMMENT **ERROR**  (MULTIPLE-VALUE (ANEW ACHANGEP) (IF (EQ (CAR ARG) (QUOTE QUOTE)) (READER-BQ (CADR ARG)) (READER-BQ-FUNFORM ARG))) 
		    LISP error during MACRO expansion in function READER-BQ-FUNFORM)
    ; DATA ERROR - TO PROCEED TYPE $P 
    Is this really a legitimate complaint for this form??

What the static checker wanted to do was "walk" over the form, looking for
things which were certifiably wrong;  a COND isn't necessaryly wrong, but
the "walker" should descend thru the clauses before complaining.  So I
made it descend thru the appropriate FSUBR's, and simply stopped it 
complaining in the case where it "didn't know".

Date: 3 April 1981 16:32-EST
From: George J. Carrette <GJC at MIT-MC>
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, GJC at MIT-MC

    Date: 3 APR 1981 1610-EST
    From: JONL (Jon L White)
    To:   GJC
    cc:   (BUG LISP)

    Re:
        Date: 9 March 1981 00:54-EST
        From: George J. Carrette <GJC at MIT-MC>
        '(THIS IS THE UNFASL FOR ((DSK GJC) RELAX /5)) 
        (COMMENT **ERROR**  (BVAL . 20.) Lost datum - ILOCMODE in function SET_RECTANGLE)
        ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% 
    I never herad back from you, but does this didn't happen for me when
    I compiled that file.  What's up?


The error was that a FIXNUM declaration was given for a variable F,
that was then used as (FUNCALL F X). This came up when
the code was generalized from taking a mere number as input to
taking a function. In order to reproduce this, construct a function
along the lines of
(defun foo (a b c d e f g)(declare (fixnum a b c d e f g))
      (funcall a (+ a b c d e f g)))

It took me a couple minutes to realize this as problem of
a general nature in COMPLR which I have been familiar with
for some time and which I gather is "impractical" to fix.

In short, there isn't a whole lot of consistency checking
in the manipulation of declaration information.

I've just about given up hope on winning with respect to this
kind of thing, as even the great lisp-machine doesn't know
the difference between a DEFUN and a DEFVAR, and I'm told by
the respected experts that it is a type of a problem for which
there is not enough resources to solve.


Date:  3 APR 1981 1610-EST
From: JONL at MIT-MC (Jon L White)
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

Re:
    Date: 9 March 1981 00:54-EST
    From: George J. Carrette <GJC at MIT-MC>
    '(THIS IS THE UNFASL FOR ((DSK GJC) RELAX /5)) 
    (COMMENT **ERROR**  (BVAL . 20.) Lost datum - ILOCMODE in function SET_RECTANGLE)
    ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% 
I never herad back from you, but does this didn't happen for me when
I compiled that file.  What's up?

Date:  3 APR 1981 1525-EST
From: JONL at MIT-MC (Jon L White)
Subject: YES-OR-NO-P and Y-OR-N-P
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date: 5 March 1981 21:17-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Why does y-or-n-p REQUIRE that I supply an argument?  I would think that
    it was completely clear what I want if I just call it with no arguments.
    Why doesn't yes-or-no-p go to the trouble to strip leading and trailing
    spaces from what the user types?
In case this hasn't been answered before, YES-OR-NO-P now ignores spaces,
and zero arguments is acceptable.  Did the LISPM version ever permit the
interchange-ability of the first and second arg?  namely is it ok to
say  (YES-OR-NO-P "What foo?" some-stream)  as well as
     (YES-OR-NO-P some-stream "What foo?")
Clearly these two arguments can be distinguished by data-type, and position
in the argument list is unimportant.

Date:  3 APR 1981 1048-EST
From: KST at MIT-MC (Kim Stefan Theilhaber)
To: (BUG LISP) at MIT-MC

My GRTOOL program still gets PDL-OVERFLOW's, and after
setting (STATUS PDLMAX 'REGDPL) closer to (STATUS PDLSIZE 'REGPDL)
as per JONL's suggestion, it gets UNRECOVERABLE ones when p'd.

Let me give the general picture.  I have an s-exp of graphics
commands. X, I do (EVAL X) to print the graph. For a given X sometimes
it will PDL-OVERFLOW, and sometimes it will not.  In other words,
evaluating the SAME unchanging S-EXP does not produce repeatable
results. 

There is nothing much on the stack, just want you would expect
from evaluating an expession like (ARDS-SET-POINT 100 100),
for some reason the PDL-OVERFLOW happens inside +TYO.

Jonl, you can run this any time on PLASMA;GRTOOL TEST, page 2
to see what you can see.


Date: 3 April 1981 01:56-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: somewhat obscure DO feature
To: SK at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 3 April 1981 00:37-EST
    From: Steven T. Kirsch <SK at MIT-MC>

    Doing (DO ((A 1 2)) () (PRINC "LOOP")) will complain about ((A 1 2))
    being improper ("extraneous stepper") rather than the exit condition
    being improper.

Unfortunately the error message is correct.  The "2" really is an
extraneous stepper.  This is because there is an obscure feature in DO
where an exit clause of just NIL, means to execute the body of the DO
EXACTLY once.  It is a way of writing a PROG with some initial values.
It is also one of the least well known features of the language.

Date: 3 April 1981 00:37-EST
From: Steven T. Kirsch <SK at MIT-MC>
Subject:  somewhat obscure error message
To: BUG-LISP at MIT-MC

Doing (DO ((A 1 2)) () (PRINC "LOOP")) will complain about ((A 1 2))
being improper ("extraneous stepper") rather than the exit condition
being improper.

GSB@MIT-ML 04/02/81 21:20:02 Re: in xlisp 2097
To: (BUG LISP) at MIT-ML
(+tyo 65. <random-file-array>)
prints a "A" to the TTY.


Date: 2 April 1981 13:38-EST
From: Richard Mark Soley <SOLEY at MIT-MC>
Subject:  STRING bug found, and fixed
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, DCP at MIT-MC, NILE at MIT-MC

	Thank you, your fix to STRING did indeed clear up the
error.  I assume you then made LSPDMP;NADMP 1049 -- this was
gronked (gave a random error message and got an MPV).  I took
the liberty of renaming it NADMP DEAD.  However, loading LISP;STRING >
into NADMP 1048 works fine.  Thanks.

	-- Richard

Date:  2 APR 1981 0501-EST
From: JONL at MIT-MC (Jon L White)
Subject: STRING bug found, and fixed
To: SOLEY at MIT-MC
CC: (BUG LISP) at MIT-MC, DCP at MIT-MC, NILE at MIT-MC
CC: (BUG NIL) at MIT-MC

    Date: 1 April 1981 21:10-EST
    From: Richard Mark Soley <SOLEY at MIT-MC>
    .  .  .
	    NILE$$^S
	    NILAID^K
	    (load 'debug)
    You will see that at lesat one (sometimes two) strings have
    had a word bitten out of them (and replaced by zeros). .  .
Why, yes, by being able to produce the bug myself, I was able
to track it down and fix it -- STRING 149 shows the fix.
Indeed it was a random timing screw inside STR:COMPRESS-SPACE,
which I'll verbally explain to the curious.   Nothing like a
garbage-collector bug, huh?
    I just :pdump'd a version of NILE as MC:SOLEY;TS WINNER.
I used the little file SOLEY;CHECK *  to verify that no strings
exist with five consecutive null's in them.  You can play with it
to see for sure that the bug is gone.  If you want to start from 
scratch yourself and load things up, be sure to re-load STRING.

Date:  1 APR 1981 2110-EST
From: SOLEY at MIT-MC (Richard Mark Soley)
Subject: Strings
To: (BUG LISP) at MIT-MC, JONL at MIT-MC, (BUG NIL) at MIT-MC
CC: NILE at MIT-MC


	I am sorry JONL, but your latest fix to whatever had
no effect whatsoever to the string bug; it happens at exactly
the same place as before.  If you take a look at str:gcmarray
after doing:

	NILE$$^S
	NILAID^K
	(load 'debug)

You will see that at lesat one (sometimes two) strings have
had a word bitten out of them (and replaced by zeros).  IT
IS ALWAYS THE SAME ONE (at least the first one, which
always shows up).  I and DCP ahve tried for hours trying
to find this bug and couldn't -- blech!

	-- Richard

Date:  1 APR 1981 1305-EST
From: JONL at MIT-MC (Jon L White)
Subject: Random string clobberage
To: SOLEY at MIT-MC
CC: (BUG LISP) at MIT-MC, NILE at MIT-MC, (BUG NIL) at MIT-MC

Probably you should CC your comments about STRING lossages to
BUG-LISP rather than BUG-NIL.  
    As mentioned in a note which I just sent off to BUG-LISP, there
was a problem with lisp's interrupt protection table, and one
manifestation of it would be that if you got a delayed interrupt in
the middle of one of the affected functions (like STATUS OSPEED, or
SUBLIS etc), then you'd wind up inside the +INTERNAL-SET-STRING-WORD-N
code.  This would likely have the effect of bombing out if you didn't
have any strings, or else just clobbering a randome string word with 0's.
    Date: 31 March 1981 18:02-EST
    From: Richard Mark Soley <SOLEY at MIT-MC>
    Subject: Strings in NIL
    My first inclination was that STRING-PNPUT was failing every
    now and then, since continued use of the environment didn't
    seem to lose any more strings.  We have found that
    STR/:COMPRESS-SPACE caused the loss of random words also
    WHEN IT DOES SOMETHING.  I.e., if there is nothing to be
    compressed, it predictably doesn't lose any string contents.
    It seems that at least STR/:COMPRESS-SPACE, and perhaps
    the STRING-PNPUT (SQUID) stuff is dead.
Rather than waste time looking at poooor STR/:COMPRESS-SPACE or STRING-PNPUT,
can you verify whether the problem is either still present, or maybe it was
fixed by the interrupt-bug fix?

Date:  1 APR 1981 1244-EST
From: JONL at MIT-MC (Jon L White)
Subject: APPLYing an EXTEND with a CALL method
To: RLB at MIT-MC, JAR at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 11 MAR 1981 2111-EST
    From: RLB at MIT-MC (Richard L. Bryan)
    A defmethod* for CALL messages to  SUBR-CLASS lets me funcall the 
    result of FSYMEVAL (the latter defined by FUNCEL). This is a win.
    However, an attempt to APPLY such a frob loses, with .  .  .
Fixed now -- patched in current LISP, and edited in source.  Apparently
this was also the problem noted in
    Date: 15 March 1981 17:17-EST
    From: Jonathan A. Rees <JAR at MIT-MC>
    5. CALLI stuff works with EXPR props but not with FUNCALL or APPLY.
       Try the following:
	    (DEFVST FOO BAR)
	    (DEFMETHOD* (CALL FOO-CLASS) (SELF) (FOO-BAR SELF))
	    (SETQ Z (CONS-A-FOO BAR 31))
	    (PUTPROP 'FN Z 'EXPR)
	    (FN) ==> 31		;Calling via a symbol works fine
	    (FUNCALL Z)   ==>   ;#{FOO BAR 31} PC WITH ILLEGAL INTRUCTION CODE
	    (APPLY Z '()) ==>   ;#{FOO BAR 31} UNDEFINED FUNCTION OBJECT
	    (DEFMETHOD* (EVAL FOO-CLASS) (SELF)
	      (LET ((G (GENSYM))) (PUTPROP G SELF 'EXPR) G))
	    (APPLY Z '()) ==>   ;Ilgl mem ref
		;Why is an EVAL even being attempted here?
The code for applying and/or evaling a hunk was just falling into the
wrong place -- now, only a CALL message will be sent, and at the right time.
(losing code was at EVAPH)

Date:  1 APR 1981 1159-EST
From: JONL at MIT-MC (Jon L White)
Subject: Args property of INCLUDEF
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 30 MAR 1981 1912-EST
    From: ALAN at MIT-MC (Alan Bawden)
    The args property of INCLUDEF is (0 . 2) and it is a SUBR.
Fixed.  Tnx for noting this.

Date:  1 APR 1981 1154-EST
From: JONL at MIT-MC (Jon L White)
Subject: Bug fixed in hairy interrupt table
To: GSB at MIT-MC, GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

The following two bugs were due to a "missing fence-post" in the middle
of the hairy interrupt table (the one that demarcates intervals of special
interrupt code action):
    GSB@MIT-ML 03/31/81 01:51:54 Re: how to reproduce that jump to %ISSW.+n
    (setq tty-return '(lambda (()) ()))
    (progn (sleep 5) (status ospeed))
    Then ^Z and ^P the lisp.  When ddt feeps, try to p it.
    This apparently explains why i see it frequently;  many of my init
    files read (status ospeed), and i often ^P them while they are loading up.
I've tested this out, and it now works ok.  Amazingly, this bug has been
around for months.
    Date: 31 MAR 1981 1628-EST
    From: GJC at MIT-MC (George J. Carrette)
    I've got a bug that shows up when a lisp which was ^P'd wants
    the TTY and is P'd. A PURGP error results that seems to have
    something to do with the TTY-RETURN and the use of UNWIND-PROTECT.
    To get it do
    :plasma;Grtool
    .  .  .
    that is, use the test files specified, and alt-p when it wants the TTY. 
I tested this one out too, and it ran ok, with none of the errors which
were visible in the non-corrected version of LISP;  however, the output
file which my test run produced (PLASMA;GRTOOL ARDS) is a little bigger
than the one you (GJC) already had there, which I renamed to GRTOOL OARDS.

Date: 31 MAR 1981 1628-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

I've got a bug that shows up when a lisp which was ^P'd wants
the TTY and is P'd. A PURGP error results that seems to have
something to do with the TTY-RETURN and the use of UNWIND-PROTECT.
To get it do
:plasma;Grtool
plasma;grtool test
2
* ards
^Z
^P
P
^Z
^P
P

that is, use the test files specified, and alt-p when it wants the
TTY. 

This bug shows up in all my maclisp subsystems using unwind-protect
in the toplevel function. (Because of IOTA).


GSB@MIT-ML 03/31/81 01:51:54 Re: how to reproduce that jump to %ISSW.+n
To: (BUG LISP) at MIT-ML
(setq tty-return '(lambda (()) ()))
(progn (sleep 5) (status ospeed))
Then ^Z and ^P the lisp.  When ddt feeps, try to p it.
This apparently explains why i see it frequently;  many of my init
files read (status ospeed), and i often ^P them while they are loading up.


Date: 30 MAR 1981 1912-EST
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG LISP) at MIT-MC

The args property of INCLUDEF is (0 . 2) and it is a SUBR.

Date: 30 MAR 1981 0032-EST
From: JONL at MIT-MC (Jon L White)
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 29 March 1981 09:48-EST
    From: George J. Carrette <GJC at MIT-MC>
    Subject:  +INTERNAL-HERALD-VERSION
    Jonl, I don't like to see any reloads of files
    as part of standard operating procedures for systemically supported
    environments. Right now :MACLISP<SPACE><CR> (LOAD "GJC;ENV") gives
    .  .  .
George, just recompile your files that had the "Experimental" HERALD
compiled into them -- roughly just those compiled Friday and early
Saturday.  I thought I mentioned that in my note yesterday, that
this was stuck into DEFMAX "for the duration", but at least you
wont have to see it reloaded if you compile now (HERALD "in-lines"
all that stuff now).

Date: 29 March 1981 09:48-EST
From: George J. Carrette <GJC at MIT-MC>
Subject:  +INTERNAL-HERALD-VERSION
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, GJC at MIT-MC

Jonl, I don't like to see any reloads of files
as part of standard operating procedures for systemically supported
environments. Right now :MACLISP<SPACE><CR> (LOAD "GJC;ENV") gives
;Loading DEFMAX 91
;CAUTION!  |forget-macromemos/||, A USER SUBR AT 126000, IS BEING REDEFINED
;    AS A SUBR BY FASL FILE ((DSK LISP) DEFMAX FASL)
Its not nice to see the system complaining about itself
like that. Even though it happens quite often on this system I still
haven't gotten used to it, and in fact I cringe when it happens
because it brings to mind the thought "oh no, what new feature/bug has
been introduced?" (A somewhat unfair critique perhaps).

If we must hack maclisp, let's have a higher quality working
environment here. Take whatever steps are needed, it aught to save
time in the long run and make the game a whole lot more fun.

-gjc


Date: 28 MAR 1981 1725-EST
From: JONL at MIT-MC (Jon L White)
Subject: +INTERNAL-HERALD-VERSION
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 27 March 1981 12:43-EST
    From: George J. Carrette <GJC at MIT-MC>
    To: BUG-LISP at MIT-MC
    What is this +INTERNAL-HERALD-VERSION ...
    Furthermore, just sticking this function randomly into
    DEFMAX causes DEFMAX to be multiply-loaded in some environments,
    e.g. the macsyma compiler.
This might be a small subr in the system -- for now, the easiest way to
retro-fit it into old lisp environments was to have it come in as an
expr on some other file.  Your observation about "multiply-loaded" 
means only "loaded a second time", since lisps dumped out with an
old defmax in them will have to be "refreshed".
   Its entirely reasonable also just to have the HERALD macro produce
a gazillion lines of expr code.

Date: 28 MAR 1981 1439-EST
From: JONL at MIT-MC (Jon L White)
Subject: Twenex SUSPEND
To: DFUSER.COCO at MIT-XX
CC: (BUG LISP) at MIT-MC

    Date: 28 Mar 1981 1328-EST
    From: DFUSER.COCO at MIT-XX
	    I have been running a program which does a suspend and recently
    i have been unable to continue with the lisp job. I ma running Twenex Mac-
    lisp at MIT-XX, version 2088 ( /2088). It can be easely redone by doing
    (suspend) directly. -jose
I just loaded up 2088 at MIT-XX, and successfully SUSPENDed several
times, dumping the saved image out, and reloading it.  Could you provide
more details of your lossage.

Date: 28 Mar 1981 1328-EST
From: DFUSER.COCO at MIT-XX
Subject: suspend at twenex
To: bug-lisp at MIT-MC

	I have been running a program which does a suspend and recently
i have been unable to continue with the lisp job. I ma running Twenex Mac-
lisp at MIT-XX, version 2088 ( /2088). It can be easely redone by doing
(suspend) directly. -jose
-------

Date: 27 March 1981 16:27-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  +INTERNAL-HERALD-VERSION
To: GJC at MIT-MC
cc: BUG-LISP at MIT-MC

I agree completely with George. This has no business being a function
that I can see. Let it be epsilon less efficient -- it should still be
GC'able eval-mungeable stuff. There should be no SUBR involved... Foo,
if you want, you can even make the silly thing do a RECLAIM on itself
if the CONS'ing bothers you ... 

Date: 27 MAR 1981 1243-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

What is this +INTERNAL-HERALD-VERSION shit?
I don't care how small the DEFMAX fasl file is,
there is no reason macro-support has to be loaded
just to print out a message and do a putprop.
Furthermore, just sticking this function randomly into
DEFMAX causes DEFMAX to be multiply-loaded in some environments,
e.g. the macsyma compiler.


Date: 24 MAR 1981 0059-EST
From: JONL at MIT-MC (Jon L White)
Subject: Rubout processing after TYIPEEK
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC, WGD at MIT-MC

    Date: 22 March 1981 01:18-EST
    From: Glenn S. Burke <GSB at MIT-ML>
    Why can't the reader, when it starts a READ (READLINE), check for
    and call (status ttyscan) when it first starts up?  
Well, it does, indirectly;  The problem is that the the $DEVICE code
fails to do the ttybuffer scan if there are already characters in the
bufferback list.  I believe the BFPRDP switch shold control this instead.
							 This will fix the
    tyipeek/read problem, since the ttyscan will then get to see the buffered
    back characters.  (I bet +internal-ttyscan-subr doesn't understand
    buffered-back characters. .  .
You luz (your "bet"); +internal-ttyscan-subr does the right thing by calling
$DEVICE -- which suffers generally from the problem noted above.  I'ved
edited in the correction, and will start a reassembly now.  XLISP 2092,
when available, should have this 6-year-old bug fixed.

GSB@MIT-ML 03/23/81 21:35:42 Re: why not flush this check entirely?
To: (BUG LISP) at MIT-ML
;(MULTIPLE-VALUE (ANEW ACHANGEP) (IF (EQ (CAR ARG) (QUOTE QUOTE)) (READER-BQ (CADR ARG)) (READER-BQ-FUNFORM ARG))) Most System funs don't return multiple-values

(COMMENT **ERROR**  (MULTIPLE-VALUE (ANEW ACHANGEP) (IF (EQ (CAR ARG) (QUOTE QUOTE)) (READER-BQ (CADR ARG)) (READER-BQ-FUNFORM ARG))) 
		LISP error during MACRO expansion in function READER-BQ-FUNFORM)
; DATA ERROR - TO PROCEED TYPE $P 
Is this really a legitimate complaint for this form??


GSB@MIT-ML 03/23/81 19:29:48
To: (BUG LISP) at MIT-ML
the conser for errframes blows it when the error was an ERINT uuo with
a 6bit string which contained escaped (i.e. lower-case) stuff.
If you extract the definition of 6BSTR out of complr and do the following
you will see:
(lap-a-list 
  '((lap foo subr)
    (erint 2 (% sixbit #.(6bstr "Bad frobozz")))
    (popj p)
  nil))
It stops at the first escaped char:  "Bad frobozz" -> B, 
"BAD frobozz" -> |BAD |


Date: 23 MAR 1981 1726-EST
From: JONL at MIT-MC (Jon L White)
Subject:  PSETQ
To: RWK at MIT-MC, GLS at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date: 20 March 1981 22:58-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    .  .  .
    Both LISPM and MacLisp return the first argument.  Since this is parallel
    assignment, I'm less bothered by this than I might be, although I still
    think it's less than optimal from a consistancy viewpoint.
MacLISP's action isn't an independent viewpoint -- I originally implemented
PSETQ as a macro which returned the last value, a la SETQ, and then
someone pointed out the discrepancy between that and the LISPM.  Not
wanting to make waves (against stone walls?), I just quietly changed it
one day.  However, I fear that there are now numerous places where the
value of PSETQ is being used.

Date: 23 MAR 1981 1621-EST
From: JONL at MIT-MC (Jon L White)
Subject:  PSETQ
To: RWK at MIT-MC, GLS at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date: 20 March 1981 22:58-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    .  .  .
    Both LISPM and MacLisp return the first argument.  Since this is parallel
    assignment, I'm less bothered by this than I might be, although I still
    think it's less than optimal from a consistancy viewpoint.
MacLISP's action isn't an independent viewpoint -- I originally implemented
PSETQ as a macro which returned the last value, a la SETQ, and then
someone pointed out the discrepancy between that and the LISPM.  Not
wanting to make waves (against stone walls?), I just quietly changed it
one day.  However, I fear that there are now numerous places where the
value of PSETQ is being used.

Date: 23 March 1981 13:53-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: BADPI;...
To: KMP at MIT-MC
cc: CSTACY at MIT-AI, BUG-LISP at MIT-AI

That BADPI is not just a "glitch in the operating system".  It is
repeatable, if you can repeat a ^Z/p sequence after some number of
microseconds of runtime.



Date: 23 March 1981 12:23-EST
From: Edward Barton <EB at MIT-AI>
Subject: BADPI
To: BUG-LISP at MIT-AI

 ... For example, I just got it in LISP 2077 by repeatedly ^Z'ing
and $P'ing during startup:

BADPI;(ATTY;) %ALLOC+31>>SETZB ATYF



Date: 23 March 1981 12:18-EST
From: Edward Barton <EB at MIT-AI>
Subject: CSTACY's BADPI bug
To: BUG-LISP at MIT-AI

That BADPI bug happens quite often if you ^Z a LISP while it is
starting up.  I doubt that it was just a "glitch in the operating
system."


Date: 23 March 1981 04:19-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  BADPI;...
To: CSTACY at MIT-AI
cc: BUG-LISP at MIT-AI

This was probably just a glitch in the operating system.
If it isn't something you can repeat, just ignore it as
best you can. -kmp



Date: 23 March 1981 00:23-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: BUG-LISP at MIT-AI

BADPI;(ATTY;) 17325>>MOVE 2,(2)  2/ 104155

I got this right before a LUSER message was printed
on my terminal.

PDUMP in cstacy;lisp bomb ai:



Date: 22 March 1981 01:18-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: read, this
To: BUG-LISP at MIT-ML

Why can't the reader, when it starts a READ (READLINE), check for
and call (status ttyscan) when it first starts up?  This will fix the
tyipeek/read problem, since the ttyscan will then get to see the buffered
back characters.  (I bet +internal-ttyscan-subr doesn't understand
buffered-back characters.  But that can be fixed.  And user-written
ones would, if they call tyi/tyipeek.)


Date: 22 March 1981 00:38-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Semantics of PSETQ?
To: BUG-LISPM at MIT-AI, Guy.Steele at CMU-10A, BUG-lisp at MIT-MC

I think that any code that depends on the value returned by PSETQ,
particularly if that value is defined to be the value of the first
variable in the list, would be extremely unclear.  I would much prefer
to make the returned value undefined.

Date: 20 MAR 1981 2258-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: PSETQ
To: (BUG LISP) at MIT-MC, GLS at MIT-MC
CC: (BUG LISPM) at MIT-MC

Both LISPM and MacLisp return the first argument.  Since this is parallel
assignment, I'm less bothered by this than I might be, although I still
think it's less than optimal from a consistancy viewpoint.

By the way, MacLisp's PSETQ gives an error about having an odd number
of arguments when you do (PSETQ).  On the LISPM, no error checking
is done at all.

Date: 20 March 1981 2249-EST (Friday)
From: Guy.Steele at CMU-10A
To: bug-lisp at MIT-MC, bug-lispm at MIT-AI
Subject:  Semantics of PSETQ?
Message-Id: <20Mar81 224929 GS70@CMU-10A>

Is PSETQ supposed to return the last value computed, the first
value computed, or what?  It is a *lot* easier to compile if
it returns either the first value or () [because you can compute
the values left-to-right, stuffing them onto a stack, then pop
them off in reverse order, except MOVEM the last one].  Also,
I think all existing versions in fact do this?  But then what of
the LISP Machine Manual's claim that "PSETQ is just like SETQ"
excepting the paralle assignment?

Date: 20 MAR 1981 1438-EST
From: JONL at MIT-MC (Jon L White)
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 20 March 1981 01:04-EST
    From: Alan Bawden <ALAN at MIT-MC>
    (break foo)
    ;BKPT FOO
    (error)I wait forever right here.   what's going on when I do this?
Break loops have an ERRSET around them.  (ERROR) generates a non-printing
error.  After the "error" has been "caught" then you are back in your
main break loop.

Date: 20 MAR 1981 1438-EST
From: JONL at MIT-MC (Jon L White)
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 20 March 1981 01:04-EST
    From: Alan Bawden <ALAN at MIT-MC>
    (break foo)
    ;BKPT FOO
    (error)I wait forever right here.   what's going on when I do this?
Break loops have an ERRSET around them.  (ERROR) generates a non-printing
error.  After the "error" has been "caught" then you are back in your
main break loop.

Date: 20 MAR 1981 0104-EST
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG LISP) at MIT-MC

When I do the following:

(break foo)
;BKPT FOO
(error)I wait forever right here.

what's going on when I do this?

Date: 19 March 1981 21:33-EST
From: Kent M. Pitman <KMP at MIT-MC>
To: GSB at MIT-ML
cc: BUG-LISP at MIT-MC, RWK at MIT-MC

    Date: 19 March 1981 09:43-EST
    From: Glenn S. Burke <GSB at MIT-ML>

        Date: 18 March 1981 20:23-EST
        From: Robert W. Kerns <RWK at MIT-MC>

            Date: 23 December 1979 04:13-EST
            From: Kent M. Pitman <KMP at MIT-MC>
	    (SSTATUS TERPRI...) also still loses for SFA's.
	    Can we have that ask the SFA, too since it may be
	    a TTY driver. Tnx. -kmp
	Isn't SSTATUS TERPRI obsolete anyway?
    It is only obsolete if you are willing to claim that ...
-----
Also, at the time that the bug note was sent, GRINDEF FASL
still did a (SSTATUS TERPRI) as it loaded, causing disaster
if TYI/TYO contained an SFA instead of its default fileobject.
I think, however, that we should support this call on SFA's
so that if other code makes assumptions about the FILEness
of TYI/TYO, people will not lose.

Date: 19 March 1981 09:43-EST
From: Glenn S. Burke <GSB at MIT-ML>
To: RWK at MIT-MC
cc: KMP at MIT-MC, BUG-LISP at MIT-MC

    Date: 18 March 1981 20:23-EST
    From: Robert W. Kerns <RWK at MIT-MC>
        Date: 23 December 1979 04:13-EST
        From: Kent M. Pitman <KMP at MIT-MC>
        (SSTATUS TERPRI...) also still loses for SFA's. Can we have that
	ask the SFA, too since it may be a TTY driver. Tnx. -kmp
    Isn't SSTATUS TERPRI obsolete anyway?
It is only obsolete if you are willing to claim that the same flag which
drives TYO level auto-newline insertion should also drive PRIN1 attempting
to make the output readable (which does NOT need to imply breaking atoms
across lines), AND if you are willing to claim that a per-stream flag
such as this is losing in "winning new io".  As i remember it, the io
code in lisp understands the bit represented by this flag in all types
of file arrays.  (status terpri) should be allowed for all kinds of
streams, should be on by default, and should not affect PRIN1 putting
line breaks BETWEEN atoms.


Date: 19 MAR 1981 0847-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

I have a dumped-out system made by CPL;SANDER (INIT) on top of MACLISP.
After it processes a file it gets a

PURPG; 20713>>MOVEM 11,@70021

error if the had given up the TTY by ^Z and ^P.


Date: 19 MAR 1981 0451-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

The argument to IO-LOSSAGE is a loser. (OPEN "NOTA FILE") gives
'(OPEN "NOTA FILE") yet (TYI TYO) gives #FILE-OUT-TTY-8235476.
If it could give '(TYI #FILE-OUT-TTY-8768976) it would be
great. Presumably since all these I/O functions can handle
the SFA call it would be easy for them to fall through
consistently when calling io-lossage error.


Date: 18 March 1981 20:41-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: y-or-n-p, yes-or-no-p
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 5 March 1981 21:17-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Subject: y-or-n-p, yes-or-no-p
    To: BUG-LISP at MIT-MC
    
    Why does y-or-n-p REQUIRE that I supply an argument?  I would think that
    it was completely clear what I want if I just call it with no arguments.
LISP had the wrong built-in ARGS property.  Fixed and patched.
    Why doesn't yes-or-no-p go to the trouble to strip leading and trailing
    spaces from what the user types?
It will now.

Date: 18 March 1981 20:23-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: KMP at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 23 December 1979 04:13-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    To:   BUG-LISP
    
    (SSTATUS TERPRI...) also still loses for SFA's. Can we have that ask the
    SFA, too since it may be a TTY driver. Tnx. -kmp
Isn't SSTATUS TERPRI obsolete anyway?

Date: 18 March 1981 18:23-EST
From: Jonathan A. Rees <JAR at MIT-MC>
Subject:  (STATUS SITE) - ?!
To: BUG-LISP at MIT-MC

In Maclisp 2088 on XX, (STATUS SITE) seems to return some random
S-expression recently consed by LOAD or FASLOAD rather than the
symbol.  (By the way, a conceivable feature might be to allow (SSTATUS
SITE foo) if (STATUS SITE) is TOPS-20 or some other meaningless value.)

Date: 18 March 1981 0222-EST (Wednesday)
From: Guy.Steele at CMU-10A
To: Earl A. Killian <EAK at MIT-MC> 
Subject:  Re: FIXing functions
CC: info-lispm at MIT-AI, bug-lisp at MIT-MC
In-Reply-To:  Earl A. Killian's message of 17 Mar 81 18:31-EST
Message-Id: <18Mar81 022249 GS70@CMU-10A>

EAK has pointed out a bug: (CEIL 4.5 2) => 3  -1.5, not 3  0.5.

Date: 17 MAR 1981 1816-EST
From: JONL at MIT-MC (Jon L White)
Subject: SEND loses again
To: (BUG LISP) at MIT-MC

(SEND query-io ':PRINT-SELF) ==>
  MPV at PRIN3A+1
In *RSET mode, it ought not to die like this.

Date: 17 March 1981 1603-EST (Tuesday)
From: Guy.Steele at CMU-10A
To: info-lispm at MIT-AI
Subject:  FIXing functions
CC: bug-lisp at MIT-MC
Message-Id: <17Mar81 160322 GS70@CMU-10A>

(In the following note, I will let "FX" mean "any one of
FLOOR, CEIL, TRUNC, or ROUND".)

I strongly support the idea that the FIXing functions
return two values: quotient and remainder.  These are not hard
to compile if they are appropriately special-cased.
The compiler can easily tell what is going on in such
situations as:
	(FX Z)
	(FX Z Y)
	(MULTIPLE-VALUE (Q R) (FX Z))
	(MULTIPLE-VALUE (() R) (FX Z))		;i.e., MOD or REMAINDER
and generate appropriate code for each.

To be more precise, it seems to me that the type of the second result
should be floating if either argument is, and an integer if both
arguments are integers.  Also, the one-argument case is exactly the same
as specifying a second argument of 1; hence an appropriate
description of the function is (DEFUN FX (X &OPTIONAL (Y 1)) ...).
Finally, the results Q and R are such that X=Q*Y+R, modulo any
floating-point inaccuracies.

Hence we have the following examples:
		Results
Argument(s)	FLOOR		CEIL		TRUNC		ROUND
4.5		4  0.5		5  -0.5		4  0.5		4  0.5
4.5  2		2  0.5		3  -0.5		2  0.5		2  0.5
7.0  2		3  1.0		4  -1.0		3  1.0		4  -1.0
7  2		3  1		4  -1		3  1		4  -1
7  2.3		3  0.1		4  -2.2		3  0.1		3  0.1
7.5  2.3	3  0.6		4  -1.7		3  0.6		3  0.6
9		9  0		9  0		9  0		9  0
Implementationally it is convenient to break this down into a number
of cases.  Semantically I believe this is the most useful definition.

--Guy

Date: 17 MAR 1981 1631-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

I can't figure out how to declare so that the subr object
made by (DEFUN (FOOBAR FOO-EXP FOO-SUBR) ...) is
SUBRCALL FLONUMable.

Date: 17 March 1981 1500-EST (Tuesday)
From: Guy.Steele at CMU-10A
To: GJC at MIT-MC (George J. Carrette)
Subject:  GLEEP!
CC: jpg at MIT-MC, bug-lisp at MIT-MC
In-Reply-To:  GJC@MIT-MC's message of 17 Mar 81 02:08-EST
Message-Id: <17Mar81 150054 GS70@CMU-10A>

Maybe you meant the GLS AI memo (420)?  Probably you
got the "L" backwards, turning it into a "J"?  Oh well.

Date: 17 MAR 1981 0224-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: GLEEP!
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC

I really messed up that last message, the AI memo in question
is by GLS of course, not GJS.

Date: 17 MAR 1981 0208-EST
From: GJC at MIT-MC (George J. Carrette)
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC

I was just looking in your old file of lisp bugs. Saw the note
about the "GLEEP! OUT OF BIT BLOCKS" so-called error message.
I'm not sure if you got a good reply to this, certainly the
error message has not changed. There is a very good explaination
of this in GJS AI memo on internal representation in maclisp.
It should say "GC ERROR #23 see AI MEMO #..."

Are these memos (e.g. memo #421 too) on line?

Suggestion: Every Maclisp Tape sent out should have these memo's with
them. They really get to the point, and should be part of the
maclisp documentation.


Date: 16 MAR 1981 2244-EST
From: JONL at MIT-MC (Jon L White)
Subject:  *RSET -> bug introduction
To: RWK at MIT-MC
CC: WGD at MIT-MC, (BUG LISP) at MIT-MC

    Date: 15 March 1981 22:34-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    JONL, your recent change to ERRCK broke almost the entire
    extended LISP system, including VECTOR, DEFVST, and FORMAT.
    I have de-installed your change.
Actually, the change to ERRCK was right;  several other files
had bugs in them, but VECTOR, DEFVST, and FORMAT weren't among
them(!!).   SUBSEQ was one that had a bug whose manifestation
was formerly inconsequential, until I fixed the defaulting problem 
with ERRCK, as per report by BIL:
    Date: 15 March 1981 01:15-EST
    From: William G. Dubuque <WGD at MIT-MC>
	    SI:REPLACER is broken in te current version of SUBSEQ.
    (TO-VECTOR '(1 2)) => #(), likewise for TO-LIST, etc. .  .
I've fixed SUBSEQ, and several other files which used the
function SI:CHECK-SUBSEQUENCER in ERRCK.  The difficulty arose
because CHECK-SUBSEQUENCER etc weren't documented, and there were
inconsistent usages of it among the several files.  I've put documentation 
for it into NIL;NEWFUN >  under section 2.6.


DICK@MIT-ML 03/16/81 13:43:04
To: GSB at MIT-ML, (BUG LISP) at MIT-ML

	with regard to my problem with wanting more MOREs.  GSB
had the essence of the solution.  all you have to do is
do a (cursopos 'T) and then another one to get you back to
where you want to be before you start the output.  This makes
DDT think that it should always cause more interrupts.

			Dick Waters


Date: 16 MAR 1981 1214-EST
From: JONL at MIT-MC (Jon L White)
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC, MACSYMA-I at MIT-MC
CC: MULTICS-LISP-PEOPLE at MIT-MC

Carl Hoffman wants to get the functionaliy of the MacLISP/NIL 
DEFMACRO into Multics, without having to add any new switches 
(such as DEFMACRO-FOR-COMPILING etc) to the Multics MacLISP 
compiler -- as an accommodation to a style of compiler usage 
whereby the user "pretends" that the switch MACROS is to take 
over the functionality of DEFMACRO-FOR-COMPILING, I've changed 
the two occurrences of this latter switch in the DEFMACRO source
file into
    (cond ((boundp 'DEFMACRO-FOR-COMPILING)
	    DEFMACRO-FOR-COMPILING)
	  ((status FEATURE COMPLR)
	    MACROS)
	  ('T))
The normal state in the PDP10 MacLISP world is that 
DEFMACRO-FOR-COMPILING is set to 'T (even in non-COMPLR lisps), and 
MACROS is defaultly (); just the opposite case would apparently obtain 
under Multics, that is DEFMACRO-FOR-COMPILING would be unbound, and 
MACROS would be T.   So, this way, in the PDP10 MacLISP world, if a user 
has a files of code which don't actually SETQ the switch 
DEFMACRO-FOR-COMPILING, then he do (MAKUNBOUND 'DEFMACRO-FOR-COMPILING) 
[possibly in a COMPLR INIT file] and let this switch meaning operate the 
way CWH will have it do under Multics.

Date: 16 MAR 1981 1157-EST
From: JONL at MIT-MC (Jon L White)
Subject: When FORMAT is autoloaded by CERROR
To: RWK at MIT-MC, GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

I don'tknow if I  remember sending a bug-note about this, but
generally you'd see

;Loading FORMAT 672-1 Does not pass the MUMBLE test ...

instead of 
;Loading FORMAT 672
-1 Does not pass the MUMBLE test ...

I've just fixed it now, by having CERROR explicity do +INTERNAL-TRY-AUTOLOADP
when the value of CERROR-PRINTER is a non-fboundp symbol.

Date: 16 MAR 1981 0846-EST
From: JONL at MIT-MC (Jon L White)
Subject: haumany PURQIO's?
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 15 March 1981 01:02-EST
    From: David A. Moon <MOON5 at MIT-AI>
    Do there really need to be five version of PURQIO on AI:SYS; ?
Apparently so -- All 5 of them have recent reference dates.  
LISP;LOCK > shows that 4 of them are tied down by dumpd-out systems,
and apparently someone is actually using version 1997 without
"lock"ing it.  Unfortunately, the two earliest versions are being
"lock"ed by dumps made by persons long gone, and thus there seems
to be little hope of getting them re-dumped in the current lisp.
It appears from reference dates on those specific dump files that
they are being used now and then by someone (uses of LAMORD and 
DIRECT were seen in Feb 1981).  When they go by the wayside,
then maybe then can be moved to tape, and the consequent (directory)
space reclaimed on the AI:SYS; directory.  
   Some time ago, I moved some unlikely stuff of AI:SYS;, and sent
notes to appropriate persons/mailing-lists.  RMS/RWK pointed out
that one of the files so moved should stay on SYS;.  But we can
still keep looking for things to put on other directories.

Date: 16 March 1981 08:07-EST
From: Jerry Roylance <GLR at MIT-AI>
To: BUG-LISP at MIT-AI


SORT does not work on numeric arrays!

(sort (*array nil 'fixnum 10) '<)

gives NIL NON-NUMERIC VALUE error.  < thinks
its been given (< NIL NIL)



GSB@MIT-ML 03/16/81 04:54:11 Re: mmcdrside/|
To: (BUG LISP) at MIT-ML
hmmm, the claim seems to be that INTERN has no side effects...


Date: 15 MAR 1981 2234-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: *RSET -> bug introduction
To: (BUG LISP) at MIT-MC

JONL, your recent change to ERRCK broke almost the entire
extended LISP system, including VECTOR, DEFVST, and FORMAT.
I have de-installed your change.  Please fix and TEST
before re-installing.

Date: 15 MAR 1981 2125-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: #() and SPRINTER
To: (BUG LISP) at MIT-MC

SPRINTER seems to print #() as #NIL, which is rather confusing and wrong.

Date: 15 March 1981 17:39-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Where more interrupts occur
To: DICK at MIT-ML
cc: BUG-LISP at MIT-ML, GSB at MIT-ML

This is a feature of ITS. Jobs get an interrupt when a --More-- interruptis appropriate. The rules for when this is appropriate are not user-settable.
Complain to BUG-ITS I guess, but it's highly unlikely that they will do 
anything as most of the time what it does right now is the right thing.



DICK@MIT-ML 03/15/81 15:58:00
To: GSB at MIT-ML, (BUG LISP) at MIT-ML

	It seems to be the case in maclisp that if I initiate a process
which does printing (a call on print, or on some program that does prints)
7 or more lines from the bottom of the screen, the results will be interupted
by more processing (if they take more than 7 lines).  However, if I am closer 
to the bottom than that when I start, there will not be a more until the ouput
goes all the way around the screen, and hits the bottom a second time.
I am using the system end page fn.
	Two questins:  first, is this a well known phenomenon, or am I doing
something strange that has broken my lisp. (I did test that this happens in
a simple lisp (version 2077) loaded without my init file or anything.)
	Second, if this is a standard feature, is there anyway to turn it
off.  I would like to see a more if I started printing anywhere except
perhaps the very last line.  If there is no way to control this then
I think that is a bug.  I appreciate the fact that DDT has a lot to do with 
this, so that maybe there is nothing that can be done.
			Dick Waters


Date: 15 March 1981 15:04-EST
From: Jerry Roylance <GLR at MIT-AI>
To: BUG-LISP at MIT-AI

Ooops, examine isn't as clear as I thought.  That example
(examine '(a . b)) should return b.  Maybe I should just forget
the whole thing.



Date: 15 March 1981 15:01-EST
From: Jerry Roylance <GLR at MIT-AI>
To: BUG-LISP at MIT-AI

Why doesn't EXAMINE take sexps? (examine '(a . b)) should
return a fixnum whose value is the same as the cons cell.


Date: 15 March 1981 01:02-EST
From: David A. Moon <MOON5 at MIT-AI>
To: BUG-LISP at MIT-AI

Do there really need to be five version of PURQIO on AI:SYS; ?

Date: 15 MAR 1981 0016-EST
From: JONL at MIT-MC (Jon L White)
To: ALAN at MIT-MC, DLA at MIT-EECS
CC: (BUG LISP) at MIT-MC, INFO-LISPM at MIT-MC

    Date: 14 March 1981 00:36-EST
    From: Alan Bawden <ALAN at MIT-MC>
	Date: 14 Mar 1981 0007-EST
	From: David L. Andre <DLA at MIT-EECS>
	Is it possible to get, in a single operation, both the quotient and
	remainder in a fixnum division?  I have often wanted to do something
	like:
	(MULTIPLE-VALUE (QUO REM)
	  (FLOOR A B))
    So have I.  Unfortunately it is rather difficult to get this to work
    since arithmetic is performed in microcode, and it is difficult to get
    multiple values out from microcode. .  .  .
I can appreciate your comments about how the hardware loses -- the IBM370
produces a floating-division result much like the PDP-10 FDVL instruction,
and then proceeds to round according to its own fixed rule.  During my
time working for there, I needed to experiment with some alternate
rounding schemes, and was chagrin'd to discover that there was no
way to get the "remainder" part out of the "internal" registers and
into a place where the  macro-code instructions could access it.
  foo.
  I've implemented some internal fixnum functions for NIL, so that 
generic arithemetic can be fully-implemented in LISP -- basically they
represent the four rational operations as implemented by most 2's-
complement computers.  For a real NIL, the compiler is open-coding them 
"by special discernment", rather than by doing a multiple-value-returning
function call; so it only is a matter of being able to get at all the bits 
implicit in the two results.  I've coded up this stuff for the PDP10 too, 
but the COMPLR doesn't open-compile these funs; rather, it calls some
quick, handy little LAP subrs.  Below is reproduced the documentation on 
them from file  MC:NIL;NEWFUN >

SI:FULLADD  (SI:FULLADD x y carry_in) ==> [sum.x+y+carry_in, carry_out]
SI:FULLSUB  (SI:FULLSUB x y carry_in) ==> [difference.x-y+carry_in, carry_out]
  Where the sum and difference indicated are two's complement results,
  and the "carry"s are all restricted to -1, 0 and +1.  Since true
  integer addition cannot be restricted to a finite range, there must be
  "wrap-around" even in these functions.  Thus, let n+1 be the number
  of bits in the FIXNUM (two's-complement) representation;  then
	mx  :==   2^n - 1	;maximum representible (positive) FIXNUM
	mnx :==  -2^n	 	;minimum representible (negative) FIXNUM
  Then both (SI:FULLADD mnx mnx -1) and (SI:FULLSUB mx mnx 1) will
  "wrap-around" (i.e., "overflow").  Thus a fail-safe, but slightly
  pessimistic, test for "overflow" is merely to test the second argument
  for being equal to "mnx".   Happily, the most important system
  usages of these two have an explicit 0 carry_in, but at a few places
  in the BIGNUM implementation they require the full generality.
SI:FULLMUL  (SI:FULLMUL x y carry_in) ==> let productsum == x*y+carry_in
		[productsum.rem.by.2^n,  productsum.div.by.2^n]
  Note that if both x and y are equal to "mnx" as described above, the
  the result will "overflow".
SI:FULLDIV  (SI:FULLDIV low hi divsr) ==> [quotient, remainder]
  The division indicated is  (hi*2^n+low)/divsr


Date: 14 MAR 1981 1433-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Traceing a function which returns multiple values
doesn't do a lot of good.

Date: 14 March 1981 03:05-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: Query about proposed slight change to FIX and FIXR functions (again)
To: MOON at MIT-MC
cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, RWG at MIT-MC

Basically I am happy with the proposal.

Presumably part of the idea here is that FLOOR and ROUND are just plain
better names than FIX and FIXR, so we are adding them instead of just
using the names FIX and FIXR.  In this case, I agree with your decision,
since these names are well-known and have well-understood meanings,
throughout the world of computers.

Using "F" as a prefix to mean "Floating point" as distinct from "Fixed
point" is not the most unambiguous thing in the whole world; it reminds
me of "MMCALL" and suchlike.  If anyone can think of anything better,
please suggest it.  The only thing I can think of is a trailing dollar
sign, whose only virtue is the Maclisp precedent, since we don't use
it anywhere in the Lisp Machine except in Maclisp compatibility functions.
But if nobody comes up with a better alternative, I think it is acceptable.

Date: 14 Mar 1981 0007-EST
From: David L. Andre <DLA at MIT-EECS>
Subject: Re: P.S. to previous message
To: MOON at MIT-MC
cc: info-lispm at MIT-AI, (BUG LISP) at MIT-MC, DLA at MIT-EECS
In-Reply-To: Your message of 13-Mar-81 1803-EST

Is it possible to get, in a single operation, both the quotient and
remainder in a fixnum division?  I have often wanted to do something
like:

(MULTIPLE-VALUE (QUO REM)
  (FLOOR A B))

but have had to do 2 separate operations, which I assume is more time
consuming.  As long as these new functions are being installed, and if
the overhead isn't too much, could this be put on all forms of
division which entail any sort of truncation?

		-- Dave
-------

MOON@MIT-MC 03/13/81 16:51:16 Re: Query about proposed slight change to FIX and FIXR functions (again)
To: info-lispm at MIT-AI
CC: RWG at MIT-MC, (BUG LISP) at MIT-AI
Thank you all for your responses.  Here is a new proposal which will go in
unless anyone objects (I'm not sure how soon, not immediately, although
it may get put into the manual immediately).

We leave FIX the same, change FIXR to round to nearest rather than adding
0.5 and calling FIX, and add eight new functions(!):
	FLOOR = convert flonum to integer, rounding toward -inf
	CEIL = convert flonum to integer, rounding toward +inf
	TRUNC = convert flonum to integer, rounding toward zero
	ROUND = convert flonum to integer, rounding to nearest integer,
		and to an even integer in the event of a tie.
	FFLOOR, FCEIL, FTRUNC, and FROUND are the same except that their
	result is a flonum rather than an integer.

The first four functions are subject to overflow; however they probably
are not guaranteed always to return a fixnum, rather it is implementation
dependent what is the largest integer they will return, and given a number
larger than that they may overflow.  The second four functions can never
signal an error.

FIX is identical to FLOOR.  FIXR will be changed to be identical to ROUND
(unless there is sentiment for leaving FIXR the way it is).

This proposal is compatible with IEEE standard floating point, which
requires that at least TRUNC, ROUND, FTRUNC, and FROUND exist, and recommends
the others, but does not suggest names for any of the operations.

Since this proposal does not involve any changes to FIX, it will be
upward compatible with Maclisp.  Is there any interest in adding these
other functions to Maclisp?  The DPL people (at least) would use 
(some of) them.


Date: 13 MAR 1981 1732-EST
From: MOON at MIT-MC (David A. Moon)
Subject: P.S. to previous message
To: info-lispm at MIT-AI
CC: (BUG LISP) at MIT-MC

Sorry, I left a couple things out of that message.

FLOOR, CEIL, etc. will accept one or two arguments.  With one argument
they will behave as described in the previous message.  With two arguments,
they will first take the quotient of arg1 divided by arg2 then round the
result accordingly.

QUOTIENT of two arguments is identical to TRUNC of two arguments.
REMAINDER is the corresponding remainder.

I will add a ninth new function, MOD, which is the remainder that
goes with the FLOOR form of division.

Except for exact division, this seems consistent with the discussion of
division of a couple months ago, factoring out the slash-backslash issue.
Exact division really requires rational numbers as a datatype, although
some people have proposed a half-measure which uses flonums to simulate
rationals.  This isn't such a win since arithmetic on such a quotient will
then never turn back into an integer.  I propose to defer exact division.

Date: 13 MAR 1981 0838-EST
From: JONL at MIT-MC (Jon L White)
Subject: Movement away from L
To: (BUG LISP) at MIT-MC

Three little MacLISP auxillaries have just been moved from off L
directory onto LSPSRC -- "edit", "sort", and "straux".  Now, except
for a few ITS-specific files, L contains just the files which
are "included" in a MIDAS assembly of the system.

Date: 13 MAR 1981 0749-EST
From: JONL at MIT-MC (Jon L White)
Subject: Movement away from COMLAP
To: (BUG LISP) at MIT-MC

On the MC machine, the sources for GRIND (GFN >) and GRINDEF (GFILE >)
have been moved to the LSPSRC directory, from off the COMLAP directory.
Also, this applies to TRACE and LAP.  On the AI machine, the COMLAP
directory has already gone away, and eventually that will happen on ML.
Sources for the LISP-written parts will henceforward be primarily on
the MC machine on the LSPSRC; COMLAP; and NILCOM; directories.

Date: 12 March 1981 15:39-EST
From: George J. Carrette <GJC at MIT-MC>
Subject:  Query about proposed slight change to FIX and FIXR functions
To: Moon at MIT-AI
cc: INFO-LISPM at MIT-MC, BUG-LISP at MIT-AI, RWG at MIT-AI

A general comment. I have seen the following catch-phrase in many
lisp and Lispm notes:

    Date: 11 MAR 1981 1758-EST
    From: Moon at MIT-AI (David A. Moon)

    ... exists in Maclisp and its functionality
    may be dictated by the way particular pdp-10 instructions work.
    ...

Frankly it bothers me, and although I feel funny addressing it to
people who are more expert than myself in such things as the pdp-10,
I think I must address it as an issue of intellectual honesty.
(0) many pdp-10 arithmetic instructions are usefull, even if they
    are "simple" and don't have "error checking."
(1) the phrase "may be dictated" considerably weakens the statement.
(2) Because of "1" the reader may be tempted to see an attempt
    at arguing against the "FIX" function via the effective technique
    of "guilt by association" with Maclisp.

In other words, can't we just let Maclisp RIP?

-gjc

I realize I say this at the risk of creating yet another catch-phrase
based on "guilt by association" with GJC.


Date: 12 MAR 1981 1409-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

(defun foo (x) (subrcall nil '#,(get 'car 'subr) x))

when compiled gives the error 
"The function pointer can't be right in function FOO"

(defun foo (x) (subrcall nil #,(get 'car 'subr) x))

gives code which is twice as big as needed

      (JRST 0 @ G0001)
G0001 (0 0 '(-SQUID- . (GET 'CAR 'SUBR)))

instead of (JRST 0 '(-SQUID- . (GET 'CAR 'SUBR)))

It would be nice to be able to generate

(JRST 0 @ '(-SQUID- . (FROBULATE))) also.

The idea is that since the maclisp compiler gives so little
real error checking and user protection anyway, you might
as well be able to go for all the gusto you can get.


Date: 12 MAR 1981 1128-EST
From: JONL at MIT-MC (Jon L White)
Subject: LISTARRAY
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 28 January 1981 04:37-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    Subject: Bugs in LISTARRAY with 2 args
    In a bare lisp,
     (SETQ A (*ARRAY NIL T 100)) => #T-100-70776
     (LISTARRAY A 1)             => NIL
[I think you meant to say "=> (NIL)" here]
     (LISTARRAY A 0)	     => MPV;LISTA1>>HRRZ B,@A(C)  B/ 0  530157/ ??
    In a new bare lisp,
     (SETQ A (*ARRAY NIL 'FIXNUM 100)) => #T-100-70776
     (LISTARRAY A 1)		   => (0)
     (LISTARRAY A 0)		   => (100)
    Both of these behaviors seem a bit silly. I would like VERY much if 
    (LISTARRAY array n) for n=0 returned NIL. It is otherwise much less useful
    than it might be. (n=-1 seems to get the whole array.)
Fixed, by editing sources and patching current LISP (version 2077)
LISTARRAY with 2nd arg of 0 now returns (); a negative 2nd arg has always
meant to list "all" elements.

Date: 12 MAR 1981 1055-EST
From: JONL at MIT-MC (Jon L White)
Subject: PURCOPY of an array
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

    GSB@MIT-ML 08/04/80 23:59:21 Re: hard times are a way of life
    purcopying an array sets the AS.FL bit in the asar rather than the TTS.CN
    bit in the ttsar.  I thought this had been fixed long ago.
I've just now edited the correction for this into the source, and patched
it in MC:LSPDMP;BBLISP 077QIO -- will be installed "soon" in the system
LISP.

Date: 12 MAR 1981 0902-EST
From: JONL at MIT-MC (Jon L White)
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

    GSB@MIT-ML 02/17/81 20:52:16 Re: features vs. bugs
    (1)   (ALPHALESSP 'A NIL) => NIL
    (2)   The rubout code is still going up one line too many when you rub out
	  line wraparound. . . .
These two are now fixed, and patched in current LISP.

Date: 11 March 1981 22:43-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Query about proposed slight change to FIX and FIXR functions
To: MOON at MIT-AI
cc: BUG-LISP at MIT-AI, RWG at MIT-AI, BUG-LISPM at MIT-AI

I think we should have all of the forms of rounding under some name
(although the idea of adding more three and four character names to
GLOBAL does not turn me on incredibly).  You might want any of them.
(If the S-1 can have sixteen rounding modes, surely we're entitles to
four rounding functions...)  Changing FIX sounds likely to hurt Macsyma
and other user programs.


Date: 11 March 1981 2220-EST (Wednesday)
From: Guy.Steele at CMU-10A
To: David A. Moon <Moon at MIT-AI> 
Subject:  Re: Query about proposed slight change to FIX and FIXR functions
CC: info-lispm at MIT-AI, bug-lisp at MIT-AI, rwg at MIT-AI,
    Scott.Fahlman at CMU-10A
In-Reply-To:  David A. Moon's message of 11 Mar 81 17:58-EST
Message-Id: <11Mar81 222051 GS70@CMU-10A>

[Why wasn't this just sent to LISP-FORUM??]

FIX isn't ridiculous -- it's just incompatible with FORTRAN
(but compatible with ALGOL and a few others).  WHat FIX should
do is very closely related to what integer division, remainder,
modulus, and arithmetic shift should do.  Think about it this way:
FIX divides the argument n by 1, producing integer quotient q and
a remainder r (which will be fractional); it then returns q.
If the remainder has the same sign as the dividend (true remainder),
then FIX rounds towards zero.  If it has the same sign as the divisor
(in this case, always positive), i.e., the remainder is actually a MOD
operation, then FIX rounds towards minus infinity.

Rather than change FIX incompatibly and potentially breaking programs,
I urge that the names FLOOR, CEILING, TRUNC, and ROUND be introduced,
to perform rounding towards minus infinity, plus infinity, zero,
and nearest integer, respectively.  I would be inclined simply not to guarantee
the behavior of ROUND on half-integers, leaving it to the implementation
to decide whether to round up or down; but I am not adamant on this point.

The point of these names is that various languages use the term FIX in
incompatible ways; but the four names proposed are never used for other
than the meanings I have described, and so leave the programmer in no
state of doubt as to what is going on.
--Guy


Date: 11 March 1981 22:11-EST
From: Glenn S. Burke <GSB at MIT-ML>
To: RLB at MIT-MC, BUG-LISP at MIT-MC
cc: PSZ at MIT-ML

    Date: 11 MAR 1981 2111-EST
    From: RLB at MIT-MC (Richard L. Bryan)
    A defmethod* for CALL messages to  SUBR-CLASS lets me funcall the 
    result of FSYMEVAL (the latter defined by FUNCEL). This is a win.
    However, an attempt to APPLY such a frob loses, with 
    UNDEFINED FUNCTION OBJECT.
Hmmm, the brand-x interpreter in the current lisp seems to suffer
from the same lossage, with the same manifestations that i remember
jonl and i fixing some time ago.  In fact, it seems that i no longer
have a dump in a lisp in which this works.


Date: 11 MAR 1981 2140-EST
From: CFFK at MIT-MC (Charles F. F. Karney)
Subject: TOPS10 Lisp #2022.
To: (BUG LISP) at MIT-MC

Use of the LET macro gives an Illegal UUO.

Date: 11 MAR 1981 2125-EST
From: GSB at MIT-MC (Glenn S. Burke)
Subject: sharpsign loses
To: (BUG LISP) at MIT-MC

i fixed a fencepost error in *read-token in the source,
could someone install it?  the source i edited was more recent than
the current installation

Date: 11 MAR 1981 2111-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

A defmethod* for CALL messages to  SUBR-CLASS lets me funcall the 
result of FSYMEVAL (the latter defined by FUNCEL). This is a win.
However, an attempt to APPLY such a frob loses, with 
UNDEFINED FUNCTION OBJECT.

Date: 11 March 1981 17:58-EST
From: David A. Moon <Moon at MIT-AI>
Subject: Query about proposed slight change to FIX and FIXR functions
To: INFO-LISPM at MIT-AI, BUG-LISP at MIT-AI
cc: RWG at MIT-AI

While editing the manual, I noticed that the FIX and FIXR functions round
in a ridiculous fashion.  FIX truncates towards negative infinity,
rather than towards zero (i.e. (FIX -1.5) is -2 rather than -1).  This may
be hard to change since this function exists in Maclisp and its functionality
may be dictated by the way particular pdp-10 instructions work.  FIXR adds
0.5 and then does FIX.  (FIXR does not exist in Maclisp.)

I would like to propose that FIX be changed to truncate towards zero rather
than negative infinity, and that FIXR be changed to round stably as all the
rest of the floating-point operations do.  To elucidate:
	Operation	Now yields	Proposed to yield
	(fixr 1.5)	2		2
	(fixr 2.5)	3		2
	(fixr -1.5)	-1		-2
	(fixr -2.5)	-2		-2
	(fix -1.5)	-2		-1

Any comments?  Change FIXR but not FIX?


Date: 11 March 1981 16:29-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  #+ ... vs (IF-FOR-LISPM ...), etc.
To: CWH at MIT-MC, GJS at MIT-AI
cc: BUG-LISP at MIT-MC

Yes, indeed, one can sure get confused about when he is at DDT and when
he is lmsend and such ... sigh. Please ignore my last message. I hadn't
meant to send it in the first place.

Date: 11 March 1981 14:54-EST
From: Ronald L. Rivest <RIVEST at MIT-AI>
To: BUG-LISP at MIT-AI

I think I have a lisp compiler bug... I can demonstrate some
difference in behavior between the interpreted and compiled versions
of the same code that I can't explain any other way.  
	Can someone come to see this? (It's a bit complicated...)
	Thanks
	Ron


Date: 11 MAR 1981 1418-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: #+ ... vs (IF-FOR-LISPM ...), etc.
To: GJS at MIT-MC, CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

Consider some function, f, which on LispM takes an additional arg
over what it does in Maclisp. :lmsend daniel@cadr2
yup. i have it on about 80 ...

Date: 11 March 1981 02:57-EST
From: Carl W. Hoffman <CWH at MIT-MC>
To: GJS at MIT-MC, BUG-LISP at MIT-MC

    Date: 9 March 1981 23:51-EST
    From: Gerald Jay Sussman <GJS at MIT-AI>

    The macros IF-FOR-LISPM and IF-FOR-MACLISP and IF-FOR-MACLISP-ELSE-LISPM
    ought to be defined by default in Maclisp just as on the Lisp machine.
    I don't want to use the #M and #Q because they are not Lisp-like.

The # macro is as Lisp-like as ' ` or ,.  Often, it describes some read-time
action to the following form, e.g. wrapping a (FUNCTION ...) around it,
reading it with certain global state modified, or making the form disappear
entirely.

Use of IF-FOR-LISPM and IF-FOR-MACLISP is discouraged:
1) They assume that the only conditionalizations you would want to make are
   for the Lisp Machine and MacLisp.  They are not extensible in any way.
2) They can only appear in a place where the compiler will do macro
   expansion.

The encouraged replacement is #+Lispm and #+MacLisp, which are newer forms
of #Q and #M.  #+<condition> <form> is read as <form> if (status feature
<condition>) is true.  Otherwise, <form> disappears entirely.  Thus, one can
do #+NIL, #+Franz, #+SchemeChip, etc. for conditionalizing code which must
run many different places, without having to create new constructs and
add them to every Lisp implementation around.

*** Note Well ***  I am not encouraging free and indiscriminant use of this
construct.  I don't consider it in any way elegant or an integral part of
Lisp.  It is simply an unfortunate engineering necessity needed to make
programs run in many different places.

In general, one uses #+ at the very beginning of one's code to set up
program-specific macros which are then used further on.  E.g.:

(defmacro symbol-definition (symbol)
	  #+MacLisp	`(cadr (getl ,symbol '(expr subr lsubr)))
	  #+Lispm	`(fsymeval ,symbol)
	  #+Franz	`(getd ,symbol))

Then the rest of your code would be written in terms of the
"symbol-definition" macro, and you must endure the # ugliness only once.
MC:ALAN;NSTRUCT is a good example of a large program conditionalized in
this fashion.  It implements the Lisp Machine defstruct macro, runs in
three separate Lisp implementations, and is used heavily in all three.

Date: 10 MAR 1981 1806-EST
From: CFFK at MIT-MC (Charles F. F. Karney)
Subject: TOPS10 Lisp V. 2022 (Running at Princeton).
To: (BUG LISP) at MIT-MC

[1] (fillarray <array> <fixnum file>) ==> Halt at user PC...
[2] (in <fixnum file>) hangs forever at the end of the file.
[3] (status jcl) doesn't work.  (This can be done with a TTMODE
call or something.)
[4] ALLFILES and friends bomb.  Should I expect them to work?
(I want to find the length of a file.)

Date: 10 March 1981 12:41-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  IF-FOR-LISPM and friends
To: BUG-LISP at MIT-MC
cc: GJS at MIT-AI

I agree with GJS's suggestion that these be provided primitively.

Date: 10 MAR 1981 0025-EST
From: JAR at MIT-MC (Jonathan A. Rees)
Subject: (OPEN 'TTY:) on Twenex
To: (BUG LISP) at MIT-MC

Due to a Twenex bug, this actually gets the terminal itself rather than
the terminal or PTY which is the process's primary input.  It would
be nice if Maclisp fixed this for the user - this can be done using
the SCTTY JSYS; it returns either 777777 which means you can open
TTY: or it returns 400xxx which means you should open TTYxxx:.  This
is what I'm doing currently although there might be a cleaner means,
like using JFN 101 or whatever.  Also DEC might get around to fixing it.
In the meantime any help is appreciated... thanx.

Date: 9 March 1981 23:51-EST
From: Gerald Jay Sussman <GJS at MIT-AI>
To: BUG-LISP at MIT-AI

The macros IF-FOR-LISPM and IF-FOR-MACLISP and IF-FOR-MACLISP-ELSE-LISPM
ought to be defined by default in Maclisp just as on the Lisp machine.
I don't want to use the #M and #Q because they are not Lisp-like.


Date:  9 MAR 1981 2318-EST
From: JAR at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC

The file JSYS-TBL.LSP on the Twenex Maclisp release tape has the following
cute mistake in it:
(eval-when (eval load compile)
	   (setq oibase ibase ibase 8.)
	   (setq frob1 127)  ...  ;Octal 127 intended
)
The (setq ibase 8) ought to be in a separate top-level-read-able form,
obviously, from the following setq's, or else the #o notation should
be used.
Did the #o(17 362 foo) bug ever get fixed?

Date:  9 MAR 1981 1911-EST
From: GSB at MIT-MC (Glenn S. Burke)
To: (BUG LISP) at MIT-MC

    GSB@MIT-ML 03/09/81 19:01:42
    LDQPR0+1/   CAIN A,TT
    should be CAIN A,(TT)
I fixed this in the source, but didn't patch

GSB@MIT-ML 03/09/81 19:01:42
To: (BUG LISP) at MIT-ML
LDQPR0+1/   CAIN A,TT
should be CAIN A,(TT)


Date:  9 MAR 1981 0443-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: GJC at MIT-MC, JPG at MIT-MC

Forwarded to BUG-LISP for GJC:
   From GJC via BUG command. Monday, Mar 9, 1981  2:41am
   Got a write into read-only memory error from location 8651
   while in routine +INTERNAL-SET-STRING-WORD-N, this is after
   continuing a calculation exited with control-Z.

Date:  9 MAR 1981 0054-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC


'(THIS IS THE UNFASL FOR ((DSK GJC) RELAX /5)) 
(COMMENT **ERROR**  (BVAL . 20.) Lost datum - ILOCMODE in function SET_RECTANGLE)
;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% 

JONL?

Date: 7 March 1981 14:05-EST
From: Christopher C. Stacy <CSTACY at MIT-AI>
To: BUG-LISP at MIT-AI

I copied mc:lisp;let fasl to AI, because the version
on the disk was irrecoverably glitched.


Date:  7 MAR 1981 0850-EST
From: JLK at MIT-MC (John L. Kulp)
Sent-by: JLK0 at MIT-MC
To: (BUG LISP) at MIT-MC

never mind about that last bug report.  I found the problem

Date:  7 MAR 1981 0842-EST
From: JLK at MIT-MC (John L. Kulp)
Sent-by: JLK0 at MIT-MC
To: (BUG LISP) at MIT-MC

Catch/Throw seems to be broken.  CHSGTV;O11DBG is old code that
has been running for ages and now gets "no tag for this throw" errors.
I tried recompiling and using OL all to no avail.

Date: 6 March 1981 14:52-EST
From: George J. Carrette <GJC at MIT-MC>
Subject:  wanted: opinions on a benchmark.
To: MOON at MIT-MC
cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, NIL-I at MIT-MC

Thanks for the explaination. 

About the divide-by-zero and overflow errors. What I really want
is some kind of arithmetic modulo M. However, the description of
24-bit-arithmetic in the Lispm-Manual scared me off a bit.

What would be very nice is to be able to use the same generic
arithmetic functions, "+","*","//","\", with a "small fixnum"
which had certain properties, amoung them "staying small."
It is not that I don't like SMALL-FLONUM's, it is just that
the algebraic properties of them are not ideal for hidden-line
clipping arithemetic.  What happens is that because the
lisp machine does a lot more CHECKING, this forces the program
using them to do checking too, and to compensate for the strange
algebraic properties. Its pretty obvious that if one can get
the required program behaviour from the properties of the objects
being manipulated, rather than from hairy control structure inside
the program itself, then it is a win.

The Array-accessing problem: Of course, the Maclisp object I used
to descibe a CLIPPING-PLANE was a fixed-size hunk, a very simple
structure fixed locations of which can be referenced with a single
PDP-10 instruction.
Lispm-machine arrays have much more complex properties, which simplify
the control structure of many of the programs which use them no doubt!

-gjc

Date:  6 MAR 1981 0324-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Re: wanted: opinions on a benchmark.
To: GJC at MIT-MC
CC: NIL-I at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date:  5 MAR 1981 1835-EST
    From: GJC at MIT-MC (George J. Carrette)

    p.s. On the Lispm the timing difference is much greater,
    which is disturbing.

This is not a very good benchmark.  It gets a division by zero error.
On the Lisp machine it mostly tests the speed of RANDOM (e.g. the ALAN-CLIPPER
test spends 79% of its time in the function RANDOM).  Having fixed those
problems, I find that ALAN-CLIPPER takes 190 microseconds on MC and 340
microseconds on the Lisp machine, while CLIPPER-CALL takes 315 microseconds
on MC and 1250 microseconds on the Lisp machine.  The ratio is 1.6 on MC
and 3.8 on the Lisp machine.  As best as I could measure the twice as large
ratio on the Lisp machine is because on MC function calling and array referencing
are similar in speed to arithmetic (maybe twice as slow), while on the Lisp
machine they are much slower because they do a lot more checking.  Function calling
is definitely too slow on the Lisp machine--I wish that weren't so.
The CLIPPER-CALL also looks like it should be doing bignum arithmetic
due to fixnum overflow in all those multiplications it does, but I
couldn't find any evidence that it actually did get into any bignums.

Date:  5 MAR 1981 2117-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: y-or-n-p, yes-or-no-p
To: (BUG LISP) at MIT-MC

Why does y-or-n-p REQUIRE that I supply an argument?  I would think that
it was completely clear what I want if I just call it with no arguments.
Why doesn't yes-or-no-p go to the trouble to strip leading and trailing
spaces from what the user types?

Date:  5 MAR 1981 1835-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: wanted: opinions on a benchmark.
To: NIL-I at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

MC:BLIS11;CLIP > is a benchmark which is designed to test
PROGRAMMING-STYLE more than anything else. It tests
a very lispy, recursive, object oriented line-clipper for arbitrary
convex polygons against one which is done as a big prog,
highly bumbed for the rectangular special-case.
MC:BLIS11;CLIP MC is the result of the test on MC.

I'm not really sure why the difference in timings is so small,
that is why I am asking for some expert opinions before I
submit the benchmark.

-gjc

p.s. On the Lispm the timing difference is much greater,
which is disturbing.

Date: 4 March 1981 11:29-EST
From: George J. Carrette <GJC at MIT-MC>
To: JIM at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 03/04/81 01:19:21
    From: JIM

    Well, now we don't have eval-ordered* on Multics. Is this necessary?

Gosh. I'm using that from DEFSETF, which is on NILCOM. The question
is if it is necessary to preserve order and number of evaluations.
The answer is that I don't really know. You could install the
standard NIL/Maclisp macrology on Multics. Maybe JONL can tell
us the order in which the files should be compiled?

-gjc

Date:  4 MAR 1981 0812-EST
From: JONL at MIT-MC (Jon L White)
Subject: COMPLR 1102
To: (BUG LISP) at MIT-MC

Just to warn you -- COMPLR now open-compiles LOAD-BYTE, DEPOSIT-BYTE,
LDB, and DPB by means of SOURCE-TRANS, instead of using defmacros
for these things.  I've tested out most cases, but . . .

Date:  4 MAR 1981 0809-EST
From: JONL at MIT-MC (Jon L White)
Subject: MC:BLIS11;DEFVST BUG
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 28 February 1981 23:24-EST
    From: George J. Carrette <GJC at MIT-MC>
    Shows a bug in the expansion of the CONS-A-CLIPPER defined by DEFVST.
The bug actually wasn't in DEFVST or any of its code, but due to
a "phase" error in compiling one of the auxillary macro files.  By
"phase" error, I mean that a bug in one facility causes a bug in
the compiled version of another facility; hence there is a problem
of correctly ordering the successive compilations of the various
files -- each compilation is to be performed by an incrementally 
more-debugged COMPLR.  In this case, the losing code looked like
    `#%(SI:XSET ,(cadr x) ,(caddr x) ,val)
and the loser was, I believe, either MACROEXPAND or SI:XSET.
   At any rate, I "bootstrapped" things up again, and the current
COMPLR did ok by this sample file.

Date:  2 MAR 1981 2159-EST
From: JAR at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC

(sstatus flush t) doesn't seem to do anything in Twenex maclisp.
This really discourages use of SUSPENDed Lisps as random system
tools on Tweneces; the overhead is just too big.  Can this be fixed?

Date:  2 MAR 1981 2127-EST
From: JAR at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC

Why is there no ALARMCLOCK in Twenex Maclisp?
And why doesn't LH/| work in Twenex Maclisp?  I need both of these
for work I'm doing, and have to kludge them in ugly ways.

Date: 28 FEB 1981 2324-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: MC:BLIS11;DEFVST BUG
To: (BUG LISP) at MIT-MC

Shows a bug in the expansion of the CONS-A-CLIPPER defined by DEFVST.

Date: 28 FEB 1981 0616-EST
From: JONL at MIT-MC (Jon L White)
Subject: (SSTATUS FLUSH () ) interacting with SUSPEND
To: EB at MIT-MC
CC: (BUG LISP) at MIT-MC

I've patched the current LISP/XLISP for this problem
    Date: 26 February 1981 17:05-EST
    From: Edward Barton <EB at MIT-AI>
    I had a file that was SUSPENDed and PDUMPed with (status flush) = NIL,
    but when the PURQIO disappeared from SYS; the dump stopped working
    (complained of not being able to find LISP pure pages).
Trouble was that FLSSTA decided to die when it couldn't find the
PURQIO file, but it didn't even bother to check if it already
had the system pages "in core".  (It still wants to TRY to find the
PURQIO file so that sharing can be done when available, even if
the lisp pages were dumped out).
   EB: I've re-dumped your file AI:EB;TS BACKUP with this patch
in it, and renamed the former version to TS OBACKUP.  As time 
goes by, we can again delete the SYS;PURQIO 1997 file, and
still have your BACKUP winning.

Date: 28 FEB 1981 0129-EST
From: JONL at MIT-MC (Jon L White)
Subject: MAKE-STRING now has optional 2nd arg
To: SOLEY at MIT-MC
CC: NILE at MIT-MC, (BUG LISP) at MIT-MC

    Date: 27 February 1981 09:34-EST
    From: Richard Mark Soley <SOLEY at MIT-MC>
	    I have a (not urgent) request for a function in NIL
    and NIL simulator: called "n-spaces", or somesuch.  Just
    same thing as make-string, but filled with spaces instead
    of NULs.  .  .  .
This oversight in the definition of MAKE-STRING has been corrected
in version number 140 -- the second arg, when supplied, specifies
the character to use as the repeated component.  NIL;NEWFUN > 
mentions this, but the PDP10 verion of MAKE-STRING has, until now,
been limited.  Since the STRING-FILL function on the PDP10 is
optimal, I used it, rather than some other word-at-a-time filler.

Date: 27 FEB 1981 0055-EST
From: GZ at MIT-MC (Gail Zacharias)
Subject: ascii-mode files
To: (BUG LISP) at MIT-MC
CC: FJW at MIT-MC

When a file is opened '(out ascii), stray CR's get turned into CRLF's, except
if the stray CR is the last character output to the file.  Could CLOSE check
for that case somehow and put the LF in?  Thanks, Gail.

Date: 26 February 1981 17:05-EST
From: Edward Barton <EB at MIT-AI>
To: BUG-LISP at MIT-AI

I had a file that was SUSPENDed and PDUMPed with (status flush) = NIL,
but when the PURQIO disappeared from SYS; the dump stopped working
(complained of not being able to find LISP pure pages).

File is AI:EB;TS BACKUP.  Don't let it start up completely or it will
take forever.


Date: 26 FEB 1981 1420-EST
From: JONL at MIT-MC (Jon L White)
Subject: <= on flonums
To: JGA at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 26 February 1981 11:21-EST
    From: John G. Aspinall <JGA at MIT-MC>
    (>= 3.0 4.0)
    .  .  .
    ;Loading FORMAT 6724.0 does not pass the FIXNUMP test, for function >=
    ;4.0 ?
    When did >= stop taking flonum args, and what is 6724.0 doing there?
It's a bug that >= didn't accept flonums too (possibly when the
"error checking" was added, it didn't think to check also for flonums).
This is fixed in current version of MLSUB.  However, the random
6724.0 printed out by FORMAT is the result of a bug in APPLY, when
the function being applied has to be autoloaded (APPLY is called
by CERROR when lexpr-funcall is called on FORMAT); I haven't fixed
this bug yet.

Date: 26 FEB 1981 1121-EST
From: JGA at MIT-MC (John G. Aspinall)
Subject: >=
To: (BUG LISP) at MIT-MC


(>= 3.0 4.0)
;Loading MLSUB 11
;Loading ERRCK 22
;Loading DEFMAX 86
;Loading CERROR 34

;Loading FORMAT 6724.0 does not pass the FIXNUMP test, for function >=
;4.0 ?

;BKPT WRNG-TYPE-ARG

 When did >= stop taking flonum args, and what is 6724.0 doing there?

 John.

Date: 25 February 1981 21:42-EST
From: George J. Carrette <GJC at MIT-MC>
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC

This is indeed what I did. In fact, I defined a macro
(DEF-SUBR-ENTER-POINTS FOOBAR 0 3) which said define subr enter points
for arguments 0 through 3 and automatically set up SOURCE-TRANS.

However, I really WANT to go through the UUO handler. 
(1) Save adding extra symbols to the environment, this is an issue,
    multiplying the number of symbols by 6. I have MERROR, and MFORMAT,
    and MTELL, and TR-FORMAT, and perhaps others in the future.
    These are all hairy error or I/O functions, and the overhead of
    the UUO handler is trivial.
(2) Better debugging. If you go through the handler then the DEBUG
    function can easily do an FRETURN for cases which are
    sort-of-recoverable errors. (hackers only).

If I could only keep the compiler from putting an assumption
about the function into the environment (if there were some
user hook to filter those assumptions), then I could win.
Now, I've searched via COMLAP;COMPLR TAGS, and I find only
two places where PUTPROP is done for '*EXPR or '*LEXPR,
one place is in the function COMPILE in COMLAP;COMPLR
and the other is in the function P1 in COMLAP;PHAS1.
If I could put a hook, e.g. call a function PUT-FUN-INFO
instead of PUTPROP, then I could win. How about it?

-gjc

Date: 25 FEB 1981 2118-EST
From: JONL at MIT-MC (Jon L White)
Subject: Default-setting of DEFUN&-CHECK-ARGS
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 23 February 1981 00:51-EST
    From: Carl W. Hoffman <CWH at MIT-MC>
    I haven't been reading my mail lately, so I'm not aware of any discussion
    which may have preceded this change.  .  .  .
    But for the naive user, receiving the error message
	; ((1 . 2) (X)) Wrong number of arguments
    is going to be more confusing than
	; ((FIRST &OPTIONAL SECOND) (X)) Wrong number of arguments
Indeed, there was only short discussion on the change of default value,
prompted by GSB's remarks, but as the LISP RECENT pointed out, the
Interpreter/UUO-handler will do the error checking anyway, so you 
won't even get to the (now-superfluous) error-checking code in the
function itself.  The sophisticated user might want the code specifically
supplied when he is writing a system utility which may often be called
in non-*RSET mode;  the naieve user will (or ought to) be in *RSET mode
by default.

Date: 25 FEB 1981 2112-EST
From: JONL at MIT-MC (Jon L White)
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 23 February 1981 01:08-EST
    From: George J. Carrette <GJC at MIT-MC>
    Is there a way to get a call to a LEXPR to compile
    as a call to an EXPR? .  .  .
A typical thing to do, as was done with the systemic functions
EVAL and PRINT, is to introduce new names (in these cases *EVAL
and *PRINT) which are subr's of a specific number of arguments,
and then they set up the lsubr call;  indeed it does save space
in the compiled code, and there is no UUO overhead at all.
If you can't pick a "common case" w.r.t. number of args, you might
have two or three such new names, and have something like a
SOURCE-TRANS to expand into the appropriate one.

Date: 23 FEB 1981 1245-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: Dave.Touretzky at CMU-10A
CC: (BUG LISP) at MIT-MC, Paul.Hilfinger at CMU-10A

I made no statement of the form ``X should not be done because
it is a pain to implement'' nor did I say ``X should not be done
because it requires an amount of extra code/memory.'' Neither do
I believe these to be good reasons not do do things in a language.

What I *did* do was to offer an explanation of why what seems
to you conceptually elegant is probably not really treated in your
mind as so natural a thing. I was using the code needed to mechanically
execute such a form as a measure of conceptual naturalness. I think
there is philosophical basis for doing this in many applications.
Ugliness in any system can often be traced to the number of special
cases that it takes to hold the system together.

You asked for a reason for not having done it your way, and that's what
you have. Now, the reason for not changing it is another issue. That's
simply a matter of not breaking things. So we aren't really arguing on
that level.

Date: 23 February 1981 1002-EST
From: Dave Touretzky at CMU-10A
To: bug-lisp at MIT-MC
Subject:  Re: exitlist in new-style DO
CC: Paul Hilfinger at CMU-10A
In-Reply-To:  Kent M. Pitman's message of 23 Feb 81 01:02-EST

I don't really like arguments of the form "X should not be done because it
is a pain to implement".  Even worse are arguments "X should not be done
because it requires a [totally trivial] amount of extra code/memory."  Having
COND work the way it does is conceptually natural and elegant.  I think DO
should be adjusted similarly.

On the other hand, if the change really would break tons of code, then I
won't press it.  How many routines actually depend on DO returning NIL
when there is no exitlist?

-- Dave

Date: 23 FEB 1981 0405-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: [CWH: DEFUN&-CHECK-ARGS]
To: (BUG LISP) at MIT-MC
CC: CWH at MIT-MC

I think Carl's point is well-taken. There is no reason sophisticated
users (Macsyma implementors, etc) couldn't set this to the value they
wanted... 

Date: 23 FEB 1981 0108-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

Is there a way to get a call to a LEXPR to compile
as a call to an EXPR? In the case of the
macsyma MFORMAT and MERROR functions, which are both
lexprs, the overhead of going through the UUO handler
for these is small compared with the time spent inside them,
also, the space save by using the SUBR calling convention
of the the LSUBR one is significant.


Date: 23 February 1981 01:02-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  exitlist in new-style DO
To: ALAN at MIT-MC, Paul.Hilfinger at CMU-10A
cc: BUG-LISP at MIT-MC, Dave.Touretzky at CMU-10A

    Date: 21 February 1981 1540-EST
    From: Paul.Hilfinger at CMU-10A

    Is there some deep underlying reason why in the expression

	(do ( ... ) (e1)  ... )

    MacLisp does not treat e1 as thelast element in the EXITLIST and returns
    (instead) NIL?  Grumble.
-----
This change would affect tons of code and is not worth the effort. In fact,
I would argue that there is a 'deep philosophical reason' for having it return
nil...  Reason? Well, you need a temporary variable in the underlying structure
otherwise. ie,  the internal code for DO is conceptually:

	... (IF (EVAL EXIT-TEST) (EXECUTE-IMPLICIT-PROGN EXIT-BODY) ... ) ...

and to get the effect you want, you have to do 

	... (LET ((TEST (EVAL EXIT-TEST)))
		 (IF TEST
		     (IF (NOT EXIT-BODY)
			 TEST
		       (EXECUTE-IMPLICIT-PROGN EXIT-BODY))
		   ...)) ...

or the equivalent. This is conceptually what COND does. In my book, it is
crock that COND does what it does when there are no expressions in the
consequent part of a succeeding clause because hair is required to make it
happen ... It is, however, a USEFUL crock, and one we have all grown used to.
It can at least be compiled well, and it's certainly not ambiguous...
So maybe that makes it less bad, maybe not. But the point is that I think
that DO should just stay as it is.

    Date: 22 February 1981 19:28-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Subject: exitlist in new-style DO
    To: Dave.Touretzky at CMU-10A, Paul.Hilfinger at CMU-10A
    cc: BUG-LISP at MIT-MC

    ... Of course you could write "(stop nil)" if that is what you really
    wanted, right?  If we are going to consider changing the behavior of
    DO, perhaps we should consider removing this wierd case:

    	(do ( ... ) nil ... )

    How many of you even know about the wierd thing that this is defined to
    do?


Yes, i did know what it did. It is kinda silly. It used to be useful before 
LET was invented, actually, ... But there's no harm in leaving that in, really.
People should probably be encouraged not to use it, but there's not any point
in trying to break working code -- if there is any that uses the feature.

-kmp

Date: 23 FEB 1981 0051-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

From LISP RECENT:

Saturday  Feb 07,1981  NM+3D.15H.34M.49S.   LISP 2071 / COMPLR 1094  -- JonL --

3) Default value for DEFUN&-CHECK-ARGS is now (), and whenever &OPTIONAL or
    &REST args are specified, the "args property" of the symbol will be set.
  [more exposition below]
   DEFUN&-CHECK-ARGS is the variable which says whether or not there should
    be code in the function itself to do number-of-args checking. 
   The interpreter, and "UUO" handler, when in *RSET mode, will check the 
    number of arguments passed to a LSUBR/SUBR against the "args property", 
    which is retrieved and set by the ARGS function.

I haven't been reading my mail lately, so I'm not aware of any discussion
which may have preceded this change.  But I want to voice my objection to
it.  My feeling is that the default setting for global switches such as this
one should be that best for naive users, i.e. those not likely to have init
files and least capable of finding information from online documentation.
Hackers and system implementors can easily create their own environments.
But for the naive user, receiving the error message

    ; ((1 . 2) (X)) Wrong number of arguments

is going to be more confusing than

    ; ((FIRST &OPTIONAL SECOND) (X)) Wrong number of arguments

Date: 22 February 1981 19:28-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: exitlist in new-style DO
To: Dave.Touretzky at CMU-10A, Paul.Hilfinger at CMU-10A
cc: BUG-LISP at MIT-MC

    Date: 21 February 1981 1540-EST
    From: Paul.Hilfinger at CMU-10A

    Is there some deep underlying reason why in the expression
    
	    (do ( ... ) (e1)  ... )
    
    MacLisp does not treat e1 as thelast element in the EXITLIST and returns
    (instead) NIL?  Grumble.

My understanding has always been that it works this way so that:

	(do var init step stop body)

and

	(do ((var init step)) (stop) body)

will do exactly the same thing.

Of course you could write "(stop nil)" if that is what you really
wanted, right?  If we are going to consider changing the behavior of
DO, perhaps we should consider removing this wierd case:

	(do ( ... ) nil ... )

How many of you even know about the wierd thing that this is defined to
do?

Date: 22 February 1981 1629-EST
From: Dave Touretzky at CMU-10A
To: bug-lisp at MIT-MC
Subject:  exitlist in new-style DO
CC: Paul Hilfinger at CMU-10A

I know the manual documents it this way (p. 2-40), but I think this
guy has a good point.  Justifications, anyone?

- - - - Begin forwarded message - - - -
Date: 21 February 1981 1540-EST (Saturday)
From: Paul.Hilfinger at CMU-10A (C410PH01)
To: Dave.Touretzky at CMU-10A
Subject:  Deep philosophical question
Message-Id: <21Feb81 154012 PH01@CMU-10A>
Origin:  C410PH01 at CMU-10A; 21 Feb 1981 1541-EST

David,

Is there some deep underlying reason why in the expression

	(do ( ... ) (e1)  ... )

MacLisp does not treat e1 as thelast element in the EXITLIST and returns
(instead) NIL?  Grumble.

--Paul
- - - - End forwarded message - - - -

Date: 21 FEB 1981 0228-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: break-level which does general binding.
To: (BUG LISP) at MIT-MC

For those into such things, LIBLSP;BREAK FASL
has a function BREAKLEVEL which has hooks for doing such
things a binding TTY echoing back on during the breakloop,
re-consing read buffers etc.

-gjc

Date: 20 FEB 1981 2027-EST
From: JONL at MIT-MC (Jon L White)
Subject: XLISP 2077
To: (BUG LISP) at MIT-MC
CC: eb at MIT-AI

Version 2077 just became XLISP -- probablby will become LISP soon.
As for GET and PUTPROP, I've added the code which KMP at one point
  suggested, namely they will treat non-USRHUNK hunks as "disembodied"
  property lists.  The code to actually send a GET or PUT message
  for USERHUNK's has not yet been done.  The idea for USRHUNK's is
  that all systems operations more-or-less work by message passing.
*:TRUTH is a super-internal variable, which controls the value of
  truth.  Normaly, for MacLISP, and any LISP1.5-like lisp, it will
  point to the symbol T, but the user may reset it at will.
New SHARABLE and MACLISP dumps also composed over this XLISP.

Date: 20 FEB 1981 1638-EST
From: JONL at MIT-MC (Jon L White)
Subject: Why BUG-LISP?
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

Since my original note was sent only to one private party, and CC'd
to another, can you justify wasting the time of everyone on BUG-LISP
with your tirade:
    GSB@MIT-ML 02/20/81 16:20:00 Re: Unsolicited false advertising
    To: JONL at MIT-MC
    CC: (BUG LISP) at MIT-MC
    Willl you PLEASE stop spreading your misconceptions?  How many times
    must i correct them?
	JONL@MIT-MC 02/20/81 09:05:31 Re: SHARABle VASLap?
	    . . . .

Date: 20 FEB 1981 1630-EST
From: JONL at MIT-MC (Jon L White)
Subject: Plea (a la GLS) for reasonableness in use of BUG-LISP
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

Re your flame:
    GSB@MIT-ML 02/20/81 16:20:00 Re: Unsolicited false advertising
    Willl you PLEASE stop spreading your misconceptions?  How many times
    must i correct them?
	JONL@MIT-MC 02/20/81 09:05:31 Re: SHARABle VASLap?
	.  .  .
    LSB is not impeded.  LSB does not supply its own pretty-printer.  LSB,
    god forbid, does not supply its own backquoter.  Maybe you suffer
    .  .  .
Wouldn't it have been sufficient merely to note that I should have said
"Certain systems, such as BRANDX, (which happend to be written in LSB)".

GSB@MIT-ML 02/20/81 16:20:00 Re: Unsolicited false advertising
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC
Willl you PLEASE stop spreading your misconceptions?  How many times
must i correct them?
    JONL@MIT-MC 02/20/81 09:05:31 Re: SHARABle VASLap?
	. . . .
    As with any new LISP, there always seems to be a follow-on about a month
    later; . . .
        But another consideration should be mentioned -- instead of using 
    SHARAB^K, most applications will probably now want to use MACLISP^K -- 
    I mentioned this in a note to bug-lisp a couplbe days ago;   I believe
    the "crinkles" are out of the MACLISP^K idea, and certainly it would
    be help more sharablilty for those systems which want most of the
    files loaded into MACLISP (see LISP;MACLIS LISP).  LSB is probably
    the only system which would be impeded, since it supplies its own
    version of DEFUN parsing, and its own pretty-printer, and its own
    backq-er, etc.
LSB is not impeded.  LSB does not supply its own pretty-printer.  LSB,
god forbid, does not supply its own backquoter.  Maybe you suffer
from confusion about what is Maclisp and what is NIL, but i do not
suffer confusion about what is LSB and what is a random general utility,
which just happens to be written using LSB by GSB but does NOT depend on
either of them to run.  And backquote, heaven help us, is a travesty
that only brand-x provides.  In fact, LSB, except in the compiler,
has never been dumped out until just recently, and even that is not
intended to be fully general, but rather for a subset of people here,
and it was only really created so that i could go and break all my
code without breaking everyone elses.
The systems that are impeded are those which are going to run out of
address space.  Perhaps you find it strange for them to be catered to,
but they happen to be the only ones (yes, that's plural) i seem to
deal with.
LSB is a definition-only facility.  It does not even call USER-HUNKP;
it has to live with funcalling (STATUS USRHUNK).  It does not impede
your use of strings, vectors, bits, character-objects, or defining
classes.  It does assume (unlike even the compiler) that any one
particular implementation of user-hunks is in use.  It does not even
hand you LOOP;  if you want that, you have to specifically say so.


Date: 20 FEB 1981 1111-EST
From: JONL at MIT-MC (Jon L White)
Subject: SFA-UNCLAIMED-MESSAGE
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 19 February 1981 05:27-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    SFA-UNCLAIMED-MESSAGE has the *WRONG* autoload property.
    It lives in EXTSFA, not CERROR. 
Ok, I fixed up the source for LISP -- but since there had been
no other references to EXTSFA, that atom didn't exist in earlier
lisps, so the only patch we can make is just to flush the
autoload prop.  Will try to re-assemble a new XLISP today.

Date: 20 FEB 1981 1031-EST
From: REM at MIT-MC (Robert Elton Maas)
To: (BUG LISP) at MIT-MC

Does somebody have a prettyprinter handy which defaults to printing
long lists reasonably instead of one atom per line in a very long narow
column?

Date: 20 FEB 1981 0926-EST
From: JONL at MIT-MC (Jon L White)
Subject: Error checking during DEFUN& expansion
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 18 February 1981 13:45-EST
    From: George J. Carrette <GJC at MIT-MC>
    .  .  .
    When I make typing errors, please, give me a break.
    (At lisp level, not ddt level). Can there be some option
Hmmmmmmmm.
    which causes both DEFUN& and DEFMACRO to call CAR and CDR functions
    which do error checking? .  .  .
It's pretty hard to cause the COMPLR not to open-code CAR and CDR, but
DEFUN& and DEFMACRO expanders could be "beefed-up" in there checking
of the users (alleged) code.

Date: 20 FEB 1981 0919-EST
From: JONL at MIT-MC (Jon L White)
Subject: Bootstrapping for *:EXTEND etc
To: RBL at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 17 February 1981 22:39-EST
    From: Richard L. Bryan <RLB at MIT-MC>
    has autoload properties for *:EXTEND and EXTEND-LENGTH which point to 
    EXTBAS, but which are not defined after loading EXTBAS.
Fixed now.  EXTBAS file was not properly "bootstrapping" all the funs -- 
failed to copy LSUBR properties from SI:foo to *:foo, and EXTEND-LENGTH
was missing.

GSB@MIT-ML 02/19/81 19:13:57 Re: gcdemn
To: (BUG LISP) at MIT-ML
I frobbed the meaning of the GC-DAEMON-PRINT switch, to make it more
usable.  The source is on lspsrc;, and the switch is documented in there.
I compiled and tested on ML, but didn't get a fasl on mc, couldn't get
net connection, so it's not installed


Date: 19 February 1981 14:04-EST
From: George J. Carrette <GJC at MIT-MC>
To: RLB at MIT-MC
cc: BUG-LISP at MIT-MC, RWK at MIT-MC

    Date: 18 February 1981 23:44-EST
    From: Richard L. Bryan <RLB>
    To:   RWK
    cc:   GJC, BUG-LISP

        Date: 18 February 1981 23:36-EST
        From: Robert W. Kerns <RWK at MIT-MC>

            Date: 17 February 1981 23:39-EST
            From: George J. Carrette <GJC at MIT-MC>
            To: BUG-LISP at MIT-MC
            I get ;(GO RETURN) ILGL GO OR RETURN - NOT INSIDE A PROG.

        This is because you have your own break loop.  I don't know
        how to fix it, perhaps there IS no way other than to have
        an interpreted PROG around your break loop?

    Sure there is. Just fix your break loop to special-case having read
    (RETURN ...) and P just like Maclisp's break loop.

Oops. We are using this same break loop in a couple Macsyma
subsystems too, MAXTUL and MCL. Thanks for pointing it out.


Date: 19 February 1981 0818-EST (Thursday)
From: Guy.Steele at CMU-10A
To: gjc at MIT-MC, rwk at MIT-MC
Subject:  Your own BREAK loop
CC: bug-lisp at MIT-MC
In-Reply-To:  Robert W. Kerns's message of 18 Feb 81 23:36-EST
Message-Id: <19Feb81 081844 GS70@CMU-10A>

Say, guys, the BREAK loop is explicitly responsible for examining
its input and checking specially for the RETURN form.  It's a hack --
the use of RETURN in BREAK has nothing at all to do with PROG.

Date: 19 FEB 1981 0527-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

SFA-UNCLAIMED-MESSAGE has the *WRONG* autoload property.
It lives in EXTSFA, not CERROR.  It does not belong
in CERROR either.  It can be called without there being
any error condition.

Date: 19 February 1981 03:58-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Incompatibilities
To: RWK at MIT-MC
cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

Well, the much newer FQUERY function (the generalization of y-or-n-p and
yes-or-no-p) does take FORMAT-like arguments (hence its name).  I agree
that format-like arguments are a nice thing, and it seems that if
y-or-n-p were designed today it would work that way.  If we wanted to
change it incompatibly, we could have a phase-over period (possibly an
infinite one) in which the existing arg order worked; I think that the
two formats are sufficiently non-overlapping to make this work.  What do
other Lisp Machine people think?

Date: 18 February 1981 23:44-EST
From: Richard L. Bryan <RLB at MIT-MC>
To: RWK at MIT-MC
cc: GJC at MIT-MC, BUG-LISP at MIT-MC

    Date: 18 February 1981 23:36-EST
    From: Robert W. Kerns <RWK at MIT-MC>

        Date: 17 February 1981 23:39-EST
        From: George J. Carrette <GJC at MIT-MC>
        To: BUG-LISP at MIT-MC
        I get ;(GO RETURN) ILGL GO OR RETURN - NOT INSIDE A PROG.

    This is because you have your own break loop.  I don't know
    how to fix it, perhaps there IS no way other than to have
    an interpreted PROG around your break loop?

Sure there is. Just fix your break loop to special-case having read
(RETURN ...) and P just like Maclisp's break loop.

Date: 18 February 1981 23:36-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: GJC at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 17 February 1981 23:39-EST
    From: George J. Carrette <GJC at MIT-MC>
    To: BUG-LISP at MIT-MC
    
    In my dumped out lisp, GJC;TS B 
    when I do
    
    (ERROR "FOO" 33 'WRNG-TYPE-ARG)
    (RETURN ARGS)
    
    I get ;(GO RETURN) ILGL GO OR RETURN - NOT INSIDE A PROG.
    
    Can you give me a hint as to how the symbol RETURN gets
    bashed here? The only thing I do in dumping out the lisp
    is load in a bunch of innocent stuff off of the LISP directory.
    
    This turns up in a bare lisp too, once certain things are
    autoloaded, sorry if I can't be more specific, but its darn
    hard to track down.

This is because you have your own break loop.  I don't know
how to fix it, perhaps there IS no way other than to have
an interpreted PROG around your break loop?

Date: 18 February 1981 23:32-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: Gratuitous incompatibilities
To: dlw at MIT-AI
cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

    Date: 18 February 1981 00:27-EST
    From: Daniel L. Weinreb <dlw at MIT-AI>
    Subject: Gratuitous incompatibilities
    To: RWK at MIT-MC
    cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI
    
    The reason that y-or-n-p took either order is because we were in the
    process of converting to the new order of arguments.  That was only a
    temporary state; we never design things that way for real.  We knew that
    we were going to remove the STREAM STRING ordering long before we
    actually removed it.  Did you ask anyone, before you assumed it would
    stay that way?

I knew it was temporary, actually, I just got the direction of the
transition wrong.  I'm of the opinion you shouldn't have made the
change, you should have made the extention to args like FORMAT instead.
I'm not upset or anything, just a friendly jab after all the complaints
about MacLisp being gratutitously incompatible.

I'm not at all enthused about reducing MacLisp's Y-OR-N-P's
functionality since I use it heavily (and know others do as well).  I'm
afraid to ask what your feelings would be to changing the LISPM's
version to be compatible with MacLisp.  At least there is a compatible
subset that can be documented.  Opinions?



Date: 18 February 1981 23:28-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: (GET (HUNK ...) ...)
To: RWK at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 18 February 1981 22:47-EST
    From: Robert W. Kerns <RWK at MIT-MC>

    While I don't really understand the point to doing GET on hunks, I can
    tell you I often do the MEMQ hack on them.  It would break lots of my
    code, including probably EXTEND, to change MEMQ in the same way.  Why
    not just make GET give an error on things that pass the USRHNP test?

I really hate to get into this discussion, but this is not an
acceptable fix to the "problem".  If you are using GET on hunks as a
way of giving your structures property lists, this would prevent you
from making your structures USRHUNKs as well.  Better (but hardly
best) would be to actually send a GET message.  This way you have a
chance of winning (slowly and inefficiently).  Best would be to put
things back the way they were before and move the class object out of
the CDR in your stuff.

Date: 18 February 1981 22:47-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: Request for more input
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, KMP at MIT-MC, JONL at MIT-MC

While I don't really understand the point to doing GET on hunks, I can
tell you I often do the MEMQ hack on them.  It would break lots of my
code, including probably EXTEND, to change MEMQ in the same way.  Why
not just make GET give an error on things that pass the USRHNP test?

GSB@MIT-ML 02/18/81 21:21:39 Re: multiple-value-return
To: (BUG LISP) at MIT-MC
    GSB@MIT-ML 02/18/81 17:07:42 Re: multiple-value-return
    Why doesn't this take any number of args, so it can be used in
    place of multiple-arg RETURN?

I'm obviously confused, ignore this.


GSB@MIT-ML 02/18/81 17:07:42 Re: multiple-value-return
To: (BUG LISP) at MIT-ML
Why doesn't this take any number of args, so it can be used in
place of multiple-arg RETURN?


Date: 18 FEB 1981 1351-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: last bug note
To: (BUG LISP) at MIT-MC

is complicated by the fact that I had set the WRNG-NO-ARG handler
to a function which didn't take the correct number of arguments.
This caused the .VAL (probably). However, the strange handling
of the argument list by DEFUN& still holds.


Date: 18 FEB 1981 1345-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: holy error checking batman.
To: (BUG LISP) at MIT-MC

Load the file MAXSRC;ERS 1

the function WRNG-NO-ARGS-HANDLER ends up with a body which looks like

(LET
 ((#'#635070 |Reqd-Var..3|))
 (COND
   ......
))

the main thing is 
(COMMENT ARGLIST = ((#'#635070 FORMAL-ARGUMENT-LIST))

Calling this function gives a .VAL error to DDT.

When I make typing errors, please, give me a break.
(At lisp level, not ddt level). Can there be some option
which causes both DEFUN& and DEFMACRO to call CAR and CDR functions
which do error checking? Please, I think I can afford the
overhead of error checking during macro expansion.

-gjc

Date: 18 February 1981 00:27-EST
From: Daniel L. Weinreb <dlw at MIT-AI>
Subject: Gratuitous incompatibilities
To: RWK at MIT-MC
cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

The reason that y-or-n-p took either order is because we were in the
process of converting to the new order of arguments.  That was only a
temporary state; we never design things that way for real.  We knew that
we were going to remove the STREAM STRING ordering long before we
actually removed it.  Did you ask anyone, before you assumed it would
stay that way?

Date: 17 FEB 1981 2339-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

In my dumped out lisp, GJC;TS B 
when I do

(ERROR "FOO" 33 'WRNG-TYPE-ARG)
(RETURN ARGS)

I get ;(GO RETURN) ILGL GO OR RETURN - NOT INSIDE A PROG.

Can you give me a hint as to how the symbol RETURN gets
bashed here? The only thing I do in dumping out the lisp
is load in a bunch of innocent stuff off of the LISP directory.

This turns up in a bare lisp too, once certain things are
autoloaded, sorry if I can't be more specific, but its darn
hard to track down.


Date: 17 FEB 1981 2239-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: MACLISP 1022 (in SHARABLE 41, LISP 2075)
To: (BUG LISP) at MIT-MC

has autoload properties for *:EXTEND and EXTEND-LENGTH which point to EXTBAS,
but which are not defined after loading EXTBAS.

GSB@MIT-ML 02/17/81 21:48:54
To: (BUG LISP) at MIT-ML
I have shuffled links on ML such that :SHARAB gets the most recent
sharab dump in the installed lisp.  The sys link points to LSPDMP;TS SHARAB,
and the latter will have to be updated as necessary.
:NSHARAB gets the most recent one.


GSB@MIT-ML 02/17/81 20:52:16 Re: features vs. bugs
To: (BUG LISP) at MIT-ML
(1)   (ALPHALESSP 'A NIL) => NIL
(2)   The rubout code is still going up one line too many when you rub out
      line wraparound.  This is because, as i have said several times before,
      when you do a ^PX (OR a ^PB) at the beginning of the line, ITS is smart
      enough to wrap to the previous line and even back over the continuation
      column (the "!").


Date: 17 February 1981 20:44-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: Request for more input
To: BUG-LISP at MIT-MC
cc: KMP at MIT-MC, JONL at MIT-MC

I have had occasion to use GET on hunks.  I have also used the hack
GSB mentioned where you use ASSQ on a list of hunks to find one with a
specific CAR.  (I hadn't thought of threading them together through
CDRs and using MEMQ, I would have done that otherwise (clever, GSB!).)

I have no current code that uses any of these features, so nothing
will break.

I do mourn the loss of this class of clever hacks.

Date: 17 February 1981 19:08-EST
From: Edward Barton <EB at MIT-AI>
Subject: Request for more input
To: BUG-LISP at MIT-MC

    Date: 17 FEB 1981 1646-EST
    From: kmp at MIT-MC (Kent M. Pitman)
    Do you use code that treats hunks as lists (eg, does
    such code use GET/PUTPROP, ASSQ/ASSOC, CAR/CDR, etc).
I have code that uses ASSQ on lists of hunks, I believe.



Date: 17 FEB 1981 1900-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

An error in the compilation of a function causes
the following functions to get tagged as
(FOOBAR FAILED TO COMPILE) example, a file with:

(DEFUN FOO () NIL)
(DEFUN FOOBAR "thought this was a defvar")
(DEFUN OKFUN () (LIST 1 2 3))
(DEFUN X () NIL)


Date: 17 February 1981 17:55-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: USRHUNKs in the car of a list?
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC

No, userhunks in the position of "forms".
I could be totally wrong about what the compiler does now, but i have been
under the distinct impression that things like the self-quotingness of
"strings" only make it through p1 by virtue of the fact that **SELF-EVAL**
has a macro definition.


Date: 17 FEB 1981 1749-EST
From: JONL at MIT-MC (Jon L White)
Subject: USRHUNKs in the car of a list?
To: GSB at MIT-MC
CC: GJC at MIT-MC, (BUG LISP) at MIT-MC

Say, how serious are you about this really?  I presume
you meant not just EXTENDs, but USRHUNKs.

Date: 17 February 1981 17:35-EST
From: Glenn S. Burke <GSB at MIT-ML>
To: GJC at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 17 February 1981 17:22-EST
    From: George J. Carrette <GJC at MIT-MC>

        Date: 02/17/81 17:12:00
        From: GSB at MIT-ML
        there is no need to extend the evaluator to deal with a class-object
        in the CAR of the hunk, as the evaluator already dispatches via
        (status usrhunk).  It is the COMPILER which requires that slot to
        have a dummy macro definition ...
    The compiler eh? Oh foobar. JONL can extend that can't he?
    Certainly nobody would object if he did. (Or would they?)
I'm sure it can be extended upwards-compatibly with the user-hunk stuff.
Probably want two messages, one for "macro-expanding" code-being-compiled,
and one for "macro-expanding" code being macro-expanded.
Probably non-user-hunk hunks want to be treated as they are now;  fall
through to the list case.


Date: 17 February 1981 17:37-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Avoiding combinatorics
To: GSB at MIT-MC
cc: BUG-LISP at MIT-MC

Try this...

(DEFUN DPL? (X)
  (IF (ATOM X) ()
    (DO ((L  (CDR X) (CDR L))
	 (FLAG NIL)
	 (LL (CDR X) (CDDR LL)))
	((NULL LL) T)
      (IF (OR (ATOM LL) (ATOM (CDR LL)))
	  (RETURN NIL) ; bad format
	(IF FLAG (IF (EQ L LL) (RETURN NIL)) ;circular
	  (SETQ FLAG T))))))

Date: 17 February 1981 17:22-EST
From: George J. Carrette <GJC at MIT-MC>
To: GSB at MIT-ML
cc: BUG-LISP at MIT-ML

    Date: 02/17/81 17:12:00
    From: GSB at MIT-ML
    To:   GJC at MIT-ML
    cc:   (BUG LISP) at MIT-ML

    there is no need to extend the evaluator to deal with a class-object
    in the CAR of the hunk, as the evaluator already dispatches via
    (status usrhunk).  It is the COMPILER which requires that slot to
    have a dummy macro definition (otherwise it could be something more
    general than "self-eval", eh?)

The compiler eh? Oh foobar. JONL can extend that can't he?
Certainly nobody would object if he did. (Or would they?)



Date: 17 February 1981 17:23-EST
From: George J. Carrette <GJC at MIT-MC>
Subject:  "bare" lisp and AUTOLOAD properties
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, JPG at MIT-MC

    Date: 17 FEB 1981 1403-EST
    From: JONL (Jon L White)
    To:   GJC
    cc:   (BUG LISP), JPG
    Re:   "bare" lisp and AUTOLOAD properties

        Date: 17 February 1981 13:31-EST
        From: George J. Carrette <GJC at MIT-MC>
        .  .  .
        In other words, I'm saying flush EVERYTHING which is not referenced
        by COMPILED code. This includes UREAD et. al. and doesn't this amount
        to something significant? 
    103. words for all old-i/o functions.
    By the way, whose "compiled code" would you set as the standard, when
    it comes to flushing functions "not referenced by COMPILED code." ??

Who's compiled code? Macsyma's probably. Who funded maclisp developement?

Date: 17 February 1981 1719-EST (Tuesday)
From: Guy.Steele at CMU-10A
To: bug-lisp at MIT-MC
Subject:  This completely cretinous argument about GET and hunks
Message-Id: <17Feb81 171939 GS70@CMU-10A>

To JONL and KMP, and whoever else cares:

   While I realize that in the area of law, the law of the land is the
legislation that was passed and not what the legislators intended to
pass, I think that in this situation the "reasonable man" and
"reasonable intent" principles apply.  I observe that nearly all of the
quoted "documentation" (and I use horror quotes, for LISP RECENT is
certainly a horrible excuse for documentation) came from my hand.  You
may well question whether I can be considered "reasonable" after
implementing hunks.  Nevertheless, if anyone had thought to ask me
earlier, I would have been happy to clarify the original intent and
design philosophy behind hunks.  (This is not to say that the future of
MacLISP must needs be confined by previous poor decisions.  On the other
hand, the past may be the best source of light for the future.)

   Hunks were originally invented to satisfy *two* applications:
(1) to provide record structures more memory-efficient than lists;
(2) to provide for list cells that could have properties attached.
I thought at the time that LISP RECENT made this fairly clear,
if not explicitly, then by example.

   The functions which were explicitly enumerated were not meant to be
the only functions which could treat hunks as lists.  It would have been
infeasible to list all such functions.  The fact that CAR and CDR were
listed as treating hunks as list cells, and the fact that ATOM of a
hunk produced NIL, together were considered sufficient informal notice
that all functions (such as GET and ASSQ) which are conceptually not
primitive, but use CAR, CDR, and ATOM, would also treat hunks as list
cells.

   Indeed, the intention was that hunks should always be treated *by
default* as list cells, *unless otherwise specified*.  This was the
reason for the HUNKP switch, and for the explicit mention of functions
such as PRINT and EQUAL:  the HUNKP switch conceptually does *not*
explicitly cause EQUAL and PRINT to treat hunks as list cells; instead,
permits the altering of that *default* behavior to make these
explicitly mentioned functions consider all components of a hunk
instead of just the car and cdr.

   Conclude from these remarks what you will.  Let me chastise both of
you, however, for your increasingly rude behavior in this interchange
and in previous messages to BUG-LISP and LISP-FORUM.  I am quite weary
of examining my mail every day or two only to find that much of it
contains snide remarks and allusions to someone's purported ignorance
or pigheadedness.  Such remarks are unnecessary to the transaction of
business in this public forum, and serve only to ruffle feelings and
impede progress.  (I have similar complaints about unnecessary and
uncalled-for use of profanity by yet other parties.)

--Guy

Date: 17 FEB 1981 1719-EST
From: JONL at MIT-MC (Jon L White)
Subject: HASHPUT and HASHGET
To: (BUG LISP) at MIT-MC

Unforuntately, MacLISP has never had the hash-table primitives
which Interlisp has had for over a decade.  This code could
still be written, and probably wholly in LISP itself.
  If we had a good HASHPUT scheme, there would, I think, be
little interest in forcing a particular interpretation onto
the GET (and ASSOC and etc) functions, ** based on how the
data are implemented in PDP10 MacLISP **.
  Why should random pair cells be the only ones onto which
you could put properties?  Why not ARRAY cells too?  one
could even have a uniform treatment for properties of numbers,
lists, pairs, arrays, hunks etc.
  The language feature should not depend, gratuitously, on
a particular data format.

GSB@MIT-ML 02/17/81 17:12:00
To: GJC at MIT-ML
CC: (BUG LISP) at MIT-ML
there is no need to extend the evaluator to deal with a class-object
in the CAR of the hunk, as the evaluator already dispatches via
(status usrhunk).  It is the COMPILER which requires that slot to
have a dummy macro definition (otherwise it could be something more
general than "self-eval", eh?)


GSB@MIT-ML 02/17/81 17:08:54 Re: hunks again
To: (BUG LISP) at MIT-ML
I was under the distinct impression that hunks were treated like lists
except where specifically handled specially.  Showing me all the
documentation does not change my opinion on what GET should do to
them.  Presumably GET should only work on symbols and disembodied
property lists.  I propose the following definition of disembodied
property list:
(declare (special *circularities))
(defun disembodied-property-list? (x)
  (and (not (atom x))
       ((lambda (*circularities) (dpl? (cdr x))) (ncons x))))
(defun dpl? (x)
   (or (null x)
       (and (not (atom x))
	    (not (memq x *circularities))
	    (not (atom (cdr x)))
	    (not (memq (cdr x) *circularities))
	    (not (eq (cdr x) x))
	    ((lambda (*circularities) (dpl? (cddr x))) 
	     (cons x (cons (cdr x) *circularities))))))
The point of this is sort of to show how interpretive one can be
on such concepts as "disembodied property lists".
I just think it is gross and self-serving to change what has become
an established behaviour, which is useful AND WHICH IS BEING USED.
People have been surviving for many years without constantly
perturbing the idiosyncratic fine points of lisp constantly just
to suit what they happen to be doing at the moment, and i think the
initial reason for this change is particularly spurious.  The "bug"
was that GET was not checking for circularity.  This could just
as well happen to lists, it has nothing inherently to do with hunks.


Date: 17 FEB 1981 1659-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: GET on HUNKS.
To: KMP at MIT-MC
CC: RLB at MIT-MC, (BUG LISP) at MIT-MC

Seems like RLB's bug note was very reasonable.
However, (GET (CONS-A-FOO) 'BAR) could be made non-circular by
changing the implementation of the EXTEND objects.
Store the CLASS object as the CAR of the object maybe. But,
then one would have to extend the evaluator to do something
interesting when the CAR is a hunk. 

Case in point: **SELF-EVAL** is a waste of space in every extend object,
more thoughtfull extension of the data structures, and how they
interact with existing primitives, is called for.
Is it not better to extend the evaluator than to de-extend "word?"
a primitive like GET?

Note for RLB: In looking over RLB;H > I thought you could
do well to use something other than GET, something more
abstract.
(1) You could put in more error checking.
(2) You could put in less error checking.
(3) You could perhaps have special slots in the SYMBOL structure
    in NIL, just for the use of your compiler H.
    Since the compiler is very important, it seems reasonable that
    it gets special bits of it's own in the symbol.
    If done cleverly, this could speed up compilation, which would
    benefit everybody.


Date: 17 FEB 1981 1655-EST
From: JONL at MIT-MC (Jon L White)
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 17 February 1981 16:11-EST
    From: Kent M. Pitman <kmp at MIT-MC>
    From the lisp 1.5 programmer's manual
       (defun listp (x)
	  (or (null x) (and (not (atom x)) (listp (cdr x))))
    The idea of making hunks not answer T to the atom test
    is a new one and one that was allowed in only for USRHUNKs because
    many implementors (myself included) use HUNK as an extended cons .  .  .
THIS IS COMPLETELY FALSE.  The idea that  hunks weren't "atoms" came
at the very first, partly as a push from Stavros Macrakis.  USRHUNKs
came only last year.  You've still ignored the documentation of
    Thursday  June 07,1979    FQ+5D.11H.58M.56S.		- Jonl - 
    1) Value of "MAKHUNK" permits use of a new HUNK2 space.
Which makes it impossible to use hunks in general as lists without
resetting the default values of certain switches.

    Furthermore, you've ignored the fact that no documentation 
explicitly promised  hunks-as-lists for more than a handful of functions.
GET isn't one of them.  Any usage of these undocumented actions must be 
categorized a MacLISP-only kludges, and the perpretator of them can't 
expect continuing compatibility.

Date: 17 FEB 1981 1646-EST
From: kmp at MIT-MC (Kent M. Pitman)
Sent-by: ___112 at MIT-MC
Subject: Request for more input
To: (BUG LISP) at MIT-MC

Since JONL and I are disagreeing on this, we would like a survey of people's
opinions on hunks. Particularly, do you feel that JONL's change to XLisp 
which makes (GET hunk ...) return NIL always is a ``bug fix'' or a change
in the language spec? Do you use code that treats hunks as lists (eg, does
such code use GET/PUTPROP, ASSQ/ASSOC, CAR/CDR, etc). Do you feel that 
something has ``changed'' or ``been fixed''? Do you feel that such a 
``change'' or ``fix'' is consistent with the present-day implementation of
Maclisp (independent of what it may be that should have been done ages ago
when hunks were originally implemented). Just reply to BUG-LISP.
Thanks.

Date: 17 FEB 1981 1645-EST
From: JONL at MIT-MC (Jon L White)
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

    GSB@MIT-ML 02/17/81 16:30:12 Re: get & hunks
    To: jonl at MIT-MC, kmp at MIT-MC
    Jonl, i have yet to see anything in the examples of "documentation"
    you supplied which would indicate to me that GET (and putprop and
    remprop) should not treat hunks like disembodied property lists.
    .  .  .
No one ever claimed that GET was debarred from treating hunks as
lists -- I merely showed you **ALL** the documentation on hunks,
and the "list contract" was guranteed only for CAR, CDR, EQUAL,
SUBST, PURCOPY, PRINT and a couple other explicitly mentined ones.
In fact, one cannot win in general using hunks as lists unless
he overrides the default settings of the switches HUNKP and MAKHUNK.

GSB@MIT-ML 02/17/81 16:30:12 Re: get & hunks
To: jonl at MIT-MC, kmp at MIT-MC
CC: (BUG lisp) at MIT-MC
Jonl, i have yet to see anything in the examples of "documentation"
you supplied which would indicate to me that GET (and putprop and
remprop) should not treat hunks like disembodied property lists.
I have made use of this quite frequently over the years, just as i
have also made use of the fact that ASSQ (and ASSOC) treat hunks
like lists as entries in association lists.  (Even cuter is the
trick of making a "list" out of hunks and using a MEMber function.
Throw in some circular backpointers...)
[btw, i replied to this a couple days ago, but got scrod and lost the
message because my emacs init on mc croaked]
Anyway, i have code which makes use of this now, and it would break.
There is undoubtedly older code that i can't think of which uses it,
as i very commonly use simple hunks as simple datastructures for
simple hacks, and i have frequently used GET on them.  
    It is NOT reasonable to go twiddling an established part of Maclisp,
(which gets used!) like this just to suit the whim of some particular
piece of code which uses it in some particular way.  I suppose GET
on hunks would be ok if it didn't just happen that the class object
was in the CDR of it, which itself had a class object in the cdr, ...
I am also not convinced that at this late date it is worth making GET
(etc) even bother with USRHUNKP:  one rather common crock has been
to have hunk objects "work" with the property-list accessors, by
virtue of guaranteeing that the CDR slot is free for that purpose.
This use predates user-hunks, but it is NOT mutually exclusive with
them, as doing it in this way allows one to not lose any efficiency
over any other call to GET.


Date: 17 FEB 1981 1611-EST
From: kmp at MIT-MC (Kent M. Pitman)
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

From the lisp 1.5 programmer's manual

   (defun listp (x)
      (or (null x) (and (not (atom x)) (listp (cdr x))))

The idea of making hunks not answer T to the atom test
is a new one and one that was allowed in only for USRHUNKs because
many implementors (myself included) use HUNK as an extended
cons. 

Since property lists are allowed to be disembodied, then
hunks may implement that. Saying that certain functions were advertised
to work on hunks doesn't mean that others were not. In the
case of hunks, I don't think anyone will claim that hunks were
not known to be GETable. 

Is there anyone else in the Bug-Lisp community that thinks
that this was not the interpretation up until JONL's recent 'fix'?

HUNKs are an implementational tool for all sorts of things. They
need to be left as flexible as possible. There was a perfectly reasonable
way to get both functionalities. Why must you break that? There was
a perfectly reasonable rule about when HUNKs were thought of as atoms.
Why must you break that? I am very annoyed that you make decisions this
large without consulting the rest of the community. 

Date: 17 FEB 1981 1458-EST
From: JONL at MIT-MC (Jon L White)
Subject: Read the Documentation first!
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

Re your confusion of CAR/CDR on hunks, and GET on hunks:
    Date: 17 February 1981 14:50-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    It was frequently advertised by word of mouth in the lab, that hunks
    were car/cdr-able. .  .  .   Maclisp
    documentation sucks in its currently released state. It is not fair for
    you to claim that the lack of documentation is lack of contract.
TUESDAY  JUNE 15,1976   FM+3D.2H.27M.33S.   LISP 1160  - GLS -
	[5B] .  .  .
	     (CXR N H) RETURNS THE N'TH ELEMENT OF THE HUNK H.
		(CXR 0 H) IS EQUIVALENT TO (CAR H), AND (CXR 1 H)
		IS EQUIVALENT TO (CDR H); IN FACT, THE CAR AND CDR
		FUNCTIONS MAY BE USED ON HUNKS AS WELL AS ON LISTS.

Date: 17 FEB 1981 1450-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

It was frequently advertised by word of mouth in the lab, that hunks
were car/cdr-able. I know full well that they are and have had no reason
to doubt this functionality. I have a whole pile of code that depends on
them being so and I know that a number of off-Arpa people do too. Maclisp
documentation sucks in its currently released state. It is not fair for
you to claim that the lack of documentation is lack of contract.

Date: 17 FEB 1981 1403-EST
From: JONL at MIT-MC (Jon L White)
Subject:   "bare" lisp and AUTOLOAD properties
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC, JPG at MIT-MC

    Date: 17 February 1981 13:31-EST
    From: George J. Carrette <GJC at MIT-MC>
    .  .  .
    In other words, I'm saying flush EVERYTHING which is not referenced
    by COMPILED code. This includes UREAD et. al. and doesn't this amount
    to something significant? 
103. words for all old-i/o functions.
By the way, whose "compiled code" would you set as the standard, when
it comes to flushing functions "not referenced by COMPILED code." ??

Date: 17 February 1981 13:31-EST
From: George J. Carrette <GJC at MIT-MC>
Subject:  "bare" lisp and AUTOLOAD properties
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, JPG at MIT-MC

    Date: 17 FEB 1981 1319-EST
    From: JONL (Jon L White)
    To:   GJC
    cc:   (BUG LISP), JPG
    Re:   "bare" lisp and AUTOLOAD properties

    ...
    There is of course a trade-off here between inconvenience to
    the "naive" maclisp user, and the address-starved Macsyma.

I would maintain that what one gets with a :LISP is not suitable
for the "naive" maclisp user and that there is in fact no such trade off;
why should :LISP get one a cold-load environment?

    but it's not clear what of the current autoloadables should
    be flushed, even if there were the opportunity to flush
    enough to make up 1K of space.

By setting up the mechanisms for this, that is, by making it policy that
the "working lisp" for naive users is thoughtfully constructed by
FASLOADing into the "cold load" lisp, we gain flexibility, and perhaps
even lift ourselves out of the gutter of worrying about 
"one more symbol does or does not go over a page boundary".

In other words, I'm saying flush EVERYTHING which is not referenced
by COMPILED code. This includes UREAD et. al. and doesn't this amount
to something significant? 


Date: 17 FEB 1981 1319-EST
From: JONL at MIT-MC (Jon L White)
Subject: "bare" lisp and AUTOLOAD properties
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC, JPG at MIT-MC

By a very clever sharing arrangement, the presence of the
initial AUTOLOAD properties takes up verry little space -- 
so little in fact, that they merely took up the "slop" in
the remaining (formerly unused) part of PURE list/symbol
structure.  We've also been very careful to delete something
less desirable, when some new autoloadable property goes in.
There is of course a trade-off here between inconvenience to
the "naive" maclisp user, and the address-starved Macsyma,
but it's not clear what of the current autoloadables should
be flushed, even if there were the opportunity to flush
enough to make up 1K of space.

Date: 17 February 1981 13:01-EST
From: George J. Carrette <GJC at MIT-MC>
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, GSB at MIT-MC, JPG at MIT-MC, RLB at MIT-MC,
    RWK at MIT-MC

    Date: 17 FEB 1981 1235-EST
    From: JONL (Jon L White)
    To:   GJC, RLB, RWK, GSB
    cc:   (BUG LISP), JPG

    two reminders:
    1) We need a way to periodically "clean out" the LISP;LOCK MAIL file,
       absorbing the relevant info into some data base that an automatic
       reaper could hack.  DUMPGC doesn't address this problem, does it?
It will take the LOCK MAIL file and produce a FASLoadable data base.
Presumably the data base wants to be GC'd too. However, since backup tapes
are never GC'd, there is an interesting problem. This is sounding more and
more like COBOL applications programming. 
    2) MACLISP, rathere than SHARABLE should be the base over which to build
       systems (unless there is an extreme address space crunch e.g. LSBCM).
       The file LISP;MACLISP LISP is an "init" loader file for MACLISP, and
       shows what all files are included in it.
Would be nice to be able to include MACSYMA in this scheme too. In that
case it builds off of a bare lisp. Speaking of bare lisps, the present
LISP IS NOT as BARE as it could be. How about having all those
AUTOLOAD properties and symbols be part of the initial SHARAB, and not
assembled with the bare lisp system. I know that Macsyma has no use
for these symbols, and it would save about a "K". I would think you
owe it to macsyma to do this.

-gjc

Date: 17 FEB 1981 1235-EST
From: JONL at MIT-MC (Jon L White)
To: GJC at MIT-MC, RLB at MIT-MC, RWK at MIT-MC, GSB at MIT-MC
CC: (BUG LISP) at MIT-MC, JPG at MIT-MC

two reminders:
1) We need a way to periodically "clean out" the LISP;LOCK MAIL file,
   absorbing the relevant info into some data base that an automatic
   reaper could hack.  DUMPGC doesn't address this problem, does it?
2) MACLISP, rathere than SHARABLE should be the base over which to build
   systems (unless there is an extreme address space crunch e.g. LSBCM).
   The file LISP;MACLISP LISP is an "init" loader file for MACLISP, and
   shows what all files are included in it.

Date: 17 FEB 1981 1137-EST
From: JONL at MIT-MC (Jon L White)
Subject: GET never advertised to "work on hunks"
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC


    Date: 16 February 1981 01:47-EST
    From: Kent M. Pitman <KMP at MIT-MC>
	.  .  .
	GET has never been advertised to do anything except return () when
	applied to something other than a LIST or a SYMBOL....
    This is *not* true. GET has been advertised to work on symbols and
    disembodied property lists, which are lists of a certain form.

Here is the note from LISP NEWS which originally documents hunks.
Do you see any "advertisement" mentioning GET here?
  TUESDAY  JUNE 15,1976   FM+3D.2H.27M.33S.   LISP 1160  - GLS -
	  [5E] MOST OTHER FUNCTIONS WHICH OPERATE ON LIST STRUCTURE
	       WILL TREAT HUNKS AS LIST CELLS, USING ONLY THE FIRST
But note how these three functions had to be specifically mentioned later:
  MONDAY  MAY 16,1977  LQ+6D.8H.0M.26S.   LISP 1272   - GLS -
  [1] THE VALUE OF HUNKP CONTROLS PRINT, PURCOPY, AND EQUAL

    Since HUNKs are advertised and have been for a long time to behave
    like lists, you are changing a documented behavior. 

Oh really?, didn't you notice the changeover in default behaviour
mentioned in this note:
  Thursday  June 07,1979    FQ+5D.11H.58M.56S.		- Jonl - 
  1) Value of "MAKHUNK" permits use of a new HUNK2 space.

    I think this is very sad, for while I will agree that it is bad that
    for HUNKs to have behaved originally as non-atoms, there is a wealth
    of code that depends on this now and I don't want to see it broken.

Only RWK mentioned the bare **possibility** that the old, list-like
behaviour would be needed for some MRG code.  NO ONE ELSE even mentioned
any code that depends on this.

Date: 17 FEB 1981 1113-EST
From: JONL at MIT-MC (Jon L White)
Subject: error checking in >=
To: WGD at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 17 February 1981 06:46-EST
    From: William G. Dubuque <WGD at MIT-MC>
	    (>= '(1 . 3) 4) => T, there's nothing like great error checking
    to facilitate debugging.
Fixed in MLSUB 10.  Note however that current XCOMPLR (and COMPLR) were 
dumped out with prior versions already loaded.

Date: 17 February 1981 07:56-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: Gratuitous incompatibilities
To: kmp at MIT-AI
cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

    Date: 17 February 1981 01:22-EST
    From: Kent M. Pitman <kmp at MIT-AI>
    To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI
         I note that Y-OR-N-P in Maclisp takes a format arg. In LispM,
         it takes some args I didn't understand when I saw the error
	message.

	Can one or the other of us agree on a cure for this?

When I wrote MacLisp's original Y-OR-N-P (it has since been re-written
by JONL, but apparently retains the same functionality), LISPM's
Y-OR-N-P took two arguments, a stream and a string, in either order.  I
decided that the obvious improvment was that it should take its
arguments like FORMAT, while retaining the compatability check that the
LISPM people also had.  This doesn't seem to have been obvious to the
LISPM people, who shortly after I introduced Y-OR-N-P to MacLisp,
*DELETED* the STREAM STRING order, leaving only the STRING STREAM
ordering of the arguments.  I guess it's my fault for not barfing at
them at that time.  I don't see any reason they couldn't retract this
"improvement", however.

You can be compatible with the LISPM crowd by giving Y-OR-N-P one or two
arguments, with the string being first.  It is unfortunate that the
LISPM people didn't see fit to extend Y-OR-N-P in this obvious manner,
but they have since come up with a fairly winning general query facility
called FQUERY, which takes no stream argument at all (rather it always
uses QUERY-IO, which can be bound if needed), but does provide for a
number of options such as clearing input, selecting a window, providing
for more than just Y or N (or Yes and No), etc.  At some point I'll
probably steal this from them for MacLisp, at which time they will
probably change it incompatibly once again.  Such is life.



Date: 17 FEB 1981 0646-EST
From: WGD at MIT-MC (William G. Dubuque)
Sent-by: BIL at MIT-MC
To: (BUG LISP) at MIT-MC

	(>= '(1 . 3) 4) => T, there's nothing like great error checking
to facilitate debugging.

Date: 17 February 1981 01:22-EST
From: Kent M. Pitman <kmp at MIT-AI>
To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

I note that Y-OR-N-P in Maclisp takes a format arg. In LispM, it takes
some args I didn't understand when I saw the error message. Can one or
the other of us agree on a cure for this?



Date: 16 FEB 1981 0147-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Get of a Hunk
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

    GET has never been advertised to do anything except return () when
    applied to something other than a LIST or a SYMBOL....

This is *not* true. GET has been advertised to work on symbols and
disembodied property lists, which are lists of a certain form.
Since HUNKs are advertised and have been for a long time to behave
like lists, you are changing a documented behavior. No longer will
simple rules tell us when HUNKs are lists and when they are not. We
will have to remember tables of how each function works on them. I
think this is very sad, for while I will agree that it is bad that
for HUNKs to have behaved originally as non-atoms, there is a wealth
of code that depends on this now and I don't want to see it broken.

Why don't you admit you made a quick-and-easy patch instead of a
correct one. There was a very straightforward albeit longer patch
that would have been right: Make GET of a USRHUNK return () if you
like -- or send the thing a GET message(?) -- and make GET on normal
hunks still cdr the thing like all good list-like frobs have been
defined to do.

-kmp

Date: 15 FEB 1981 2104-EST
From: JONL at MIT-MC (Jon L White)
Subject: MacLISP recidivus!
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

I thought I'd give this old dog a new try, by combinng the
dump of the SHARABLE file along with all the MACLISP^K stuff -- 
see the loader file LISP;MACLISP LISP for what all went into it.
Apparently the "round off" of pure pages costs about 4K just
at the cascade level of the SHARAB, so doing things this way
saves a bit;  it means that the MACDMP file will be first in
*SHARING-FILE-LIST* rather than any SHBDMP.  Anyway, it might
be worth another try, to see how much we can share again.
Not yet distributed to other ITS's due to network lossage.

A COMPLR composed of such a MACLISP does take 10K more than
one composed with absolutely bare essentials;  however,
it is possible that only the GRINDEF file is "dross" for
the COMPLR, and that accounts for about 4K.  NILAID shows
a loss of only 2K now, so it seems reasomable to let
it be composed over MACLISP rather than SHARAB.  How
about some of y our dumps?

Date: 15 FEB 1981 1927-EST
From: JONL at MIT-MC (Jon L White)
Subject: GET
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

GET has never been advertised to do anything except return () when
applied to something other than a LIST or a SYMBOL.  Thus your
charge of "language changes" is completely mis-applied.
    Date: 15 February 1981 11:39-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    Subject:  GET of a HUNK
     ...[GET applied to HUNKs]
    It REALLY bugs me that these things aren't discussed in advance. I don't
    like this change and I would like it retracted. It is bad for two reasons:
     (1) It can break code. I haven't had time to analyze my packages to see
	.  .  .
     (2) It is not uniform with the treatment of non-user-hunks and the value 
	 of HUNKP elsewhere in Lisp. Please do not make changes to the language
	 which are not coherent with what little overall design philosophy 
	 there is still persisting in Maclisp after all the other changes that
	 have been forced upon it to get NIL going.
    .  .  .
Speaking of the value of HUNKP, the switch MAKHUNK also affects the
(now-obsolete) interpretation of hunks as pseudo-lists;  the default setting
of both of them is **not** to make this interpretation, and I don't really 
know of any current applications which change that.   If there were such
applications, then GET, GETL, and a host of other functions would have 
to be "refined".
   Incidentally, it was the development of NIL which discovered the
inconsistent behaviour of GET on hunks -- not, as you mistakenly suggest,
that MacLISP was changed to accommodate NIL.

Date: 15 February 1981 11:39-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  GET of a HUNK
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 13 February 1981 20:03-EST
    From: Jon L White <JONL>

        Date: 12 February 1981 23:39-EST
        From: Richard L. Bryan <RLB at MIT-MC>

        How much cpu time have YOU wasted waiting for your program to run,
        when it turns out it was looping infinitely, doing GET off some extend?

    ...I ALWAYS SAID THAT HUNKS SHOULD PASS THE ATOM TEST!! SOOOO, I've just
    edited in the source the code for GET and GETL to distinguish between LIST
    non-atoms and HUNK non-atoms, and return () for the latter.

It REALLY bugs me that these things aren't discussed in advance. I don't
like this change and I would like it retracted. It is bad for two reasons:

 (1) It can break code. I haven't had time to analyze my packages to see
     if it does, but I don't use USRHUNK at all -- I like just bare hunks
     and I have used them as CDR-able objects and as objects with plists on
     a number of occasions. I don't know if I currently have code that cares
     and haven't had time to look. Even if it doesn't break any code, it
     radically changes the way in which hunks must be viewed as a tool for
     implementation -- i think NOT for the better.

 (2) It is not uniform with the treatment of non-user-hunks and the value of
     HUNKP elsewhere in Lisp. Please do not make changes to the language 
     which are not coherent with what little overall design philosophy there
     is still persisting in Maclisp after all the other changes that have
     been forced upon it to get NIL going.

The correct fix would have been to make only USRHUNKs have the behavior
you described. I would have no objection to that, as it is both safe and
consistent.

-kmp

Date: 14 FEB 1981 2316-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFVAR
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

Yea, this is a loss
    Date: 14 February 1981 00:26-EST
    From: Alan Bawden <ALAN at MIT-MC>
    (defvar foo)
     ==>	. . .   (or (boundp 'foo) (setq foo nil)) . . .
    Why does defvar seem to think that it has to bind foo to something in
    this case?  This is a screw if you just want to do (defvar foo) in one
    file, and (defvar foo 'initial-value) in another.  .  .  .
Fixed in MLMAC  74.

Date: 14 FEB 1981 0026-EST
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG LISP) at MIT-MC

I note that

(defvar foo)
 ==> (progn 'compile
	    (eval-when (eval load compile)
		       (and (fboundp 'special) (special foo)))
	    (or (boundp 'foo) (setq foo nil))
	    'foo)

Why does defvar seem to think that it has to bind foo to something in
this case?  This is a screw if you just want to do (defvar foo) in one
file, and (defvar foo 'initial-value) in another.  The initial
valueing from the second file won't happen since the first file bound
foo to nil.  If the user means (defvar foo nil), then he can say that!

Date: 13 FEB 1981 2327-EST
From: JONL at MIT-MC (Jon L White)
Subject: PURE-SUSPEND will mail note to LISP;LOCK MAIL
To: GJC at MIT-MC, RLB at MIT-MC
CC: (BUG LISP) at MIT-MC

In order to spur you (GJC) to write some programs for hassling
the data-base LISP;LOCK >,  I've just hacked PURE-SUSPEND TO
mail `(,(status LISPV) ,.*SHARING-FILE-LIST*)  to the file
LISP;LOCK MAIL.  Note that  each such mailing will have the
lisp version (as a symbol) as first element, the sharable-dump file
name (as a namelist) as second element, and then any other
dependencies (as namelists) in the order in which they depend.
This is now effective in the current SHARABLE, which is built
over the current XLISP.

Date: 13 FEB 1981 2003-EST
From: JONL at MIT-MC (Jon L White)
Subject: GET of a HUNK
To: RLB at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 12 February 1981 23:39-EST
    From: Richard L. Bryan <RLB at MIT-MC>
    How much cpu time have YOU wasted waiting for your program to run,
    when it turns out it was looping infinitely, doing GET off some extend?
Myself, probably more cup time wasted than anyone else.  Maybe than all
others put together.  I ALWAYS SAID THAT HUNKS SHOULD PASS THE ATOM TEST!!
    SOOOO, I've just edited in the source the code for GET and GETL to 
distinguish between LIST non-atoms and HUNK non-atoms, and return () for
the latter.  Funny thing, I noticed a savings in the main GET loop, so
it is now two instructions shorter (5 instead of 7).  Why that wasn't
noticed before? oh well.
    Will be installed in XLISP 2075, which will be ready within the hour.

Date: 13 FEB 1981 0236-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: MACROEXPAND-1*M
To: (BUG LISP) at MIT-MC

This now calls the value of FIND-MACRO-DEFINITION
(defaultly FIND-MACRO-DEFINITION) to find the macro definition.
If you want macros which you have stashed somewhere else to be
included, set FIND-MACRO-DEFINITION to your own function
(which can call FIND-MACRO-DEFINITION if it wishes).

FIND-MACRO-DEFINITION now will find macros that the
compiler pushed onto MACROLIST, so mere user programs
will get these macros expanded too.

This feature is useful for those writing cross-compilers.
It could also be used as a way to get the effect of
macros without actually making something a macro.  I.e.
a better way to do things than defining something to
be both a MACRO and a SUBR might be to do

(DEFUN MY-FIND-MACRO-DEFINITION (sym)
  (or (cdr (assq sym my-fake-macros))
      (find-macro-definition sym)))

Date: 13 FEB 1981 0146-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: previous bug report
To: (BUG LISP) at MIT-MC

Apologies.  I was trying to test a change to MACROEXPAND-1*M, and I was
using MULTIPLE-VALUE as a test case.  Unfortunately, the spurious
error checking uses MACROEXPAND-1*M, which was indeed broken.
Were it not for this spurious error checking, I could have found
the bug a lot easier.  I remain dubious that this suprious
error checking is ever useful in finding bugs....

Date: 13 FEB 1981 0129-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(DEFUN FOO (X Y) (VALUES X Y))

(MULTIPLE-VALUE (X Y) (FOO))
;(MULTIPLE-VALUE (X Y) (FOO)) Most System funs don't return multiple-values


**SO FUCKING WHAT?  IF YOU'RE GOING TO INSTALL SPURIOUS CHECKING, AT LEAST
  MAKE SURE YOUR CHECKS ARE CORRECT!!! **

Date: 12 FEB 1981 2339-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: GET
To: (BUG LISP) at MIT-MC

How much cpu time have YOU wasted waiting for your program to run,
when it turns out it was looping infinitely, doing GET off some extend?
At least in *RSET mode, GET should err when given an extend.

Date: 12 February 1981 22:31-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: [LFG.KRIS at MIT-SPEECH: LEDIT interface]
To: BUG-EMACS at MIT-MC
cc: BUG-LISP at MIT-MC, LFG.KRIS at MIT-SPEECH

Date: 12 Feb 1981 1212-EST
From: LFG.KRIS at MIT-SPEECH
Subject: LEDIT interface
To: bug-lisp at MIT-MC
cc: LFG.KRIS at MIT-SPEECH

When I invoke EMACS from LISP by (LEDIT) and I exceed a
directory quota in writing out a file I am returned to LISP
and unable to get back to the inferior EMACS through (LEDIT),
even after I have done an expunge from EXEC. When I try to get
back to EMACS I get the following error:

	;78644. Bad RFSTS

This is inconvenient since it causes you to loose whatever
editing you had been doing before saving in EMACS.

-------
I think this is because EMACS throws you to EXEC when it
gets this error, rather than handling it itself?

Date: 12 FEB 1981 1418-EST
From: JONL at MIT-MC (Jon L White)
Subject: Lightening quenched!
To: (BUG LISP) at MIT-MC
CC: WGD at MIT-MC

Finally, I think I have tested all cases of my "patch" to the
"lightening strikes twice" bug:
    Date: 10 February 1981 17:53-EST
    From: Jon L White <JONL at MIT-MC>
    Subject: Lightening Strikes Twice!
    .  .  .
    Sigh, remember the PUTPROP twice bug that has plagued us lo these
    6 years?  This is still another manifestation of it.  I've done some
    more work on PUTPROP, but it still isn't completely bug-free (will work
    more on it later tonite)
The only anomalous case is that when you are trying to do a pure-putprop,
and the page on which the property-list cell resides **has already been
made read-only**, then the initial part of the plist will be copied into
impure space;  this behaviour isn't buggy, but simply leaves 2 words
in impure space that could go into pure.   Look on the bright side!  it
doesn't cause the frivolous creation of yet another page of pure space 
when you "accidentally" pure-putprop twice.

Date: 12 FEB 1981 1411-EST
From: JONL at MIT-MC (Jon L White)
Subject: Strength
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

Apparently this has been broken for years?
    GSB@MIT-ML 02/10/81 20:41:13 Re: Give me strength!
    (apply 'this-is-an-undefined-function nil)
    =>
    ;IMPROPER USE OF MACRO - EVAL
    ;BKPT *RSET-TRAP
    What's wrong with the undefined function handler???
I've just fixed it, by patches into the current lisp dump on MC
(version 2071), and will try to :INSTALL it as soon as the net is 
winning.  Source also is fixed.

Date: 12 FEB 1981 1219-EST
From: JONL at MIT-MC (Jon L White)
Subject: Buggy XLISP
To: WGD at MIT-MC, RWK at MIT-MC
CC: (BUG LISP) at MIT-MC

Incidentally, since last Saturday, the "newer" lisp had been placed as
LISP^K, so XLISP^K is again experimental.
    Date: 10 February 1981 19:55-EST
    From: William G. Dubuque <WGD at MIT-MC>
	    LISP;EXTEND fails to load into an XL, dying trying to call 0 
    (actually its when EXTSFA is being loaded). Congratulations, that's 
    every day now for the past two weeks that some piece of the system has 
    screwed me.
LISP^K and XLISP^K, although same version numbers, should have been different 
dumps when you got this problem, and you shouldn't have seen it in LISP^K. 
RWK's fix is correct, mentioned in
    Date: 11 February 1981 02:46-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    Subject: Problems with XLISP
    The problem with EXTEND and EXTSFA and YESNOP not loading is due to
    GENTEMP not working which is in turn due to EXPLODEN being broken, giving
    FXPDL OUT OF PHASE for fixnums, and ILOPR at location 0 for flonums.
    .  .  .
    I have fixed and patched the problem.
However this patch should be installed only as XLISP^K, due to the
fact that I was still trying to get the bug out of PUTPROP referenced as
    Date: 10 February 1981 17:53-EST
    From: Jon L White <JONL at MIT-MC>
    Subject: Lightening Strikes Twice!
    .  .  .
    Sigh, remember the PUTPROP twice bug that has plagued us lo these
    6 years?  This is still another manifestation of it.  I've done some
    more work on PUTPROP, but it still isn't completely bug-free .  .  .
So I hope this "experimental" PUTPROP doesn't cause any problems -- 
they would be manifest when pure-loading up a big system (like,
COMPLR, NILAID or MACSYMA!)

Date: 12 Feb 1981 1212-EST
From: LFG.KRIS at MIT-SPEECH
Subject: LEDIT interface
To: bug-lisp at MIT-MC
cc: LFG.KRIS at MIT-SPEECH

When I invoke EMACS from LISP by (LEDIT) and I exceed a
directory quota in writing out a file I am returned to LISP
and unable to get back to the inferior EMACS through (LEDIT),
even after I have done an expunge from EXEC. When I try to get
back to EMACS I get the following error:

	;78644. Bad RFSTS

This is inconvenient since it causes you to loose whatever
editing you had been doing before saving in EMACS.

-------

Date: 11 FEB 1981 2118-EST
From: RPG at MIT-MC (Richard P. Gabriel)
To: (BUG LISP) at MIT-MC

Sorry, an unsucessfully typed mail forwarding test.
			-rpg-

Date: 11 FEB 1981 2116-EST
From: BUG-LISP at MIT-MC
Subject: Losing?
To: RPG at MIT-MC
CC: (BUG LISP) at MIT-MC

Can you be more specific?

Date: 11 FEB 1981 2112-EST
From: RPG at MIT-MC (Richard P. Gabriel)
To: (BUG LISP) at MIT-MC

you loser

Date: 11 February 1981 1521-EST (Wednesday)
From: Guy.Steele at CMU-10A
To: bug-lisp at MIT-MC
Subject:  Re: Lightening Strikes Twice!
In-Reply-To:  JONL@MIT-MC's message of 10 Feb 81 17:53-EST
Message-Id: <11Feb81 152109 GS70@CMU-10A>


Old lightening never strikes; it just fades away.
Actually, probably it was lightning that struck.

Date: 11 FEB 1981 0356-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: EXPLODEN in XLISP
To: (BUG LISP) at MIT-MC
CC: WGD at MIT-MC

I have fixed and patched the problem.

Date: 11 FEB 1981 0246-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: Problems with XLISP
To: (BUG LISP) at MIT-MC

The problem with EXTEND and EXTSFA and YESNOP not loading is due to
GENTEMP not working which is in turn due to EXPLODEN being broken, giving
FXPDL OUT OF PHASE for fixnums, and ILOPR at location 0 for flonums.

GSB@MIT-ML 02/10/81 20:41:13 Re: Give me strength!
To: (BUG LISP) at MIT-ML
(apply 'this-is-an-undefined-function nil)
=>
;IMPROPER USE OF MACRO - EVAL
;BKPT *RSET-TRAP

What's wrong with the undefined function handler???


Date: 10 FEB 1981 1955-EST
From: WGD at MIT-MC (William G. Dubuque)
Sent-by: BIL at MIT-MC
Subject: Consistent lossage
To: (BUG LISP) at MIT-MC

	LISP;EXTEND fails to load into an XL, dying trying to call 0 (actually
its when EXTSFA is being loaded). Congratulations, that's every day now
for the past two weeks that some piece of the system has screwed me.

Date: 10 FEB 1981 1753-EST
From: JONL at MIT-MC (Jon L White)
Subject: Lightening Strikes Twice!
To: WGD at MIT-MC, RLB at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 10 February 1981 03:31-EST
    From: Richard L. Bryan <RLB at MIT-MC>
    Hah! In a bare XC, look at (PLIST 'CLASS-CLASS) for only one of many such 
    instances of lossage. .  .  .
Sigh, remember the PUTPROP twice bug that has plagued us lo these
6 years?  This is still another manifestation of it.  I've done some
more work on PUTPROP, but it still isn't completely bug-free (will work
more on it later tonite)
   Since the problem in COMPLR is caused by INITIALIZE being called
(which wants to SPECIALize some important systemic variables, but
which had already been specialized by the loading of some files), then
I've put out a COMPLR fix file which just remprop's them, and re-puts
the properties (in impure space).
   By the bye, remember how these problems didn't occur in NILAID
and NACOMPLR?  well I remember last summer when first becoming aware
of the PUTPROP-twice bug that the NALOADer file just did a lobotomy
of some offenders:  
   (mapc '(lambda (y) (mapc '(lambda (x) (putprop (car x) 
						  (car (remprop (car x) y)) 
						  y))
			    SI:INITIAL-CLASSES))
	 '(CLASS CLASS-SYMBOL))
and sure enough, the SPECIAL propertie in NACOMPLR are the right thing.
I guess this "lobotomization" can be removed when I finish with
PUTPROP tonite.  (maybe PUTPROP shsould be removed??)

Date: 10 February 1981 1536-EST (Tuesday)
From: Guy.Steele at CMU-10A
To: DCP at MIT-MC (David C. Plummer)
Subject:  Re: Am I just a naive IO user, or is this a bug?
CC: bug-lisp at MIT-MC
In-Reply-To:  DCP@MIT-MC's message of 9 Feb 81 01:31-EST
Message-Id: <10Feb81 153637 GS70@CMU-10A>

You're just a naive I/O user.  The action at end of file
can be controlled by the EOFFN associated with the file object.
The default action is to close the file.

Date: 10 Feb 1981 0300-PST
From: Rod Brooks <ROD at SU-AI>
Subject: explode is broken  
To:   bug-lisp at MIT-MC    

The following happens at MC (and SAIL).
*l^K!

LISP 2071
Alloc? n


*
(explode 8.795)
(/8 |.| /7 &)

EXPLODE has been broken at SAIL since we got the latest version of LISP.
The changes that were made to fix that got rid of the way it was losing
at first but now it loses this way. (RPG has been out of contact with the
net for a few days, and will probably be for a while longer).



Date: 10 FEB 1981 0338-EST
From: RLB at MIT-MC (Richard L. Bryan)
Sent-by: JPG at MIT-MC
Subject: Pure plist, continued
To: (BUG LISP) at MIT-MC

Didn't happen in compiler 1063.

Date: 10 FEB 1981 0331-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

Hah! In a bare XC, look at (PLIST 'CLASS-CLASS) for only one of many such 
instances of lossage.  CLASS-CLASS has a pure plist cell for the SPECIAL
property, pointing into the freelist!  So do other mumble-CLASS symbols.
These appear to be the only symbols with pure plist cells pointing to
impure nonatomic sexp.

"Damn, I knew it wasn't my bug"     -- BIL

Date: 10 FEB 1981 0059-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

Userhunks don't print to the TTY when I run a wallpaper file.
WALBEG and WALEND are in GJC;LSPENV >

Date: 9 February 1981 23:04-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: "When doesn't unwind-protect?" (or) "Oh where, oh where did my End-Of-File go?"
To: BUG-LISP at MIT-ML
cc: BUG-LSB at MIT-ML, BUG-BRAND-X at MIT-ML

A:  When the reader does the unwinding!
Seriously now...
  I am always gettinng shafted because EOF is not detected nicely
inside a (toplevel) readmacro.  It just punts out to the READ, and
quietly returns the eof-val.  This happens also with vertical-bars,
and used to happen with ";", except that that was "fixed" (in a nifty
way which is inaccessible to the lisp user).  Now, i COULD go and
calculate the input file (from ^Q and INFILE) and call TYI explicitly
on that, but due to the particularly winning and general way in which
the ascii input code in newio was implemented, this ups the time
taken in TYI by somewhere between one and two orders of magnitude,
because it will then do an inbind/eofbind on me for each tyi.
  So, i thought to myself, first i'll see if i can trap it with a
CATCHALL.  Well, that showed no results, but then i didn't really think
it would.  So i tried an unwind-protect.  SURPRISE!  Look ma, no
unwinding!  TYIMAN must really think he's something to have such
privileged treatment.


Date:  9 FEB 1981 1602-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: JONL at MIT-MC
CC: RWK at MIT-MC, (BUG LISP) at MIT-MC, JPG at MIT-MC

   JONL@MIT-MC 02/09/81 11:55:08 Re: LEXPR-SEND and CHECK-ARG
   To: RWK at MIT-MC
   CC: (BUG LISP) at MIT-MC, JPG at MIT-MC
   Poor COMPLR didn't get enough autoload properties -- LISP doesn't
   have room to put autoloads for all out-of-core functions, so its
   kind of guess as to which ones are most important.  But COMPLR 
   certainly should get more, and I'll make up a COMPLR within a few
   hours which has more of these added.
   By the bye, this would be another area to apply RWK's idea of a
   standard file to be loaded which would supply a lot of initially-missing
   autoload properties.
Perhaps, COMPLR like MACSYMA should be looking into using a hash table 
for AUTOLOAD properties that is accessed by the UNDF-FNCTN (sic) handler, 
so that these properties need not be in core at all. 

Date:  9 FEB 1981 1211-EST
From: JONL at MIT-MC (Jon L White)
Subject: HAIPART confusion
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

    From: Kent M. Pitman <KMP at MIT-MC>
    Subject: HAIPART fixed??
    The following examples failed prior to your fix and continue to fail now:
      (HAIPART -5 -5) => -5
	.  .  .
Yea, this is the "LOHPART" function, and I didn't change that;  since
the manual shows that the first arg should be ABSify'd in each case, 
then I'll patch that too.

Date:  9 FEB 1981 1157-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: standard autoloads
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

Such a file should also have ARGS information.

Date:  9 FEB 1981 1155-EST
From: JONL at MIT-MC (Jon L White)
Subject: LEXPR-SEND and CHECK-ARG
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, JPG at MIT-MC

    Date: 8 February 1981 08:48-EST
    From: Robert W. Kerns <RWK at MIT-MC>
    LEXPR-SEND is still not known to LISP.  At the *VERY* least
    COMPLR should know it's an LSUBR.
Poor COMPLR didn't get enough autoload properties -- LISP doesn't
have room to put autoloads for all out-of-core functions, so its
kind of guess as to which ones are most important.  But COMPLR 
certainly should get more, and I'll make up a COMPLR within a few
hours which has more of these added.
   By the bye, this would be another area to apply RWK's idea of a
standard file to be loaded which would supply a lot of initially-missing
autoload properties.

Date: 9 February 1981 02:41-EST
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC

i replied to dcp.

Date:  9 FEB 1981 0131-EST
From: DCP at MIT-MC (David C. Plummer)
Subject:  Am I just a naive IO user, or is this a bug?
To: (BUG LISP) at MIT-MC


File foo is freshly opened for input, but there is nothing in the
file. Now I do either a 

(tyi foo)   ==> -1
or
(readline foo 'nil) ==> nil

This is right, but try to do another tyi or readline
and you will find that the file has been graciously
closed behind your back. You cannot attempt to read
from it and request more end-of-file conditions.

what gives??

Date: 8 February 1981 09:19-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: JPG at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 8 February 1981 08:00-EST
    From: Jeffrey P. Golden <JPG at MIT-MC>
    To: BUG-LISP at MIT-MC
    cc: JPG at MIT-MC
    
    Take any(?) file, e.g. JONL;FOO 1 .
    (LOAD "JONL;FOO") gives NIL in L^K, T in OL^K.
    Is this change a bug?
Fixed.

Date: 8 February 1981 08:58-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: GJC at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 6 February 1981 18:05-EST
    From: George J. Carrette <GJC at MIT-MC>
    To: BUG-LISP at MIT-MC
    
    I just did a (DESCRIBE 'TRANSL) in MAXTUL;TS MCL,
    got a ;FSYMEVAL - MACRO NOT PERMITTED IN UUO CALL error.
    
    "No Comment"
Fixed.

Date:  8 FEB 1981 0848-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

LEXPR-SEND is still not known to LISP.  At the *VERY* least
COMPLR should know it's an LSUBR.

Date:  8 FEB 1981 0800-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

Take any(?) file, e.g. JONL;FOO 1 .
(LOAD "JONL;FOO") gives NIL in L^K, T in OL^K.
Is this change a bug?

Date:  8 FEB 1981 0400-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: HAIPART fixed??
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

The following examples failed prior to your fix and continue to fail now:

  (HAIPART -5 -5) => -5
  (HAIPART -5 -4) => -5
  (HAIPART -5 -3) =>  5
  (HAIPART -5 -2) =>  1


Date:  8 FEB 1981 0140-EST
From: GSB at MIT-MC (Glenn S. Burke)
Subject: structured non-local exits win again
To: (BUG LISP) at MIT-MC

(setq alarmclock '(lambda (x) (nointerrupt nil) (*throw 'frobozz 'timed-out)))
(defun frobozz ()
  (*catch 'frobozz
     (unwind-protect (alarmclock 'time 1)
	(sleep 5.)
	(alarmclock 'time nil))))
(frobozz)
  => TIMED-OUT
; Only problem is, UNREAL contains -1 !  We are left in (NOINTERRUPT T)
mode.  This example is somewhat forced, but this kind of thing can
happen from various timing problems.

Date:  7 FEB 1981 1753-EST
From: JONL at MIT-MC (Jon L White)
Subject: PURCOPY of an array (?)
To: (BUG LISP) at MIT-MC

This is still outstanding:
    GSB@MIT-ML 08/04/80 23:59:21 Re: hard times are a way of life
    purcopying an array sets the AS.FL bit in the asar rather than the TTS.CN
    bit in the ttsar.  I thought this had been fixed long ago.


Date:  7 FEB 1981 1124-EST
From: JONL at MIT-MC (Jon L White)
Subject: HAIPART
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC, KMP at MIT-MC

Hwenever, oh!, hwenever will this bug go away:
    Date:  9 DEC 1980 0358-EST
    From: JPG at MIT-MC (Jeffrey P. Golden)
    HAIPART is documented to return a positive result.
    (HAIPART -2 35.) however returns -2.
    The bug seems to occur for all negative fixnum first arguments.
Fixed in source now, and patched in the past three lisps (versions
2071, 2057, 1997, and 1914).  Problem was that if there aren't
enough bits in the fixnum to satisify the haipart request, then
the ABS of the input argument should be returned (of course, ABS
need only be called when the first arg is both negative and "too small").

Date:  7 FEB 1981 1021-EST
From: JONL at MIT-MC (Jon L White)
Subject: COMPLR not at fault
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, CWH at MIT-MC

Re:
    Date: 5 February 1981 17:21-EST
    From: Jeffrey P. Golden <JPG at MIT-MC>
    Subject: Bug in (TAN 10), continued
    This looks like it is a compilation bug (AC being clobbered?)
    Just get a MACSYMA, quit into LISP, and (TRACE SIN COS).
    You'll see that the argument to COS (which should be the same as the 
    argument to SIN, obviously) is being clobbered.
    The function TAN is defined in MRG;TRIGI > .
the bug is entirely due to the faulty declaration in the TRIGI file
reproduced here:
    ;; This declaration applies to the parameter variables and local variables
    ;; of many of the functions defined below.  They do not apply to special
    ;; variables.  If you use these names in any context below, the compiler
    ;; will assume them to be flonums.
    (DECLARE (FLONUM Y YY X))
X certainly isn't being used as a FLONUM variable in TAN.

Date:  6 FEB 1981 1941-EST
From: JONL at MIT-MC (Jon L White)
Subject: DECLAREs in MULTIPLE-VALUE-BIND, and spurious "passing thru".
To: GSB at MIT-MC, RG at MIT-MC
CC: (BUG LISP) at MIT-MC

    GSB@MIT-ML 02/04/81 20:11:16
    (multiple-value-bind (a b c) (frobozzery)
	    (declare (fixnum a b c))
	    (mumble))
    should expand into . . .
    so that the declare is properly placed.
Done, in MLMAC version 70.  Also, the *:ARn variable is now being
SETQ'd to 0 after an explicit multiple-value-returning call, so
that multiple-return-values aren't "passed thru" spuriously.  (This
should only cost 1 extra instruction per MULTIPLE-VALUE -- namely
the SETZM of *:ARn).  UNWIND-PROTECT isn't done, so you could
conceivably lose by random THROWs out of an asynchronous interrupt.

Date:  6 FEB 1981 1805-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

I just did a (DESCRIBE 'TRANSL) in MAXTUL;TS MCL,
got a ;FSYMEVAL - MACRO NOT PERMITTED IN UUO CALL error.

"No Comment"

Date:  6 FEB 1981 1718-EST
From: JONL at MIT-MC (Jon L White)
Subject: MULTIPLE-VALUE error checking
To: WGD at MIT-MC
CC: (BUG LISP) at MIT-MC

I've refined the error checking for MULTIPLE-VALUE/MULTIPLE-BIND:
    Date: 5 February 1981 00:30-EST
    From: William G. Dubuque <WGD at MIT-MC>
    Why does (MULTIPLE-VALUES (A B) (VALUES 1 2)) lose? Also, why doesn't
    (MULTIPLE-VALUE (A) ...) do the correct thing instead of losing; this
    would be important for automatically generated code. ... also
    for instance, we have (MULTIPLE-VALUE (A) 1) ).
In the cases where 0 or 1 variables are being set, the expander will now 
permit atomic evaluations, and produce a "simple" SETQ or LET.   The
problem with (MULTIPLE-VALUES (A B) (VALUES 1 2)) is more subtle, and
the correction for it is simply to special-case the "evaluations" which
call VALUES or VALUES-LIST;  in particular, VALUES is a macro which
expands into (PROG1 ...)  and in general, a PROG1 can't work there (but
of course this specific prog1 is setting up the values vector ...)
    .  .  .
	    PS, MULTIPLE-VALUE should also work with () as first arg, as it
    does on the Lispm (also with 1 arg).
Right, fixed -- a null varlist just "calls the function", or whatever.
    .  .  .I think the sysp check should either
    by eliminated or changed to an appropriate warning.
It's more accurate now.  But a general problem with these system macros
is that there are many places where "abnormalities" are found, and a
specific diagnosis would require many more words of memory to store
the specific msgs;  until we're willing to give up a lot more address
space, we'll just have to make do with a single message saying that the
expansion didn't make it.  LET, DEFUN& and DEFMACRO are other system
macros which come to mind.

Date: 6 February 1981 02:16-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  [SOLOMON: forwarded]
To: BUG-LISP at MIT-MC

Date: Tuesday, 27 January 1981  06:09-EST
From: Jonathan Alan Solomon <SOLOMON at RUTGERS>
To:   kmp, JONL
cc:   Solomon at RUTGERS

Sigh.. Lots of MACLISP bugs for me to report... Terrible lossage!

First, I brought down the new maclisp using LISP20;LISP F-CTL (or somesuch)
and I ran the .EXE from there, my CUBE got some sort of PC error on
protected memory (details below).. Then I tried to assemble the
LISP.MID.69 file, I ran it and it bombed with undefined JSYS..
I presume it is one of the VTS jsii, so someone has to add a VTS
switch so I can turn it off....

[here is what happened when I got the protected memory error..]

LISP 2022
Alloc? n


* 
(load '|s:<solomon>cdriv.lsp|)
;Loading SHARPM 67 
T 

(make-cube)
;Loading DEFMAX 77
;Loading LET 90
;#700027 PC WITH MEMORY PROTECTION VIOLATION
^C


Sigh... Tell me what else you need to know...

/JSol

Date:  5 FEB 1981 1721-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
Subject: Bug in (TAN 10), continued
To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC
CC: JPG at MIT-MC

This looks like it is a compilation bug (AC being clobbered?)
Just get a MACSYMA, quit into LISP, and (TRACE SIN COS).
You'll see that the argument to COS (which should be the same as the 
argument to SIN, obviously) is being clobbered.
The function TAN is defined in MRG;TRIGI > .
(Please try this in OA^K rather than A^K, so I can fix MACSYMA.)

Date: 5 February 1981 16:41-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  SYSP
To: EB at MIT-MC
cc: BUG-LISP at MIT-MC

The manual is misleading. They were assuming you redefine a SUBR by clobbering
its SUBR property. Personally, I think system symbols should return T even if
they are redefined. Eg, my fortran->lisp translator wants to know if it should
rename a fortran name if it conflicts with a lisp name ... It doesn't care if 
it (the translator) has redefined the name in the current environ, it just 
wants to protect the code it generates.

Date:  5 FEB 1981 1544-EST
From: EB at MIT-MC (Edward Barton)
Subject: SYSP
To: KMP at MIT-MC, (BUG LISP) at MIT-MC

    Date:  5 FEB 1981 1220-EST
    From: kmp at MIT-MC (Kent M. Pitman)
    Subject: SYSP
     It makes no claim to tell you if the
     functional property in effect is the system version.

According to the old LISP manual, it DOES make such a claim.
From that manual:

sysp                SUBR 1 arg

     The sysp predicate takes an  atomic symbol as an argument.  If  the atomic
     symbol is the name of a system function (and has not been redefined), sysp
     returns  the type  of function  (subr, lsubr,  or fsubr).   Otherwise sysp
     returns nil.

Date:  5 FEB 1981 1448-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

(tan 10) is wrong.  (tan 10.0) is correct.

Date:  5 FEB 1981 1220-EST
From: kmp at MIT-MC (Kent M. Pitman)
Sent-by: ___104 at MIT-MC
Subject: SYSP
To: REH at MIT-MC, WGD at MIT-MC
CC: (BUG LISP) at MIT-MC

(SYSP x) returns a non-() value if x is a symbol which has a system SUBR,
 LSUBR, FSUBR, or AUTOLOAD property. It also returns non-() if x is of typep
 RANDOM and is in the range of the binary program space of the initial lisp 
 system. Otherwise, it returns NIL. It makes no claim to tell you if the
 functional property in effect is the system version.
eg,
	(DEFUN LOAD (X) X)    => LOAD
	(LOAD 'FOO)	      => FOO
	(SYSP 'LOAD)          => SUBR
	(REMPROP 'LOAD 'SUBR) => (#...)
	(SYSP 'LOAD)	      => NIL

-kmp

Date:  5 FEB 1981 0030-EST
From: WGD at MIT-MC (William G. Dubuque)
Sent-by: BIL at MIT-MC
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

Why does (MULTIPLE-VALUES (A B) (VALUES 1 2)) lose? Also, why doesn't
(MULTIPLE-VALUE (A) ...) do the correct thing instead of losing; this
would be important for automatically generated code. (In particular,
the above will lose because of the ``crockish sysp check'' and also if,
for instance, we have (MULTIPLE-VALUE (A) 1) ).

Date:  5 FEB 1981 0026-EST
From: REH,WGD at MIT-MC
Sent-by: BIL at MIT-MC
To: (BUG LISP) at MIT-MC

	If a system function is redefined, SYSP does not take notice
of this (at least in the interpreter).

GSB@MIT-ML 02/04/81 20:11:16
To: (BUG LISP) at MIT-ML
(multiple-value-bind (a b c) (frobozzery)
	(declare (fixnum a b c))
	(mumble))
should expand into
(LET ((A (PROG2 (SETQ *:ARN 0.) (FROBOZZERY)
	    (AND (< *:ARN 2.) (SI:CHECK-MULTIPLICITIES 2.))))
      (B *:AR2) (C *:AR3))
   (DECLARE (FIXNUM A B C)) (MUMBLE))
so that the declare is properly placed.  (Isn't parallel binding neat?)


Date:  4 FEB 1981 1617-EST
From: JONL at MIT-MC (Jon L White)
Subject: COMPLR address space
To: PSZ at MIT-MC, GSB at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC

I've just made an investigation of packages the were put on
the list of things to be pre-loaded into complr, and removed
a few that there only due to "obarray dyslexia".  Current
XCOMPLR (version 1088) now has only 2K less space than
the COMPLR of 6 months ago, and this seems reasonable as
the amount by which the primitive facilities have grown.
Note that the two (STATUS MEMFREE)'s differ by 6K, but that
the more recent compiler has and additional 4K of reclaimed
LIST storage, so the net loss is only 2K.

Date:  4 FEB 1981 0741-EST
From: GZ at MIT-MC (Gail Zacharias)
Subject: allocation question
To: (BUG LISP) at MIT-MC

Could someone explain the following to me?
:LISP<space>
LISP 2057
Alloc?n
(sstatus flush t)
(suspend ":pdump gz;ts test
")
The resulting GZ;TS TEST file has size 18 blocks.  Now I try:
:LISP<space>
LISP 2057
Alloc?y
# REGPDL = 10000	0
# SPECPDL = 4000	0
# FXPDL = 10000 0
# FLPDL = 2000  0
 LIST =  40000  0
 SYMBOL = 6000  0
 FIXNUM = 14000 0
 FLONUM = 2000  0
 BIGNUM = 2000  0
 ARRAY = 1000   0
(sstatus flush T)
(suspend ":pdump gz;ts test
")
The file that results  from this is 21 blocks, i.e. larger.  If I do
(gc) before the sstatus, I get 16 and 19 blocks, respectively, still larger
despite all those 0's.  Thanks.

Date: 4 February 1981 04:28-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: severe consternation
To: GSB at MIT-ML
cc: BUG-LISP at MIT-ML, MOON at MIT-ML

    GSB@MIT-ML 01/20/81 18:27:37 Re: severe consternation
    To: (BUG LISP) at MIT-ML
    CC: MOON at MIT-ML
    Here i was, demonstrating the wonders of SETF preserving implicit
    order-of-evaluation.  I showed the macro-expansion of 
    (SETF (ARRAYCALL T (FOO) (BAR)) (BAZ)), and imagine my surprise when
    it came out to be:
    ((LAMBDA (G0002) ((LAMBDA (G0004 G0005 G0006)
			   (STORE (ARRAYCALL T G0004 G0005) G0006))
			(FOO) (BAR) G0002)
		     G0002)
       (BAZ))
    So, i said, "Well, i've got a SETF which isn't being used, but at least
    I can trust it.  Let's try it."  There was no fasl, so i loaded the source.
    What did it say?  It said ";TEM UNBOUND VARIABLE".  Closer examination
    showed that
    (DEFUN FOO (A B &AUX (C (F A)) (D (G C)))
	(LIST A B C D))
    produced the following definition:
    (DEFUN FOO (A B)
	(COMMENT ARGLIST = (A B))
	(LET ((D (G C)) (C (F A))) (LIST A B C D)))
    Gremlins, perhaps?
    The big question is this:  why is my compiled code working?
    Or is it?

BTW, I believe we forgot to report these as fixed.



Date: 4 February 1981 04:26-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: Writing structures to a file
To: BYRON at MIT-ML
cc: BUG-LISP at MIT-ML

    BYRON@MIT-ML 01/21/81 13:15:37 Re: Writing structures to a file
    To: (BUG LISP) at MIT-ML
    What is the canonical way to save DEFVST structures in a file.
    Does code exist to parse the #{} syntax?

No code currently exists to parse the #{} syntax.  However, it
wouldn't be that hard to write, and if you do so you should let
us know so we can steal it.

Another way of dealing with the problem is to define a method
to output code to produce the objects.  For example:

;; Everything not handled specially, just print
(DEFMETHOD* (:OUTPUT OBJECT-CLASS) (SELF FILE)
  (PRINT SELF FILE))

;; Unaesthetic, but workable
(DEFMETHOD* (:OUTPUT PAIR-CLASS) (SELF FILE)
  (PRINC "(" FILE)
  (SEND (CAR SELF) ':OUTPUT FILE)
  (PRINC " . " FILE)
  (SEND (CDR SELF) ':OUTPUT FILE)
  (PRINC ") " FILE))


(DEFVST MYFROB SLOT-A SLOT-B)

(DEFMETHOD* (:OUTPUT MYFROB-CLASS) (SELF FILE)
  (PRINC "#.(CONS-A-MYFROB SLOT-A  '" FILE)
  (SEND (MYFROB-SLOT-A SELF) ':OUTPUT FILE)
  (PRINC " SLOT-B '" FILE)
  (SEND (MYFROB-SLOT-B SELF) ':OUTPUT FILE)
  (PRINC ")
" FILE))


and then to output stuff to the file, instead of using
(PRINT <stuff> <file>), do

(SEND <stuff> ':OUTPUT <file>).  This will print code to
the file to reproduce <stuff> when read back in.  If you don't
mind always seeing your objects looking like this, you can just do

(DEFMETHOD* (:PRINT-SELF MYFROB-CLASS) (SELF FILE LEVEL SLASHIFY-P)
  (IF (NOT SLASHIFY-P)				;PRINC case, do as usual
      (SEND-AS STRUCT-CLASS SELF FILE LEVEL SLASHIFY-P)
      ;; Otherwise we output a form to be evaluated to get our object
      (PRINC "#." FILE)
      (PRINT-OBJECT `(CONS-A-MYFROB SLOT-A ,(MYFROB-SLOT-A SELF)
				    SLOT-B ,(MYFROB-SLOT-B SELF))
		    LEVEL SLASHIFY-P FILE)))

Thus, PRINC will print using the #{} syntax, but PRINT will print using
the #.(CONS-A-MYFROB ....) syntax.



Date: 4 February 1981 02:53-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: EB at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 2 February 1981 21:56-EST
    From: Edward Barton <EB at MIT-MC>
    To: BUG-LISP at MIT-MC
    
    Pardon me if this is documented, but is LINEL of an SFA really supposed
    to give the handler the SFA twice, once as the first and once as the third
    argument?
Hmm.  It seems that the LINEL message isn't documented at all.  (EB, the SFA
documentation lives in .INFO.;LISP SFA).  Anyway, this is definately a bug.
It should be giving () as the 3'rd argument when LINEL is called with 2
arguments.

Date:  3 FEB 1981 1738-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: :PUNT-YOURSELF
To: ALAN at MIT-MC, GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

C'mon, turkeys, just because the implementation of user objects in MacLisp is
less than stellar is no reason to assume (erroneously) that code which sends
messages cannot be transportable.  In fact, such an assumption is BLATANTLY
FALSE.  I have much code which I expect to run under NIL's FLAVOR system which
do not expect to have to change a single SEND for.  Message passing is supposed
to buy you independence of implementation, remember?

Writing it without a colon will be possible when the code which allows colons
for the other method names is installed.

The fact that these involve MacLisp's USERHUNKS and SFA's is totally irrelevant
to this discussion.  This implementation will not be transported, but CODE
SENDING MESSAGES USING THESE NAMES CERTAINLY WILL.

Date:  3 FEB 1981 1559-EST
From: JONL at MIT-MC (Jon L White)
Subject: FERROR
To: WGD at MIT-MC
CC: (BUG LISP) at MIT-MC

works again.

Date:  2 FEB 1981 2156-EST
From: EB at MIT-MC (Edward Barton)
To: (BUG LISP) at MIT-MC

Pardon me if this is documented, but is LINEL of an SFA really supposed
to give the handler the SFA twice, once as the first and once as the third
argument?

Date:  2 February 1981 1735-EST (Monday)
From: Guy.Steele at CMU-10A
To: Richard M. Stallman <RMS at MIT-AI> 
Subject:  TYPEP
CC: barbara.steele at CMU-10A, bug-lisp at MIT-MC
In-Reply-To:  Richard M. Stallman's message of 1 Feb 81 05:22-EST
Message-Id: <02Feb81 173550 GS70@CMU-10A>

The one-arg TYPEP
  Predicates not.
The two-arg TYPEP
  Exists only in thought.
And I will bet
  A steam calliope
There isn't any
  Three-arg TYPEP.
--TGQ (apologies to Ogden Nash)

Date:  2 FEB 1981 1557-EST
From: JONL at MIT-MC (Jon L White)
Subject: LET loses
To: (BUG LISP) at MIT-MC

Shouldn't (LET ((() (mumble)) (A 1)) (list A)) expand into
 ((LAMBDA (() A) (LIST A)) (MUMBLE) 1)
instead of the buggy
 ((LAMBDA (() A) (LIST A)) () 1)

Date:  2 FEB 1981 1008-EST
From: JONL at MIT-MC (Jon L White)
Subject: SLEEP on TOPS-20
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

    GSB@MIT-ML 01/31/81 22:21:33 Re: SLEEP loses on tops20
    To: BYRON at MIT-ML
    CC: (BUG LISP) at MIT-ML
	BYRON@MIT-ML 01/31/81 22:11:20
	On Tops20, in versions 1983 and 2022, (sleep x) where x is between
	0 and 1 acts like (sleep 0).  I.e. it doesn't seem to sleep at all.
    Wasn't this fixed?  It was reported long ago. .  .
I never worked on this one before, but I've just fixed it in the
source now.  Will re-assemble for TOPS-20 later today, and hopefully
be able to install a Twenex lisp shortly.

Date:  2 FEB 1981 0149-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

(PROGN (TYIPEEK -1) (READ))

If you then type a character, say an X, it does not get
put into the redisplay buffer. Also, typing any whitespace
will not cause the READ to return. However, some read macros
and "(" or ")" will give completion.


Date: 1 February 1981 17:39-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: :GIVE-ME-A-BREAK
To: ALAN at MIT-MC, RWK at MIT-MC
cc: BUG-LISP at MIT-MC

It does seem that the USERHUNK stuff is the next-to-the-last place i
would expect there to be any need for name compatibility.  (The last
is SFAs.)  By the way, alan, i certainly WOULD say that your defstruct
should accept the colon forms, as the use of that IS a situation where
you want the code to be textually compatible;  but then, i don't use
it (yet).  But :PRINT-SELF seems to be pretty gratuitous.  And
somewhat of a surprise (where is it documented?).  IF you have a layer
between the user-hunk stuff and your code, then that layer can make
all of the textual compatibility changes it wants.  (Then there is the
issue of exactly which names in there need the colons, and which do
not, as they will differ in maclisp.)  The user-hunk stuff provides a
nice primitive functionality;  please don't go messing with a basicly
incompatible facility to try and make it into what it is not.


Date: 1 February 1981 16:32-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: :GIVE-ME-A-BREAK
To: RWK at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 1 February 1981 09:47-EST
    From: Robert W. Kerns <RWK at MIT-MC>

    Your complaint is silly.  If you are going to write code which is
    textually compatible with a system with a package system, where
    ":" marks the keyword packge, you have to write the colon.  Or are
    you going to suggest that any symbols that you can be compatible
    for have to be in the GLOBAL package, or you always have to write
    #+MacLisp 'PRINT-SELF #-MacLisp ':PRINT-SELF ??  Have you got any
    better ideas?

    It IS a bug that the others don't even alias the : names to the
    non-: names.

Your answer is silly.  Look, trying to be compatable with people with
package systems is just fine with me.  I have nothing against programs that
do things like: 

	(if (memq subject '(punt-yourself /:punt-yourself))
	    (send-obnoxious-mail)
	    (send-flaming-mail))

just to help out people who want to write code that runs on
LispMachines.  You can even stick pins in me for not having done this
to defstruct yet, and I will just wince and take it.  But this is not
the same kind of situation here.  You are not ALLOWING me to use
colons if I like, you are FORCING me to use colons even if I DON'T like.

A USRHUNK handler is hardly a piece of code that I am likely to try to
bring up on the LispMachine!

Since I have no idea what kind of amazing hair you people have to use
the USRHUNK feature, I have no idea why you think you have to spell
the message with a colon.  But couldn't you just supply a handler that
accepted the messages both with and without colon?  then the MacLisp
system could continue to send uncolonified messages, and you could
send colonified messages and everything would win!  You could even
have an "any other" handler that RE-SENT messages spelt with a colon
without the colon!

But, OK, OK, end of flame, you can spell the message names any way you
like (even inconsistently!) and I can still win, so who cares.

Date: 1 February 1981 09:47-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: :PUNT-YOURSELF
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 1 February 1981 06:01-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Subject: XLISP
    To: BUG-LISP at MIT-MC
    
    You changed the USRHUNK printing message from PRINT to /:PRINT-SELF.
    The colon is silly.  Especially since none of the other messages have
    colons in their names.
Your complaint is silly.  If you are going to write code which is textually
compatible with a system with a package system, where ":" marks the keyword
packge, you have to write the colon.  Or are you going to suggest that any
symbols that you can be compatible for have to be in the GLOBAL package,
or you always have to write #+MacLisp 'PRINT-SELF #-MacLisp ':PRINT-SELF ??
Have you got any better ideas?

It IS a bug that the others don't even alias the : names to the non-: names.

Date:  1 FEB 1981 0601-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: XLISP
To: (BUG LISP) at MIT-MC

You changed the USRHUNK printing message from PRINT to /:PRINT-SELF.
The colon is silly.  Especially since none of the other messages have
colons in their names.

Date: 1 February 1981 05:22-EST
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-LISP at MIT-AI

Is Maclisp ever going to have two-argument TYPEP?


GSB@MIT-ML 01/31/81 22:21:33 Re: SLEEP loses on tops20
To: BYRON at MIT-ML
CC: (BUG LISP) at MIT-ML
    BYRON@MIT-ML 01/31/81 22:11:20
    On Tops20, in versions 1983 and 2022, (sleep x) where x is between
    0 and 1 acts like (sleep 0).  I.e. it doesn't seem to sleep at all.
    The Moonual says that it should work for arbitrary flonums and
    fixnums.  sleep does appear to work for flonums greater than 1.0
    however.
Wasn't this fixed?  It was reported long ago.  What is happening
is that the gets FIXed BEFORE it is multiplied by 1000. [the system
call takes an arg in milliseconds], so ALL flonum args are being
truncated.


BYRON@MIT-ML 01/31/81 22:11:20
To: (BUG LISP) at MIT-ML
CC: BYRON at MIT-ML
On Tops20, in versions 1983 and 2022, (sleep x) where x is between
0 and 1 acts like (sleep 0).  I.e. it doesn't seem to sleep at all.
The Moonual says that it should work for arbitrary flonums and
fixnums.  sleep does appear to work for flonums greater than 1.0
however.


Date: 30 January 1981 18:11-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DEFUN&-CHECK-ARGS putting out a ARGS request
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 30 JAN 1981 1737-EST
    From: JONL at MIT-MC (Jon L White)

        Date: 30 January 1981 17:03-EST
        From: Glenn S. Burke <GSB at MIT-ML>
        .  .  .  i said that i fixed
        it, since it didn't look like it would get fixed any other way.
    So why all the flaming?
Yes, why?
        ...  i thought it
        dumb and inconsistent that the ARGS info should be put out ONLY if i
        set DEFUN&-CHECK-ARGS to NIL.  I feel that it should ALWAYS be output.
        The argument about not doing it because of purification does NOT hold
        up in most cases, because most people don't have such symbols already
        extant in a pure dump (eg TO-STRING in the base Lisp).
    So why didn't you do that too?   I don't have any case against doing the 
    call to ARGS when DEFUN-&CHECK-ARGS is ().  In fact, why not let 
    DEFUN-&CHECK-ARGS = () be the default state, so that a loser has to reset 
    it if he wants the explicit args checking code in his function.
Again why?  Because this opinion is not the one expressed in the original
message.  It is not an opinion expressed by the implementation of the
code.  I think it is fairly normal for one to infer some justification
for default settings of flags and default behaviour of code controlled
by those flags.  I don't make it a practice to go changing the functionality
of things (even if it is only the default value of flags) when it is
something which might be noticed by others, as that can be a severe
inconvenience to them even if it is something they can trivially
compensate for.  I tend to make the assumption (which it appears
is frequently unjustified) that there is Good Reason for things to
be The Way They Are.  So when i get spurious babblings i tend to take
offense.
If i were to make a practice of changing functionality of things when
they didn't suit me i might not be able to stop, given the current
state of things.


Date: 30 JAN 1981 1737-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFUN&-CHECK-ARGS putting out a ARGS request
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 30 January 1981 17:03-EST
    From: Glenn S. Burke <GSB at MIT-ML>
    .  .  .  i said that i fixed
    it, since it didn't look like it would get fixed any other way.
So why all the flaming?
    ...  i thought it
    dumb and inconsistent that the ARGS info should be put out ONLY if i
    set DEFUN&-CHECK-ARGS to NIL.  I feel that it should ALWAYS be output.
    The argument about not doing it because of purification does NOT hold
    up in most cases, because most people don't have such symbols already
    extant in a pure dump (eg TO-STRING in the base Lisp).
So why didn't you do that too?   I don't have any case against doing the 
call to ARGS when DEFUN-&CHECK-ARGS is ().  In fact, why not let 
DEFUN-&CHECK-ARGS = () be the default state, so that a loser has to reset 
it if he wants the explicit args checking code in his function.

Date: 30 January 1981 17:27-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: *:TRUTH affecting <=
To: JONL at MIT-MC
cc: "(FILE [NUL:])" at MIT-ML, BUG-LISP at MIT-MC


    Date: 30 JAN 1981 1712-EST
    From: JONL at MIT-MC (Jon L White)

    NO, *:TRUTH shouldn't be affecting <= or >= in MacLISP -- I've
    fixed it now (in the MLSUB file);  *:TRUTH is a NIL variable
    to hold the canonical truth value.

Then why is it cluttering up my Maclisp?


Date: 30 JAN 1981 1712-EST
From: JONL at MIT-MC (Jon L White)
Subject: *:TRUTH affecting <=
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

NO, *:TRUTH shouldn't be affecting <= or >= in MacLISP -- I've
fixed it now (in the MLSUB file);  *:TRUTH is a NIL variable
to hold the canonical truth value.

Date: 30 January 1981 17:03-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DEFUN&-CHECK-ARGS 
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC


    Date: 30 JAN 1981 1615-EST
    From: JONL at MIT-MC (Jon L White)

    I'm not sure I understand your flaming -- isn't
      (SETQ DEFUN&-CHECK-ARGS () )
    just what you want?  Do you claim that the ARGS info is getting
    the wrong value now?

Of course it's what i want.  I wouldn't be complaining about getting
screwed by it if i weren't trying to use it.  And no, i am not
claiming that it is getting the wrong value now, i said that i fixed
it, since it didn't look like it would get fixed any other way.  My
original statement, long ago (at least 4 days), was that i thought it
dumb and inconsistent that the ARGS info should be put out ONLY if i
set DEFUN&-CHECK-ARGS to NIL.  I feel that it should ALWAYS be output.
The argument about not doing it because of purification does NOT hold
up in most cases, because most people don't have such symbols already
extant in a pure dump (eg TO-STRING in the base Lisp).


GSB@MIT-ML 01/30/81 16:47:18 Re: offensive incompatibility
To: (BUG LISP) at MIT-ML
If i get an XLISP and do
(SETQ *:TRUTH '|True|)
then (<= 2 3) returns |True|, but (< 2 3) still returns T.
They should at least be consistent.


GSB@MIT-ML 01/30/81 16:39:20
To: (BUG LISP) at MIT-ML
this goddamned fucking badpi interrupt on startup is getting to be a real pain

Date: 30 JAN 1981 1615-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFUN&-CHECK-ARGS 
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

I'm not sure I understand your flaming -- isn't
  (SETQ DEFUN&-CHECK-ARGS () )
just what you want?  Do you claim that the ARGS info is getting
the wrong value now?

Date: 30 January 1981 16:05-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DEFUN&-CHECK-ARGS
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC


    Date: 30 JAN 1981 1557-EST
    From: JONL at MIT-MC (Jon L White)

    I remember you had a question earlier this month about when
    DEFUN& would output (ARGS 'FOO ...).  Well, the variable
    DEFUN&-CHECK-ARGS only controls the insertion of number-of-arg-
    checking code into the body of the function -- thus if such code
    did get inserted, it is presumed that the ARGS needn't be
    changed (and there are reasons why you might not want to 
    change it frivously -- like, not having to unpurcopy the
    symbol).
Tell me about it.  I recently fixed a bug which was screwing me to the
wall because i set DEFUN&-CHECK-ARGS to NIL:  it was outputting 
(ARGS 'FN ...), INCORRECTLY.  And ONLY when i set DEFUN&-CHECK-ARGS to
NIL.  I take it you consider such ARGS information not useful.  My
complaint had nothing to do with changing ARGS info, only having it there
in the first place.  The only one who loses because of having to unpurcopy
the symbol is YOU, since MY functions aren't all defined with autoload
properties in Maclisp already;  when ARGS gets called on them, the
SY block is impure, even though it may be marked for purification.
I still think that such number-of-arg checking should be left to
the interpreter/uuo-linker, and i also think it is gross that the
interface from an APPLY or EVAL generated error is different from
one generated in-line.


Date: 30 JAN 1981 1557-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFUN&-CHECK-ARGS
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

I remember you had a question earlier this month about when
DEFUN& would output (ARGS 'FOO ...).  Well, the variable
DEFUN&-CHECK-ARGS only controls the insertion of number-of-arg-
checking code into the body of the function -- thus if such code
did get inserted, it is presumed that the ARGS needn't be
changed (and there are reasons why you might not want to 
change it frivously -- like, not having to unpurcopy the
symbol).

Date: 30 JAN 1981 1556-EST
From: DCP at MIT-MC (David C. Plummer)
Subject:  simple and useful demonstrative case
To: (BUG LISP) at MIT-MC


(defun fib (n)
       (do ((old 0 new)
	    (new 1 (+ old new))
	    (i 0 (1+ i)))
	   ((= i n) old)))

This is our friend the fibonacci numbers. I want to demonstrate
it to people and compile it for my own use. I know it uses
fixnums, but that's ok.

Run it interpretted:
   (setq base (setq ibase 10.))
   (fib 20)
   6765.				; the AI phone number
demonstrate the compiler: (compiled function loaded of course)
   (fib 20)
   524288.				; phone number??

A naive user would be totally lost at such a response from such a
simple (and useful) function.

Date: 30 JAN 1981 1046-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFMACRO-DISPLACE 
To: GJS at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 28 January 1981 23:18-EST
    From: Gerald Jay Sussman <GJS at MIT-AI>
    (defmacro-displace foo (x) (list x 'y)) generates bad expr code:
    (lambda (foo-macroarg) (comment ...) displace foo-macroarg ...)
    missing parens around the displace.
Yes, how embarrassing. I've just fixed it now.  
Note that the macro code will work ok -- it just wont displace.  
Remember also that using DEFMACRO with default options,  instead of 
  DEFMACRO-DISPLACE, gives you the capability of deciding at runtime 
  what to do about DISPLACEment. 

Date: 30 JAN 1981 0942-EST
From: JONL at MIT-MC (Jon L White)
To: DCP at MIT-MC
CC: (BUG LISP) at MIT-MC, rod at SU-AI

Re the long-standing COMPLR failure:
    Date: 29 January 1981 20:28-EST
    From: David C. Plummer <DCP at MIT-MC>
    Will somebody please fix this? PLEASE?? This ==> BUG <== hit me today, 
	 Date: 16 Jan 1981 0319-PST
	 From: Rod Brooks <ROD at SU-AI>
	 Subject: COMPLR can't do DO 
	 I have vague memories of complaining about something like this years 
	 ago but maybe this is different. In any case I wish it didn't happen 
	 this way.
	 (defun baz (n)
		(do ((old 1 new)
		     (new 2 (1+ new))
		     (l () (cons (list old new) l))
		     (i 0 (1+ i)))
		    ((= i n) l)))
	 interpreted:
	 (baz 4) ==> ((4 5) (3 4) (2 3) (1 2)) 
	 compiled (both 905 and 924):
	 (baz 4) ==> ((5 5) (4 4) (2 3) (1 2)) 
    Perhaps COMPLR thinks it is too smart. 
This is a long-standing bug which fortunately has hit only a very few
persons (notably, GLR twice, GSB once I believe, and now ROD and DCP).
The problem occurs precisely if there are local variables being SETQ'd in
parallel, such as in a DO loop, which haven't been declared numeric, 
*** but which in fact are being used a numeric variables ***.  Possibly 
the reason so few instances of this lossage occur is that most persons 
would have already done (DECLARE (FIXNUM OLD NEW)).  I don't think anyone 
wants to work on correcting this bug now (for lack of time mainly),
so maybe it should be 'documented'.

Date: 30 Jan 1981 0124-PST
From: Lowe at SRI-CSL (Jay Lowe)
Subject: MACLISP compiler
To:   bug-lisp at MIT-AI
cc:   jonl at MIT-AI


I have been asked to put up the MACLISP compiler on this machine.

Is it available and if so, how should I obtain it with minimum hassle
for y'all...

Jay
-------


Date: 30 January 1981 00:34-EST
From: Richard M. Stallman <RMS at MIT-AI>
To: BUG-LISP at MIT-AI

I hear that Maclisp now has something like the Lisp machine's
user-supplied compiler optimizers.  But it is not compatible
with the Lisp machine.

I think it ought to be changed to be compatible,
especially since it isn't in use by users yet.


Date: 29 January 1981 21:51-EST
From: Kent M. Pitman <KMP at MIT-MC>
To: SGR at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 29 January 1981 20:01-EST
    From: Stephen G. Rowley <SGR>
    To:   BUG-LISP

    while loading a file, the following happened:
    ILOPR; 1652>>0   0/   0   0/   0
    and the lisp died...
-----
If it is a compiled file you are loading, it may well not be a Lisp bug,
but yours. If it is one of your files, and it is compiled, try running
the file interpreted. In any case, the name of the particular file so
we can reproduce it would have to be given in order for this to get looked at
at all. -kmp

Date: 29 JAN 1981 2028-EST
From: DCP at MIT-MC (David C. Plummer)
Subject:  PLEASE???
To: (BUG LISP) at MIT-MC


Will somebody please fix this? PLEASE?? This ==> BUG <== hit me
today, and most people compile their code for speed.


     Date: 16 Jan 1981 0319-PST
     From: Rod Brooks <ROD at SU-AI>
     Subject: COMPLR can't do DO 
     To:   bug-lisp at MIT-MC    

     I have vague memories of complaining about something like this years ago
     but maybe this is different. In any case I wish it didn't happen this way.

     (defun baz (n)
	    (do ((old 1 new)
		 (new 2 (1+ new))
		 (l () (cons (list old new) l))
		 (i 0 (1+ i)))
		((= i n) l)))

     interpreted:
     (baz 4) ==> ((4 5) (3 4) (2 3) (1 2)) 

     compiled (both 905 and 924):
     (baz 4) ==> ((5 5) (4 4) (2 3) (1 2)) 

Perhaps COMPLR thinks it is too smart. 

Date: 29 JAN 1981 2001-EST
From: SGR at MIT-MC (Stephen G. Rowley)
To: (BUG LISP) at MIT-MC

while loading a file, the following happened:
ILOPR; 1652>>0   0/   0   0/   0
and the lisp died...

Date: 28 January 1981 23:18-EST
From: Gerald Jay Sussman <GJS at MIT-AI>
To: BUG-LISP at MIT-AI

(defmacro-displace foo (x) (list x 'y)) generates bad expr code:
(lambda (foo-macroarg) (comment ...) displace foo-macroarg ...)
missing parens around the displace.


Date: 28 JAN 1981 2202-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: SETF losing on FIX-I stuff...
To: (BUG LISP) at MIT-MC

(MACROEXPAND '(SETF (FIXNUM-IDENTITY (CAR X)) Y))

  => (PROGN (FIXNUM-IDENTITY (RPLACA X Y)) Y)

This seems to me to be a bit silly... I suspect it means that the recursive
relation you are using to do expansions in general has a bug in it ... whatever
mechanism you use should see to it that the FIXNUM-IDENTITY is held to the
outside... I don't really understand why it doesn't just return

  (FIXNUM-IDENTITY (SETF (CAR X) Y))

and then let the SETF inside get expanded later. That would assure that later
an independent macroexpansion would leave you with the form

  (FIXNUM-IDENTITY (PROGN (RPLACA X Y) Y))

which is what I think ought to be returned ... I still question whether

(SETF (FIXNUM-IDENTITY x) y) shouldn't turn into 
(FIXNUM-IDENTITY (SETF x (FIXNUM-IDENTITY y)))

since in the case of GJC's generalization of PUSH/POP, it might be useful
to know the typep of the value being put into the slot ... 
-kmp

Date: 28 JAN 1981 1620-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFVST
To: (BUG LISP) at MIT-MC

the "&REST" option is losing -- try
(DEFVST BANK MANAGER &REST VAULTS)
(SETQ CBT (CONS-A-BANK MANAGER 'BILL VAULTS 6))
and notice that BANK-VAULTS has a SELECTOR property, but
not a MACRO property.

Date: 28 January 1981 12:36-EST
From: Glenn S. Burke <GSB at MIT-MC>
Subject: what gives?
To: BUG-LISP at MIT-MC

    Date: 26 JAN 1981 1658-EST
    From: GSB at MIT-MC (Glenn S. Burke)

    Here is a bug report i sent in some time back.  Attempting to ressurect
    some code shows that it wasn't fixed.
        GSB@MIT-ML 09/07/80 01:51:15 Re: +tyo loses on sfas in *rset T
        To: (BUG LISP) at MIT-ML
        ptyo2/movei ar1,(b)
        ptyo2+1/jsp tt,xfosp
        ptyo2+2/jfcl
        ptyo2+3/skipa
        ptyo2+4/jrst ptyo3
        ptyo2+5/jsp t,fxnv1
----
Fixed in source, patched in lisps 2057 and 2070

Date: 28 January 1981 06:35-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: sfa error checking
To: KMP at MIT-MC
cc: GZ at MIT-MC, BUG-LISP at MIT-MC

    Date: 27 January 1981 05:26-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    Subject:  sfa error checking
    To: GZ at MIT-MC
    cc: BUG-LISP at MIT-MC
    
	Date: 20 December 1980 08:48-EST
	From: Gail Zacharias <GZ>
	Re:   sfa error checking
    
	Consider the following session:
	    (defun nothin N '())
	    NOTHIN 
	    (setq test (sfa-create #'nothin 17. 'testing))
					    =>	#SFA-|TESTING|-70766 
	    (open test)			=>	NIL 
	    (close test)			=>	NIL 
	    (deletef test)			=>	NIL 
	    (filepos test 13.)		=>	NIL 
	    (sfa-call test #'untyi ())	=>	NIL 
	    (tyo 3 test)			=>	T 
	    (out test 2)			=>	NIL 
	    (force-output test)		=>	NIL 
	    (prin1 1 test)			=>	T 
	    (princ 'a test)			=>	T 
	    (print 'foo test)		=>	T 
	    (cursorpos test)		=>	NIL 
	    (in test)			=>	;NIL NON-FIXNUM VALUE
					       ;; Well, at least this one errs out
	  
	Do I have to define all these operations just to have them err out?
	TYI is the only one that actually complains that it is not supported.
    -----
    Yes. For the time being at least, a common way of handling this problem 
    is:
    
      (DEFUN NOTHING (SELF OP DATA)
	     (CASEQ OP
		    ((WHICH-OPERATIONS) '(TYO CLOSE))
		    ((TYO)		    ...code...)
		    (T
		     (ERROR "Unsupported SFA Operation"
			    (LIST 'SFA-CALL SELF OP DATA)))))

Even better, you should look at the file .INFO.;LISP SFA, which contains
(has for a few weeks, but didn't if you read it before then) documentation
for DEFSFA, which takes care of issues like erroring out and handling
WHICH-OPERATIONS.

Date: 28 JAN 1981 0437-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Bugs in LISTARRAY with 2 args
To: (BUG LISP) at MIT-MC

In a bare lisp,
 (SETQ A (*ARRAY NIL T 100)) => #T-100-70776
 (LISTARRAY A 1)             => NIL
 (LISTARRAY A 0)	     => MPV;LISTA1>>HRRZ B,@A(C)  B/ 0  530157/ ??
In a new bare lisp,
 (SETQ A (*ARRAY NIL 'FIXNUM 100)) => #T-100-70776
 (LISTARRAY A 1)		   => (0)
 (LISTARRAY A 0)		   => (100)

Both of these behaviors seem a bit silly. I would like VERY much if 
(LISTARRAY array n) for n=0 returned NIL. It is otherwise much less useful
than it might be. (n=-1 seems to get the whole array.)
-kmp

Date: 28 January 1981 01:19-EST
From: Gerald Jay Sussman <GJS at MIT-AI>
To: BUG-LISP at MIT-AI

There is no TS NCOMPL on AI.  SYS1;TS N points to SYS1;TS NCOMPL
which does not exist.


Date: 27 JAN 1981 1209-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFUN&
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC

I've just fixed a bug in DEFUN& whereby &optional and &aux
vars were sometimes not being bound "sequentially".

Date: 27 January 1981 10:32-EST
From: Edward Barton <EB at MIT-AI>
To: BUG-LISP at MIT-AI

(alphalessp nil 'D) and (alphalessp 'd nil) are both NIL in XLISP
on AI.  I'm not a LISP internals hacker, but my hypothesis is as
follows.  Last time I checked, ALPHALESSP began with instances of
a type-checking macro names SKOTT or something.  It's my understanding
that that macro just checks the type bits to see if they correspond
to being a symbol and doesn't do anything special for NIL.  So it
doesn't think NIL is a symbol, and it doesn't retrieve the PNAME
properly.  A couple of JUMPE's or something might be in order.


Date: 27 January 1981 05:26-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  sfa error checking
To: GZ at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 20 December 1980 08:48-EST
    From: Gail Zacharias <GZ>
    Re:   sfa error checking

    Consider the following session:
        (defun nothin N '())
        NOTHIN 
        (setq test (sfa-create #'nothin 17. 'testing))
					=>	#SFA-|TESTING|-70766 
        (open test)			=>	NIL 
        (close test)			=>	NIL 
        (deletef test)			=>	NIL 
        (filepos test 13.)		=>	NIL 
        (sfa-call test #'untyi ())	=>	NIL 
        (tyo 3 test)			=>	T 
        (out test 2)			=>	NIL 
        (force-output test)		=>	NIL 
        (prin1 1 test)			=>	T 
        (princ 'a test)			=>	T 
        (print 'foo test)		=>	T 
        (cursorpos test)		=>	NIL 
        (in test)			=>	;NIL NON-FIXNUM VALUE
					   ;; Well, at least this one errs out
      
    Do I have to define all these operations just to have them err out?
    TYI is the only one that actually complains that it is not supported.
-----
Yes. For the time being at least, a common way of handling this problem 
is:

  (DEFUN NOTHING (SELF OP DATA)
	 (CASEQ OP
		((WHICH-OPERATIONS) '(TYO CLOSE))
		((TYO)		    ...code...)
		(T
		 (ERROR "Unsupported SFA Operation"
			(LIST 'SFA-CALL SELF OP DATA)))))


Date: 27 JAN 1981 0340-EST
From: JONL at MIT-MC (Jon L White)
Subject: SFA Lossage
To: RPG at SU-AI, LSP at SU-AI
CC: (BUG LISP) at MIT-MC, ejg at SU-AI

    Date: 26 Jan 1981 1529-PST
    From: Lisp files <LSP at SU-AI>
    Subject: SFA Loss 
    Jonl, the following makes the reader lose. In particular, when it tries to
    put together OXYZY it gets two nulls in a row. 
    The problem centers around the (ascii (car sfa-buffer)) in that changing 
    that to () or to (ascii 101) does not cause the lossage, which happens at 
    MC as well.
    .  .  . | P O OXYZY OXYZT OXYZT |  .  .  .
Indeed, there are a number of "screws" that we have been finding out as
the SFA feature gets more usage -- this one is due to the fact that the
ASCII function will ocasionally clobber a word of the PNBUF (a 10 word
vector which is READ's buffer for words of a forming pname).  As it
happens, READLIST also has this side effect, so I put in a little code
to preserve-and-restore the portion of the PNBUF which is clobbered.
Your conjecture that some "register" was getting clobbered by the
sfa function was correct -- it's just that the "register" was this
writeable vector of words.  Do a SRCCOM on the latest version of
MC:L;READER >  to see how I fixed it.

Date: 26 JAN 1981 1739-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Odd case of LEXPR-FUNCALL
To: (BUG LISP) at MIT-MC

I don't really care if LEXPR-FUNCALL supports FSUBRs. In fact, I'd prefer
if it didn't bother running the code to get those props, as I think it
is totally awful for anyone to actually LEXPR-FUNCALL a FEXPR ... 

HOWEVER, I do wonder why if 

	(LEXPR-FUNCALL #'QUOTE '((F))) => F ;win
	(LEXPR-FUNCALL #'QUOTE '(F))   => #74332 ; ie, (CAR 'F) -- reasonable

then how could

	(LEXPR-FUNCALL #'QUOTE NIL) => #100346 

since if QUOTE did any arg checking, it would know it had been given a bad
arg, and since if you did 2 extra CARs of NIL, you'd get NIL, not #100346 ...

What kind of nonsense is it doing that gets me such an obscure return value?


Date: 26 JAN 1981 1658-EST
From: GSB at MIT-MC (Glenn S. Burke)
Subject: what gives?
To: (BUG LISP) at MIT-MC
CC: WAM at MIT-MC

Here is a bug report i sent in some time back.  Attempting to ressurect
some code shows that it wasn't fixed.
    GSB@MIT-ML 09/07/80 01:51:15 Re: +tyo loses on sfas in *rset T
    To: (BUG LISP) at MIT-ML
    ptyo2/movei ar1,(b)
    ptyo2+1/jsp tt,xfosp
    ptyo2+2/jfcl
    ptyo2+3/skipa
    ptyo2+4/jrst ptyo3
    ptyo2+5/jsp t,fxnv1

Date: 26 January 1981 14:59-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  TYIPEEK on SFA's
To: GZ at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 26 January 1981 10:34-EST
    From: Gail Zacharias <GZ>
    Re:   TYIPEEK on SFA's

    This doesn't work with non-trivial first argument (i.e. lisp doesn't 
    implement it itself), and it's not possible for the sfa to do it itself,
    because it never sees the first argument.
-----
It's probably just as well. The first arg to TYIPEEK is icky anyway.

GSB@MIT-ML 01/26/81 14:39:13 Re: this random pdl overflow business
To: (BUG LISP) at MIT-ML
is getting to be a real drag.  Can't something be done???
With load doing an unwind-protect in xlisp it's getting more frequent...


Date: 26 January 1981 14:14-EST
From: Richard C. Waters <DICK at MIT-AI>
Subject: debug
To: RWK at MIT-MC
cc: KMP at MIT-AI, RMS at MIT-AI, BUG-LISP at MIT-AI


	I made debug* (I didn't know enough at the time to call it
NDEBUG) be upward compatable with the only other debug I knew of at
the time.  I didn't know about your debug until today.  I think that
a merger of the two versions is the only GOOD solution.  I would
be glad to spend a little time helping that along.  My version is
very old, and is written in very old lisp using a bunch of my
macros.  It should be rewritten anyway.  I would be glad to rewrite my
version in vanilla lisp, and cooperate on a joint command set, if
you would add the features you have a particular knowledge of into it.
There is no reason that we should continue with three versions of DEBUG.

			Dick

Date: 26 JAN 1981 1034-EST
From: GZ at MIT-MC (Gail Zacharias)
Subject: TYIPEEK on SFA's
To: (BUG LISP) at MIT-MC

This doesn't work with non-trivial first argument (i.e. lisp doesn't implement
it itself), and it's not possible for the sfa to do it itself, because it
never sees the first argument.

Date: 25 January 1981 17:59-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  Does anyone use LIBLSP;DEBUG and dislike LIBLSP;DEBUG*?
To: RMS at MIT-AI
cc: RWK at MIT-MC, TLP at MIT-MC, DICK at MIT-MC, BUG-LISP at MIT-MC

    MSG:  DEBUG* 1     
    Date: 01/25/81 06:10:12
    From: RMS at MIT-AI
    Re:   Does anyone use LIBLSP;DEBUG and dislike LIBLSP;DEBUG*?

    If nobody complains, I will flush DEBUG and replace it with DEBUG*.
    I don't plan to maintain it, just to install it.
-----
Do not install it. On MC, the DEBUG FASL on LIBLSP; (RWK's) is different
and has been for years. It evolved from TLP's AI version but is much extended.
It is also the version which goes out on the release tape and everyone here
is quite satisfied with it. There are significant differences between it
and DICK's DEBUG* make it warranted to at least retain the MC version of
DEBUG. If you find people don't use TLP's much, you might want to standardize
the naming so that RWK's DEBUG package is used on all sites, and leave 
DICK's as DEBUG* since anyone now using it will expect to find it under
that name anyway. -kmp

Date: 25 JAN 1981 1308-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

Gee, what a loss.  FILEPOS of FASLOAD's file array always returns 0.

Date: 25 JAN 1981 1001-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: GJC at MIT-MC, JPG at MIT-MC

Could this bug be fixed some time?
   JPG@MIT-MC 26 MAR 1980 0648-EST
   To: (BUG LISP) at MIT-MC
   In a fresh LISP, (MERGEF '(1 2 3) DEFAULTF) gives an ILOPR; error.
   I think some form of bad file specification error would be more 
   appropriate.

Date: 24 JAN 1981 1148-EST
From: JONL at MIT-MC (Jon L White)
Subject: THROW not featureful
To: (BUG LISP) at MIT-MC

(UNWIND-PROTECT (*THROW () () ) (PRINT 'CLEANING-UP))
barfs about not finding a catch tag for nil.  Why doesn't it
just trundel up to top level?

Date: 24 JAN 1981 0601-EST
From: JONL at MIT-MC (Jon L White)
Subject: CGOL and CGPRIN
To: JL at MIT-MC
CC: (BUG LISP) at MIT-MC

For the record, I just recompiled the current sources, and
"protected" the fasl files (on MC) so that they don't get moved
off disk.  Tnx (to JL) for mentioning that CGPRIN FASL had
disappeared.

GSB@MIT-ML 01/23/81 12:59:45
To: (BUG LISP) at MIT-ML
    WAM@MIT-ML 01/23/81 10:09:14
    I'VE HAD TWO MORE CASES OF THE RANDOM PDL OVERFLOW COMPILING
    SMALL FILES.  IN EACH CASE IT WORKED ON A SECOND TRY.
for the record, all of these i have looked at seem to happen at the
tail end of a compiled unwind-protect, immediately after (or perhaps
it is during and the stack has been frobnicated) the unbinding of
+internal-without-interrupts.  The .DF1 word when the pdlov code is
run is one used for memerr interrupts, not pdlov interrupts.


Date: 23 JAN 1981 0410-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: REM's query
To: (BUG LISP) at MIT-MC

I responded to him.

Date: 23 JAN 1981 0409-EST
From: REM at MIT-MC (Robert Elton Maas)
To: WJL at MIT-MC, (BUG LISP) at MIT-MC

What is the "LISP FORUM"??

Date: 23 JAN 1981 0111-EST
From: JONL at MIT-MC (Jon L White)
Subject: MSETQ-CALL
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

I fixed it so that (MSETQ-CALL (A B) (MUMBLE)) expands into
(PROG2 (SETQ A (MUMBLE) B *:AR2) A) instead of just the
SETQ expression -- thus MSETQ-CALL has the same return value
now as MULTIPLE-VALUE on the LISPM.

Date: 22 JAN 1981 1844-EST
From: BYRON at MIT-MC (Byron Davies)
To: (BUG LISP) at MIT-MC

Dumparrays doesn't work on TOPS20.
FILLARRAY doesn't like to fill a file array.

Date: 22 JAN 1981 0002-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Not accepting SFA's
To: (BUG LISP) at MIT-MC
CC: BYRON at MIT-MC

INPUSH also doesn't accept SFA's as I have reported before. That should be
fixed at the same time as STATUS TTYCONS.

Date: 21 JAN 1981 2328-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC
CC: GJC at MIT-MC, ALAN at MIT-MC

ALAN said today "hey, you know, there are a whole *hell* of a lot
of symbols which are |FOOBAR MACRO| now in maclisp, sounds like
time for a MACRO-SUBR property". We talked about this for
a while, (many obvious problems, many not so obvious), and
came up with the following scheme, which will save
space and hair.

(defmacro <name> <argument-list>
          <body>)

Will give <name> a MACRO property of MACRO-HANDLER and
a MACRO-EXPR property of whatever is made from the <argument-list>
and the <body>. When compiled a MACRO-SUBR property will be given.
Then the MACRO-HANDLER will deal with all the displacing and
number-of-arguments checking, and perhaps even with the destructuring.
[The ARGS property could be used for the number-of-arguments check.]

Presently, macros turn into gross stuff, example:

(defmacro aset (val ar &rest l) `(store (funcall ,ar ,@l) ,val))

(grindef aset)

(DEFUN ASET MACRO (ASET-MACROARG) 
  (COMMENT ARGLIST = (VAL AR &REST L))
  (OR (MACROFETCH ASET-MACROARG)
      (MACROMEMO ASET-MACROARG
		 (PROGN (AND (NOT (NOT (< (LENGTH ASET-MACROARG) 3)))
			     (ERROR '|Wrong number args to a macro call|
				    ASET-MACROARG))
			(LET (((VAL AR . L) (CDR ASET-MACROARG)))
			     `(STORE (FUNCALL ,AR ,@L) ,VAL)))
		 'ASET)))

Not only is this a waste of time to look at, it wastes space
in sorely pressed maclisp.
With the ALAN/GJC scheme (grindef aset) would show

(DEFUN (ASET MACRO-EXPR) (ASET-MACROARG)
       (LET (((VAL AR . L) (CDR ASET-MACROARG)))
	    `(STORE (FUNCALL ,AR ,@L) ,VAL)))

In summary, the only thing which would have to be changed is
Defmacro and Grindef.

p.s. The advantage of having a Handler do the destructuring
(which we haven't shown here), is that it could afford (in space) to do
it correctly! Presently a compiled "defmacro" gets no error checking
in maclisp. e.g. (defmacro foo ((a . b) . c) `(bar ',a ',b . ,c))
(foo 1 2 3) macroexpands into (bar 'nil '#1 2 3). 

The hacker general has long determined that having macros expand into
totally random pointers generated by HLRZ and HRRZ is hazardous
to your health.


Date: 21 JAN 1981 2315-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(DEFAULTF '((DSK KMP) * >))	=>	((DSK KMP) * >))
(SETQ F (OPEN))			=>	#FILE-IN-|DSK:KMP;* LOGIN|-70772
(DEFAULTF '(KMP >))		=>	((DSK KMP) KMP >))
(CLOSE F)			=>	T
(OPEN F)			=>	#FILE-IN-|DSK:KMP;KMP XYMAIL|-70772

Please excuse the no-arg call to OPEN. That's not really relevant. Anyway,
I don't think that if an explicit file arg is given for re-opening, the name
should be MERGEF'd with DEFAULTF before opening. I think if the guy tries to
reopen a file, it's clear that he wants the same specs. If he CNAMEF'd the
file, that's another issue, but reopening a real file object should happen
with NODEFAULT as a default option.

Date: 21 JAN 1981 2150-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(CURSORPOS 5000. 0.) on a printing terminal in a fresh lisp returns T as if
the operation had succeeded instead of NIL as it claims it will on failing
operations (eg, (CURSORPOS 'U) correctly returns NIL on printing ttys) ...
-kmp

GSB@MIT-ML 01/21/81 21:13:17
To: (BUG LISP) at MIT-ML
(sort '(a b c nil d e f) 'alphalessp)
=> (A B C NIL D E F)


Date: 21 JAN 1981 2049-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

DEFUN is setting up an incorrect ARGS property for the function
MTRACE-OPTION-P in the file MAXSRC;NTRACE BUGGER

DICK@MIT-ML 01/21/81 17:55:40
To: (BUG LISP) at MIT-ML
	DEFSETF DOESN'T SEEM TO HAVE AN AUTOLOAD PROPERTY LIKE IT SHOULD
			DICK WATERS


BYRON@MIT-ML 01/21/81 13:18:26 Re: (sstatus ttycons ...)
To: (BUG LISP) at MIT-ML
Is there any reason why the arguments to (sstatus ttycons ...) aren't
allowed to be SFAs?  I've been hacking various ways to make
cursorpos work in Tops20 Maclisp, and one is to make TYO
be an SFA that simulates CRTSTY.

I'd like to be able to link TYI with this new TYO, but
(sstatus ttycons ...) won't let me.


BYRON@MIT-ML 01/21/81 13:15:37 Re: Writing structures to a file
To: (BUG LISP) at MIT-ML
What is the canonical way to save DEFVST structures in a file.
Does code exist to parse the #{} syntax?


GSB@MIT-ML 01/20/81 18:27:37 Re: severe consternation
To: (BUG LISP) at MIT-ML
CC: MOON at MIT-ML
Here i was, demonstrating the wonders of SETF preserving implicit
order-of-evaluation.  I showed the macro-expansion of 
(SETF (ARRAYCALL T (FOO) (BAR)) (BAZ)), and imagine my surprise when
it came out to be:
((LAMBDA (G0002) ((LAMBDA (G0004 G0005 G0006)
		       (STORE (ARRAYCALL T G0004 G0005) G0006))
		    (FOO) (BAR) G0002)
		 G0002)
   (BAZ))
So, i said, "Well, i've got a SETF which isn't being used, but at least
I can trust it.  Let's try it."  There was no fasl, so i loaded the source.
What did it say?  It said ";TEM UNBOUND VARIABLE".  Closer examination
showed that
(DEFUN FOO (A B &AUX (C (F A)) (D (G C)))
    (LIST A B C D))
produced the following definition:
(DEFUN FOO (A B)
    (COMMENT ARGLIST = (A B))
    (LET ((D (G C)) (C (F A))) (LIST A B C D)))
Gremlins, perhaps?
The big question is this:  why is my compiled code working?
Or is it?


Date: 19 JAN 1981 1659-EST
From: JONL at MIT-MC (Jon L White)
To: WGD at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 18 January 1981 02:02-EST
    From: William G. Dubuque <WGD at MIT-MC>
	    The function STRING-PNPUT uses CHECK-TYPE and yet the STRING package
    does not make sure that CHECK-TYPE is around when doing a STRING-PNPUT.
    .  .  . I put the necessary eval-when
    form into the STRING package and this is fixed on 
Problem was actually a faulty complr -- the ERRCK package should be pre-loaded.
Indeed, the current COMPLR and XCOMPLR have it, but apparently the COMPLR
of Dec 23 (when the previous STRING was compiled) didn't.

Date: 18 JAN 1981 2308-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

:L
ALLOC? N
(SETQ MSGFILES 0)
(ERROR)
.VAL 0; ...

:L
ALLOC? N
(SETQ MSGFILES 'FOO)
(ERROR)
PURPG;....

In .INFO.;LISP NEWS, bad values of MSGFILES are documented to cause an 
IO-LOSSAGE type error (after setting MSGFILES to '(T)), similar to the 
way bad BASE and IBASE values are treated with FAIL-ACT breaks. Couldn't
Lisp be coaxed to do something along the lines of what it's documented to?
-kmp

Date: 18 January 1981 12:20-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: I DON'T BELIEVE IT !!!
cc: BUG-LISP at MIT-MC


Will somebody please fix this compiler bug. IT REALLY IS A BUG,
ISN'T IT?

(defun foo (n)
       (print (eval `(- ,n #/A -13)))
       (print (eval `(+ (- ,n #/A) 13)))
       (print (- n #/A -13))
       (print (+ (- n #/A) 13)))

(defun foo$ (n)
       (print (eval `(-$ ,n 101.0 -13.0)))
       (print (eval `(+$ (-$ ,n 101.0) 13.0)))
       (print (-$ n 101.0 -13.0))
       (print (+$ (-$ n 101.0) 13.0)))


(foo 101) is ok
(foo 102) is not ok
(foo$ 101.0) is ok
(foo$ 102.0) is not ok

Please???

Date: 18 January 1981 02:51-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: JPG at MIT-MC
cc: BUG-LISP at MIT-MC, ASB at MIT-MC

    Date: 16 January 1981 09:42-EST
    From: Jeffrey P. Golden <JPG at MIT-MC>
    To: BUG-LISP at MIT-MC
    cc: ASB at MIT-MC
    
    How about if one of you answer this for ASB:
       ASB@MIT-MC 01/16/81 02:37:30 Re: Garbage question
       Just now I was running a longish computation and out of curiosity hit ^D
       to see if I could determine whether I was in trouble or not.  Turned out 
       not, but I noticed that very often the following message would be printed
       prior to a Garbage collection:
       ADDING A NEW LIST SEGMENT--BUT DIDN'T SUCCEED.
       I guess that this means that there is no free memory left, which I am not
       surprised to learn.  But I was wondering why the information that no list
       segments could be added anymore was not available to whomever it was that
       was trying to add them.  Or does my question merely reveal my ignorance?
       Seems to me that once segment adding fails, it will fail forever after.
       Is that not true?
LISP tries to add segments when it sees after a GC that there is less space
than is 'optimal'.  If it can't get any more, yes, it will keep failing to
add more, and will just have to GC more.  There is no reason why the GC should
remember the fact that it failed before since it's just a trivial scan of
the segment table to see that there's no room, and there's certainly no reason
why CONS or whoever caused the GC should ever be told about it, since the GC
did find something for it.

Date: 18 JAN 1981 0204-EST
From: WGD at MIT-MC (William G. Dubuque)
Sent-by: BIL at MIT-MC
Subject: continuation of a slipped control-c
To: (BUG LISP) at MIT-MC

	... fixed on MC. Someone should do a :INSTAL and make sure this
fix permeates to other systems when AI comes back up.

Date: 18 JAN 1981 0202-EST
From: WGD at MIT-MC (William G. Dubuque)
Sent-by: BIL at MIT-MC
To: (BUG LISP) at MIT-MC

	The function STRING-PNPUT uses CHECK-TYPE and yet the STRING package
does not make sure that CHECK-TYPE is around when doing a STRING-PNPUT. Thus
a file being loaded will get an incorrectly nested fasload if it did not
have ERRCK around when the STRING-PNPUT is done. I put the necessary eval-when
form into the STRING package and this is fixed on 

Date: 16 JAN 1981 0942-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: ASB at MIT-MC

How about if one of you answer this for ASB:
   ASB@MIT-MC 01/16/81 02:37:30 Re: Garbage question
   Just now I was running a longish computation and out of curiosity hit ^D
   to see if I could determine whether I was in trouble or not.  Turned out 
   not, but I noticed that very often the following message would be printed
   prior to a Garbage collection:
   ADDING A NEW LIST SEGMENT--BUT DIDN'T SUCCEED.
   I guess that this means that there is no free memory left, which I am not
   surprised to learn.  But I was wondering why the information that no list
   segments could be added anymore was not available to whomever it was that
   was trying to add them.  Or does my question merely reveal my ignorance?
   Seems to me that once segment adding fails, it will fail forever after.
   Is that not true?

Date: 16 Jan 1981 0319-PST
From: Rod Brooks <ROD at SU-AI>
Subject: COMPLR can't do DO 
To:   bug-lisp at MIT-MC    

I have vague memories of complaining about something like this years ago
but maybe this is different. In any case I wish it didn't happen this way.

(defun baz (n)
       (do ((old 1 new)
	    (new 2 (1+ new))
	    (l () (cons (list old new) l))
	    (i 0 (1+ i)))
	   ((= i n) l)))

interpreted:
(baz 4) ==> ((4 5) (3 4) (2 3) (1 2)) 

compiled (both 905 and 924):
(baz 4) ==> ((5 5) (4 4) (2 3) (1 2)) 



Date: 15 JAN 1981 2232-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: GJC at MIT-MC

(SETQ) complains about an odd number of arguments.  Perhaps that should be
'strange' number of arguments instead?

Date: 15 JAN 1981 1924-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: number of arg checking.
To: (BUG LISP) at MIT-MC

FOOBAR!  (defmacro foo (x) `(cdr ,x))

(setf (foo '(a b c) '99))

Returns NIL and causes no error.

Not only does SETF not do wrong-number of argument checking,
it somehow manages to suppress the checking in the
macros which it expands. How is it so clever?
This sure caused me to waste a whole lot of time.
FOOBAR FOOBAR FOOBAR.


Date: 15 JAN 1981 1659-EST
From: GJC at MIT-MC (George J. Carrette)
Subject: interpreters written in maclisp.
To: JONL at MIT-MC, RWK at MIT-MC
CC: WGD at MIT-MC, CWH at MIT-MC, GJC at MIT-MC, (BUG LISP) at MIT-MC

It would be sufficiently nice to have a version of
LEXPR-FUNCALL which took a type-t-array as argument
instead of a LIST. Thus an implementor who knew what
he was doing could save the consing of call frames
without going outside of the language. This is very
much like passing arguments through registers, and
then providing an actual home for them on the stack.

-gjc

Date: 15 JAN 1981 0127-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: STRING
To: (BUG LISP) at MIT-MC

I have a reproducible instance of STR:ARRAY getting turned into a DEAD-ARRAY,
presumably by the garbage collector.  I caused the problem not to occur
by pointing to the array object with a non-pure list cell.

Date: 14 JAN 1981 1839-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: WRITEABLEP
To: CPR at MIT-MC, (BUG LISP) at MIT-MC, keshav at MIT-XX

Actually, there is a problem with (DEFUN WRITEABLEP (X) (NOT (PUREP X)))
-- it only works AFTER the PUREP library has been loaded. Otherwise PUREP
autoloads and clobbers the good definition of writeablep. So until things
are fixed, putting 

	(COND ((GET 'WRITEABLEP 'SUBR)
	       (LOAD "LISP:PUREP")))
	(DEFUN WRITEABLEP (X) (NOT (PUREP X)))

is the correct thing to do on a Twenex machine.

Date: 13 January 1981 20:56-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: this doesn't have much to do with any new monitor, I suspect
To: CPR at MIT-EECS
cc: BUG-LISP at MIT-MC, Keshav at MIT-XX

    Date: Tuesday, 13 January 1981  13:22-EST
    From: Chris Ryland <CPR at MIT-EECS>
    To: bug-lisp at mc
    Subject: this doesn't have much to do with any new monitor, I suspect
    cc: Keshav at MIT-XX
    
    Date: Monday, 12 January 1981  17:03-EST
    From: KESHAV at MIT-XX
    To:   cpr at MIT-XX
    Re:   A Bug
    
    The function writeablep in Maclisp is defined in the fasl file <maclisp>purep.
    fasl. My guess is that it checks for write protection violations. Until
    yesterday, calling this function with an output file (in Maclisp) gave t(rue).
    It still does so in Maclisp on ML. However, your new monitor gives a
    write protection error.
	  One LISP program that shows this is -
	   (load '((dsk maclisp) purep fasl))
	   (setq outfilep (open '(my output) 'out))
	   (writeablep outfilep)
       This should return t.

Your example looks suspsiously like you think WRITEABLEP has something
to do with files.  It does not.  It's purpose is to determine if
operations like RPLACA will result in a write-protection violation.
I.e.E WRITABLEP should return T for INPUT files as well, because
file-arrays are never placed on unwritable pages.  I cannot conceive of
a situation where you would legitamately be calling WRITABLEP on a file.

It is true, however, that WRITEABLEP does not yet work on TOPS-20.  (It
never did, and if you think it did you're wrong).  However, you can
write an acceptable substitute of (DEFUN WRITABLEP (X) (NOT (PUREP X))).

GSB@MIT-ML 01/13/81 20:52:12 Re: defun& losing
To: (BUG LISP) at MIT-ML
in NILCOM;DEFMAC, "776" -> "#o776" for future safety
Compiled & installed on mc,ml,ai
I put links for fix files on ml


GSB@MIT-ML 01/13/81 19:51:10 Re: 24 carat multifaceted lossage
To: (BUG LISP) at MIT-ML
With DEFUN&-CHECK-ARGS set to NIL, (defun foo (a &rest b) ...)
outputs (ARGS 'FOO '(1. . 776.)).  That, of course, should be #O776,
ie 510.  What sort of feature is it that this information is not output
when DEFUN&-CHECK-ARGS is not NIL?  It's not nice to hide such information
away where no one can find it...


Date: Tuesday, 13 January 1981  13:22-EST
From: Chris Ryland <CPR at MIT-EECS>
To: bug-lisp at mc
Subject: this doesn't have much to do with any new monitor, I suspect
cc: Keshav at MIT-XX

Date: Monday, 12 January 1981  17:03-EST
From: KESHAV at MIT-XX
To:   cpr at MIT-XX
Re:   A Bug

The function writeablep in Maclisp is defined in the fasl file <maclisp>purep.
fasl. My guess is that it checks for write protection violations. Until
yesterday, calling this function with an output file (in Maclisp) gave t(rue).
It still does so in Maclisp on ML. However, your new monitor gives a
write protection error.
      One LISP program that shows this is -
       (load '((dsk maclisp) purep fasl))
       (setq outfilep (open '(my output) 'out))
       (writeablep outfilep)
   This should return t.

GSB@MIT-ML 01/13/81 13:01:39 Re: incompatible format change
To: (BUG LISP) at MIT-ML
Some upcoming Maclisp format will have a change to one of the ~< variations,
which is currently in the Lisp machine implementation.
In "~<prefix~:;text~>", this outputs text, and if it won't fit on the line,
it will output a newline and prefix first.  The change is to omit the newline,
ie, you need to include it yourself.  There will also be a function added,
FORMAT:PRINT-LIST, defined the same as it is on the lisp machine;  this
will appear earlier.


Date: 12 JAN 1981 0409-EST
From: JAR at MIT-MC (Jonathan A. Rees)
Subject: (funcall usrhunk ...)
To: (BUG LISP) at MIT-MC

worked once upon a time, but seems to be broken now - the frob gets called
correctly but loses when it returns with an ILOPR.  Putting it on some
symbol's EXPR property works like a charm.  APPLY is still utterly oblivious.
I didn't check the UUO handler...