Date: 18 JUN 1978 1726-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: GC printing out garbage
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


    GSB@MIT-ML 06/16/78 06:44:05 Re: GC printing out garbage
    To: (BUG LISP) at MIT-ML
    is coming from inside of the STGPNT routine inside the GCPNT2 loop.
    What happens is that IFORCE clobbers F - STRT saves it, so that never
    cause any problems;  it only happens when IFORCE gets entered while 
    the gc is printing one of the numbers (either the words free or the
    percent-free.)
--------
Thanks, this will be fixed in next version.

Date: 18 JUN 1978 0519-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: (BUG DDT) at MIT-MC

I was watching my job FORTRN (which is a fortran->lisp translator running
in lisp using only functions that i have defined and lisp system functions)
from peek as it groveled away over a translation when suddenly it opened
a filename (for "R" mode) called EMACS;[RMAI] <n> where <n> was a number I
don't recall. It stayed long enuf that I am sure that it was my job referencing
the file and that it mode it was referencing it was R ... the thing is that
I have checked and the atoms EMACS and [RMAI] don't occur in the OBARRAY
and they don't occur in any of my code. The file I was reading from didn't
have them in it, and I don't explode these atoms out of thin air! What does
the reference to said file -- or if no one knows, maybe I can recreate it
if I knew what breakpoints to set to trap all file i/o in a lisp ...?
-- i was very confused... 
(additional -- files were running compiled in the new complr, but jonl claims
there is nothing special about these atoms in the complr...)
sigh. --kmp

Date: 17 JUN 1978 2238-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

SYSP fails to give the right answer for any of the AUTOLOADable functions
(like GETMIDASOP, SORT, SPRINTER etc.) because if they are already loaded,
then SYSP is faked out by the SUBR property in BPORG space.  It should
first look for an AUTOLOAD property, and if found, determine if that is
SYSP (according to the prior definition.)

Date: 17 JUN 1978 1825-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

How do you find out if a random S-expression array has the 
GC-MARK property?  ARRAYDIMS only tells you that it is an 
S-expression array.  thus
(EQUAL (ARRAYDIMS (ARRAY A T n1 n2)) (ARRAYDIMS (ARRAY B NIL n1 n2)))
is true.  Foo.

Date: 17 JUN 1978 1449-EDT
From: JONL at MIT-MC (Jon L White)
Subject: RMS
To: (BUG LISP) at MIT-MC

The poooooor compiler must intercept any flavor of DISPLACE and imitate
it without actually doing the RPLAC's, but rather by copying.  The reason
is that ocasionally the complr likes to "back-up", and any munging of the
original code (as read in) would be bad.  Even if there are multiple
pointers to a given cell in code, it would not be bad to run the
macro expander twice or more, since the macro-expansion occurs only
once per instance in code (rather than once per use in normal lisp
running enviromnent).  Apparently the expansion of macros more than once
(due to the "backing-up") has caused some consternation to some 
people, so it is apparently something a compiler user will have to
live with, or else use read-time macros (instead of eval-time macros
which BLAIR calls "meta-composition").

GSB@MIT-ML 06/16/78 07:06:02
To: (BUG LISP) at MIT-ML
suspend with 2 args should open some dummy name and do a renmwo when
done;  any device which will support pdump is certainly going to support
that.


GSB@MIT-ML 06/16/78 06:44:05 Re: GC printing out garbage
To: (BUG LISP) at MIT-ML
is coming from inside of the STGPNT routine inside the GCPNT2 loop.
What happens is that IFORCE clobbers F - STRT saves it, so that never
cause any problems;  it only happens when IFORCE gets entered while 
the gc is printing one of the numbers (either the words free or the
percent-free.)


MILLER@MIT-AI 06/16/78 06:22:50 Re:  displace
To: RMS at MIT-AI, (BUG LISP) at MIT-AI

rms' version of displace looks like a winner to me.
i vote for that.  -- mark


Date: 16 JUN 1978 0341-EDT
From: JONL at MIT-MC (Jon L White)
Subject: many DISPLACEs
To: (BUG LISP) at MIT-MC

I'm perfectly happy with either the current definition of DISPLACE,
or with the one proposed by RMS, and am all in favor of "giving the
user what he wants".  But before we go out to take a hasty vote,
it might be a good idea to examine all the consequences of the
more "totalitarian" choice.  For example,
1) Should the functions be called "DISPLACE", since its action is
   more of a macro-expansion shunting.  Would the naive user be
   aware that could not use "DISPLACE" for displacement, due to the
   extra cruft pushed in.
2) Some macro-expansions take a monsterous amount of code, and produce
   even more - the "DISPLACED" scheme saves both around, with no
   choice available to the user, so that gc may be impacted.  Admittedly
   many users would like to be able to retrieve the source that the
   expansion came from, but then again most wouldn't go to any effort
   to save it.  see 3.
3) The current definition is essentially the one that has been in the
   LISP lore for the past 12 years, and one advantage of putting it
   in the "system" is that it can become the SUBR that it rightly is
   rather than hacking it in as another level of MACRO.  Its persistent
   use, in this form, would not seem to support the statement "Putting
   in any other sort of DISPLACE [than SDISPLACE] is tantamount to not
   putting in any, but creating some random system function instead."
4) My suggestion of a standard MACRO libaray, which would supply
   SDISPLACE (or better yet, MACRO-DISPLACE), doesn't seem to require
   that "each user must define it himself".  Or at least I didn't 
   think so.  Anyway, there are probably hordes of users who wont displace
   anything, but will be content with ordinary macro expansion.  How
   dull!  But if I read the most recent rmsuggestion correctly, we would
   have to require everyone to use the new "SDISPLACE" form of macros
   in order for automatic code analysis programs to have any success.
   Hence the appellation "totalitarian".

RMS@MIT-AI 06/16/78 01:53:58 Re: DISPLACE for anything besides macros.
To: (BUG LISP) at MIT-AI
To say that people should define SDISPLACE for themselves if they want it
is to 1) throw away all the advantages of that form of DISPLACE, and
2) throw away all the advantages of putting a DISPLACE in the system.

The advantage of my form of displace is that it is easy for things like GRIND
and anything else that looks at code to understand what a displaced thing is.
For this advantage to become real, all displacing macros must use that
form of displace.  So each user must define it himself.

The whole point of putting DISPLACE in the system is to give everyone
the thing which everyone wants to use in macro definitions.
That thing, I claim, is my DISPLACE.  Putting in any other sort
of DISPLACE function is tantamount to not putting in any, but creating
some random system function instead.  Create the random one if you like,
but please make DISPLACE be what everyone will like in his macros.


KEN@MIT-AI 06/16/78 01:08:38
To: (BUG LISP) at MIT-AI

.info.;lisp news described displace as 
    SUBR:  (DISPLACE X Y) ==>  (PROGN (RPLACA X (CAR Y)) (RPLACD X (CDR Y)) X)
while the way it seems to behave (and in my humble opinion aught to) is

    SUBR:  (DISPLACE X Y) ==>  (PROGN (RPLACA X (CAR Y)) (RPLACD X (CDR Y)) y) ;;return y

Date: 16 JUN 1978 0102-EDT
From: JONL at MIT-MC (Jon L White)
Subject: RMS's  DISPLACE
To: (BUG LISP) at MIT-MC

Not to be contrary, but the most common complaint against
DISPLACE (and this includes the one for which RMS vouches
"winning in all respects") is that it fails to error out
if given an atom.   But as regards whether or not to have
DISPLACE act as currently in MACLISP, or to install the
DISPLACED marker, I prefer the current.  For example, 
RMS's scheme can be implemented using the current DISPLACE:
(DEFUN SDISPLACE (X Y) 
       (DISPLACE X (LIST 'DISPLACED (CONS (CAR X) (CDR X)) Y)))
(DEFUN DISPLACED MACRO (X) (CADDR X))
But for the ocasional user who tries out DISPLACE in a way that
we didn't conceive, it will be very difficult to get around
the extra stuff stuck in by StallmanDISPLACE.  E.g.,
(DEFUN CELL-EXCH (X Y) 
       (LET ((X` (CONS (CAR X) (CDR X))))
            (DISPLACE X Y)
            (DISPLACE Y X`)))
The intent of similar usage would be defeated if the DISPLACED
marker kept getting pushed onth the head of the cell.
    Whereas the primary use of DISPLACE will probably be for
macro-expansion shunting, the current definition does not presume
that;  RMS's one does.  In either case, the compiler has to
override the SUBR definition by some macro trap similar to
(DEFUN DISPLACE MACRO (FUNNY-SYMBOL/|)
       (LIST 'QUOTE (EVAL (CADDR FUNNY-SYMBOL/|))))
or possibly by special-case trap to extract the "Y" part
as if it were the original expression.
   At any rate, StallmanDISPLACE deserves to be added to the big
bag of MACRO tricks, of which there are right now 
1) none in the interpreter, and
2) many floating around, such as on LIBLSP
Perhaps we need some more canonical place to put winning MACROs.

RMS@MIT-AI 06/15/78 23:28:50
To: (BUG LISP) at MIT-AI
Having a built-in DISPLACE is a win, but the one you have chosen
is suboptimal.  The DISPLACE that I have put in on the lisp machine
is, I claim, winning in all respects:
(DEFUN DISPLACE (OLD NEW)
       (LET ((COPY (CONS (CAR OLD) (CDR OLD))))
            (RPLACA OLD 'DISPLACED)
	    (RPLACD OLD (LIST COPY NEW))))

(DEFUN DISPLACED MACRO (FORM) (CADDR FORM))

This makes it easy to identify a displaced macro call
and find what the original code looked like.
Actually undoing the displacement is also easy.
But it is not much less efficient than the simpleminded displace.


Date: 15 Jun 1978 1329-PDT
From: GLS at SU-AI (Guy Steele)
Subject: DISPLACE 
To:   bug-lisp at MIT-MC    

DISPLACE ought to have a definition something like this:
(DEFUN DISPLACE (X Y)
       (COND ((ATOM Y) Y)
	     ((ATOM X) Y)	;or error
	     (T (RPLACA X (CAR Y))
		(RPLACD X (CDR Y))
		X))))
Then again, what about Stallman's theory of:
(DEFUN DISPLACE (X Y)
       (COND ((ATOM X) Y)
	     (T (RPLACD X (LIST (CONS (CAR X) (CDR X)) Y))
		(RPLACA X 'DISPLACED)
		X)))
(DEFUN DISPLACED FEXPR (X) (CADR X))
?

-------

Date: 15 JUN 1978 0749-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Getddtsym
To: (BUG LISP) at MIT-MC, MILLER at MIT-AI


    MILLER@MIT-AI 06/15/78 05:34:04 Re: Getddtsym
    To: (BUG LISP) at MIT-AI

    Apologies: besides GETCOR and SACONS, CFIX1 and 2DIMF
    are needed for TK-TV graphics if loading symbols is
    to be avoided.  I think that's really it this time.
    Do you mind adding those, too?      -- Mark
---------
I will look into adding these for the next LISP, but I currently see no
problems.

Date: 15 JUN 1978 0746-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC, ALAN at MIT-AI

The bug whereby you could not use NIL as a second arg to apply has been
fixed and patched on all machines.

ALAN@MIT-AI 06/15/78 06:48:58
To: (BUG LISP) at MIT-AI
JESUS! I can't apply a function of no arguments to the empty list!
What an incredible screw!!

MILLER@MIT-AI 06/15/78 05:34:04 Re: Getddtsym
To: (BUG LISP) at MIT-AI

Apologies: besides GETCOR and SACONS, CFIX1 and 2DIMF
are needed for TK-TV graphics if loading symbols is
to be avoided.  I think that's really it this time.
Do you mind adding those, too?      -- Mark


Date: 14 JUN 1978 2329-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

I would like very much if the next interpreter could
arrange to have () in a lambda-variable list mean
"ignore this arg".  I believe a simple patch to bind
(and specbind) would do it.  Probably some current
"error" checking would be omitted.

ALAN@MIT-AI 06/14/78 20:09:07
To: (BUG LISP) at MIT-AI
	You see the problem with DISPLACE is that suppose you do the following:

(setq a '(q w e r))
(setq b 'cons)
(displace a b)

then the value of a is this list "(#73100 subr #13302)".  Even better I can use DISPLACE
to change the printname, valuecell, propertylist etc. of a symbol!  If we really
want this thing to help macro hackers, then the thing should check for
an atomic second arg and replace it with "(progn <thing>)". And in any case shouldn't
the first arg be checked for atomicness?

Date: 14 JUN 1978 2006-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

1633 this problem, not seen in earlier versions - 
   (APPLY 'CRUNIT NIL)  ==>  error, with msg "NIL MUST BE A LIST -- APPLY"

Also, how about a quickie version of LET, as FSUBR, for the next
version.  In the documentation, be sure to call them FSUBRs, rather
than FEXPRs.

Date: 14 JUN 1978 1942-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Why does FASLOAD set defaultf? This has caused me some big screws on occasion.

Date: 14 Jun 1978 1239-PDT
From: GLS at SU-AI (Guy Steele)
Subject: Use of ^Q in namestrings
To:   BUG-LISP at MIT-AI
CC:   KMP at MIT-AI   

Well, indeed, there is code in the namestring parser which purports
to understand ^Q, but it evidently doesn't work.

-------


Date: 14 JUN 1978 1440-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML
CC: BYRON at MIT-ML


    GSB@MIT-ML 06/14/78 14:28:31
    To: hic at MIT-MC
    CC: BYRON at MIT-ML
    At CNP.H+mumble, lisp checks to see if the horizontal cursor position
    specified is greater than the linel of the output file so that it can
    set the charpos to the right hand margin;  the problem is that
    (STATUS TERPRI) sets the sign bit of the FO.LNL slot, so the charpos
    specified is always larger than the linel (so it thinks)...
--------
Fixed for next LISP (I can patch it if this is important)....

HIC@MIT-MC 06/14/78 14:11:10 Re: Winning New Macro POP (?)
To: MILLER at MIT-AI, (BUG LISP) at MIT-AI, (BUG COMPLR) at MIT-AI

    Date: 14 JUN 1978 1259-EDT
    From: MILLER at MIT-AI (Mark L. Miller)
    Subject: Winning New Macro POP (?)
    To: (BUG LISP) at MIT-AI, (BUG COMPLR) at MIT-AI

    Come on, you guys!  According to the last two lisp
    recents, (POP X) returns (CAR X) in the interpreter,
    but (CDR X) in the compiler!!!  And how about clarifying
    how one overrides these with ones own (presumably more
    consistent) definitions?  Thanks, Mark
--------
Unfourtunatly, after the compiler was released, we decided that (CAR X) was
more apprpriate...I suspect this change will be reflected in the compiler
shortly.



JOHAN@MIT-AI 06/14/78 13:43:49
To: (BUG LISP) at MIT-AI
^x inside a break point seems to lose input stream.

Date: 14 JUN 1978 1259-EDT
From: MILLER at MIT-AI (Mark L. Miller)
Subject: Winning New Macro POP (?)
To: (BUG LISP) at MIT-AI, (BUG COMPLR) at MIT-AI

Come on, you guys!  According to the last two lisp
recents, (POP X) returns (CAR X) in the interpreter,
but (CDR X) in the compiler!!!  And how about clarifying
how one overrides these with ones own (presumably more
consistent) definitions?  Thanks, Mark


Date: 14 JUN 1978 1103-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: NAMESTRINGS
To: (BUG LISP) at MIT-MC

Mostly a curiosity question. I'm sure it's not much worth worrying about.
Why can't lisp understand that '|KMP;^Q FOO ^Q BAR| means KMP;^Q FOO ^Q BAR
as a file -- it seems to ignore the ^Q and look for a file named '|FOO BAR|
(I am not concerned since the namelist '((DSK KMP) | FOO| | BAR|) seems to
work ok, but for the purposes of my namestring reader in FORTRAN (which I
have just converted from my own filename parser to LISP's namestring
at HIC's request) it would be nice if anyone ever tries to use such a thing
as a filename for him not to get an error or clobber some other file or
whatever.)

Date: 14 JUN 1978 0928-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC

DISPLACE should check for either X or Y being an atom [at least for Y being
atomic, certainly].  This may be breaking some of my code, though I guess my
stuff should redefine the system function.

Date: 14 JUN 1978 0819-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC


    Date: 13 JUN 1978 2204-EDT
    From: MOON at MIT-MC (David A. Moon)
    To: HIC at MIT-MC
    CC: (BUG LISP) at MIT-MC

    	Date: 13 JUN 1978 0447-EDT
    	From: HIC at MIT-MC (Howard I. Cannon)
    	To: (BUG LISP) at MIT-MC, MOON at MIT-AI
    	
    	
    	    MOON@MIT-AI 06/13/78 01:20:51
    	    To: (BUG LISP) at MIT-AI
    	    +TYO GIVEN AN UNBOUND VARIABLE AS THE FILE TO OUTPUT
    	    TO, RANDOMLY BASHES LISP, STARTING ROUGHLY IN THE AREA OF UNBND2.  IT SEEMS WORTH
    	    THE COST OF A CHECK
    	--------
    	The only bug that I could find with regards to +TYO was that when you gave
    	it a T, the check succeded, but it used ttsar+truth rather than the
    	file-array in TYO.  This has been fixed.  Otherwise, when *RSET is on the
    	second argument is checked -- it must be an ascii, output file array.

    My apologies; it wasn't anything to do with +TYO.  The bug was in the form
    (PRINC '|FOO| OUTPUT-FILE) which compiles into a STRT UUO.  If OUTPUT-FILE
    is unbound, this bashes low core.
--------
A check has been put in STRT for this condition.

Date: 14 JUN 1978 0742-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG LISPM) at MIT-MC, GSB at MIT-MC


    Date: 13 JUN 1978 1501-EDT
    From: JONL at MIT-MC (Jon L White)
    To: (BUG LISP) at MIT-MC
    CC: (BUG LISPM) at MIT-MC, GSB at MIT-MC

    So let us define PUSH and POP macros to produce something like
    (PUSH X L)   ==>  (SETQ L (CONS X L))
    (POP L)      ==>  (PROG2 () (CAR L) (SETQ L (CDR L)))
    This way, the value left by the "POP" will be the thing  popped off.
---------
This is the way they are inplImented [RLB take note] in the interpreter except
that (POP L X) pops L into X and returns the new value of X.

Date: 14 JUN 1978 0729-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: SUSPEND
To: GLS at MIT-MC
CC: (BUG LISP) at MIT-MC, GSB at MIT-ML

It is quite possible that the QUIT function does accept a fixnum for use
in a .BREAK 16...unfourtunatly, this does not help with SUSPEND.  Therefore,
since suspend/valret use the same parsing routine, they both impliment the
.BREAK fixnum hack.

Date: 13 JUN 1978 2204-EDT
From: MOON at MIT-MC (David A. Moon)
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

	Date: 13 JUN 1978 0447-EDT
	From: HIC at MIT-MC (Howard I. Cannon)
	To: (BUG LISP) at MIT-MC, MOON at MIT-AI
	
	
	    MOON@MIT-AI 06/13/78 01:20:51
	    To: (BUG LISP) at MIT-AI
	    +TYO GIVEN AN UNBOUND VARIABLE AS THE FILE TO OUTPUT
	    TO, RANDOMLY BASHES LISP, STARTING ROUGHLY IN THE AREA OF UNBND2.  IT SEEMS WORTH
	    THE COST OF A CHECK
	--------
	The only bug that I could find with regards to +TYO was that when you gave
	it a T, the check succeded, but it used ttsar+truth rather than the
	file-array in TYO.  This has been fixed.  Otherwise, when *RSET is on the
	second argument is checked -- it must be an ascii, output file array.

My apologies; it wasn't anything to do with +TYO.  The bug was in the form
(PRINC '|FOO| OUTPUT-FILE) which compiles into a STRT UUO.  If OUTPUT-FILE
is unbound, this bashes low core.

Date: 13 JUN 1978 2107-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: SUSPEND
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC, GSB at MIT-ML


    Date: 13 JUN 1978 0006-EDT
    From: HIC at MIT-MC (Howard I. Cannon)
    Subject: SUSPEND
    To: (BUG LISP) at MIT-MC, GSB at MIT-ML

        GSB@MIT-ML 06/12/78 09:00:14 Re: SUSPEND
        nice/reasonable for SUSPEND to accept something like, say,
        a fixnum in place of the valret string, to indicate that it should do
        a .BREAK with that frob? 
    --------
    If the argument to a VALRET, or the first argument to a suspend, is a fixnum,
    then a .BREAK 16,<RH-of-the-fixnum> is done.
    This will come up in the next LISP.
I believe that the QUIT function already accepts a fixnum and feeds it to
a .BREAK 16,.

Date: 13 JUN 1978 1501-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: (BUG LISPM) at MIT-MC, GSB at MIT-MC

So let us define PUSH and POP macros to produce something like
(PUSH X L)   ==>  (SETQ L (CONS X L))
(POP L)      ==>  (PROG2 () (CAR L) (SETQ L (CDR L)))
This way, the value left by the "POP" will be the thing  popped off.

MILLER@MIT-AI 06/13/78 06:54:31 Re: reply to reply to reply to ##MORE## bug message
To: hic at MIT-MC
CC: (BUG LISP) at MIT-AI

I just got your note stating that fasload masks interrupts.
Ok.  But I just made up that as a fast example of a way
to reproduce the bug.  It can hapen in lots of other ways
too.  It is hard for me to say without much more investigation
whether in every case some function happened to have masked
interrupts.

If that is always the cause, then perhaps what is needed is
a way to selectively mask only certain interrupts.  E.g.,
allow ##MORE## but disallow ^G etc.

Mark


Date: 13 JUN 1978 0652-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: MILLER at MIT-MC, (BUG LISP) at MIT-MC

When it realizes to print the redefining messages during a fasload,
interrupts are off (because you can't randomly interrupt out of a fasload
and run a random user function...interrupts are only turned on during
evals during fasload)...therefore, inr eality they are off, and this
is causing the symptoms you observed.

MILLER@MIT-AI 06/13/78 06:51:11 Re: ##MORE##
To: hic at MIT-MC
CC: (BUG LISP) at MIT-AI

I don't think (but I could be wrong) that interrupts are normally
disabled while fasloading grindef.  I gave the specifics on how
to reproduce the bug: i.e., start up a bare lisp, say N to Alloc?,
fasload grindef, go near the middle-bottom part of the screen
(using <return> M times), and then fasload it again.  You get the
warning messages normally printed when fasloading the same file
twice.  Notice that the printing wraps around the screen, overwriting
stuff you haven't had a chance to read and then at some random
point prints ##MORE##.

Mark


Date: 13 JUN 1978 0649-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Reminder -- ##MORE## Bug
To: (BUG LISP) at MIT-MC, MILLER at MIT-AI

Sorry, you did say what you did -- you were fasloading -- yup, that'll
do it....interrupts will not happen while the fasloading is going on
so the more processor does not get invoked at the "right" time...
this is a seriousproblem and probably cannot be rectified in the current
implimentation.

Date: 13 JUN 1978 0645-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Reminder -- ##MORE## Bug
To: (BUG LISP) at MIT-MC, MILLER at MIT-AI

Sometimes the MORE interrupt occurs at random places because the thing that
caused the interrupt occured while interrupts were disabled.  I need more
specifics (what gets printed when this happens?) to determine whether you
have discovered a bug or simply this well-known (and well disliked)
"misfeature".

--Howard

MILLER@MIT-AI 06/13/78 06:38:14 Re:  Reminder -- ##MORE## Bug
To: (BUG LISP) at MIT-AI
Back in December I sent the following bug message:

MILLER@MIT-AI 12/21/77 12:22:40
    Re: ##More## Interrupt
    To: (BUG LISP) at MIT-AI
    	I am having problems with the ##MORE## interrupt in Lisp.
    The problem is that sometimes it occurs at the top of the screen
    rather than the bottom.
    	At first I thought it was my stuff or the splitscreen
    package, but you can get it in an almost bare lisp as follows:
    	Q^K
    	Alloc? N
    	(fasload grindef fasl com)
    	;;; make sure you are near bottom of screen and
    	;;; fasload switch is on
    	(fasload grindef fasl com).
    	I notice the pagel is very large (I guess to use the ddt
    interrupt).  Making it 37. (on a tv) doesn't help.  Making it 36.
    causes it to occur BOTH at bottom and top of screen.
    	The problem is worse with splitscreening since there are
    fewer lines to work with and the occasional problem erases a
    larger percentage of your stuff.
    	Suggestions?  Thanks, Mark
    ps. turning off the who-line doesn't affect it.

As far as I can tell, the problem still exists in current
newio Lisp.  -- Mark


Date: 13 JUN 1978 0623-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: CFFK at MIT-MC, JLK at MIT-MC, (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

CFFK@MIT-MC 06/10/78 16:46:48
If FOO FASL is the compilation of
(DECLARE (FLONUM ($F) ($G FLONUM)))  (DEFUN $F NIL ($G 3.0))
Then (LOADFILE(FOO,FASL),F()); ==> ;(LISTIFY NIL) NOT INSIDE LEXPR/LSUBR
instead of saying that G is undefined.

Has been "fixed" thanks to a patch suggested by HIC.

MILLER@MIT-AI 06/13/78 06:22:42 Re:  Reminder -- Bug in Errprint of 2 args
To: (BUG LISP) at MIT-AI
Back in January I sent the following bug message:
    Date: 6 JAN 1978 1101-EST
    From: MILLER at MIT-AI (Mark L. Miller)
    Subject:  Seeming Bug in Errprint of 2 args.
    .Info.;Lisp News contains the following claim:
        [3] The ERRPRINT function now takes an optional second argument
    	like PRINT to specify the output files to print the message
    	on.  Thus, for example,
    	(ERRPRINT NIL MSGFILES)
    	prints the most recent error message onto the message files.
    Since that was just what I needed, I tried it.  I think errprint
    is buggy.  Part of the message goes to the tty (msgfiles, actually,
    I bet), and part goes to the list of files as advertised:
        LISP 1293 WITH WINNING NEW I/O
        ALLOC? n
        *
        (setq base 10. ibase 10. *nopoint nil)		;(habit)
        NIL
        (setq fil (open '((dsk miller) tstfil >) 'out))
        #FILE-OUT-|DSK:MILLER;TSTFIL 1|-62776
        (+ 'foobar 8.)
        ;FOOBAR NON-NUMERIC VALUE
        ;BKPT WRNG-TYPE-ARG
        (errprint nil (list fil))FOOBAR			;"FOOBAR" printed on tty!
        T
        (close fil)
        T
    Here is a copy of the file dsk:miller;tstfil 1:
    --------------------------
        ;NON-NUMERIC VALUE					;No "FOOBAR"!
    --------------------------
The bug is still present in current newio Lisp.
Mark


Date: 13 JUN 1978 0447-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, MOON at MIT-AI


    MOON@MIT-AI 06/13/78 01:20:51
    To: (BUG LISP) at MIT-AI
    +TYO GIVEN AN UNBOUND VARIABLE AS THE FILE TO OUTPUT
    TO, RANDOMLY BASHES LISP, STARTING ROUGHLY IN THE AREA OF UNBND2.  IT SEEMS WORTH
    THE COST OF A CHECK
--------
The only bug that I could find with regards to +TYO was that when you gave
it a T, the check succeded, but it used ttsar+truth rather than the
file-array in TYO.  This has been fixed.  Otherwise, when *RSET is on the
second argument is checked -- it must be an ascii, output file array.

MOON@MIT-AI 06/13/78 01:20:51
To: (BUG LISP) at MIT-AI
+TYO GIVEN AN UNBOUND VARIABLE AS THE FILE TO OUTPUT
TO, RANDOMLY BASHES LISP, STARTING ROUGHLY IN THE AREA OF UNBND2.  IT SEEMS WORTH
THE COST OF A CHECK

Date: 13 JUN 1978 0012-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: GCMIN
To: JONL at MIT-MC, GJS at MIT-MC, (BUG LISP) at MIT-MC


    Date: 5 JUN 1978 1747-EDT
    From: jonl at MIT-MC (Jon L White)
    Subject: GCMIN
    (SSTATUS GCMIN 'LIST .2)  loses by doing (probably ) nothing.
    (SSTATUS GCMIN 'LIST 33245)  wins however.
--------
Fixed for next release.

Date: 13 JUN 1978 0006-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: SUSPEND
To: (BUG LISP) at MIT-MC, GSB at MIT-ML

    GSB@MIT-ML 06/12/78 09:00:14 Re: SUSPEND
    nice/reasonable for SUSPEND to accept something like, say,
    a fixnum in place of the valret string, to indicate that it should do
    a .BREAK with that frob? 
--------
If the argument to a VALRET, or the first argument to a suspend, is a fixnum,
then a .BREAK 16,<RH-of-the-fixnum> is done.
This will come up in the next LISP.

Date: 12 JUN 1978 2315-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: low-order bit in pname!
To: (BUG LISP) at MIT-MC, GSB at MIT-ML

STATUS JCL now turns off the low-order bit in JCLBF/PNBUF to prevent
all kinds of screws that were present because of this bit getting set....
(DDT sometimes turned it on...)

HIC@MIT-MC 06/12/78 22:42:52 Re: :L<space><cr>
To: MILLER at MIT-AI, (BUG LISP) at MIT-AI
Well, we have defined the thing to work like this:
:L<space><cr> means do the same thing as if no init file is present.
:L<cr> means look for an init file: if there is one -- read it, if not --
	ask the ALLOC? question.

I do not believe that the alternatives are more useful.  You are welcom to
make a null init file.



MILLER@MIT-AI 06/12/78 09:24:42 Re: :L<space><cr>
To: (BUG LISP) at MIT-AI

When you have no init file, why does
:L<space><cr> ask the alloc? question?
The <space> should be equivalent to
answering N.  Without the space, it makes
sense to ask: Alloc?.

Mark


Date: 12 JUN 1978 0459-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: JLK at MIT-MC
CC: JPG at MIT-MC, (BUG LISP) at MIT-MC

Noting CFFK's bugnote of 6/10 in MACSYM MAIL, HIC says that your 
UUF-HANDLER is only equipped to handle CALLs to undefined functions, 
not NCALLs as in CFFK's case.  Well, maybe HIC or JONL can patch it 
in the LISP system.  If not, the scheme may have to be changed or 
might be in trouble.

Date: 12 JUN 1978 0419-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JLK at MIT-MC

CFFK@MIT-MC 06/10/78 16:46:48
If FOO FASL is the compilation of
(DECLARE (FLONUM  ($F) ($G FLONUM))) (DEFUN $F NIL ($G 3.0))
Then (LOADFILE(FOO,FASL),F()); ==> ;(LISTIFY NIL) NOT INSIDE LEXPR/LSUBR
instead of saying that G is undefined.

But UUF-INTERPRETER is an LSUBR and the call is to (LISTIFY N) where 
N is a fixnum, probably 0.  (UUF-INTERPRETER is part of the MACSYMA 
UNDF-FNCTN handler, defined in JPG;SUPRV > .)

GSB@MIT-ML 06/12/78 02:57:09
To: (BUG NCOMPLR) at MIT-ML, (BUG LISP) at MIT-ML
What is this shit?  I have to not give the compiler jcl so that it won't
put low order bits in my declarations??????


Date: 11 JUN 1978 1633-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: BEE at MIT-MC, (BUG LISP) at MIT-MC


    Date: 11 JUN 1978 1439-EDT
    From: BEE at MIT-MC (Bruce E. Edwards)
    To: (BUG LISP) at MIT-MC

    Sometimes if I do a close on a channel, it doesn't close the channel
    until the next gc. Is this a bug???
--------
If you mean close the channel (as in terminate communication with the
operating system, mark the channel as closed, etc...) this is a bug.  Could
you please tell me how to reproduce this, and I will fix it.

Date: 11 JUN 1978 1439-EDT
From: BEE at MIT-MC (Bruce E. Edwards)
To: (BUG LISP) at MIT-MC

Sometimes if I do a close on a channel, it doesn't close the channel
until the next gc. Is this a bug???

Date: 11 JUN 1978 1008-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: INF-EDIT
To: (BUG QN) at MIT-MC
CC: (BUG LISP) at MIT-MC

I am trying to compile INF-EDIT into some code and not only do I get a
message saying INF-EDIT is undefined in this file, but when the compiled
code runs it tries autoloading the inf-edit (which it shouldn't because
there is a macro definition already on inf-edit) and then it says inf-edit
is undefined after autoload ... lose!

Date: 9 JUN 1978 0442-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
Subject: Numerical routines for the PDP-10 
To: MLB at SU-AI
CC: (BUG LISP) at MIT-MC

The ones we use in MACSYMA are actually in MACLISP.  Contact a LISP 
system person (JONL, GLS, HIC, RPG at SAIL) for further info.

rms@MIT-AI (Sent by GJS@MIT-AI) 06/07/78 17:15:00 Re: Named PROG
To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI, NIL at MIT-AI
I have implemented (PROG <name> <vars> ...) in the Lisp machine compiler.
The name is used by saying (RETURN-FROM <name> <value> <value> ...)
instead of RETURN.  A PROG with name T is "invisible" in that ordinary
RETURN returns past it.  This is used for expanding MAPs, etc,
but user macros might also find it useful.  I wouldn't expect anyone
to use it in code.
(DO-NAMED <name> <vars> ...) is also implemented.  There is no good way
to extend DO without using a new function name.
There is no need to specify the name of the PROG in a GO, since the GO
can manage to figure out what to do.  It just searches all PROGs
and finds the tag in whichever one defines it.  Note that computed GOs
are not allowed on the Lisp machine.  It would make sense for you to decide
that a computed GO applies only to the innermost PROG.  After all,
they are hardly a winning thing to use, and this course of action
would allow all old programs that use them to continue to work.


HIC@MIT-MC 06/07/78 16:43:17
To: MOON at MIT-ML, GSB at MIT-ML, (BUG LISP) at MIT-ML

    MOON@MIT-ML 06/07/78 15:28:15
    To: GSB at MIT-ML, (BUG LISP) at MIT-ML
    why are there sys;atsign l, atsign lisp, atsign q, atsign qio?
    The sys directory is full and these uesless-sounding links take up space.

--------
I have no idea why these exist, and I have no need for them.



Date: 7 Jun 1978 1330-PDT
From: GLS at SU-AI (Guy Steele)
Subject: Named PROG Feature
To:   NIL at MIT-MC
CC:   bug-lisp at MIT-MC, bug-lispm at MIT-AI  

It has been suggested that a feature be introduced into LISP for
naming PROGs.  This would permit returns out of multiple levels
of PROG, allow more precise specification of non-local GOs,
and effectively provide the "lexical CATCH" notion.  Here I attempt
to gather together all the proposals for possible syntaxes for this
feature.  I would like to reach a prompt decision on this feature,
so speedy feedback would be appreciated.

The basic notion is that a PROG can be assigned a name by which
RETURN and GO forms can refer to it.  As with CATCH, there is the
issue of whether it should be permitted to compute the name.
(I am inclined to say "no", given that the feature may be intended
to be more static in nature than CATCH).

I believe that two suggestions have been put forward for the syntax
of named PROGs:
(1)	(PROG <name> ( <-vars-> ) ...)
(2)	(PROG ( <-vars-> ) <name> ...)
I happen to favor (1), just because the name is a little easier to see.
One feature of (2) is that the name looks like a tag, which is both an
advantage and a disadvantage.

Possible syntaxes for RETURN are:
(1)	(RETURN <name> <value>)
(2)	(RETURN <value> <name>)
where in each case the <name> can be elided, meaning the immediately
containing PROG, as usual.  These both have the disadvantage of
conflicting with existing LISPM multiple-value syntax.  A more
off-the-wall possibility is:
(3)	(RETURN <value1> ... <valuen> . <name>)
where <name> can be elided.  This has the useless elegance that
() means the immediately containing PROG, and so is somewhat similar
to CATCH.  It has the severe inelegance of introducing dot notation.
Another possibility is just introducing a new keyword for non-local
RETURNs:
(4)	(NLRETURN <name> <value1> ... <valuen>)

Similar choices exist for GO:
(1)	(GO <name> <tag>)
(2)	(GO <tag> <name>)
(3)	(GO <tag> . <name>)		[this hardly seems justified!]
(4)	(NLGO <name> <tag>)
While there is no problem with multiple-value returns, there is one
with computed GOs.  Even without the named PROG feature, I would
lean toward an incompatible change, and introduce a special
COMPUTED-GO primitive, which could have its own funny syntax as
desired and would solve the problem of having a tag in a variable
FOO and wanting to say (GO FOO) -- the usual contortion (GO (SYMEVAL 'FOO))
will have insurmountable interactions with local variables in NIL.

-------

MOON@MIT-ML 06/07/78 15:28:15
To: GSB at MIT-ML, (BUG LISP) at MIT-ML
why are there sys;atsign l, atsign lisp, atsign q, atsign qio?
The sys directory is full and these uesless-sounding links take up space.


SUN@MIT-ML 06/07/78 10:17:30
To: (BUG LISP) at MIT-ML
CC: MOON at MIT-ML
Well I've putterred around a bit with the LISP
and have come up with a few mostly trivial bugs.
Try these out at some TOPS-10 net site.
I'll range from bugs to features.
1) setqing t or nil blows the lisp out
of the water rather than causing a fail-act.

2) Some problems with io.
  a) The value of defaultf is set using uname
       rather than udir.  (status udir) is correct
       however (it uses the path).
  b)To compund the obscurity, TRUENAME does not
    return the true name of a file but always uses
the udir no matter where the file really is.
  c) NAMESTRING rarely (though not never)
    puts in the PPN into a namestring.  This seems to
    carry over into the string in the printed file
    object name.

  In b) above, DEFAULTF  of the file object
  really does return its true name.

3) Another io thing but more a not-feature.
   LISP does not know about SFD's.  SFD's are used quite
regularly these days and it is a pain to not be able to
   reference most of one's files.  Thus if one has set a path
   with SETSRC to be down in an SFD
   udir should be there too.  The form of the namelist
   should be:

   ((DSK (12 6 FOO BAR DUUX)) FOO BAR)

4) I notice that CRUNIT only changes the directory
   and not the device (both on ITS and TOPS-10).
   This seems incorrect.

5) Lastly, there is the problem of what to do with
   cursor control when away from ITS.
   One particular case is rubout processing.  On TOPS-10
   LISP could ask the monitor if the TTY is a CRT and
  make rubouts backspace.  A second item is more type
   processing.   When a TTY is not an ITS  crt
   (i.e. most terminals in the universe)
t   the endpagefn of TYO could run when the
   pagel is exceeded, since the alternative method
   is used since ITS is so good at knowing were you really
   are.  Oh well, fun to have the true tongue again.



Date: 6 JUN 1978 1438-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: This isn't a bug -- maybe a non-feature -- Probably a hopeless case
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

Grumble, grumble. I was in a (READ) and typed 4,34 instead of 4.34
... 'No problem,' said I, 'for Lisp is smart and doesn't snarf commas
until I type a space' ... so I typed a rubout and it grabbed the 4,
leaving me with a mere 3 .... sigh.

Date: 5 JUN 1978 2229-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: Summary of binding
To: NIL at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG lispm) at MIT-AI

I forgot to mention the suggestion that the declarations
as to binding class of variables be placed as declarations of some sort
at the head of the body, rather than inserted as funny keywords
in the lambda-variable list itself.  This is similar to the way
the LISP Machine has come to use CHECK-ARG rather than the type
keywords.  On the other hand, declarations of DO variables still look
pretty strange.  On the third hand, keywords in DO variable lists
would look even crazier, maybe.

Date: 5 JUN 1978 1848-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 5 JUN 1978 1746-EDT
    From: JONL at MIT-MC (Jon L White)
    Sent-by: TNP at MIT-MC
    To: (BUG LISP) at MIT-MC

    Apparently, the Last function in the system area is ^G, and this
    has the effect that if some random binary program has been installed
    without ordinary linkup to the property list of some atom (such as
    LISPT seems to do), then a baktrace says that ^G has been entered
    instead of saying "random-unknow-function-in-bporg-area" entered.
    Hau Abaut letting a trivial funciton have the name "?", and letting
    it be the last one in the system area.
-------
OK, I added a SUBR ? which will return a question-mark (arg) and I made
sure to put it after ^G...

Date: 5 JUN 1978 1821-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Change in return value of RPLACA/RPLACD
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

There has never been a serious proposal to do this - RMS
was merely being obstinate when we proposed to change the
return value of SETPLIST.  Likely, SETPLIST will return its
second arg (but I was curious to know who depended upon the
return value at all of SETPLIST).

Date: 5 JUN 1978 1747-EDT
From: jonl at MIT-MC (Jon L White)
Sent-by: TNP at MIT-MC
Subject: GCMIN
To: (BUG LISP) at MIT-MC

(SSTATUS GCMIN 'LIST .2)  loses by doing (probably ) nothing.
(SSTATUS GCMIN 'LIST 33245)  wins however.

Date: 5 JUN 1978 1746-EDT
From: JONL at MIT-MC (Jon L White)
Sent-by: TNP at MIT-MC
To: (BUG LISP) at MIT-MC

Apparently, the Last function in the system area is ^G, and this
has the effect that if some random binary program has been installed
without ordinary linkup to the property list of some atom (such as
LISPT seems to do), then a baktrace says that ^G has been entered
instead of saying "random-unknow-function-in-bporg-area" entered.
Hau Abaut letting a trivial funciton have the name "?", and letting
it be the last one in the system area.

Date: 5 Jun 1978 0028-PDT
From: GLS at SU-AI (Guy Steele)
Subject: This note is an attempt to summarize the discussion JONL and I
To:   nil at MIT-MC
CC:   bug-lisp at MIT-MC, bug-lispm at MIT-AI  

and others had about the nature of variable bindings and references
in NIL.  If I have made any mistakes, or failed to represent the
consensus of opinion, please let me know.  I am going to try to
mention the alternatives that were considered, and also contrast
NIL, MacLISP, LISP 1.5, and SCHEME.
"Variables" in NIL are used for at least three different purposes:
[1] as the names of "globally" defined procedures, e.g. CONS.
[2] as "local" names of data objects.
[3] as "global" (i.e. dynamic) names of data objects.
Now the names of functions are normally thought of as being
"constant", while global names of data objects are though of
as varying over time.  It may be a useful notion, we have said,
to allow binding of global function cells.  Conversely, LISP 1.5
had a notion of a globally constant data object name (APVALs).
Now one problem with APVALs was that they were checked for BEFORE
the a-list was searched -- there was no way to "shadow" them.
Besides the issue of binding function names, there is also the
issue of wanting to treat functions per se as data objects.

In any case, we assume there are three sorts of variables (at least
-- one could for example complete the symmetry and imagine local
functional variables as well as global ones).  Now if gross screws
are to be avoided, there must be a way for the user to precisely
specify which variable is to be bound and which variable is to be
referenced at any point in his program.

In MacLISP, functions are not really first class data objects.
The model is that there are two distinct "evaluation contexts"
for names.  One is the function position of the combination,
and the other is essentially all other places.  In the function
position, an atomic symbol is interpreted as a reference to
the function cell, unless undefined, in which case the dynamic
value is used (modulo EVALPUNT, and the fact that a function as such
cannot live in a value cell, but only a symbol).  I have no idea
what happens when you write (FUNCTION symbol) in the function
position, either interpreted or compiled.  There is no good way
to refer to a function object in a local or dynamic variable
from the functional context -- instead, the FUNCALL construction
must be used.
In non-functional contexts, the "function cell" can be referred
to by writing the construct (FUNCTION symbol), and a plain atomic
symbol refers to a dynamic value.  (MacLISP has no consistent notion
of a local variable.  The interpreter cannot handle them correctly.
The compiler assumes that variables are by default local, leading
to a non-robustness, because by default interpreted and compiled
versions of the same program are likely to have radically differing
behaviors.)
MacLISP has only one kind of variable binding (dynamic, local
being excluded as above).  There is no way to bind a function
cell.

In SCHEME, there is (or ought to be) a consistent notion of
a global function cell, a dynamic value cell, and local variables.
SCHEME provides no facility for binding function cells; the model
is that the function cells provide the outermost "contour" for
the lexical environment.  There is only a single evaluation context
for names.  In that context, one writes an atomic symbol to refer
to a lexical variable, and (FLUID symbol) to refer to a dynamic
variable.  There is no way as such to refer directly to a global
function cell, because a function cell can always be lexically
shadowed.  This is seldom a problem for user programs, but can
pose problems for macros.
For binding, SCHEME distinguishes fluid bindings from lexical ones.
There is no way to bind a global function cell.  Thus function cells
can be shadowed lexically but not dynamically.

I believe what was decided, at last meeting, for NIL was
that the notion of two distinct "evaluation contexts" for names
be preserved, the model being that function names are usually thought
of as constants in some sense.  However, there may be a way
to shadow such definitions dynamically by binding the function
cell.  On the third hand, such names cannot be shadowed lexically.
Thus, in the "functional context", only a small class of expressions
are legitimate: atomic symbols (referring to the global, possibly
dynamic, function cell), and a few special expressions such as
LAMBDA-expressions.  (Are macro calls to be allowed to work in functional
context?)  There is no way to refer to a dynamic variable or a local
variable in function context -- one must use FUNCALL, as in MacLISP.
(It would be possible to define constructs which would legitimately
refer to such other variables in function context, but it is not
clear whether this is better or worse as a user syntax than FUNCALL.)
In other evaluation contexts, the three kinds of variable can be
referred to by the constructs:
	symbol			[local or dynamic variable]
	(DYNAMIC symbol)	[dynamic variable]
	(FUNCTION symbol)	[global function cell]
Now as we discussed, there is a set of nasty cases where an ambiguity
arises from the fact that an atomic symbol can be viewed as either
a local or a dynamic variable, and so one must have a way to force
the dynamic interpretation; hence the provision of the DYNAMIC construct.
There is still some doubt in my mind as to whether we should simply
tell the user always to use the DYNAMIC construct, which always but
always works (in which case a macro character similar to ' for QUOTE
should be provided), or tell him it mostly works not to use it
and describe the kind of hairy situations where it will lose.

Now it is interesting to note some similarities and differences between
the NIL proposal and the SCHEME proposal (which does not fully exist
either as an implementation).  Both implicitly acknowledge the existence
of three distinct kinds of variable in terms of which the user may wish
to think.  Both try to squeeze the three kinds into two sorts, because
the user may wish to mix sorts in his mind occasionally.  In SCHEME,
the global functional and local (lexical) types of variables are allowed
to be confused: atomic symbols are conditionally treated first
as local, and then as global functional if that fails.  This seems to
be good for styles of programming in which it is likely that globally
defined functions will be referred to as objects to be passed as
arguments;  it was of course just such styles that SCHEME was in part
designed to explore.  The dynamic variables are kept apart, because
they behave differently from the other two.  (The relationship between
global "data" variables and global "function" variables is not apparent
in SCHEME because there is no facility for dynamic binding of global
functional variables.  In writing "The Art of the Interpreter" I first
realized how important this notion might be to SCHEME.)
In the NIL proposal, the three kinds of variable are also squeezed into
two, but using a different division: here it is the global functional
which is the loner, and the other two are confused.  This suits a style
of programming in which functions are seldom treated as data objects,
and so it is mostly useful to separate names for functions from names
for other kinds of data objects.  It may be useful to confuse local
with dynamic variables for some purposes.  The lookup discipline is
(as I understand it) to check for a local definition first, and if
that fails, use the dynamic value cell.
Both proposals have the serious disadvantage that whichever kind of
variable is confused with local variables can be accidentally shadowed
by a lexical variable (note the similarity between the conditional
lookup disciplines in the two proposals as I have (I hope accurately)
described them).  This poses little problem to the user, but can
make things tricky for macros which cannot see their precise binding
contexts.  In each case this necessitates the introduction of a special
construct for eliminating the confusion.  In the case of NIL, it is
the dynamic construct; I am considering likewise proposing the
FUNCTION construct for SCHEME to eliminate the analogous ambiguity.

As may perhaps be well known, I still happen to favor the SCHEME
proposal slightly, because it simplifies the description of the language
(requiring only one kind of name evaluation context) while maintaining
that standard "Cambridge Polish" functional notation for the simple
cases; i.e. (CONS A B) means applying the function names by "CONS"
to two arguments named by "A" and "B".  The FUNCALL notation is not needed.
On the other hand, for those used to using one name as both the name
of a function as as the name of a data object (and there are often
good reasons for this -- e.g. LIST and EXP!), the separation inherited
from MacLISP contained in the NIL proposal can be valuable.
In conclusion, I repeat what I said earlier: the NIL proposal, the
SCHEME proposal, and yet other possibilities are each appropriate to
a certain style of programming.  Certainly the choice of model and
discipline will have the effect of encouraging certain styles of
programming and discouraging others.  This choice is therefore not
to be made lightly.  I favor a rather liberal approach, namely to
try to encompass as many styles comfortably as is possible without
conflict, other things being equal.

Now some issues that have not yet been touched upon here or in our
meetings include that of local functions, encompassing both
closures of various sorts and LABEL or LABELS or whatever.  I think
it is true that the MacLISP handling of LABEL is not acceptable.
What can be done to fix this?  Also, I recommend the LABELS syntax
as being analogous to LET in allowing mutually recursive definitions;
indeed, it is a subset of LETREC (cf. Landin).  A useful borderline
case between the use of a LABELS-like construct and packages is the
construction of OWN variables by some such piece of code as:
	(PROG (OWN0 OWN1 OWN2 ...)
	      (DEFUN FUNNYFN1 ...)
	      (DEFUN FUNNYFN2 ...)
	      ...)
Gerry and I have been considering simply defining DEFINE to be a macro
which expands into an ASET', i.e. not to hide so carefully the fact that
it simply clobbers afunctional value into a certain variable (though the
user can ignore this fact mostly if he likes):
	(DEFINE FOO (X Y) BARF)  =>  (ASET' FOO (LAMBDA (X Y) BARF))
Do we similarly want to simply define DEFUN as a macro defined in
terms of FSETQ or SETQ or whatever?

-------

GJS@MIT-AI 06/05/78 03:00:32
To: (BUG LISP) at MIT-AI
THERE SEEMS TO BE NO WAY TO (SSTATUS GCMIN 'LIST 0.1)... AFTER
DOING IT, I GET (STATUS GCMIN 'LIST) = .25

Date: 4 JUN 1978 2341-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Sent-by: TNP at MIT-MC
To: (BUG LISP) at MIT-MC

Sigh. I seem to be MPV;'ing all over these days -- this is a very discouraging
type of error to debug. Anyway, can you make (APPLY 'FROB '<atom>) so that it
type checks and discovers the atom before MPV'ing --? Thanx, kmp

GSB@MIT-ML 06/04/78 01:33:10 Re: RPLACA/RPLACD returning T
To: (BUG LISP) at MIT-ML
I give one short reason why not:
(rplaca
    (cdr (rplaca
	  (cdr (rplaca
		(cdr (rplaca
		      (cdr (rplaca
			    (cdr (rplaca 
				  (cdr (rplaca
					(cdr (rplaca (cdr start) tw))
					(invert-list seps)))
				  (invert-list labs)))
			    lw))
		      mw))
		first))
	  num))
    last)
Isn't this what lisp is all about?  Or do people really like
doing long series of setq's to random variables?
This 'example' is taken directly out of some running code...


Date: 3 JUN 1978 0616-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC


    Date: 3 JUN 1978 0248-EDT
    From: KMP at MIT-MC (Kent M. Pitman)
    To: (BUG LISP) at MIT-MC


    NREVERSE loses utterly with a PURPG; message when one tries to NREVERSE a
    number. (Yes, should be an error but maybe not fall thru to DDT...)
    --kmp
-------
NREVERSE/NRECONC code now makes sure first (or only!) arg is a list.
[for next release]

Date: 3 JUN 1978 0248-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC


NREVERSE loses utterly with a PURPG; message when one tries to NREVERSE a
number. (Yes, should be an error but maybe not fall thru to DDT...)
--kmp

GSB@MIT-ML 06/02/78 21:24:45 Re: How about
To: (BUG LISP) at MIT-ML
(STATUS CLI) and (SSTATUS CLI) to enable and disable cli interrupts.
The problem is that if the lisp doesn't want to bother, the sender
may hang up doing output...  This should be independent of the
value of CLI-MESSAGE, so that the cli handler can 'defer' the ints
while it is processing them by binding it to NIL.


Date: 2 JUN 1978 2105-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC

My read macro characters seem to have problems with
rubout processing, but if I ' [quote] a form, then rub-out processing works
fine.  What gives?

Date: 2 JUN 1978 1534-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: LET macro & fsubr
To: (BUG LISP) at MIT-MC

Before it's too late, why not generalize it to allow atomic symbols in the
bind list. If these occur, bind to NIL in the interpreter, and in compiled
code, to the appropriate zero.
Thus, at macro level,
 (let ((a 'a) b c) . body) becomes
 ((lambda (a b c) . body) 'a nil nil)
This is only a little harder than mapcar'ing 'CAR or 'CADR over the lists,
and the DO equivalent required might accomplish additional error checking.

Date: 2 JUN 1978 1500-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject:  Rubout processing
To: (BUG LISP) at MIT-MC, PONDY at MIT-AI

The problem is that LISP needs to run in order to send the proper control
codes to erase the character you rubout, whereas echo happens at system
interrupt level.  Thus, the other characters a printed by the system
"behind LISP's back".  MOON is working on a scheme which will correct this
problem in the system (it happens for MANY pprograms, and not only LISP).
The best bet is to either:
A) wait for the rubout to happen before typing
B) If things mess up, type a ^L [clear screen and redisplay] or a ^K
   [simply redisplay]

--Howard

PONDY@MIT-AI 06/02/78 14:24:12
To: (BUG LISP) at MIT-AI
if I use the rubout when typing things at lisp
it is echoed incorrectly. That is, although the correct character is rubbed
out as far as lisp is concerned, the rubout is echoed back maybe 4 or 5
characters later and rubs out (on the screen) a character which lisp thinks
is still there, but is no longer on the screen.
eg.  if I type  (defum<rubout>n foo (..
        lisp sees    (defun foo (...
    but I see (on the screen)        (defumn fo (..
which is somewhat disturbing.   PONDY

Date: 2 JUN 1978 1231-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, GSB at MIT-MC, (BUG LISP) at MIT-MC


    Date: 2 JUN 1978 1029-EDT
    From: JONL at MIT-MC (Jon L White)
    To: (BUG LISP) at MIT-MC

    (STATUS FILEMODE TYI) ==> ((IN FIXNUM TTY SINGLE))
    but it should say         ((IN ASCII  TTY SINGLE))
-------
Fixed for next release.

Date: 2 JUN 1978 1029-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(STATUS FILEMODE TYI) ==> ((IN FIXNUM TTY SINGLE))
but it should say         ((IN ASCII  TTY SINGLE))

Date: 1 JUN 1978 1544-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

POP and PUSH have been implimented (and straightforward LET is on the way).
I plan to release a new LISP in time for the next Macsyma release (which
will be in 1 or two days).  Any specific desires should be expounded
now...


RWK@MIT-MC 06/01/78 06:42:35
To: GSB at MIT-ML, (BUG LISP) at MIT-ML
CC: (BUG DDT) at MIT-MC

    GSB@MIT-ML 04/13/78 22:25:07
    To: (BUG LISP) at MIT-ML
    CC: (BUG DDT) at MIT-ML
    Lisp should test for a superior at SIDDTP, and ddt should clear both
    %OPBRK and %OPCMD in addition to clearing %OPDDT.
    I on occasion like to disown a compiler without having it get stopped
    by .break's looking to see if there is a symbol table.
Fixed in source, and can be patched if you like.



Date: 1 JUN 1978 0219-EDT
From: JONL at MIT-MC (Jon L White)
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

1) Yes, have the TYI/TYIPEEK/READ/READLINE/READCH axis check for correct
   type of input file.  Probably some checking is done now, but is not
   strict enough?  Hopefully, it can be made fast.
2) I dont remember any code to do special case check for mul/div by 1,
   nor add/sub by 0.  True, the only case that could have a detectable
   difference is the bignum-mul/div-one case and the bignum-add/sub-zero
   case.  If this case can be checked in one instruction or less (combined
   with some jump?) then there is no question that it should be done.
   One caveat - some code, i cant remember where, depends upon (PLUS X 0)
   allocating a new fixnum cell, for large enough X;  we should at least
   provide a way to force a new fixnum cell allocation (and flonum too).

Date: 1 JUN 1978 0210-EDT
From: JONL at MIT-MC (Jon L White)
To: EAK at MIT-MC
CC: (BUG LISP) at MIT-MC

yes, ts complr  was the old non-fast-numeric compiler, which has
gone the way of the buggy whip.  but leave ts nlisp, I think HIC
may have some purpose for it.

Date: 1 JUN 1978 0102-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: (BUG LISP) at MIT-MC

MC:SYS;TS COMPLR and TS NLISP are links to nonexistant files.  Should
they be flushed?

Date: 31 MAY 1978 2333-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: SSTATUS TTY
To: GSB at MIT-ML
CC: (BUG LISP) at MIT-MC


    GSB@MIT-ML 05/30/78 19:33:44 Re: SSTATUS TTY
    To: HIC at MIT-ML
    Presumably, (SSTATUS TTY NIL NIL <fixnum>) is equivalent to 
    (SSTATUS TTY (CAR (STATUS TTY)) (CADR (STATUS TTY)) <fixnum>);
    however, it does (SSTATUS TTY <fixnum> <fixnum> <fixnum>)...
-------
Yup, the case of three arguments was losing when either one or both of the
first or second arg was NIL.  this has been fixed for the next release of LISP.

Date: 31 MAY 1978 2317-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: DRB at MIT-MC, (BUG LISP) at MIT-MC
CC: BMT at MIT-MC

I'll need a JONL or QUUX response to back me up, but as far as I can tell
no special check is done for division/multiplication by 1.  This check does not
seem hard to impliment for the bignum cases (and it probably would be a win in
these case).  Ok, GLS and JONL (who I hear is really the math hacker around
here!)...what say you?


Date: 31 MAY 1978 2012-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

I think that TYI/TYIPEEK/READ/READLINE should check for the type of input
file and barf if it is a non-ascii (namely, binary) input file....otherwise
things such as MPV's crop up, and completely nonsensical things happen.
Unless there is some major objection, I'll go ahead with this.

Date: 31 MAY 1978 1700-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC
CC: RMS at MIT-MC



Date: 31 MAY 1978 1456-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC

BMT suggests that for MACSYMA we have the convention that all *, //, \, and \\
functions check for any arguments of 1.  It probably isn't important for
fixnums or flonums, but it could be for bignums.  Do the appropriate lisp
functions do the checking?  Thanks.

Date: 31 MAY 1978 1013-EDT
From: JONL at MIT-MC (Jon L White)
Subject: reason behind the proposed change to setplist
To: HIC at MIT-MC
CC: RMS at MIT-MC, (BUG LISP) at MIT-MC

The reason is quite obscure, but is purely a question of compiler
ease and efficiency.  Since it is so obscure, I talked it out with
GLS once, (and he agreed), but don't really want to do it again, 
unless there is large objection to the proposed change in return value.
In fact, some (PRATT is among them) think that the change to return
second arg is more consistent with other functions.

Date: 31 MAY 1978 1010-EDT
From: JONL at MIT-MC (Jon L White)
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

How about next lisp having a new subr DISPLACE, roughly defined as
(defun displace (x y) (rplaca x (car y)) (rplacd x (cdr y)) x)
and how about new fsubrs corresponding to the definitions for
PUSH, POP, and LET as found in the compiler under the functions
PUSHMENT, POPMENT, and LETMENT.  I would hope to get some argument
destruction (i.e., "pattern matching") for the variables to be "letted".

Date: 30 MAY 1978 2213-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: Changling what MAP returns
To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, RMS at MIT-MC

While we're at it, hau about RPLACA and SETQ?

RMS@MIT-AI 05/30/78 20:47:17 Re: Changing what MAP returns.
To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI
I seem to recall that people are changing other functions
to return T.  Why not one more?


Date: 30 MAY 1978 1850-EDT
From: JONL at MIT-MC (Jon L White)
Subject: MAPC returning some constant
To: (BUG LISP) at MIT-MC, RMS at MIT-MC, (BUG LISPM) at MIT-MC

Superwinning idea, if it had been thought of 10 years ago!
Frankly, isn't it too late, with too little to gain, for this now?

Date: 30 MAY 1978 1847-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC, KMP at MIT-MC

I'm afraid HIC's reply to question about (FLATC '<control-H>)
was somewhat in error - he is right in that the definition of
FLATC corresponds with the number of characters output by PRINC,
but it actually operates by noting the count of number of stored
characters in the string for the PNAME.  But FLATSIZE actually
calls a subroutine of PRIN1, which generates characters for printout,
and then merely counts how many characters were counted.  Neither
of these routines try to outguess whether or not ITS will add
escape characters of its own (PRIN1 of course adds the escape character
slash in front of any control character it is about to print).
My personal opinion is that ITS would have to supply a FLATSIZE
functions for character strings in order to correctly accomplish
what you (KMP) want.

Date: 30 MAY 1978 1726-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: FLATC
To: KMP at MIT-MC, (BUG LISP) at MIT-MC

FLATC returns the NUMBER OF CHARACTERS in a PRINC'ed representation - FLATSIZ
returns the length of the object if it was PRINC'ed.  So, (FLATC '^H) returns
1 whereas (FLATSIZE '^H) returns 2.  No special checking is done for ^H at
all in either of the SUBR's.

Date: 30 MAY 1978 1303-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: FLATC
To: (BUG LISP) at MIT-MC

Why does (FLATC '^H) return 1??? ... If it goes to the trouble to figure out
that a backspace is not like most ctrol-chars (with a 2: the "^" and the 
control'd char), then why can't it at least special case it to something
useful? The only reasonable use of FLATC is to determine if there is enuf
space someplace to print something, and you this makes that one use very
difficult ... sigh. Can this be remedied? Thanx. KMP

Date: 30 MAY 1978 0415-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: JLK at MIT-MC
CC: JPG at MIT-MC, (BUG LISP) at MIT-MC

JLK@MIT-MC 05/30/78 01:17:45
When the allocator asks you for more array space, I assume it means more
array header space, which is much different.  If that is true, why doesnt
it say so?

I just use the words given to me by LISP and LISP calls it "ARRAY" 
space.  I suppose I could check everywhere and whenever LISP says 
"ARRAY", I could change it to ARRAY-HEADER but I wonder if doing 
this in MACSYMA is worth it, especially since it is very rare for 
MACSYMA users to run out of this space.  Well, I wonder what HIC thinks.

RMS@MIT-AI 05/29/78 20:49:09
To: (BUG LISP) at MIT-AI, (BUG BUG-LISPM) at MIT-AI
Why don't we decide that MAP and MAPC should return T or NIL or some such thing?


GLS@MIT-AI 05/27/78 17:09:59 Re: Cretinous Stack Groups
To: NIL at MIT-AI
CC: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI
Here is a proposed theory of "stack group/cretin" interactions.
This was worked out by DLW and me, with reference to the SL5 paper
in this month's CACM, starting also from the existing LISPM SG
implementation.  DLW worked out quite a bit of this, but I may take
liberties in emending it, so any inaccuracies are my fault.
Because I am not fond of "stack group" as the name of these entities,
I'll call them "cretins", and also choose completely terrible names
for the proposed functions, hoping that they will not become entrenched,
because I haven't given much thought to names that would meaningfully
reflect their high-level semantics.

A cretin must contain a certain amount of state; it has the control
stack and binding pdls for a process, and possibly much other stuff.
Here I will not talk at all about the binding disciplines, but only about
the control.
Let one slot of the state of a cretin be known as the "resumer".
This slot may be empty, or may point to another cretin, in which
case that cretin is presumably in a suspended state, waiting for a value
to carry on with.
Now when one cretin (a) wants to transfer control to another (b), it must
pass a value to it; it may or may not also want to pass a resumption
point.  If it (a) does, it may want the resumption point to be itself (a),
its own resumer (the resumer of a), or yet a third party (c).
Now if a does choose to pass a resumer to b, then it will be stored
in b's resumer slot for later reference.  The resumer slot of b must
be empty for this to occur (stipulation, to avoid losing information
and allow error-checking).  It is permissible, however, not to pass
b a resumption point when b'd resumer slot is empty; in this situation
b must be smart enough not to use its resumer slot.
We thus propose primitives of this sort:
(CRETIN-GO value cretin resumption)
	This transfers control to <cretin>, giving it <value>,
and passing it <resumption> to be put in its resumer slot.
Error if <cretin>'s resumer slot is not empty.
(CRETIN-GO value cretin)
	Transfers control to <cretin>, passing no resumption point.
(CRETIN-JRST value cretin)
	Transfers control to <cretin>, passing it my resumer as a resumption
point, and also clearing my resumer slot.  If I have no resumer (my slot
is already empty), then <cretin>'s slot will be made empty also (?).
(CRETIN-PUSHJ value cretin)
	Transfer control to <cretin>, passing myself as the resumption
point.
(CRETIN-POPJ value)
	Transfer control to the cretin in my resumption slot (error if
none), passing no resumption point.
(MY-RESUMER)
	Returns my resumer, and as a side-effect clears my resumer slot.
Useful for weird hacks.
(HIS-RESUMER cretin)
	Returns the resumer slot of <cretin>.
(CLOBBER-HIS-RESUMER cretin resumption)
	Clobbers <cretin>'s resumer slot.  NIL (i.e. ()) means make empty.
CLOBBER-MY-RESUMER??

Some of these are incredibly dirty, and others are more disciplined.
It is not hard to show that if things are initialized properly,
and only CRETIN-PUSHJ and CRETIN-POPJ are used, then nothing bad can
happen - no errors should be able to occur undetected.  Maybe
this also holds if CRETIN-JRST is added - this is intended as the
equivalent of the "JRST hack".  The otherrs allow for completely
general hair, such as may be necessary for time-slicing or distributed
processing kinds of deals.
Now transferring control to another cretin suspends the current one,
putting it into a state that awaits a value.  When eventually someone
else transfers to it, that value is returned as the value of the call
to CRETIN-PUSHJ or whatever.  Multiple-value versions of all of
the above can be worked out.


Date: 26 MAY 1978 1610-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISPT) at MIT-MC
CC: (BUG LISP) at MIT-MC

I am getting an IOCERROR: - CHNL NOT OPEN
in my LISPT.... it may be core problems. we are out of core right now.
Is that possible? 

Date: 26 MAY 1978 0954-EDT
From: DRB at MIT-MC (David R. Barton)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC, DRB at MIT-MC


    Date: 26 MAY 1978 0543-EDT
    From: JONL at MIT-MC (Jon L White)
    To: (BUG LISP) at MIT-MC, DRB at MIT-MC

    Why isn't TRACE 61 standard now?  Is there any reason not to accept
    DRB's losing addition of **TRACE-MUNGER-FCN** or whatever it is??

Sorry about that JONL - I deleted my stuff since I decided that what I want
can't be mimicked by the current trace package.  I am going to write a small
one of my own, and so I deleted those changes I made.  I didn't know I should
tell you.  Sorry.

Date: 26 MAY 1978 0757-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: (STATUS FASLOAD)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 13 MAY 1978 0126-EDT
    From: JONL at MIT-MC (Jon L White)
    Subject: (STATUS FASLOAD)
    To: (BUG LISP) at MIT-MC

    Hau Abaut letting (STATUS FASLOAD) return the LDBSAR of the currently-
    being-loaded-file, if executed within a fasloading, or NIL of not
    fasloading.  Thus EVAL-mungeables could decide what the name of the
    resultant file is, and ^B breaks could snoop around a little more.
---------
Done for next LISP.  But we may have to think about having FASLOAD clear
LDBSAR when it is done or else thee closed file-array hangs around...

Date: 26 MAY 1978 0754-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

On tops-10 versions, if the autoload property points to
a non-existent file, then trying to use that symbol as a function
results in MPV disastres.

Date: 26 MAY 1978 0543-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC, DRB at MIT-MC

Why isn't TRACE 61 standard now?  Is there any reason not to accept
DRB's losing addition of **TRACE-MUNGER-FCN** or whatever it is??

Date: 26 MAY 1978 0505-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, DLW at MIT-AI


    DLW@MIT-AI 05/18/78 02:03:18
    To: (BUG LISP) at MIT-AI
    Let me add my voice to the crowd:
    (DEFUN FEXPR MACRO (X) ...)
    should define a macro called "FEXPR", rather than vice versa.  There
    are several reasons for this.  One is that the @ program and EMACS
    think of (DEFUN xxx ...) as the definition of xxx.
    	I was under the impression that everyone agreed to this change.
    How about it?
---------
After a discussion with JONL, and consideration of my own feelings on the
matter, we have decided to change the 'LAST MOST FINAL' definition of the
hairy defun feature.  The current definiton will be:
(defun <spec> [<flag>] <bvl-or-lexpr-flag> <body>)

Where <spec> is what to defun (can be a list if putting on an arbitrary
property).  <flag> is optional and is the type of function (fexpr, expr,
macro).  Note the change is that the first thing is ALWAYS the spec.
We are not sure when we will release this...

--Howard

Date: 26 MAY 1978 0101-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML

    GSB@MIT-ML 04/20/78 21:10:06
    TTYINT for ^Z goes and does a reset blindly on the channel of the original
    tty input file array.  What if someone has re-setqed TYI and TYO, and
    the channel has been re-allocated to something else?
-----------
CHNINT for ^Z now resets the channel the ^Z interrupt was recieved on.

JONL@MIT-AI 05/26/78 00:42:27
To: (BUG LISP) at MIT-AI
HENRY@MIT-AI 05/26/78 00:34:59
I'm trying out the new compiler, recompiling my whole
system. Thanks for getting the new compiler out. 
I'll let you know the results. I tried that hunk loop
thing already, and it seems to work fine. I notice
that you've got a lot of the popular macros LET, PUSH, 
POP, etc. That's really good, how bout putting them
in interpreter as well? Also, I like INCREMENT and
DECREMENT in the same vein.
^_


Date: 25 MAY 1978 2239-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: BASE
To: (BUG LISP) at MIT-MC

A completely random idea: if BASE is a list, then it is a list
of the single character objects for the digits.  If it is a list
of lists, then it is a variable-radix system, with the car being
the radix for the first digit, etc.

Date: 25 MAY 1978 1546-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

I mis-stated my problem due to a lack of understanding of DEFAULTF [the
function].  What I want is a hook into the LOAD de-sugaring syntax, so that
I can write a MLOAD function, which before passing its argument to LOAD, can
first to some hair, based on the file to be loaded.  What I want is to find
the file that LOAD will load if I pass it a given argument.  For instance,
LOAD of an atom will check to see if a FASL file exists, else go for a > file,
else crap out, etc.  I want to do all that stuff, but then just get my hands
on the actual file-name before the file is loaded.  Simple?

Date: 25 MAY 1978 0102-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    RLB@MIT-MC 05/23/78 20:58:13
    Please look into (a) SUSPEND doing its own PDUMP; 
-----------
The second arg to suspend now specifies the file in which to PDUMP the lisp.
It uses the standard filespec parser so may take a namelist, namestring,
or file-object (which must be closed, of course).  BTW, is it reasonable
to add a function to pdump a LISP at an arbitrary point in time
such that the LISP is immediatly continued or would simply saying
(suspend '/$p '(foo bar))
be adequate?
-----------
(b) Generating SYS:TS XL
    so (SSTATUS FLUSH T) will win.
-----------
If you purify the LISP by saying 'XPURIFY$G' then it will cause itself to
be on:
DSK:LISP;PURQIX verno
This should solve your problems and you can get rid of the links on sys.
BTW, the locations for the LISP system filespec are:
SYSDEV, SYSFN1, SYSFN2, SYSSNM

Date: 24 MAY 1978 2154-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
To: (BUG LISP) at MIT-AI
CC: jweiner at UCLA-SECURITY

I know that someone sent mail to jweiner while logged
in as me, and this seems to be a reply.  Was it one of you?

    Date: 24 May 1978 0948-PDT
    Sender: jweiner at UCLA-Security
    Subject: Lisp for TOPPS-10
    From: jweiner at UCLA-Security
    To: dlw at mit-ai

    When the new version is out, what machine will the compiler be on?(mit-ai,
    mc , ml ..)
    What will be its name?
    Is there documentation to acompany it that describes how to load it?
    Is there a write-up for pars 3&4 of the MACLISP manual?. It appears
    that only parts 1&2 have offically been printed.

    				Thanks for your help.
    				   Jim Weiner
    -------



Date: 24 MAY 1978 0603-EDT
From: EAK at MIT-MC (Earl A. Killian)
Subject: init files
To: RMS at MIT-MC, RWK at MIT-MC, MOON at MIT-MC, (BUG LISP) at MIT-MC

If init files are going to be named <hsname>;<xuname> <name> then its
probably a loss to have <name> be something like .LISP. or .EMACS when
LISP or EMACS would be just as good.  The "."s probably were to put
the file at the front of the directory; now that FN1 is the XUNAME, the
"."s serve no useful purpose and just make it difficult to have six
character program names.

RMS, is the next E going to continue getting its init files using the old
names or will you change it to the <hsname>;<xuname> EMACS scheme?

Date: 24 MAY 1978 0559-EDT
From: GSB at MIT-MC (Glenn S. Burke)
Subject: RUBOUT function
To: (BUG LISP) at MIT-MC

The rubout function, if the horizontal cursor position is less than
the number of positions which are to be killed, does a (CURSORPOS 'U),
apparently neglecting the fact that doing a (CURSORPOS 'B) will do a
(CURSORPOS 'U) when it goes past the left margin.
It should either do a (CURSORPOS 'X) the proper number of times,
or just (CURSORPOS 'B) the proper number of times, followed by 
(CURSORPOS 'L).  (The former is 'correct', but the latter will bypass
an its bug...)
The current method ends up in the proper (usually) position, but on the
wrong line.  Also, this method of rubbing chars out is ineffective anyway
if a reprint of the buffer inserts terpri's when it tyo's the characters.

Date: 23 MAY 1978 2024-EDT
From: RLB,HIC at MIT-MC
Sent-by: RLB at MIT-MC
Subject: 5K lost symbol words
To: MRG at MIT-MC, GLS at MIT-MC, (BUG LISP) at MIT-MC, RLB at MIT-MC

After PURCOPYing a symbol, the impure SY2 blocks were never freed for reuse.
The garbage collector doesn't sweep any SY2 segments. Now PURCOPY explicitly
adds the old SY2 block to the SY2 freelist, and the SY2 segments are still
not swept.

KWC@MIT-AI 05/23/78 16:20:42
To: HIC at MIT-AI, GLS at MIT-AI, (BUG LISP) at MIT-AI
sorry about my last bug message, it was intended for the
lisp machine group.

Date: 23 MAY 1978 1602-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: HIC at MIT-MC, KWC at MIT-MC, (BUG LISP) at MIT-MC, KLE at MIT-AI


    Date: 23 MAY 1978 1119-EDT
    From: HIC at MIT-MC (Howard I. Cannon)
    To: KWC at MIT-MC, (BUG LISP) at MIT-MC, KLE at MIT-AI


        KLE@MIT-AI 05/22/78 17:33:32
        To: (BUG LISP) at MIT-AI
        a number of errors print while compiling <function> with no
        space after the "white compiling".
        			Ken Church (KWC)
    --------
    I don't understand this at all.

He means, "a number of errors print 'while compiling <function>' with no
space after the 'while compiling'", I assume.  The missing quotation
marks are confusuing.

Date: 23 MAY 1978 1119-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: KWC at MIT-MC, (BUG LISP) at MIT-MC, KLE at MIT-AI


    KLE@MIT-AI 05/22/78 17:33:32
    To: (BUG LISP) at MIT-AI
    a number of errors print while compiling <function> with no
    space after the "white compiling".
    			Ken Church (KWC)
--------
I don't understand this at all.

Date: 23 MAY 1978 0344-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Can someone fix SPRINTER so that it doesn't change the value of LINEL? It
sets it to 78. and doesn't reset it when it is done. Thanx. KMP

Date: 22 MAY 1978 2128-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: FRAWLE at MIT-MC
CC: (BUG LISP) at MIT-MC

Unlike FORTRAN, LISP defines a floating-point number to be one
with a decimal point AND one or more digits following the decimal
point.  An integer followed by a decimal point just means a
decimal integer (one without a decimal point is interpreted
according to the current input radix in IBASE).

Date: 22 MAY 1978 2127-EDT
From: FRAWLE at MIT-MC (Bud Frawley)
To: (BUG LISP) at MIT-MC


bug? not really ... but

GRIND changed instances of integers ("1") to flonums ("1.")
which seems a bit libertine.


KLE@MIT-AI 05/22/78 17:33:32
To: (BUG LISP) at MIT-AI
a number of errors print while compiling <function> with no
space after the "white compiling".
			Ken Church (KWC)

GLS@MIT-AI 05/22/78 09:51:26 Re: I/O functions
To: kmp at MIT-MC
CC: (BUG lisp) at MIT-MC
[1] PRINT et al. did used to return their arguments at one time.
This got changed to support the number compiler (it is expensive
to needlessly return one's numeric pdl argument).
[2] When they got changed, we followed the by then standard convention
that a routine which "succeeds" should return T (not NIL) if it
has nothing better to return.  TERPRI, being a hangover from
the very, VERY bad old days, continued to return NIL.
Tough noogies.  Why the hell did you ever depend on their values?
(If it was because you wrote
	(AND HAIR (TERPRI) (PRINC FOO))
you deserve what you get -- you only saved one letter and a pair
of parens over (COND ...).)


Date: 22 MAY 1978 0852-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

DRAT!!! GUNK! ICKKK! I CAN'T BELIEVE ALL THE I/O FUNCTIONS DON'T RETURN THE
SAME THING. 

[1] (In my opinion) PRINT, PRIN1, ... and all the printy things like TYO too
    shud return their arg.

[2] Since [1] is not the case, the least you could do is make (TERPRI) and
    (PRINT ...) return the same thing!!! It took me hours to find bugs related
    to this just now!

Thanx. kmp
(sorry to flame, just frustrated)

Date: 21 MAY 1978 0046-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC

(mergef (defaultf 'upoly) '((dsk drb) * fasl)) returns ((dsk drb) upoly @),
not ((dsk drb) upoly fasl) or ((dsk drb) upoly *), i.e. now passing it to
LOAD loses.  I thought this was the function of DEFAULTF?

Date: 20 MAY 1978 1952-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: MPV; error
To: KMP at MIT-MC, (BUG LISP) at MIT-MC


    Date: 20 MAY 1978 1507-EDT
    From: KMP at MIT-MC (Kent M. Pitman)
    Subject: MPV; error
    To: (BUG LISP) at MIT-MC

    I don't know what STATUS-PURSI does, but I was randomly looking and
    I did "(STATUS PURSI)" it said wrong # of args, so I did (STATUS PURSI NIL)
    and it MPV;'d ... 1) This is probably a bug? 2) What does it do? Thanx, kmp
--------
(STATUS PURSI <space-name>) returns the PURSIZE (pure size) of that space.
The error checking code for this particular space hacking function was very
poor due to the fact that it hacked with the argument prematurely.  This
has been fixed but not patched.

Date: 20 MAY 1978 1507-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: MPV; error
To: (BUG LISP) at MIT-MC

I don't know what STATUS-PURSI does, but I was randomly looking and
I did "(STATUS PURSI)" it said wrong # of args, so I did (STATUS PURSI NIL)
and it MPV;'d ... 1) This is probably a bug? 2) What does it do? Thanx, kmp

Date: 19 MAY 1978 0219-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

I added a special value to *PURE: SYMBOL for RLB.  When *PURE is this
everything except symbols is purified.

Date: 19 MAY 1978 0132-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC

RLB and I just found one of the reasons that MACSYMA is smaller
in the new LISP.  The value of GCPROTECT was #2 in the old LISP due
to a typo in the STRUCT file.  I fixed this during one of my random
walks through struct trying to do something useful.  This was causing
a list > 1700 octal objects long to be created and causing things
which should have been pruified not to be!!!  Oh well, the pure stuff helps
a little I'm sure, but this takes into account at least 1k of impure
space and probably more like 2k of pure space!!!  (wow, a powerful typo).

--Howard

DLW@MIT-AI 05/18/78 02:03:18
To: (BUG LISP) at MIT-AI
Let me add my voice to the crowd:
(DEFUN FEXPR MACRO (X) ...)
should define a macro called "FEXPR", rather than vice versa.  There
are several reasons for this.  One is that the @ program and EMACS
think of (DEFUN xxx ...) as the definition of xxx.
	I was under the impression that everyone agreed to this change.
How about it?


KEN@MIT-AI 05/17/78 23:09:08
To: (BUG LISP) at MIT-AI
A semi colon comment at the very end of a file that does not have a carriage return causes
load to complain about end-of-file.  This is annoying, and the very first time it happened I
must have spent half an hour tracking it down.  I understand why it happens but wonder if
there isn't some inexpensive way of fixing it.
E.G.
(setq foo 'bar)
;this comment does not end with a cr

Date: 17 MAY 1978 2136-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: lock for dumped Lisp systems
To: HENRY at MIT-AI
CC: (BUG LISP) at MIT-MC


    HENRY@MIT-AI 05/17/78 15:59:31 Re:  lock for dumped Lisp systems
    To: HIC at MIT-AI
    There might be a problem with people 
    remembering to edit the lock file in the
    manner you propose. Here's an alternative.

    Keep a file with the names of files dumped
    with the flush feature. It could also contain
    the UNAMES of their maintainers. A simple
    program run each time a new Lisp was dumped
    could do the following. It could mail reminders
    to maintainers to redump systems in the new Lisp.
    After a while, a GC program could run around checking
    (STATUS LISPVERSION) in each of the files, and
    if all existing systems were updated, the copy
    would be deleted.
------------
Your ideas regarding the handling of the LISP system are reasonable; but I want
to keep the mechanism down to a low level of complexity for all parties
involved.  I don't want to have to have hairy hacks, and I want
to be able to find the cases of lossage fast.  Therefore, I think the
single user-maintained file is the best scheme.  BTW, even if a lISP does
go away it is a simple matter to restore it from backup tape, so there really
isn't that much lossage if the system maintainer forgets.....

--Howard

Date: 17 MAY 1978 0701-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, KEN at MIT-AI


    KEN@MIT-AI 05/17/78 03:55:28
    To: (BUG LISP) at MIT-AI
    The new Lisp seems to get stuck fasloading.  Its happened to me twice.
    The one that's easiest to reproduce is:
    :lisp ken;direct
    (go-fast)
    (load'((ken)obtest)) ;;about one cpu minute later it loops fasloading ken1;tutil fasl

    while the exact same sequence works fine with :olisp
    WARNING: to reproduce this you should be on a tv since it does some graphics calls first
---------
There was a bug introduced into recursive fasload's by the introduction of the
new extendable uuolinks stuffwhich has been fixed in the source and a
kludgy (but working!) patch installed to correct the problem in the running 
LISP.  I ran your example through to completion!

--Howard

KEN@MIT-AI 05/17/78 03:55:28
To: (BUG LISP) at MIT-AI
The new Lisp seems to get stuck fasloading.  Its happened to me twice.
The one that's easiest to reproduce is:
:lisp ken;direct
(go-fast)
(load'((ken)obtest)) ;;about one cpu minute later it loops fasloading ken1;tutil fasl

while the exact same sequence works fine with :olisp
WARNING: to reproduce this you should be on a tv since it does some graphics calls first


Date: 17 MAY 1978 0142-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: init files
To: EAK at MIT-MC, JPG at MIT-MC, ELLEN at MIT-MC, JLK at MIT-MC
To: RWK at MIT-MC, RMS at MIT-MC, MOON at MIT-MC, (BUG LISP) at MIT-MC


I have written up the results of my various conversations on the subject
of init files, a scheme which I think wins as much as it is possible to
win; more than I used to think it was possible to win, in fact.

Since I try to answer all the questions I've encountered on the subject,
it is a little on the long side so I didn't mail it.  It may be found in
the file Z;INIT FILES.  I think that it is easier to understand than
the current hodgepodge of algorithms for finding init files.


Date: 17 MAY 1978 0121-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC, (BUG NIL) at MIT-MC

It would be really nice if one could print and read subr-pointers without
doing a mapatoms looking for the symbol with the right property.  I want to
be able to shove these guys on files somehow, and read them back in later.
Is there some way to grovel and discover the function name associated to a
subr-pointer?  A related question:  can FUNARGs in NIL be written and read
in a later lisp?  How about on the lisp machine?

Date: 17 MAY 1978 0024-EDT
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC

Apparently there is no documentation on GCTWA in LISP RECENT, NEWS, or ARCHIV,
other than noting it is no longer a status option.

Date: 16 MAY 1978 2240-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: LISP ARCHIV AND LISP NEWS
To: JONL at MIT-MC, (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

I found a section of one LISP RECENT was missing from LISP ARCHIV but present
in LISP NEWS.  I moved that section into LISP ARCHIV.  Now LISP NEWS is
the same as LISP ARCHIV (according to SRCCOM) up to the end of LISP NEWS.

--Howard

Date: 16 MAY 1978 2150-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: CASEQ
To: (BUG LISP) at MIT-MC, EB at MIT-AI


    EB@MIT-AI 05/16/78 18:05:31 Re: CASEQ
    To: HIC at MIT-MC
        There's something I don't understand.  Since I haven't used
    CASEQ before it might be a problem with how I'm trying to use it,
    but why doesn't this work?

    	(DEFUN FOO (N)
    	       (CASEQ N
    		      (1 (PRINT 1))
    		      (2 (PRINT 2))
    		      (T (PRINT 'FOO))))

    	(foo 1)
    	1 
    	(foo 2)
    	;2 DOES NOT MATCH MATCHING EXPRESSION TYPE
----------
There was actually a bug in interpreted CASEQ, which has been fixed and patched
on all systems.  Thanks for pointing this out.

Date: 16 MAY 1978 2028-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject:  LISP ARCHIV
To: JPG at MIT-MC, (BUG LISP) at MIT-MC

It has come to my attention that LISP ARCHIV looks somewhat out-of-kilter.
As soon as I get a chance, I will look into it and make sure that 
(STATUS PUNT) is cleared up.

Date: 16 MAY 1978 2018-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, WJL at MIT-ML

LISP now uses the XUNAME to find the init file.  The XUNAME is set by $^S
independently from your working directory.

Date: 16 MAY 1978 2015-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: EAK at MIT-MC, (BUG LISP) at MIT-MC, ALAN at MIT-AI


    ALAN@MIT-AI 05/16/78 15:41:56
    To: (BUG LISP) at MIT-AI
    Typing '|A| gets a symbol with the proper print name, however
    the printer prints it as "A".  '|A| however prints like it should.
    Apparently an all zero number in the pname list is ignored?
-------
The reason that '|^@^@^@^@A| prints correctly is to prevent a screw where
a null byte anywhere in a word would cause the remainder of that word to be
ignored.  LISP now ignores trailing nulls.  Unfourtunatly, ^@ in printnames
is not fully implimented and I strongly recommend you do not use them....

--Howard

ALAN@MIT-AI 05/16/78 15:42:32
To: (BUG LISP) at MIT-AI
Btw that last bug note was really from EAK, not ALAN.

ALAN@MIT-AI 05/16/78 15:41:56
To: (BUG LISP) at MIT-AI
Typing '|A| gets a symbol with the proper print name, however
the printer prints it as "A".  '|A| however prints like it should.
Apparently an all zero number in the pname list is ignored?

WJL@MIT-ML 05/16/78 13:45:37
To: (BUG LISP) at MIT-ML
How come the new lisp demands that the init be on the directory
of the login name rather than the name that was $$^S'd to?

Date: 16 MAY 1978 1332-EDT
From: EAK at MIT-MC (Earl A. Killian)
Subject: init files
To: RWK at MIT-MC, RMS at MIT-MC, MOON at MIT-MC, (BUG LISP) at MIT-MC

I believe I started this whole debate by getting HIC to change LISP to stop
using the MSNAME which I assume everyone agrees is equally losing.
Now, RWK claims he and RMS have decided that <hsname>;<xuname> .LISP. is the
proper place to look.

First, is this only after looking for <xuname>;.LISP. (INIT) and failing?
I.e. will my lisp init be EAK;.LISP. (INIT) or EAK;EAK .LISP.?

Second, is it really desirable for people without directories to have a
HSNAME of (INIT)?  If they do then thats where RMAIL will put the person's
RMAIL file, which hardly seems desirable.

Third, would someone please explain the motivation for the HSNAME variable?
For example what is wrong with using (INIT);<xuname> .LISP.?  What lossage
will occur?

Date: 16 MAY 1978 0516-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC

To put it in writing: LISP ARCHIV contains no description of 
(STATUS PUNT), even though such a description is contained 
in LISP NEWS.  Also, the description given contains no mention of 
FUNCALL although that is a handy way out of the dilemma (SSTATUS PUNT T) 
causes.

Date: 16 MAY 1978 0305-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

LISP sets it's .SNAME sometimes, and it set's it's STATUS UDIR
when it is $G'd, this can result in STATUS UDIR getting clobbered completely
randomly. (randomly == uselessly).

Date: 16 MAY 1978 0211-EDT
From: PURE at MIT-MC
Subject: PURE
To: (BUG LISP) at MIT-MC

Pure-Uses-Resources-Erratically, the ultimately-pure  system.??

Date: 16 MAY 1978 0134-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: (INIT) files
To: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC

One might suggest, only half-jokingly, that (INIT) should be another
special second file name like < and >; it could then thrash
around as a function of XUNAME, HSNAME, JNAME, JTMU, and phase of moon,
trying to find an init file.

Date: 16 MAY 1978 0033-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC, RMS at MIT-MC, MOON at MIT-MC

RMS and I talked about it, and came to the conclusion that DDT should
set the .HSNAME with $^S, by looking it up in INQUIR.  Similarly,
DDT would replace SETMSN, thus fixing problems of HSNAME not being set
properly unless you do it yourself.  Thus FOO$^S would always get FOO's
init.  Thus what LISP should use would be
<HSNAME>;XUNAME .LISP. or <HSNAME>;.LISP. XUNAME (the difference is a matter
of aesthetics).  The .HSNAME will always be set to something reasonable
where init files and RMAIL files can be placed.


RMS@MIT-AI 05/15/78 23:45:21
To: (BUG LISP) at MIT-AI, RWK at MIT-AI, MOON at MIT-AI
I used to think that using the hsname and the xuname would work.
But if finding the init file uses anything other than the xuname,
you have the problem that you can't tell lisp to use someone else's init
file, unless lisp wants to be smart enough to look up the guy's hsname
in the inquir data base the way setmsn does.  I think that such hair
is unacceptable.  FOO$^S should make Lisp use FOO's init, and that can
be done only if looking for the init depends only on the xuname.

Or do people think it is ok for all programs that look for inits
to have to look the person up in inquir?

Another alternative is to have a special file on (INIT) which
you use to specify hsname.  Then, to find FOO's init, look
for (INIT);FOO HSNAME, read its contents to find BAR,
then look for BAR;.LISP. FOO.  Note that this doesn't use .HSNAME.
It does seem as if the hsname may not really be a workable idea,
when combined with $^S.  Or, perhaps $^S should set the next program's
.hsname to corrspond to what it puts in that program's .xuname,
by looking on (INIT) or in inquir.

RWK, I wish you wouldn't get so emotional about any message I send.
My message was hardly comdemning you (it agreed with part and disagreed
with part), so you shouldn't have taken it as such.


Date: 15 MAY 1978 2327-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: RMS's message.
To: (BUG LISP) at MIT-MC, RMS at MIT-MC, MOON at MIT-MC

I think it should read from
<HSNAME>;<XUNAME> .LISP. for that reason.  Or it could look on
(INIT) first.  Shared init files are commonly used.  And it is
possible for an init file to check the XUNAME.  What is the
HSNAME for if not to specify where init files are to be found???
Just where RMAIL files go?  That's pretty random!

RMS@MIT-AI 05/15/78 23:20:21
To: (BUG LISP) at MIT-AI, RWK at MIT-AI, MOON at MIT-AI
What lisp does now IS right.
If I have an init file, people who use my dir as home
shouldn't have to get my init.
But lisp should have a way to read the hsname.


Date: 15 MAY 1978 2316-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC, MOON at MIT-MC, RMS at MIT-MC

Not only does LISP not do init files right, it doesn't have a (STATUS HOMEDIR)
so that systems built in it can do the right thing.


Date: 15 MAY 1978 2113-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Init files
To: MOON at MIT-MC, (BUG LISP) at MIT-MC
CC: RMS at MIT-MC

Foo....I suspect that we are still doing the wrong thing then!!
I will wait for your comments, RMS, and I will try to get it right!

--Howard

Date: 15 MAY 1978 2035-EDT
From: JONL at MIT-MC (Jon L White)
Subject: LISP ARCHIV AND LISP NEWS
To: (BUG LISP) at MIT-MC

The first umpteen pages of LISP ARCHIV should be identical to LISP
NEWS, but character number 242357. of former corresponds with number
250388. of latter, for a missing-segment of 8031. chars.

Date: 15 MAY 1978 1944-EDT
From: PRATT at MIT-AI (Vaughan Pratt)
To: CGOL-USERS at MIT-AI, JONL at MIT-AI
CC: (BUG LISP) at MIT-AI

Use ONCOMPL to compile CGOL files.  NCOMPLR has for a long time now been unable to
cope with (DEFUN (FOO BAZ) ...) (DEFUN (FOO BAR) ...) - it gets a FOO DUPLICATED FUNCTION
error.  JONL take note (again).


Date: 15 MAY 1978 1906-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Init files
To: (BUG LISP) at MIT-MC
CC: MOON at MIT-MC, RMS at MIT-MC

If Lisp follows the algorithm implied by lisp recent, it is still wrong.
I believe the correct algorithm is considered to be:
	<hsname>; .LISP. (INIT)
then	(INIT); <xuname> .LISP.
LIsp sounds like it is using <xuname> rather than <hsname>.
What is your opinion, RMS?

Date: 15 MAY 1978 1719-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: PURIFY
To: GLS at MIT-MC, RBR at MIT-AI
CC: (BUG LISP) at MIT-MC


    RBR@MIT-AI 05/15/78 17:14:59 Re:  PURIFY
    To: HIC at MIT-AI, GLS at MIT-AI
    How does the change to extensible UUOLINKS affect the procedure outlined inthe
    old blue manual for computing arguments to PURIFY.  There, one allocated
    a finite number of pages for UUO links and carefully avoided including them
    in the range of BPS to be purified.  Is this now unnecessary?  Do UUO links have
    their own space?

    Bruce
---------
Ah, yes, unfourtunatly, I suspect this was an oversight on my part not
explaining how the procedure would change.  The calculations are no longer
necessary.  The uuolinks segments are now allocated one LISP segment at a
time from both the impure and pure storage areas.  The LISP system keeps track
of which pages are pure and which are impure when using this means
(the pages are no longer allocated out of BPS) and therefore
(PURIFY 0 0 'BPORG) is garunteed to purify the pure area of the uuolinks
segments.  BTW, do you have a pure system? (I want to get a handle on the
number of pure systems around in terms of the impact that (SSTATUS FLUSH T)
might have...)

--Howard

Date: 15 MAY 1978 1311-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

See NIL;NUMBER > for some discussion (and, alas, few solutions)
of some problems with numbers in NIL.  Suggestions solicited.

KLE@MIT-AI 05/14/78 21:30:06
To: (BUG LISP) at MIT-AI


Date: 14 MAY 1978 2024-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: INIT files
To: (BUG LISP) at MIT-MC, EAK at MIT-AI

In the next LISP (to be released within hours) the XUNAME will be used as
the SNAME is used now.  Therefore, the algorithm should be:
Try:
xuname;.lisp. (init)
then:
(init);xuname .lisp.


Date: 14 MAY 1978 1929-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: (BUG LISP) at MIT-MC

How about providing a way of using FASL files as (INIT)'s directly.
Currently it is necessary to have a .LISP. (INIT) that does nothing
but do (LOAD ...).

EAK@MIT-AI 05/14/78 12:43:00 Re: INIT files
To: (BUG LISP) at MIT-AI
Sigh.  LISP algorithm for finding INIT files loses badly.
It seems that if the working directory (i.e. DDT's MSNAME which
is the SNAME Lisp is started with) does not exist then Lisp does
the right thing, i.e. it uses (INIT);<xuname> .LISP. as the INIT
file.  However if the working directory does exist then it looks
for <wd>;.LISP. (INIT) which is an utter loss.  I don't believe
the working directory is the proper place to look for INIT files
for any program.  INIT files are usually a personal thing and so
the place to look should be based on the <xuname>.

Therefore I suggest the following:
Look for <xuname>;.LISP. (INIT) and use it if found.
If not found then look for (INIT);<xuname> .LISP. .
This in no way depends on the working directory.

Alternatively you could do the following:
Look for <xuname>;.LISP. (INIT) as above.
If not found then look for <hsname>;<xuname> .LISP. .
(Not <hsname>;.LISP. (INIT) !).

Do you think this can be changed soon?  The current scheme is a
real screw.

Date: 14 MAY 1978 0607-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: When to creat PURE symbols (sy2blks)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 13 MAY 1978 0304-EDT
    From: JONL at MIT-MC (Jon L White)
    Subject: When to creat PURE symbols (sy2blks)
    To: (BUG LISP) at MIT-MC

    Any symbol created by RINTERNing, such as thru READ and FASLOAD
    (of course, assuming *PURE = T), and thru PURECOPY, and at no
    other times.  Thus the current usage on PNGNK1, PNGNK2 etc by
    GENSYM, MAKNAM, READLINE, and COPYSYMBOL will never directly
    create symbols with pure structure.
------
Implimented for next release of LISP (se note re macsyma)

Date: 14 MAY 1978 0607-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 13 MAY 1978 0257-EDT
    From: JONL at MIT-MC (Jon L White)
    To: (BUG LISP) at MIT-MC

    (DO ((I 0 (1+ I)) (^D T) (*PURE T))
        (NIL)

       (GENSYM))
-------
No longer causes pure space to be eaten up.

Date: 14 MAY 1978 0559-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject:  LISP did some reducing (if only I could!)
To: (BUG MACSYM) at MIT-MC, (BUG LISP) at MIT-MC, JM at MIT-MC
To: ELLEN at MIT-MC, RWK at MIT-MC

Using new changes to LISP (dealing with purification hackery) that RLB, myself,
and JONL worked out, I built a LOSER >.  It turns out that it shares two more
pages then current MACSYMA, has five fewer impure pages, is 3 pages smaller,
and can actually run ODE2 DEMO to completion (!!).

I am thus installing this LISP this weekend.

--Howard (The large? --RWK)

GSB@MIT-ML 05/14/78 02:38:58
To: (BUG LISP) at MIT-ML
Need some way to supply a function to catch interrupts on a
fixnum output file.  (ie endpagefn and eoffn won't allow it.)


GSB@MIT-ML 05/13/78 19:41:00
To: (BUG ITS) at MIT-ML
CC: (BUG LISP) at MIT-ML
FORCE on an sty output channel gives a WRONG DIRECTION error;  i suppose
that if it doesn't want to do anything, it should say WRONG TYPE DEVICE.
Lisp does a FORCE when it reads the cursorpos, apparently.


GSB@MIT-ML 05/13/78 19:28:15
To: (BUG LISP) at MIT-ML
God dammnes lost user interrupt!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
What the hell is it anyway???????????????????


Date: 13 MAY 1978 0500-EDT
From: JONL at MIT-MC (Jon L White)
To: RLB at MIT-MC
CC: (BUG LISP) at MIT-MC, RMS at MIT-MC

I have tried this last round to put special checking in the
compiler's file-scanner to look for instances of lap-a-list with
quoted arg.  But evidently failed!  Anyway, I think it is a 
good suggestion, and will continue to try to win on it.
  Also, I have tried to change the default file (just after 
doing QC^K) to be something on the (STATUS UDIR), while still
loading in the init file from the (STATUS USERID) directory.

Date: 13 MAY 1978 0304-EDT
From: JONL at MIT-MC (Jon L White)
Subject: When to creat PURE symbols (sy2blks)
To: (BUG LISP) at MIT-MC

Any symbol created by RINTERNing, such as thru READ and FASLOAD
(of course, assuming *PURE = T), and thru PURECOPY, and at no
other times.  Thus the current usage on PNGNK1, PNGNK2 etc by
GENSYM, MAKNAM, READLINE, and COPYSYMBOL will never directly
create symbols with pure structure.

Date: 13 MAY 1978 0257-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(DO ((I 0 (1+ I)) (^D T) (*PURE T))
    (NIL)

   (GENSYM))

Date: 13 MAY 1978 0126-EDT
From: JONL at MIT-MC (Jon L White)
Subject: (STATUS FASLOAD)
To: (BUG LISP) at MIT-MC

Hau Abaut letting (STATUS FASLOAD) return the LDBSAR of the currently-
being-loaded-file, if executed within a fasloading, or NIL of not
fasloading.  Thus EVAL-mungeables could decide what the name of the
resultant file is, and ^B breaks could snoop around a little more.

GLS@MIT-AI 05/12/78 20:26:51
To: rz at MIT-MC
CC: RMS at MIT-AI, (BUG lisp) at MIT-MC
(STATUS USERID) reads the XUNAME.


Date: 12 MAY 1978 1712-EDT
From: RZ at MIT-MC (Richard E. Zippel)
Subject: Which directory to get .LISP. (INIT) from
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC, rms at MIT-AI

I think the .SNAME was used because that was at one time
the reason for it - namely a subsystem was started with the
default directory from the .sname (or was it .msname), but
of course when you log in, this is initialized to the .UNAME
One problem is changing it now is that there is a status
call (STATUS UDIR)  which currently gets the .SNAME, and 
there is currently no (STATUS XUNAME) [but there is (STATUS UNAME)].

Date: 12 MAY 1978 1301-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject:  PURCOPY getting PURPG after PURIFY done
To: JPG at MIT-MC, (BUG LISP) at MIT-MC

Well, yes, unfourtunatly, in this case, the problem is that the patch
only takes affect on system creation and.  If you were to build a new
Macsyma, you would win...if you wish, I can fix the macsyma by hand to
allow you to PURCOPY.  Is this desirable?

MOON@MIT-ML 05/12/78 12:44:11
To: (BUG LISP) at MIT-ML
(LOAD '((MC MOON) FOO BAR)
;DEVICE NOT AVAILABLE
;BKPT IO-LOSSAGE
ARGS
(LOAD ((MC MOON) FOO BAR)
(RETURN ARGS)
;LOAD UNBOUND VARIABLE

ISN'T (RETURN ARGS) SUPPOSED TO RETRY THE OPERATION,
IN EFFECT?

Date: 12 MAY 1978 0243-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

HIC@MIT-MC 11 MAY 1978 2018-EDT
The bug that was causing pure space consing to fail with PURPG;
trap after a PURIFY was done has been fixed and patched on MC.

I don't know what "fixed and patched" means.  It still loses 
in MACSYMA, e.g. (PURCOPY '(FOO BAR)) gives the same old error.

Date: 11 MAY 1978 2018-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

The bug that was causing pure space consing to fail with PURPG;
trap after a PURIFY was done has been fixed and patched on MC.

Date: 11 MAY 1978 2005-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

Minor change to unreleased feature:
(STATUS SYSTEM foo) where foo is s system symbol includes SYMBOL in the
list returned (not ATOM as mentioned before)

Date: 11 MAY 1978 1405-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RMS at MIT-MC, (BUG LISP) at MIT-MC


    Date: 11 MAY 1978 0202-EDT
    From: RMS at MIT-MC (Richard M. Stallman)
    To: (BUG LISP) at MIT-MC

    kmp$^S Q^K ^Q should run kmp's init file.
    The XUNAME should always be the thing used to decide what init file to run
--------
It seems that the XUNAME is the right thing to use.  This will come up in the
next version of LISP.

--Howard

Date: 11 MAY 1978 1050-EDT
From: RLB at MIT-MC (Richard L. Bryan)
To: HIC at MIT-MC, RLB at MIT-MC
CC: (BUG LISP) at MIT-MC

Proposal for changes needed to impliment winning purification regime:

A) Add explicit PURE sy2 conser and IMPUre SY2 conser
B) PURCOPY of a symbol shouuld also purify SY2
C) COPSYSYMBOL ignores *PURE
D) Since SY2 is now being copied, don't set CCN or OTC;  the depurifier should
   set these bits when SY2 is written into.

RMS@MIT-AI 05/11/78 02:29:14
To: (BUG LISP) at MIT-AI
It is a mistake to use .SNAME to determine which init file to run.


Date: 11 MAY 1978 0223-EDT
From: JONL at MIT-MC (Jon L White)
To: RMS at MIT-AI
CC: (BUG LISP) at MIT-MC

kmp$$^s Q^K 
will read KMP's .LISP. (INIT) file, since  LISP and COMPLR 
gobble down the .SNAME rather than the .XUNAM

Date: 11 MAY 1978 0202-EDT
From: RMS at MIT-MC (Richard M. Stallman)
To: (BUG LISP) at MIT-MC

kmp$^S Q^K ^Q should run kmp's init file.
The XUNAME should always be the thing used to decide what init file to run

Date: 10 MAY 1978 1806-EDT
From: BEE at MIT-MC (Bruce E. Edwards)
To: (BUG LISP) at MIT-MC

(expt -3.0e-6 .33)
gives you a strange error, where as
(expt 3.0e-6 .33) wins.

Date: 10 MAY 1978 1616-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: (STATUS SYSTEM FOO)
To: RLB at MIT-MC, (BUG LISP) at MIT-MC



    Date: 18 APR 1978 1125-EST
    From: RLB at MIT-MC (Richard L. Bryan)
    Subject: (STATUS SYSTEM FOO)
    To: (BUG LISP) at MIT-MC

    This should return an indication (e.g. T) for symbols needed internally in 
    Lisp but which have no other reason to appear in STATUS SYSTEM.
    For example, LAMBDA and FUNARG.
    The philosophy being that (STATUS SYSTEM foo) should return non-NIL for
    ALL symbols needed by the Lisp system.
-------
In the next LISP, (STATUS SYSTEM foo) will return, as a member of its list
the atom ATOM if foo is a system atom.  This way, CONS will return (SUBR ATOM)
and LAMBDA will return (ATOM).

--Howard

KLE@MIT-AI 05/10/78 15:21:02
To: (BUG LISP) at MIT-AI, NIL at MIT-AI

    KLE@MIT-ML 05/10/78 01:48:00
    To: (BUG LISPM) at MIT-ML, TRENCHARD at MIT-ML, LSP at MIT-MC
    To: KHG at MIT-MC
    After a lot of fighting the system and helpful suggestions from the magical
    realm of the almight LISP, APL and Array Theory wizzards of the world At last!
    A true chance to be bored out of your skull:

    A written proposal on Extended Array Functions for Lisp-Macine LISP has been
    written and is available in several different flavors for your casual perusal,
    enjoyment, or annoyance:

    At a terminal:  KLE;ARFDOC LPT
    For Hard Copy:  KLE;ARFDOC XGP
    For Masochists: KLE;ARFDOC >

    I gladly welcome any and everyones comments and suggestions ESPECIALLY on 
    names for the numerous functions which are presented, that will be reasonably
    mnemonic and meaningfull.  Send your comments to KLE, and/or BUG-LISPM and they
    will probably be incorporated into the document, and/or appended to the end of
    it.

    Thanks --54.



PHW@MIT-AI 05/10/78 09:11:41
To: (BUG LISP) at MIT-AI


Date: 10 MAY 1978 0446-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC

Hey, you experts on reading and printing floating point numbers, 
how about fixing this already?  
JPG@MIT-MC 02/02/77 01:38:28
To: (BUG LISP) at MIT-MC
In MACSYMA:  3.1415926535897932384626433832795;  ==> 0.0
Trace:
  (1 ENTER READLIST ((/3 |.| /1 /4 /1 /5 /9 /2 /6 /5 /3 /5 /8 /9 /7 /9 /3 /2 
/3 /8 /4 /6 /2 /6 /4 /3 /3 /8 /3 /2 /7 /9 /5))) 
  (1 EXIT READLIST 0.0) 

Date: 10 MAY 1978 0411-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Hiseg follies
To: RPG at SU-AI
CC: (BUG LISP) at MIT-MC

I am currently FTP'ing both an OLDIO and a NEWIO over to [NEW,LSP].
(version 1567)
As for changes and fixes, well, I guess there really isn't anything
major (most new developments has been on ITS features for FASLOAD and the
like to make MACSYMA happier!).  GETDDTSYM has been hacked to use LISP's
mini-symbol-table (this is perhaps useful).  Other then that, I guess there
is no reason to bring it up (there are probably some didly bug fixes)...
But you might want to give it a go anyway and let me know if I introduced
any major new screws.....

--Howard
(PS  Could you please expand upon that fasload temp file array problem?)

Date: 9 MAY 1978 0919-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RLB at MIT-MC
CC: (BUG LISP) at MIT-MC

GETDDTSYM will now look in in-core table of symbols before going to DDT.
This will be in the next release of LISp (I wanna talk to you about
when you feel your features are stable enough to allow such a release...it
has been a while)

--Howard

Date: 9 MAY 1978 0334-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC
CC: RLB at MIT-MC


    JPG@MIT-MC 05/05/78 04:26:25
    To: HIC at MIT-MC
    CC: RLB at MIT-MC
    Well, you saw the note from GLS.  He says it is ok to go ahead with 
    the SUSPEND flushing of LISP pure pages from LISP dumps such as 
    MACSYMA being made available as a non-default mode.  MACSYMA will 
    certainly use it.
--------
This feature has been implimented and is under control of the status
option FLUSH.  (SSTATUS FLUSH T) turns it on, and the default value
of (SSTATUS FLUSH NIL) means it is off. (STATUS FLUSH) returns its value.
This will come up in the next LISP.

--Howard

ANDYA@MIT-AI 05/08/78 21:14:45
To: (BUG LISP) at MIT-AI
-----
|   |  Yes, I love NIL to be printed out as the cretinous monstrosity '()' ...
-----

-----
| X |  NO! Leave the poor thing alone. NIL should ALWAYS be printed as letters.
-----      It is incredibly un-aesthetic for it to be printed as '()' !!!



KLH@MIT-AI 05/08/78 15:24:57
To: (BUG LISP) at MIT-MC
I'm not proposing a character.  I merely meant that if for some
reason (which you haven't explained) it is necessary to change
from NIL, something like F (as opposed to T) would seem more reasonable
than ().

Date: 8 MAY 1978 1443-EDT
From: SATAN at MIT-MC (Michael R. Genesereth)
Subject: ()
To: (BUG LISP) at MIT-MC

It just isn't worth the incompatibility.

If you insist on suuch unimportant changes, why not do it right
and distinguish between NIL (the truth value), an atom, and
() (the empty list), not an atom but a list.

DOYLE@MIT-AI 05/08/78 08:10:37 Re: I like NIL to print as NIL, not as ().  Thanks.
To: (BUG LISP) at MIT-AI


Date: 7 MAY 1978 2307-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Hiseg follies
To: RPG at SU-AI
CC: (BUG LISP) at MIT-MC

Oh, ok, I didn't realize that hiseg name would be reinitialized from lowseg
Well, no problem then, with the wonders of EMACS I'll just move the code...
Do you want a copy after I do that? (NIL has been changed back, BTW)

--Howard

DCH@MIT-ML 05/07/78 22:43:01
To: (BUG LISP) at MIT-ML
Weird behavior of frame creation:

Inside DIDL, an LSUBR, I do  (EVALHOOK form 'DIDL-EVALHOOK-STEP)


EVALHOOK does the right thing, and calls DIDL-EVALHOOK-STEP, a SUBR,
with (* 2 3).  Then DIDL-EVALHOOK-STEP does (DIDL form).

Now DIDL does EVALFRAME's.  The first frame it gets is a frame for
(+ (* 2 3) 4).  It does not find a frame for DIDL-EVALHOOK-STEP on top
of the stack.  This I sort of expect, because the call to DIDL was through
a snapped UUO.

However, if I now do a ^B, and do EVALFRAME's by hand, the first frame I
get is (... (DIDL-EVALHOOK-STEP ((* 2 3)) ...), with the (+ (* 2 3) 4)
frame underneath it.

So why does the DIDL-EVALHOOK-STEP frame suddenly appear?  For the DIDL
debugger, I actually want it, and it seems I'd have to compile in (nouuo t)
mode to get it.  But if ^B can "create" the frame, can I too?

If that isn't possible, here's a suggestion:
I don't want to compile everything in (nouuo t) mode because I think it
would probably slow the running of the compiled code down noticeably.
However, I do want to have frames created for a few routines like DIDL
and DIDL-EVALHOOK-STEP.  So it would be nice if I could say
(nouuo (DIDL DIDL-EVALHOOK-STEP)) to turn on nouuo only for these routines.

I don't know how (nouuo t) works now, but I guess that it sets a global flag
so that the uuo handler doesn't replace the uuo.  So it would be inefficient
to have the uuo handler search a list everytime to see what links should and
shouldn't be snapped.  But, if instead, there were TWO uuo's, one meaning
"snap me", and the other meaning "don't snap me", then the compiler could
generate the appropriate uuo, and the uuo handler wouldn't have to worry about
anything.
--Dan

Date: 7 MAY 1978 2033-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Arguments to ALLOC function
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 25 APR 1978 0916-EST
    From: JONL at MIT-MC (Jon L White)
    Subject: Arguments to ALLOC function
    To: (BUG LISP) at MIT-MC

    ****WORKS FOR (ALLOC ...) & PROBABLY FOR INITIAL DIALOUGE, BUT THERE AIN'T
        NO FREE SPACE IN WHICH TO CONS THE FLONUMS CREATED BY READ****

    Let all the arguments to ALLOC be expressible as floating-point numbers.
    Thus one could say (ALLOC '(LIST (56.0E3 64.0E3 .2)))  rather than type
    some fixnums with lots of trailing (meaningless) zeros.  Since these
    quantites are rounded up to the neares multiple of a segment size,
    there would be no difficulyt in first fixing the flonum, and then carrying
    on.
-----------
This works now for the alloc function, but unfourtunatly if you have a flonum
in the init file alloc comment, LISP dies because it tries to do a GC due to
flonum space...barf, how can I allocate some initial flonum space??


Date: 7 MAY 1978 1521-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Forwarding of mail
To: (BUG LISP) at MIT-MC

REM@MIT-MC 05/07/78 15:12:21 Re: NOT ()
To: KMP at MIT-MC
(1) I have occasionally wanted () instead of NIL, but agree that NIL
is probably the best default.
(2) I think there should be a  flag that the user can set to get ()
instead of NIL, but FLATSIZE et al should check this flag and give
consistant results.  Perhaps the flag should be set automatically
whenever READ or READLIST gets "NIL" or "()" as input, thus if the user
inputs () he will get () rather than NIL as output.  Not sure....
^_

Date: 7 MAY 1978 1403-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: TRACE Package
To: (BUG LISP) at MIT-MC, MRG at MIT-MC
CC: KMP at MIT-MC

I have been getting some pretty strange results from TRACE these days. 
Yesterday I had something traced and I read in a new copy of it and when
I did UNTRACE it took away my copy leaving a null property list!
Today I had zeroed a property list [using (REMPROP '<thing> 'EXPR)] and
I did UNTRACE later (having traced <thing> before using the remprop command)
and when I did untrace it brought back the property list.

Proposal:

Why can't TRACE, in addition to what it does, keep a latch on the variables
it creates. Since they are gensymed, it could de an eq test on the current
arglist of expr by doing

((LAMBDA (EXPR-PROP)
	 (COND ((AND (> (LENGTH EXPR-PROP) 2)
		     (EQUAL (CADR EXPR-PROP)
			    THE-VAR-LIST-I-PUT-THERE-WHEN-I-TRACED-IT))
		(GO-AHEAD-WITH-UNTRACING))
	       (T (TERPRI TYO)
		  (PRINC '|;A NEW VERSION OF | TYO)
		  (PRINC EXPR-PROP TYO)
		  (PRINC '| EXISTS SINCE IT WAS TRACED. I AIN'T GONNA| TYO)
		  (TERPRI TYO)
		  (PRINC '|;MUNG WITH IT!| TYO)
		  (COMMENT DO NOTHING!))))
 (GET THING-TO-BE-UNTRACED 'EXPR))

Oh, well, if that doesn't work, I'd appreciate knowing why...?

				--kmp

DPR@MIT-ML 05/07/78 13:01:13
To: (BUG LISP) at MIT-ML
what the hell happened to nil?
looks like somebody took to heart the acronym "lots of irritating silly parentheses"

I presume this is only a hack, not a feature.


Date: 6 MAY 1978 2203-EDT
From: STEVER at MIT-MC (Steve Robbins)
To: (BUG LISP) at MIT-MC

I really think that NIL should be returned to it's former state of NIL,
being an atom. The way it is now, it creates many more inconsistancies and
bugs, I am all for NIL being retuend to it's origional state!

Date: 6 MAY 1978 2000-EDT
From: RJF at MIT-MC (Richard J. Fateman)
To: (BUG LISP) at MIT-MC

CHANGE FOR THE SAKE OF CHANGE IS SUSPECT. I THINK I CAN LIVE WITH THIS
ONE, BUTJUST OUTOF CURIOUSITY, IS THERE AN ESPECIALLY GOO DREASON FOR THE CHANGE?

Date: 6 MAY 1978 1717-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG MACSYMA) at MIT-MC, (BUG LISP) at MIT-MC

What is the cause of SYMBOL STORAGE CAPACITY EXCEEDED BEYOND RECUPERATION
MAJOR RESTART UNDERTAKEN?
Does this essentially mean there is no storage of any kind left?  If so,
why not say so, instead of obscure meaningless messages.

FORBUS@MIT-AI 05/06/78 15:36:08
To: (BUG LISP) at MIT-AI
	If what kmp says is true about nil printing out as (), then let
me register the strongest possible objection!  "()" is simply poor in
terms of both traditional usage and readability.  the case of a list
being empty is very (repeat, very!) special, and denoting the concept of
it by the special atom "nil" is I belive the only appropriate way to go.
	Good grief, people!  Maclisp is a running language, in which people
write programs and expect to build systems in.  The high rate of changes
in it serves only to frustrate people trying to do useful work in it. 
Currently the only saving grace is oldio, in that nobody screws around 
with it any more, "improving" it and making new "features".  Please don't 
get me wrong-I am not against signifigent improvements, even if, heaven
help us, they bring about incompatibilities.  But why not make them more
or less all at once, DOCUMENT THEM WELL, and WITH PLENTY OF WARNING.
	Once again-this crock with nil is just absurd, and it would be 
nice if people who feel this kind of change is important could find
some other program to play with.
		Ken Forbus


SACHS@MIT-ML 05/06/78 02:33:01
To: (BUG LISP) at MIT-ML
Please register my vote in favor of NIL as its own pname (in agreeance with KMP).

HENRY@MIT-AI 05/06/78 00:37:50 Re:  NIL
To: (BUG LISP) at MIT-AI
A vote for the old way - but maybe there's
some reason for the change that I'm missing?


Date: 6 MAY 1978 0034-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: LISP bug
To: EB at MIT-ML
CC: (BUG LISP) at MIT-MC


    EB@MIT-ML 04/19/78 00:24:10 Re: LISP bug
    To: HIC at MIT-MC
    CC: EB at MIT-AI

    So why does (haipart -1 -1) give me -1 instead of 1 in LISP 1513?
----------
Bug is fixed but not patched (is this important to you?)

--Howard

Date: 6 MAY 1978 0010-EDT
From: OTA at MIT-MC (Owen T. Anderson)
Subject: (): what a win!
To: (BUG LISP) at MIT-MC

In the light of all the flac about () <=> nil I thought I would put in
my vote.  I love the new print-name of ().  Keep up the good work.

RMS@MIT-AI 05/06/78 00:03:18
To: (BUG LISP) at MIT-AI, KMP at MIT-AI, nil at MIT-MC
I claim that the empty list and the truth value for falsehood
should be a special object, not identical to the symbol NIL,
for which LISTP would be true and SYMBOLP false.
CONSP, if it ever exists, would be false for it.
Its CAR and CDR would be itself.
The value of NIL would be (), but NIL would have no other
particular connection with ().  This way, most programs
would not have to be changed.  Those that did have to
be changed could probably be made to win just by
replacing every NIL with a () - or, there could be a
compatibility mode in the reader which turned NIL into ().

The advantage would be that all symbols would be on an equal footing.
Otherwise, either there is a symbol which is also a list,
or LISTP is not true of all lists (in particular, not of the empty list).
It is simply clear that (SYMBOLP 'NIL) should be true, and
(LISTP '()) should be true, and if NIL is the same as () this
is rather paradoxical.

As long as () and NIL continue to be identical (so (SYMBOLP '()) is true)
then () might as well print as a symbol.

By the way, there is no similar need to get rid of using the symbol T for truth,
because ANY symbol will do (except for the symbol NIL; but if my scheme
is adopted, this exception will cease).

There is actually some merit in Muddle's feature of providing
infinitely many FALSE's.  The easiest thing to do would be to
create the data type FALSE IN ADDITION to he empty list ().
Both () and things of data type FALSE would count as FALSE.
This way, the Lisp advantages of having () count as false
would still exist;  people would not have to use FALSEs to end
lists with;  and yet people who want to return FALSE with extra
information can do so.  I have not worked out all the details
of any way to do this, so it might involve screws.


Date: 6 MAY 1978 0001-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Hiseg follies
To: RPG at SU-AI
CC: (BUG LISP) at MIT-MC

The hiseg name gets changed to a random name via SETNM2 *before* the
origional hiseg gets removed from the jobs adr space.  This should prevent
any timeing screws (as long as the name is valid, the hiseg will be valid;
when the name becomes invalid, then the hiseg will still be valid, but,
who cares??)
Is this adequate?  If so, I will build a new LISP version for you and you can
have one with NIL that prints as ()!!

--Howard

Date: 5 MAY 1978 2351-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC, RLB at MIT-MC


    Date: 5 MAY 1978 0421-EDT
    From: JPG at MIT-MC (Jeffrey P. Golden)
    To: (BUG LISP) at MIT-MC, RLB at MIT-MC

    RLB@MIT-MC 05/04/78 14:07:51 Re: Lisp unpurify
    I have seen comments in the Lisp source code near the PURIFY code which
    claim that there exists UNPURIFY "for JPG".  Are you using this? If so,
    what for? It might affect some of the loader stuff I'm doing.

    GLS wrote this for me a long time ago.  I never used it. 
    Also, I think it may be obsolete, replaced by DP$X or something, 
    but I'm not sure of this.
--------
Since you apparently don't need this UNPURIFY entry point, and I have not heard
of any other uses for it, I have flushed it from the source.

DLW@MIT-AI 05/05/78 22:22:23
To: (BUG LISP) at MIT-AI
	My vote regarding NIL is to revert to the way it was.  Nobody
seems to like the new way, and we do not intend to change the Lisp
machine printer.  I really think the new thing is ugly, and since
when have you guys started doing things like this without asking
people?  Usually you are pretty good about such things.


DDM@MIT-AI 05/05/78 22:05:25
To: (BUG LISP) at MIT-AI
And again I add my voice to the thunder of the masses:
    "let that print name be !!   nil >>> ()  "

...and given KMP's observations you didn't even make
the change consistant - don't you have anything better
to do with your time than mucking around with things that
shouldn't be changed - you didn't even bother to ask 
our opinions.
			FOO!!!!


GSB@MIT-ML 05/05/78 21:18:26
To: (BUG LISP) at MIT-ML
I'm sorry, that was non-existent directory.


GSB@MIT-ML 05/05/78 21:18:04
To: (BUG LISP) at MIT-ML
Ha, ha,
(OPEN '|DSK:NIL;FOO >| 'IN)
==>
;(OPEN ((DSK ()) FOO >) IN)  FILE NOT FOUND
;BKPT IO-LOSSAGE


EGBERT@MIT-ML 05/05/78 21:14:46
To: (BUG LISP) at MIT-ML
	Please bring back nil's proper pname, i.e. 'nil'.  If I said 'Please
bring back ()'s proper pname.' it would look fuuny.
	If you really want I can send a message explaining all my reasons, but
the most important is that I can parse deeper expressions by eye when it's in
the 'nil' form.
                                     Ed Gilbert


PRATT@MIT-AI 05/05/78 21:09:33
To: (BUG LISP) at MIT-AI
I prefer () to NIL because
   it gives me the zip and zoom of a big typhoon.


Date: 5 MAY 1978 2057-EDT
From: NIL at MIT-AI (New Implementation of LISP)
To: (BUG LISP) at MIT-AI

I see that you fixed flatc on ().


Date: 5 MAY 1978 2024-EDT
From: GLS & HIC at MIT-MC (Guy L. Steele, Jr.)
Sent-by: HIC at MIT-MC
To: (BUG LISP) at MIT-MC, KLH at MIT-AI

Which character, other then a letter, do you propose?

Date: 5 MAY 1978 1952-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: ELLEN at MIT-MC, KMP at MIT-MC, RWK at MIT-MC, GSB at MIT-MC
CC: FFM at MIT-MC

If "NIL" is going to print as "()", I suggest that 
"T" print as ")(".

KLH@MIT-AI 05/05/78 19:48:21
To: (BUG LISP) at MIT-AI
I'm not a frequent LISP user, but I too grew up with T and NIL and
if aything was to be changed about it, I'd suggest a one-letter
counterpart to T rather than (), which of course has even less
chance of going over.  Why don't you folks announce your
own rationales?


Date: 5 May 1978 1645-PST
From: RPG at SU-AI (Dick Gabriel)
To:   eak at MIT-MC, bug-lisp at MIT-MC    

 05-May-78  1641	EAK at MIT-MC (Earl A. Killian)    
Date: 5 MAY 1978 1940-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: (BUG LISP) at MIT-MC

How about a symbol which controls whether things are uppercased by
the reader.  Sort of like *nopoint for symbols.  Thus with this
flag T if I typed "foo" I would get something different from "Foo".

You can try something like this, which, I believe, is the better way to
control this action in principle:

(DEFUN LOWER () (DO ((I 141 (1+ I)))
		    ((LESSP 172 I))
		    (SETSYNTAX I 2 I)))
(DEFUN UPPER () (DO ((I 141 (1+ I)))
		    ((LESSP 172 I))
		    (SETSYNTAX I 2 (- I 40))))
			-rpg@SAIL-

-------

Date: 5 MAY 1978 1940-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: (BUG LISP) at MIT-MC

How about a symbol which controls whether things are uppercased by
the reader.  Sort of like *nopoint for symbols.  Thus with this
flag T if I typed "foo" I would get something different from "Foo".

PGS@MIT-AI 05/05/78 19:29:03
To: (BUG LISP) at MIT-AI
-----
|   |  Yes, I love NIL to be printed out as the cretinous monstrosity '()' ...
-----

-----
| X |  NO! Leave the poor thing alone. NIL should ALWAYS be printed as letters.
-----      It is incredibly un-aesthetic for it to be printed as '()' !!!



Date: 5 MAY 1978 1741-EDT
From: PL1 at MIT-MC (Programming Language 1)
To: (BUG LISP) at MIT-MC

Wow!  Now i can always do
(AND <random pred>
     (SETQ FOO (IMPLODE BAR))
     <random cruft>)
instead of
(COND (<random pred> (SETQ FOO (IMPLODE BAR)) <random cruft>))
!!! Think of all the typing saved!

Date: 5 MAY 1978 1736-EDT
From: CFFK at MIT-MC (Charles F. F. Karney)
To: (BUG LISP) at MIT-MC

() requires a space after it before it is read.

Date: 5 MAY 1978 1731-EDT
From: ELLEN at MIT-MC (V. Ellen Lewis)
To: (BUG LISP) at MIT-MC

-----
|   |  Yes, I love NIL to be printed out as the cretinous monstrosity '()' ...
-----

-----
| X |  NO! Leave the poor thing alone. NIL should ALWAYS be printed as letters.
-----      It is incredibly un-aesthetic for it to be printed as '()' !!!


Date: 5 MAY 1978 1727-EDT
From: BKERNS at MIT-MC (Barbara S. Kerns)
To: (BUG LISP) at MIT-MC

-----
|   |  Yes, I love NIL to be printed out as the cretinous monstrosity '()' ...
-----

-----
| X |  NO! Leave the poor thing alone. NIL should ALWAYS be printed as letters.
-----      It is incredibly un-aesthetic for it to be printed as '()' !!!


Date: 5 MAY 1978 1724-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: My vote
To: (BUG LISP) at MIT-MC

-----
|   |  Yes, I love NIL to be printed out as the cretinous monstrosity '()' ...
-----

-----
| X |  NO! Leave the poor thing alone. NIL should ALWAYS be printed as letters.
-----      It is incredibly un-aesthetic for it to be printed as '()' !!!


Date: 5 MAY 1978 1607-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: (BUG QCOMPL) at MIT-MC
CC: (BUG LISP) at MIT-MC, BSG at MIT-MC

I wanted to square the value of an expression "efficiently".  I tried
(^$ x 2) and found that the compiler generated a call to ^$ instead of
doing it inline.  This is the first lossage I found.  Then I tried
using ((lambda (y) (*$ y y)) x) and found that it generated the right
thing (basically a single floating multiply instruction) as long as
the symbol x was not declared.  If x was declared to be flonum then
it generated a lot of random pushing and poping.  E.g.

(declare (flonum (square flonum)))
(defun square (x) ((lambda (y) (*$ y y)) x))

caused it to generate code to pick up its arg, move it onto some pdl,
get the address of it on the pdl, get it via the address, do the
multiply, and finally clean up the pdl.  Whew!  Maybe i should stop
declaring my functions!

I did manage to win by adding (declare (flonum y)) to the file, but
thats not a very good solution because it forces me to make sure every
y I use is a flonum.  Can the compiler be made smarter about this
situation?  I'd be curious to know what mechanism is causing it to
generate this code so even if you decide not to fix it could you
explain it to me?

P.S.  I noticed the compiler was generating a PUSH P,[FLOAT1] at the
start of all my functions and doing a POPJ at the end.  Why not
have it just do JRST FLOAT1 at the end instead?

Date: 5 MAY 1978 1512-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: GODDAMMITT HHIICC!!
To: (BUG LISP) at MIT-MC

FASLOAD at LDQAT never inserts the quoted atom into the word being loaded!

Date: 5 MAY 1978 1030-EDT
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

(flatc ())  =>  3

GSB@MIT-ML 05/05/78 07:38:43
To: (BUG LISP) at MIT-ML
hmmmm, what is the NIL printing out as '()' onn a printing terminal
feature?  I've never seen it bbefore, but its reaking havok with
my jobbnamed NIL, and attempting to load from the file TS NIL...
Alsom its jobname prints out rather funny........

ALAN@MIT-AI 05/05/78 05:08:45
To: (BUG LISP) at MIT-AI
	Currently the fact that NIL is printed as "()" causes NIL to be
the only interned symbol with the property that (IMPLODE (EXPLODE X)) is not
EQ to X.  In fact (IMPLODE (EXPLODE NIL)) is the symbol whose printname is "()".

	Don't you think it is a little late in the game to start changing the
way that NIL is special-cased? What is the printname of NIL for if not to
be printed? Frankly I think this is a bad idea and should be flushed as soon as possible,
if not sooner.

Date: 5 MAY 1978 0421-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC, RLB at MIT-MC

RLB@MIT-MC 05/04/78 14:07:51 Re: Lisp unpurify
I have seen comments in the Lisp source code near the PURIFY code which
claim that there exists UNPURIFY "for JPG".  Are you using this? If so,
what for? It might affect some of the loader stuff I'm doing.

GLS wrote this for me a long time ago.  I never used it. 
Also, I think it may be obsolete, replaced by DP$X or something, 
but I'm not sure of this.

MOON5@MIT-ML 05/04/78 23:36:41
To: (BUG LISP) at MIT-ML
By the way, I noticed this change to make nil print out
as "()".  I think this is extremely misguided.  I realize you
probably don't care what anyone thinks, but anyway that's my opinion
as a sometime user.

Date: 4 MAY 1978 2205-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: (BB$X to get defered) to get defered
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

I am defering work on the BB$X problem because solution looks non-trivial...
the interrupt stacking routines expect INTPDL to be setup from an interrupt.
So, punting is the best policy for now...

--Howard

Date: 4 MAY 1978 2054-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: PURCOPY of symbols
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    RLB@MIT-MC 05/03/78 11:04:10 Re: PURCOPY of symbols
    To: (BUG HIC) at MIT-MC
    Should set SY.OTC as well as SY.CCN
---------
Done.

Date: 4 MAY 1978 1824-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: FILEPOS
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    Date: 2 MAY 1978 1409-EDT
    From: RLB at MIT-MC (Richard L. Bryan)
    Subject: FILEPOS
    To: (BUG LISP) at MIT-MC

    Bletchery of bletcherosities!
    It sure looks like FILEPOS does a .CALL ACCESS each time, even though
    the place being accessed-to is in Lisp's buffer!
    (This applies particularly to fixnum block input)
    Why not just adjust the pointer into the buffer??
---------
Fixed....will be released in next LISP.

Date: 4 MAY 1978 1244-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC, RLB at MIT-MC

I often wish to dump out a LISP environment that takes some time to load.
But it is very inhibiting for LISP dumps to take up so much room!
Find, if you want robustness, provide that as an option too.  (Although
if LISP's were reaped by reference date, you'd probably not lose).
But I'd very much like to be able to dump out experimental frobs without
feeling guilty for comsuming inordinate amounts of disk space!


Date: 4 MAY 1978 1239-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC, RLB at MIT-MC


    RLB tells me he spoke to HIC about a mode in SUSPEND or something 
    whereby the MACSYMA dump need not duplicate on disk the pure pages 
    contained in the PURQIO dump.  This sounds to me like a neat hack 
    that should be done, and HIC tells me he is willing to do it, only 
    that GLS didn't think this should be done.  Since MACSYMA has always 
    loaded in the LISP dump on SYS;, I don't see why not.  Comments from 
    GLS?
The reason for dumping out the complete set of pages is mainly robustness;
in case the LISP somehow disappears, the MACSYMA is still runnable.
There is a tight enough coordination  between the LISP people and the MACSYMA
people that this may not be a problem; but for the sake of other suspended
programs, I think that flushing the pages should not be the DEFAULT mode,
even if offered as a (slightly dangerous) alternative.

Date: 4 MAY 1978 0352-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: RLB at MIT-MC

RLB tells me he spoke to HIC about a mode in SUSPEND or something 
whereby the MACSYMA dump need not duplicate on disk the pure pages 
contained in the PURQIO dump.  This sounds to me like a neat hack 
that should be done, and HIC tells me he is willing to do it, only 
that GLS didn't think this should be done.  Since MACSYMA has always 
loaded in the LISP dump on SYS;, I don't see why not.  Comments from 
GLS?

MOON@MIT-AI 05/03/78 22:39:15
To: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI
The file AI: LMDOC; LMFNS > contains the latest list of functions
and variables in the Lisp machine system, if anyone is interested.
(It is moby long.)  This should be useful for finding what exists
that isn't documented.

Date: 3 MAY 1978 1820-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: (STATUS SEGSIZE)
To: (BUG LISP) at MIT-MC, GLS at MIT-AI

I will put an inquiry as to the usefulness of SEGLOG/SEGSIZE in the
next LISP RECENT and then we can act on data.

Personnaly, I think SEGSIZE is more useful (for no particular reason
other then intuition....)

--Howard

Date: 3 MAY 1978 1811-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: PURCOPY of symbols
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    RLB@MIT-MC 05/03/78 11:04:10 Re: PURCOPY of symbols
    To: (BUG HIC) at MIT-MC
    Should set SY.OTC as well as SY.CCN
---------
Done.

Date: 3 MAY 1978 1611-EDT
From: MOON at MIT-MC (David A. Moon)
To: (BUG LISP) at MIT-MC

RLB@MIT-MC 05/03/78 11:04:10 Re: PURCOPY of symbols
To: (BUG HIC) at MIT-MC
Should set SY.OTC as well as SY.CCN


Date: 3 MAY 1978 1459-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 1 MAY 1978 1657-EST
    From: JONL at MIT-MC (Jon L White)
    To: (BUG LISP) at MIT-MC

    Please delete SYS;BBLISP 493QIO
    ASAP.
-------
Done.....(I guess I goofed a while back....)

Date: 3 MAY 1978 1340-EDT
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

I sure don't see any way an eof-handler for a number file can win!
How the hell can a function not compiled as a number function possibly
win? In particular, a simple (EOFFN F '(LAMBDA (Z) -1)) necessarily loses.

Date: 3 MAY 1978 0424-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

What is this ancient LISP, version 229EG, in SECOND:SYS;TS OOOLIS
for?  Can anyone really WANT such a frob?

Date: 3 MAY 1978 0028-EDT
From: EAK at MIT-MC (Earl A. Killian)
Subject: SORT
To: (BUG LISP) at MIT-MC

Is it still true that SORT can't sort number arrays?  This seems losing.
Also to be useful it seems to be that SORT should take an optional third
argument which is the exchange operator.  E.g. (SORT 'A '> (FUNCTION
(LAMBDA (X Y) (STORE (A X) (PROG2 0 (A Y) (STORE (A Y) (A X))))))) would
be equivalent to (SORT 'A '>).  This would allow you to sort two or three
arrays on the on the ordering of just one of the arrays.  Maybe you can
think of a better mechansim for this.

GLS@MIT-AI 05/02/78 22:48:49 Re: TTYFLS
To: moon at MIT-MC
CC: (BUG lisp) at MIT-MC
No, I haven't gotten around to installing TTYFLS yet in LISP.
This may require a slight change to (SSTATUS TTYINT), and maybe even
to the format of TTY input file objects.  The most general idea
would be that EVERY tty interrupt function may have some associated bits
-- this requires that twice the room be allocated in the file object
for holding data about interrupt character functions.  Possible
associated bits are:  the "must be/most no be control/meta" bits;
the "should be suppressed from main program level input stream"
bit; and the "should do a clear-input (TTYFLS up to the interrupt
character) at interrupt level" bit.  In this way user interrupt
characters such as ^^ can specify TTYFLS'ing as well.


Date: 2 MAY 1978 1701-EDT
From: CFFK at MIT-MC (Charles F. F. Karney)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

UREAD in NEWIO is not compatible with OLDIO nor with DDT/TECO etc.
when you ask it to read a nonexistent file e.g. with (UREAD FOO BAR
 DSK CFFK), it doesn't change the value of DEFAULTF.  DEFAULTF should
be set before the attempt to OPEN is made.  This would bring UREAD
in line with OLDIO and other ITS programs.  If the fix isn't
made to UREAD etc. I still think that MACSYMA's LOADFILE etc. should
be fixed.

Date: 2 MAY 1978 1642-EDT
From: MOON5 at MIT-MC (David A. Moon)
To: (BUG LISP) at MIT-MC

IS LISP'S INTERRUPT HANDLER USING THE TTYFLS .CALL?
IF IT ISN'T, EMBARRASSING THINGS WILL HAPPEN WHEN THE NEW
"RUBOUT SCHEME" IS PUT INTO I.T.S.  NOTE THIS SYSTEM CALL
WAS PUT IN EXPRESSLY FOR LISP'S BENEFIT.

IF THIS MESSAGE MAKES NO SENSE, CONTACT ME FOR MORE DETAILS.

Date: 2 MAY 1978 1409-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: FILEPOS
To: (BUG LISP) at MIT-MC

Bletchery of bletcherosities!
It sure looks like FILEPOS does a .CALL ACCESS each time, even though
the place being accessed-to is in Lisp's buffer!
(This applies particularly to fixnum block input)
Why not just adjust the pointer into the buffer??

GLS@MIT-AI 05/01/78 17:54:21 Re: (STATUS SEGSIZE)
To: (BUG lisp) at MIT-MC
There is a (STATUS SEGLOG), of course, so (^ 2 (STATUS SEGLOG))
will do the job (speed demons may prefer (LSH 1 (STATUS SEGLOG))).
(STATUS SEGSIZE) is more intuitive and more general, however.
Perhaps (STATUS SEGLOG) could be phased (fazed?) out - does anyone use it?


Date: 1 MAY 1978 1657-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Please delete SYS;BBLISP 493QIO
ASAP.

Date: 1 MAY 1978 1239-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Perhaps there should be a (STATUS SEGSIZE) and (STATUS MEMSIZE) ?

Date: 30 APR 1978 0711-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

ST. added and symbols redefined for looking at symbol table in ? mode.

Date: 30 APR 1978 0703-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC


    JPG@MIT-MC 04/18/78 20:22:14
    Do (PURCOPY '(X Y)) in a MACSYMA to get WRITE INTO READ-ONLY MEMORY.
    PURCOPY should be a no-op as it once was if purification cannot be done.
-------
In looking at this I find that it isn't PURCOPY that is dying, put the pure
consers.....this is related to other problems we are having with pure consers
attempting to cons into pure-space after purification has been done (they
attempt to write into newly purified pages!)....
This problem will be fixed along with the other purification problems when
we figure out the right thing to do.

--Howard

Date: 30 APR 1978 0639-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject:  Purification, *PURE=T with PURE=NIL, and other lossage
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

LOSSAGE!

A) With PURE=nil and *PURE=T, the UUO handler tries to clobber UUO's in pure
   code!!!!

B) If you purify after loading one file but before loading a second file, then
   pointers into freespace are left pointing into purified pages.

I think the whole mechanism needs some review and thus I am not going to
touch it until we get to talk more.  The purification mechanisms seem somewhat
ill-defined and this is what is causing these random screws.

--Howard

Date: 29 APR 1978 1206-EST
From: KGK at MIT-MC (Kleanthes G. Koniaris)
To: (BUG LISP) at MIT-MC

On the first time that one goes :

(grindef <program>)

the grinder loads itself up. Unfortunatly,
it sometimes forgets to give a promptor.
This can possibly leave people waiting
for a long time expecting the grinder
to output a "*".

Date: 28 APR 1978 2053-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    Date: 24 APR 1978 0956-EST
    From: RLB at MIT-MC (Richard L. Bryan)
    To: (BUG LISP) at MIT-MC

    Autoloading LAP barfs with 
    ;((LAPSETUP/| NIL NIL) (NIL . 1)) TOO MANY ARGUMENTS SUPPLIED - APPLY

    Note that LAPSETUP/| is also called with only 1 arg, too ...
    I can win by doing (args 'lapsetup/| '(1 . 2)) but what a crock!
---------
This has been fixed andwill come up in the next LISP.


FORBUS@MIT-AI 04/28/78 12:09:49
To: HIC at MIT-AI
	No, NVID is not used anymore-we (meaning vision hackers) have long 
since switched to our own software for the sake of reliability...
		Ken Forbus

   Date: 27 APR 1978 2234-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: GRIND
To: forbus at MIT-AI
CC: (BUG LISP) at MIT-MC

Nobody is really maintaining it right now.  Care to volunteer?

Date: 27 APR 1978 2233-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, FORBUS at MIT-AI


    FORBUS@MIT-AI 04/27/78 22:31:37
    To: (BUG LISP) at MIT-AI
    	Say, who is responsible for maintaining grind these days?
    	It does hidious things to comments, such as breaking them up
    off the line, and thus causing errors when the file is read in.  Also it
    seems to make many sub-optimal decisions about when to start going down
    the page as opposed to across, and in short seems to be a holdover from
    teletype and datapoint days...
    		Good luck
    		  Ken Forbus

--------
It is not obvious to me that anyone is!!  If you have specific bugs, someone
the LISP group is surely able to fix them; but, as for a general overhaul,
there is no talk of this coming.

FORBUS@MIT-AI 04/27/78 22:31:37
To: (BUG LISP) at MIT-AI
	Say, who is responsible for maintaining grind these days?
	It does hidious things to comments, such as breaking them up
off the line, and thus causing errors when the file is read in.  Also it
seems to make many sub-optimal decisions about when to start going down
the page as opposed to across, and in short seems to be a holdover from
teletype and datapoint days...
		Good luck
		  Ken Forbus


Date: 27 APR 1978 1410-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Here is a sequence that will lose for purcopy
LISP
ALLOC?N
*
(SETQ *PURE T)
T
(FASLOAD GETMID FASL COM)
xxxxx
(PAGEBPORG)
xxxxx
(PURIFY 0 0 'BPORG)
xxxxx
(UREAD NCOMPLR LAP DSK COMLAP)
<<<<lose, lose>>>

Date: 27 APR 1978 0843-EST
From: JLK at MIT-MC (John L. Kulp)
To: RWK at MIT-MC, JLK at MIT-MC, (BUG LISP) at MIT-MC

You evidently did not see the message immediately following that bug
report.  I agree it is really an ITS misfeature.

Date: 27 APR 1978 0555-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: JLK at MIT-MC, (BUG LISP) at MIT-MC


    Date: 25 APR 1978 1125-EST
    From: JLK at MIT-MC (John L. Kulp)
    To: (BUG LISP) at MIT-MC

    If I am compiling a file FOO and there exists a file called FOO FASL1
    the compiler acts very strangely, namely, it it types out a large number
    of CRLF's (this is with -T flag) and then exits, but does not write an
    output file.  If I do it with the T flag on, then it just says DOT CONTEXT
    ERROR.  If I rename the FOO FASL1 to FOO BAR, then the problem goes away
    and the file FOO > compiles successfully.

Foo, you are hacking me!  If you go to compile FOO >, you will be trying to
compile a fasl file, unless it's called FASL2, because FASL1 is what
:PRINT FOO > will get too!  Hardly a compiler bug.  Maybe an ITS bug.  I
haven't much of an opinion on that (rather, I have conflicting ones).

PRATT@MIT-AI 04/26/78 07:34:10
To: (BUG LISP) at MIT-AI
NCOMPLR still does not compile CGOL.  ONCOMP works fine on it.  The
problem seems to be related to having multiple defuns of the form
(DEFUN (FOO A) ...
(DEFUN (FOO B) ...
which CGOL makes extensive use of.


Date: 26 APR 1978 0406-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, DRB at MIT-MC

There is also READ-EVAL-*-PRINT which does obvious(?) thing...
is hook between toplevel eval and toplevel print.

Date: 26 APR 1978 0245-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

I added (at DRB's request) a hook between in TLEVAL (top-level EVAL) to
call a user function in READ-*-EVAL-PRINT if there is one (of course)...
he is going to use this to determine if the result of the eval'ed form
requires special printing and will set appropriate flags and things for
his program....seems like a generally useful feature, though (he might
also want to mung the user's input some!!)

--Howard

Date: 26 APR 1978 0122-EST
From: DRB at MIT-MC (David R. Barton)
To: (BUG LISP) at MIT-MC
CC: DRB at MIT-MC, BMT at MIT-MC, RZ at MIT-MC

This is not a bug but a question:  Can I easily re-define the read-eval-print
loop?  My problem is almost a standard one:  I want to use different printers
for different data-types.  The problem is that I can't just setq PRIN1 to
something, because I can't tell the data-type of a frob by looking at its
value.  [I can only find the data-type if I know the expression that was READ,
before the EVAL.]  Thanks for any advice.

Date: 25 APR 1978 2050-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    From: RLB at MIT-MC (Richard L. Bryan)
    
    ... Or is LISP;DEFNS > updated when a new Lisp is released for ITS?
-------
Yes.

Date: 25 APR 1978 1816-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

Is there any good reason why 
SYS:.FASL DEFS -> LISP;.FASL DEFS -> LISP;DEFNS >
should be different from L;DEFNS >  ?
If the philosophy is that stuff on LISP; is for transport, why not 
relink SYS:.FASL DEFS to L;DEFNS >  ?
Or is LISP;DEFNS > updated when a new Lisp is released for ITS?

Date: 25 APR 1978 1126-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

Oops, forget previous message.  Obviously
FOO FASL1 was FOO > (I was losing...)

Date: 25 APR 1978 1125-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

If I am compiling a file FOO and there exists a file called FOO FASL1
the compiler acts very strangely, namely, it it types out a large number
of CRLF's (this is with -T flag) and then exits, but does not write an
output file.  If I do it with the T flag on, then it just says DOT CONTEXT
ERROR.  If I rename the FOO FASL1 to FOO BAR, then the problem goes away
and the file FOO > compiles successfully.

Date: 25 APR 1978 0916-EST
From: JONL at MIT-MC (Jon L White)
Subject: Arguments to ALLOC function
To: (BUG LISP) at MIT-MC

Let all the arguments to ALLOC be expressible as floating-point numbers.
Thus one could say (ALLOC '(LIST (56.0E3 64.0E3 .2)))  rather than type
some fixnums with lots of trailing (meaningless) zeros.  Since these
quantites are rounded up to the neares multiple of a segment size,
there would be no difficulyt in first fixing the flonum, and then carrying
on.

Date: 25 APR 1978 0859-EST
From: GSB at MIT-MC (Glenn S. Burke)
Subject: Clarification
To: (BUG LISP) at MIT-MC
CC: MOON at MIT-MC, RWK at MIT-MC

1)  When i said 'image [binary]' i meant 36. bit bytes only;  ITS
conveniently calls that 'image', and lisp knowingly uses 'image' as a
tag for something else.
2)  What i was suggesting was a disjunction of the sizes of bytes that
lisp uses for inputting/outputting and user-accessing.  EG, lisp
could read off a device in 36. bit bytes, but give it to the user
in 7. bit bytes (and hack filepos accordingly).
The lisp internals look like they could hack this without too much
trouble;  in fact, they look like they could hack arbitrary byte sizes
now, if open would only take that option.

Date: 25 APR 1978 0826-EST
From: MOON at MIT-MC (David A. Moon)
Subject: siot/cla/cli/its/usr.....
To: GLS at MIT-MC, (BUG LISP) at MIT-MC, GSB at MIT-ML
CC: MOON at MIT-MC, rms at MIT-AI

For a real crock:  perhaps we should change the core-link device to use the standard
I/O routines, in which case as it happens Lisp's SIOT would use a BLT and would preserve
the low bit of the sixbit names.  This change would also make the system a little smaller
and simpler.  The only reason currently it cannot use the standard routines is because
of the "multiple eofs" feature of core-link.  I doubt that anything depends on this.
Flushing this would mean that if guy A opens CLI:FOO BAR, then closes, then guy B
opens CLI:FOO BAR, guy B would have to wait until FOO BAR had read out the first message,
whereas with multiple eofs he wouldn't have to wait if the messages were short enough.
However, with the code as it is now you get a file-locked error in these circumstances
anyway!  So I'm proposing that core link be changed to use a character-count instead
of EOF bits, and to use the standard (BLKT etc.) I/O routines.  I am not seriously
proposing this as a solution to the loss that Lisp will not let you do block-mode IOTs.

Date: 25 APR 1978 0816-EST
From: MOON at MIT-MC (David A. Moon)
Subject: siot/cla/cli/its/usr.....
To: GLS at MIT-MC, (BUG LISP) at MIT-MC, GSB at MIT-ML

Agreed that the way the CLA device gives you the names is a crock, that
isn't the only reason why a way to tell Lisp to read in block-mode (or
image, as you prefer) would be a win.  It also seems like a crock to
add a new system call for the sole purpose of getting around a misfeature
of Lisp.  Also, there is a problem, which is that the only place that
the names are remembered is in the buffer; the CLI'ing job may be long
gone by the time you open the CLA device.

Date: 24 APR 1978 1700-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: siot/cla/cli/its/usr.....
To: MOON at MIT-MC, (BUG LISP) at MIT-MC, GSB at MIT-ML


    From: MOON at MIT-MC (David A. Moon)
    	GSB@MIT-ML 04/24/78 03:00:22 Re: siot/cla/cli/its/usr.....
    	The best conceptual fix would be for lisp to have a filemode which said
    	'read this file in image [binary] mode but give me the contents in ascii
    	bytes'.  The utility of this for random devices is (i hope) obvious;
    	i don't know, but suspect that it might be meaningful on systems other
    	than ITS.
    I HEARTILY AGREE.
Barf.  There is a way to say IMAGE, but that has nothing to do with the
low bit getting dropped.  The problem is that the CLI/CLA convention is
a piece of shit, and there should be a system call which takes a CLA
channel and returns the names of the interrupter.

Date: 24 APR 1978 1655-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: BB$X
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC


    BB$X fails to be delayed properly if it is done at a time when
    the interrupts are shut off.  apparently, it totally forgets about
    the request (by doing a POPJ P,  near FCN.B)  if the INHIBIT switch
    is on.  I surely need a thing to do that forces a ^B break loop
    the next time possible (e.g., when UNLOCKI is done)

A long time ago, in a hackery far, far away... this was deemed a feature
so that the BB interrupts wouldn't stack up uselessly.  Maybe we should
have a BBBX that allows it to stack up.

Date: 24 APR 1978 1542-EST
From: JONL at MIT-MC (Jon L White)
Subject: My Lossage
To: (BUG LISP) at MIT-MC

Forget the BUG-LISP note about CALLF for FUNARGs.  

Date: 24 APR 1978 1533-EST
From: JONL at MIT-MC (Jon L White)
Subject: UUO trap to a FUNARG
To: (BUG LISP) at MIT-MC

(CALLF 4 @ 0 P)
Fails miserably, where a FUNARG is on the top of the stack.
first off, it clobbers all the ac's into '**MISSING-ARG**, and
pushes some random cruft on top of the stack to boot.
double foo!  I NEED THIS TO WORK FOR THE NEXT NCOMPLR!!

Date: 24 APR 1978 1507-EST
From: JONL at MIT-MC (Jon L White)
Subject: BB$X
To: (BUG LISP) at MIT-MC

BB$X fails to be delayed properly if it is done at a time when
the interrupts are shut off.  apparently, it totally forgets about
the request (by doing a POPJ P,  near FCN.B)  if the INHIBIT switch
is on.  I surely need a thing to do that forces a ^B break loop
the next time possible (e.g., when UNLOCKI is done)

Date: 24 APR 1978 1022-EST
From: MOON at MIT-MC (David A. Moon)
Subject: siot/cla/cli/its/usr.....
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


	GSB@MIT-ML 04/24/78 03:00:22 Re: siot/cla/cli/its/usr.....
	To: (BUG LISP) at MIT-ML
	CC: RWK at MIT-ML, MOON at MIT-ML
	The best conceptual fix would be for lisp to have a filemode which said
	'read this file in image [binary] mode but give me the contents in ascii
	bytes'.  The utility of this for random devices is (i hope) obvious;
	i don't know, but suspect that it might be meaningful on systems other
	than ITS.
I HEARTILY AGREE.

Date: 24 APR 1978 0956-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

Autoloading LAP barfs with 
;((LAPSETUP/| NIL NIL) (NIL . 1)) TOO MANY ARGUMENTS SUPPLIED - APPLY

Note that LAPSETUP/| is also called with only 1 arg, too ...
I can win by doing (args 'lapsetup/| '(1 . 2)) but what a crock!

GSB@MIT-ML 04/24/78 03:12:08 Re: siot on cla
To: (BUG ITS) at MIT-ML
CC: (BUG LISP) at MIT-ML
Why not have the CLA device give one the names of the sender as the
truename iff it was opened in unit ascii input?  Or barring that because
of complexity, a CLUTZ device?  It is a real loss that you lose that bit
in the names if you use siot, especially since the cli device supports 
exact character counts.


GSB@MIT-ML 04/24/78 03:00:22 Re: siot/cla/cli/its/usr.....
To: (BUG LISP) at MIT-ML
CC: RWK at MIT-ML, MOON at MIT-ML
The best conceptual fix would be for lisp to have a filemode which said
'read this file in image [binary] mode but give me the contents in ascii
bytes'.  The utility of this for random devices is (i hope) obvious;
i don't know, but suspect that it might be meaningful on systems other
than ITS.


Date: 24 APR 1978 0254-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: SIOT/CLI/CLA/ETC
To: (BUG ITS) at MIT-MC, (BUG LISP) at MIT-MC, GSB at MIT-MC

Even better (not to exclude SIOT getting the low bit!) would be to
have ITS support changing the mode of a channel while open!
(direction would be nice too!)

GLS@MIT-AI 04/24/78 02:09:09 Re: CLA Device
To: (BUG lisp) at MIT-MC
CC: (BUG ITS) at MIT-AI, gsb at MIT-ML
Grumble!  Properly aligned SIOTs don't get the low bit of the sixbit
cruft at the head of a CLI file.  That feature always was obviously
a piece of shit.  I suggest either [a] ITS should provide a better
feature for people who SIOT on CLA devices, or [b] we just flush the
feature from LISP (snicker).


GSB@MIT-ML 04/24/78 01:27:54 Re: CLA device and Truename
To: GSB at MIT-ML, (BUG LISP) at MIT-ML, GLS at MIT-MC
How can the CLA hack possibly work for ascii input?  Lisp uses SIOT,
so at best it would be losing the low order bit out of the names.
How about a BLOCK-MODE-IOT open option?  (snicker)


GLS@MIT-MC 04/23/78 02:00:57
To: GSB at MIT-ML, (BUG LISP) at MIT-ML

    GSB@MIT-ML 04/20/78 21:10:06
    To: (BUG LISP) at MIT-ML
    TTYINT for ^Z goes and does a reset blindly on the channel of the original
    tty input file array.  What if someone has re-setqed TYI and TYO, and
    the channel has been re-allocated to something else?


Right - this is a known screw.  The whole issue of when resets get done
in LISP needs recoding.  (At CN.Z, and also at CHECKI ff.  There really
ought to be a way for the user to say whether an interrupt character
should reset input on that TTY, so the new features of WHYINT/.ITYIC
or whatever can be exploited.)



GLS@MIT-MC 04/23/78 01:59:06 Re: truename
To: GSB at MIT-ML, (BUG LISP) at MIT-ML
I don't underrstand the remark about not being able to use CLA
device for ASCII input -- that was the whole reason for the TRUENAME
hack in the first place: because the first two words were the only
non-ASCII data in the stream.
Maybe it is broken now, but I have certainly succeeded before in
passing ASCII data through a CLI-CLA pipe between two LISP jobs.



GLS@MIT-MC 04/23/78 01:46:00
To: GSB at MIT-ML, (BUG LISP) at MIT-ML

    GSB@MIT-ML 04/22/78 08:20:43
    To: (BUG LISP) at MIT-ML
    (gctwa t)
    (setsyntax '/ 'macro 'this-function-is-undefined-as-yet)
    .....
    (gc)
    ....
    (status macro /)
      ==> (<null string or randomness> NIL)
    ???????????  What gives?  ???????????


I thhink that macro functions may not really be properly protected.
Temporary fix: make sure the function is defined before giving its
atomic symbol name to SETSYNTAX.



Date: 23 APR 1978 0017-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: NIL at MIT-MC
CC: (BUG LISP) at MIT-MC

Talked with HIC about certain features it would be nice to have and he said
that I should forward them to NIL since LISP may never get them...

1] Some function to tell what type args a system function (or user function?)
   will take -- e.g., (ARG-TYPE? 'FOO) would return (FIX FLOAT ...) or 
   (FIX-ARGS? 'FOO) would return T or something like that -- just so the 
   info was available somehow.

2] Some function to tell whether a program had an expr or fexpr definition.
   Since it is not clear that FEXPR's, SUBR's etc. will always be on the
   property list of the atom, it would be nice from the standpoint of one
   using SUBRCALL (free functional variables no longer working) could tell
   what he was likely to get ahold of by knowing what functional types were
   available.

If these are unclear I can elaborate. Thanx for your attention.
KMP

EJG@MIT-ML 04/22/78 19:31:33
To: (BUG LISP) at MIT-ML
While terseness is to be valued, I feel that the error msg.
wna - setq
may be a bit too short to be easily understood.


GLS@MIT-AI 04/22/78 17:22:01 Re: Read flushing spaces.
To: RMS at MIT-AI, (BUG LISPM) at MIT-AI
CC: GLS at MIT-AI, (BUG LISP) at MIT-AI, NIL at MIT-MC
RMS is correct that I advocate changing MacLISP when it becomes feasible
to correct this screw.  Also, having two separate functions READ and
READ-SUBEXPRESSION is similar to the way MacLISP treats (READ) as
READ-SUBEXPRESSION, but (READ ...) as READ.  I'm not sure READ-SUBEXPRESSION
is quite the right name for it, but I can't think of a better.

Howevere, here is a problem I just thought of:  consider reading in
the expression "'FOO " (the "" are metasyntactic).  If ' uses
READ-SUBEXPRESSION, then the space following FOO doesn't get gobbled;
but then it is left around as a result of the top-level read,
even though it was needed to terminate the top-level expression.
A hairier theory is needed to win completely.


Date: 22 APR 1978 1717-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RLB at MIT-MC, (BUG LISP) at MIT-MC


    Date: 21 APR 1978 1805-EST
    From: RLB at MIT-MC (Richard L. Bryan)
    To: (BUG LISP) at MIT-MC

    I really need to be doing RPLACAs on symbols. I do know what I'm doing and
    why. I claim that RPLACA should check CAR and not barf if CAR doesn't.
    Also the similar case for RPLACD/CDR.
--------
I can understand our need for RPLACAing a symbol, but wouldn't it be more
consistent to have a SETSY2 (or whatever) function analagous
to SETPLIST?

Date: 22 APR 1978 1713-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


    GSB@MIT-ML 04/22/78 08:20:43
    To: (BUG LISP) at MIT-ML
    (gctwa t)
    (setsyntax '/ 'macro 'this-function-is-undefined-as-yet)
    .....
    (gc)
    ....
    (status macro /)
      ==> (<null string or randomness> NIL)
--------
Since SETSYNTAX does not proctect the function atom in any way, it goes away
when doing a GCTWA.  Is there any easy way to fix this??

Date: 22 APR 1978 0826-EST
From: ECC at MIT-MC (Eugene C. Ciccarelli)
Subject: STEP
To: (BUG LISP) at MIT-MC

    Just trying the STEP package for the first time, and it's really
great.  How about having ^L clear the screen and redisplay the last
line printed?

GSB@MIT-ML 04/22/78 08:20:43
To: (BUG LISP) at MIT-ML
(gctwa t)
(setsyntax '/ 'macro 'this-function-is-undefined-as-yet)
.....
(gc)
....
(status macro /)
  ==> (<null string or randomness> NIL)
???????????  What gives?  ???????????


GSB@MIT-ML 04/22/78 05:11:24
To: (BUG LISP) at MIT-ML
I've got a problem; in doing file searching, i call OPEN while binding
IO-LOSSAGE to some function.  The idea is to find out the reason for
the open failing, and this appears to be the only way to do so.  However,
if this stuff gets called from inside an errset, (eg a break loop),
then my io-lossage handler doesn't get called, so the outward appearance
is that random open errors are happening.  I don't want to bind ERRSET,
since that could cause confusion if some asynchonous event happened
while it was bound.  Also, i would rather only have to have the OPEN
call happen once (rather than doing a probef or equivalent, followed
by the OPEN, in the case that the open was a slow one, say over the net.)
Any suggestions?  If all else fails, i guess i will end up binding errset,
but it would be nice to be able to do this as cleanly as possible
(which also implies it would be nice not to even have to bind IO-LOSSAGE).


Date: 21 APR 1978 1805-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

I really need to be doing RPLACAs on symbols. I do know what I'm doing and
why. I claim that RPLACA should check CAR and not barf if CAR doesn't.
Also the similar case for RPLACD/CDR.

Date: 21 APR 1978 0712-EST
From: JONL at MIT-MC (Jon L White)
Subject: primitive DISPLACE macro
To: rms at MIT-AI
CC: (BUG LISP) at MIT-MC

Yea, super-good idea.  We've had DISPLACEment for 10 years, and
there is no reason not to provide it as part of the supplied system.
I'm about to release a new NCOMPLR that will also have the CASEQ
expander macro in it, so I'll put in DISPLACE too.

RMS@MIT-AI 04/21/78 05:00:30
To: (BUG LISP) at MIT-AI
The compiler should define (DEFUN DISPLACE (OLD NEW) NEW)
for the sake of user macros.  Of course, the user will be able to
redefine it if he cares to.  But while people may prefer various
forms of DISPLACE for interpreted use in their execution environments,
during compilation the precise form of displace hardly matters,
so people should not be forced to supply their own ones.

This is relevant because of ITER, which uses DISPLACE but can't
supply one since that would clobber the user's own displace in
an execution environment.  But this means that the user of ITER must
make sure himself that there is a DISPLACE present in the compiler
when he compiles anything that uses ITER.

If the compiler had its own displace, a user could win just by
putting his favorite displace in his .lisp. (init).  Then
during execution he would have his own style of displace,
whereas during compilation he would have the compiler's appropriate one.
As it is now, he must not only have a displace in his lisp init
for execution time, but a (declare (defun displace (old new) new))
in the front of every file for compile time.


GSB@MIT-ML 04/21/78 00:55:24
To: (BUG LISP) at MIT-ML
How is %IOL  defined to return?  It appears to do a popj or something
itself.  Is this what it's supposed to do?  (eg %IOL EMS3X never returns
to ddt if a (return '(t)) is done.)


GSB@MIT-ML 04/20/78 21:10:06
To: (BUG LISP) at MIT-ML
TTYINT for ^Z goes and does a reset blindly on the channel of the original
tty input file array.  What if someone has re-setqed TYI and TYO, and
the channel has been re-allocated to something else?


GSB@MIT-ML 04/20/78 17:56:37 Re: truename
To: (BUG LISP) at MIT-ML
WHat i meant was, is that a real feature of lisp?  It wasn't always so;
in fact, i used to argue that when one asked for the truename of a file,
it should read those things in again.  (I still think so.)
I can make similar (tho not nearly as good) analogies;  eg, (status tty)
could return the slots in the file array that contain those parameters.
Obviously, that is a cretinous thing to do.  EG, i can rename a file
(from ddt) that lisp has open;  then, TRUENAME is wrong. Admittedly, 
it is nice to be able to ask what the 'truename attribute' of a file
array is, but it is also nice to be correct. Also, i have never really
found the feature of truename hackery on the cla device useful, since
i can't use it for ascii input.


HIC@MIT-MC 04/20/78 17:38:36
To: GSB at MIT-ML, (BUG LISP) at MIT-ML

    GSB@MIT-ML 04/20/78 14:41:22
    To: (BUG LISP) at MIT-ML
    Is TRUENAME guaranteed to always work on a closed file?
--------
Yes, TRUENAME gets its info directly from the file-object.  It does not
do any I/O or .CALL's



GSB@MIT-ML 04/20/78 14:41:22
To: (BUG LISP) at MIT-ML
Is TRUENAME guaranteed to always work on a closed file?


GSB@MIT-ML 04/20/78 14:41:22
To: (BUG LISP) at MIT-ML
Is TRUENAME guaranteed to always work on a closed file?


GLS@MIT-AI 04/20/78 00:16:44 Re: (SYSCALL 0 'RENMWO ...) vs. RENAMEF
To: rwk at MIT-MC
CC: (BUG lisp) at MIT-MC
If RENAMEF were incompatible, then either way of doing it
would be incompatible.  At least a SYSCALL makes it clear that
you're doing something that no other system will win on.
I don't like it either, but it is far easier to decree that RENAMEF
will close the file on ITS (and in 99% of all situations the user
is about too close it anyway), than to really hair it up on
TOPS-10 and TOPS-20.


Date: 20 APR 1978 0008-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RWK at MIT-MC, (BUG LISP) at MIT-MC

Foobar, this is sort of a moot point -- I suspect that changing it now would
cause more havoc then it would cure.  Perhaps it is losing, yes, but
GLS made the decision, and I'll leave it up to him to justify it furthur.

As far as thinking that (OPEN (RENAMEF ..)) wins, I realize that it doesn't,
but I was giving a simple example rather then spending my time writing
code (I sent this in a personal communiction to RWK).

Enough said!

Date: 19 APR 1978 2355-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: HIC at MIT-MC, (BUG LISP) at MIT-MC

HIC seems to believe that  (OPEN (RENAMEF ...)) is the same
as (RENAMEF ...) that does not close.  This is clearly false, in at least
two ways.

An open file is a sort of string, preventing randomness from causing
file to go away or be modified.

An output file cannot be re-opened in winning way.  A real equivalent,
modulo the previous objection is more like:
(bind ((pos (filepos foo)))
      (open (renamef foo ...) '(append))
      (filepos foo pos))

Date: 19 APR 1978 2349-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: HIC at MIT-MC, RWK at MIT-MC, (BUG LISP) at MIT-MC

Barf.  I have no desire to be compatible with SAIL.  I don't think that
a system like LISP should hide winning features of the operating system,
unless the user desires it for compatibility.  What is wrong with
allowing the user to win if he is on ITS?  It doesn't make programs
that are written in the matter you want to ENFORCE not work!  One can
always write fully compatible programs by doing (CLOSE (RENAMEF ...))

Or, alternatively, one could have (SSTATUS RENAMEF NIL)
Or the other compatibility hack, already in use for a lot of other
operating-system dependent stuff, by
(COND ((STATUS FEATURE ITS) ...)

It's cretinous to have to do
(SYSCAL 0 'RENMWO foo-file #FOO #BAR)
Talk about operating-system dependence!

GLS@MIT-AI 04/19/78 21:45:12 Re: Space after reading an atom
To: (BUG LISPM) at MIT-AI
CC: (BUG lisp) at MIT-MC, NIL at MIT-MC
The theory behind the space not going away is that a recursive
read by a macro character e.g. should not
lose information.  The current "fix" in the top level is a crock.
Is can't even really be fixed at the read level, because not all
ways of reading the same atom require a terminating space.
() = NIL<sp> is one example, but another is |FOO| = FOO<sp>.
It really has to be fixed at the token-parsing level.  I think
the best idea is that a "top-level" read reading a "top-level" atom
should swallow any space needed to terminate the atom, but recursive
reads should not.  Currently, in MacLISP, a recursive read is one with
no arguments, and a top-level read is one with arguments (in NEWIO).
I don't know if this is the best way to do this.


Date: 19 APR 1978 1939-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: MACLISP FOR TENEX AND TOPS-20
To: Boyer at SRI-KL
CC: (BUG LISP) at MIT-MC, MMCM at SRI-KL

You raise some issues which I have been thinking about for a little while.

A) On SRI-KL a current version of Tops-10 MacLISP NEWIO can be gotten from:
	<MACLISP>NEWMACLSP.EXE

B) As far as ability for Tops-10 MacLISP to use full address space on
   Tops-10 VM, there has been talk of trying to bring up such a version 
   in an attempt to get MACSYMA up on a Tops-10.  If we manage to get this
   to win, then hopefully it will also work on -20's under PA1050 (not clearly
   true, though!)

C) Perhaps the best possibility is this one.  As soon as the Tops-20 that now
   exists at our site is fully operational, the LISP group (probably mainly
   myself) will be finishing up and testing the Tops-20 implimentation of
   MacLISP (there is much code written by Guy Steele to support the -20,
   but none has been tested).  I hope to have a fairly operational native -20
   version up by the end of the summer (schedule may change depending upon
   the availability of our 2050).  SRI-KL will be perhaps the first non-local
   site to be running this software when it arrives.

I am responsible for the Tops-10 version of NEWIO (the one that is running at
SRI-KL).  I would be happy to talk to you furthur on any of these issues.
I am HIC@MIT-MC.  If you do decide to try the MacLISP on SRI-KL, please inform
me of bugs and I will fix them as soon as possible.  The local person to
contact is probably Mike McMahon (MMCM@SRI-KL) who has helped me in a number
of ways and seems to be the most knowledgable person about MacLISP at SRI.
I have CC'ed a copy of this message to him.

Sincerely,
Howard Cannnon [HIC@MIT-MC]

GLS@MIT-AI 04/19/78 18:22:35 Re: ARGS and lsubrs
To: gsb at MIT-ML
CC: (BUG lisp) at MIT-MC
Of course!  It's a coomplete crock.


Date: 19 APR 1978 1816-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: MACLISP FOR TENEX AND TOPS-20
To: Boyer at SRI-KL
CC: GLS at MIT-AI, (BUG LISP) at MIT-AI


    Date: 19 Apr 1978 1446-PST
    From: Boyer at SRI-KL (Bob Boyer)
    Subject: MACLISP FOR TENEX AND TOPS-20
    To:   GLS at MIT-AI

    Is there any news since say four months ago on 
    improving the DEC-10 version of MACLISP
    so that it can use the full core image on
    TOPS-20 and TENEX.

    As a separate matter, do you know of any plans
    to rewrite MACLISP to take advantage of the new
    DEC extended hardware for 10's that permits
    addresses greater than 18 bits?
    -------

Regarding the TOPS-20 version, perhaps HIC@MIT-MC (Howard Cannon,
to whom I am forwarding this note) can answer better than I.
As far as use of PDP-10 extended addressing, we hhave no plans at
all at present to exploit that.  We are currently undertaking
a "new implementation of LISP" to be brought up on very-large-address
machines, such as the DEC VAX/11 and the Stanford S-1.  I suppose it
might be possible to bring up a version of this eventually on
an extended-address PDP-10, but we have given it no thought, as far
as I know.


Date: 19 APR 1978 1311-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-MC, DLW at MIT-MC

Due to the size of LISP;BUG MAIL, it has been renamed to LISP;BUG 1 and
a new BUG MAIL file has been started.  I would like a mailing list in order
to send messages such as this to people who should see them.  As it stands, I
try to guess at who the interested parties are.  Does one exist?  If not, one
should be set up.

--Howard