Date: 13 APR 1980 0251-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: SETF/POP bugs
To: (BUG LISP) at MIT-MC

The bug with ARRAYCALL and the bug with some cases of POP have been fixed.

Date: 13 APR 1980 0134-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: RIVEST's LOAD query
To: (BUG LISP) at MIT-MC

I have replied to him saying I thought his idea of having most recent file
load in Lisp is unworkable. Anyone interested in the reply, which is like
30 lines and probably uninteresting to most of you, can read 
KMP;[MC]AR1:LOAD REPLY
-kmp

Date: 12 APR 1980 2330-EST
From: JONL at MIT-MC (Jon L White)
To: NIL-I at MIT-MC
CC: (BUG LISP) at MIT-MC, EJS at MIT-MC

I've added a "NAMESTRING" method for strings in the new
super-winning maclisp string package, so that on the next
reassembly of lisp, we can have the I/O routines send
a NAMESTRING message to a random extended datum, and hopefully
come back with a symbol, which would be treated just as if
the symbol were directly handed in.  E.g.,
   (LOAD "rjf;some file")  ===  (LOAD '|rjf;some file|)

RIVEST@MIT-ML 04/12/80 21:56:00
To: (BUG LISP) at MIT-ML
The LOAD function currently decides between a LISP source file and a
corresponding FASL file by selecting the FASL file.  
	I would prefer that it always picked the MOST RECENT file,
even if is a source file.  This seems to be what anyone would want...
	Ron Rivest


Date: 12 April 1980 21:33-EST
From: Alan Bawden <ALAN at MIT-MC>
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC

    Date: 12 APR 1980 2124-EST
    From: JONL at MIT-MC (Jon L White)
    Have you forgotten how DO is generalized?  with the old-style available,
    a non-atomic first arg is *not* generalized the way you just did for
    DOTIMES.

No I have not forgotten anything.  I am not defending old-style
DO as an example of elegant syntax.  But here it is and we are stuck
with it (I confess to even using it sometimes).  This is not a reason
to implement other NEW such crocks.

Date: 12 APR 1980 2124-EST
From: JONL at MIT-MC (Jon L White)
Subject: Inconsistencies imposing constraints
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date: 12 April 1980 21:11-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Subject: Inconsistency in various DOs
	Date: 12 APR 1980 1819-EST
	From: JONL at MIT-MC (Jon L White)
	.  .  .     The "gain" for flushing
	old-style DO is to free up the constraints on other DOers imposed
	by the syntax which treats an atomic first "argument" as an abbreviated
	variable specification, rather than a "name" for the DO.  
    I don't see how this follows.  Given that other DOers such as DOTIMES
    are written as macros, they are free to expand into anything they
    want, their syntax is entirely up to the macro-writer.
I don't think I wrote that note in such a way to give the impression
that the constraint was due inability to code up the functionality;
rather the problem is popular attitudes as to what are consistent 
extensions, and abbreviations, for DO.  In fact, your "narrow" viewpoint
towards DOTIMES, expressed in just this very note, is such an example.
    Secondly, you are incorrect in stating that the named mumble argument
    was the only "practical point" mentioned.  (Perhaps we differ on the
    definition of "practical".)  The best argument to my mind was the
    complete lack of generality of your suggestion.  To remind you:
      (DOTIMES X ...)		;Does the thing X times BUT
      (DOTIMES (1+ X) ...)		;Doesn't do the thing X+1 times
    I think that (DOTIMES <atom> ...) should be an ERROR! (How novel!)  I
    also think that (PROG <atom> ...) should be an error, but I am too
    late for that one!  
Have you forgotten how DO is generalized?  with the old-style available,
a non-atomic first arg is *not* generalized the way you just did for
DOTIMES.

Date: 12 April 1980 21:11-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: Inconsistency in various DOs
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC

    Date: 12 APR 1980 1819-EST
    From: JONL at MIT-MC (Jon L White)

    ...

    Either you missed the first part of these communications, about syntax
    of DO and DOTIMES, or you're simply confused.  The "gain" for flushing
    old-style DO is to free up the constraints on other DOers imposed
    by the syntax which treats an atomic first "argument" as an abbreviated
    variable specification, rather than a "name" for the DO.  

I don't see how this follows.  Given that other DOers such as DOTIMES
are written as macros, they are free to expand into anything they
want, their syntax is entirely up to the macro-writer.  They can
become DO-NAMEDs or PROGs or anything you want, not just DOs. (I guess
that the name DO does imply that you can RETURN from them.) So it is
not necessary to flush old-style DO to free up anyone's constraints.
							      
							      That is,
    DOTIMES and other yet-to-be-invented DOers are constrained by popular
    opinion to interpret an atomic first arg as a "name", rather than leaving 
    that for some other operation like DOTIMES-NAMED -- that was the only 
    practical point mentioned in all the mail to my inquiry about the syntax
    (DOTIMES <symbol> ...).

First off, I don't sense the popular opinion that you speak of,
specially since the ONLY special form that has this syntax currently
is PROG!

Secondly, you are incorrect in stating that the named mumble argument
was the only "practical point" mentioned.  (Perhaps we differ on the
definition of "practical".)  The best argument to my mind was the
complete lack of generality of your suggestion.  To remind you:

  (DOTIMES X ...)		;Does the thing X times BUT

  (DOTIMES (1+ X) ...)		;Doesn't do the thing X+1 times


I think that (DOTIMES <atom> ...) should be an ERROR! (How novel!)  I
also think that (PROG <atom> ...) should be an error, but I am too
late for that one!  Why do we think that we are obliged to define
a meaning for every special case there is?

WOW!!! what an amazing amount of mail!!  For the record I vote for
DLW's suggestion of a lexical CATCH.  (Now we can flame about what to
call it!)

Date: 12 April 1980 21:08-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: *CATCH vs named PROG
To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC

For the record, I did not forget about *CATCH; I was just being
sarcastic, for which I apologize.  Yes, RWK is right, it is dynamic and
not lexical.  So let us actually introduce a new form that IS lexical,
and use IT everywhere.  The compilers would be quite capable of
producing the same code for a DO surrounded by a lexical CATCH as they
do now for DO-NAMED.  I'm not kidding; I think this is the right
solution to the problem.


Date: 12 APR 1980 2054-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: What should we DO?
To: (BUG LISP) at MIT-MC, NIL at MIT-MC, (BUG LISPM) at MIT-MC
CC: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, RMS at MIT-MC
CC: MOON at MIT-MC

RMS - doing (PROG name () (DO ...)) seems rather inelegant --
 an idiom for achieving something conceptually different than what
 you were really asking for. Take for example:

   (PROG name
	 (DO
	  ... code that extends off page ...))

 you'd be forced to scan to the next page to see that name was referring
 really to the DO. This sort of reasoning is why we most of us use let rather
 than LAMBDA. So I certainly wouldn't advocate that DO-NAMED was redundant.

Moon - Clearly we aren't advocating making everything named -- just the
 constructs that do flow of control-hacking -- for such constructs need
 information about where to GO/RETURN to. Probably we need a DOTIMES that
 allows the capability and another flavor that doesn't -- ie, that becomes
 an invisible prog.

My personal feelings on this are that we should come up with consistent
rules about these things. Documentation is much simpler if you could
generalize in it. So I would prefer flushing old-DO in the longrun but
it's probably unworkable at present. There's no reason to leave ourselves
open to future problems of this sort by implementing something now without
thinking first -- which is why I advocated not allowing (DOTIMES n ...).
I was not advocating that (DOTIMES lab ...) be installed -- just allowing
for that contingency.

I now present my feelings on this issue of how DO/PROG could be done in order
this haggling, part of which I think comes out of the fact that these return
tags are tied up in PROG-ness and so on ... Suppose you had the following
primitives in Lisp:

(PROG-BODY ...) which evaluated all non-atomic stuff. Atoms were GO-tags.
 Returns () if you fall off the end. RETURN does not work from this form.

(PROG-RETURN-POINT form name) name is not evaluated. Form is evaluated and
 if a RETURN-FROM specifying name (or just a RETURN) were executed, control
 would pass to here. Returns the value of form if form returns normally or
 the value returned from it if a RETURN or RETURN-FROM is executed. [Note:
 this is not a [*]CATCH because it is lexical in nature and optimized out
 by the compiler. Also, a distinction between NAMED-PROG-RETURN-POINT
 and UNNAMED-PROG-RETURN-POINT might be desirable -- extrapolate for yourself
 how this would change things -- I'll just present the basic idea here.]

(ITERATE bindings test form1 form2 ...) like DO is now but doesn't allow
 return or goto. All forms are evaluated. GO does not work to get to any form
 in the iteration body.

So then we could just say that the definitions for PROG and DO might be
(ignore for now old-DO's -- they could, of course, be worked in if people
really wanted them but they have nothing to do with this argument) ...

 (PROG [ <tag> ] <bvl> . <body>)

  => (PROG-RETURN-POINT (LET <bvl> (PROG-BODY . <body>)) [ <tag> ])

 (DO [ <tag> ] <bind-specs> <tests> . <body>)

  => (PROG-RETURN-POINT (ITERATE <bind-specs> <tests> (PROG-BODY . <body>))
			[ <tag> ])

Other interesting combinations could be formed by those interested in them.
If these lower-level primitives were made available to the user, he needn't
feel tied to one of PROG/DO -- he can assemble an operator with the 
functionality he really wants. 

-kmp

ps - apologies for multiple copies ... i wish i knew how to make that
	not happen ...

Date: 12 APR 1980 2051-EST
From: JONL at MIT-MC (Jon L White)
Subject: "*CATCH"?
To: RWK at MIT-MC, DLW at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

I presumed that Dan just forgot about the existence of
*CATCH in it current definition, and was trying to propose something
new.  RMS seems to have noticed this same possibililty, by suggesting
that named progs could supplant the need for anything else named.
E.g.,  (DO-NAMED GORILLA ...) ==> (PROG GORILLA () (DO ...))

Date: 12 April 1980 20:47-EST
From: Robert W. Kerns <RWK at MIT-MC>
Sender: ___126 at MIT-MC
Subject: *CATCH vs named PROG
To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, DLW at MIT-MC

*CATCH is not the same.  For one thing, it's dynamicly scoped, not
lexical.  This is not the semantics we're looking for.  Why not flush
RETURN and always use *CATCH/*THROW instead?  This means it must
compile to something a couple orders of magnitude slower than the
pop/jump sequence of a named prog and return.  *THROWs outside the
context where they should be allowed would find the *CATCH above them,
unlike the construct we're looking for.

Date: 12 April 1980 20:43-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: DO-NAMED
To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

I have a new proposal.  In the schemes being discussed, PROG, DO,
DOTIMES and DOLIST must each exist in two forms, either with different
function names (DO versus DO-NAMED) or different syntaxes (DOTIMES
followed by a symbol versys followed by a list).  JONL correctly points
out that there may be more such special forms in the future, each of
which would have to have two versions for the same reason.

Rather than duplicating this functionality in all these forms, why
not "subroutinize out" the functionality into a new special form,
which could be called "*CATCH"; you could have merely one version
of each special form, and then put a *CATCH around it if you need
a named escape expression.  This will keep the definition of the
language simpler (by keeping down the number of special forms
or different syntaxes of special forms), and will automatically
work for any new special forms that are invented in the future without
putting constraints on their syntax.


Date: 12 APR 1980 1833-EST
From: JONL at MIT-MC (Jon L White)
Subject: Named constructs
To: MOON at MIT-MC
CC: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, (BUG LISPM) at MIT-MC
CC: (BUG LISP) at MIT-MC

Uh, don't these things only apply to prog-like constructs? things
with GOs and RETURNs or loops in them?

Date: 12 April 1980 18:35-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject: DO-NAMED
To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

There is probably no need for DO-NAMED at all.
Putting a named PROG around the DO ought to do just as well.


Date: 12 APR 1980 1831-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Inconsistency in various DOs
To: JONL at MIT-MC
CC: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG LISPM) at MIT-MC

If you're going to promote named DOTIMES's, you might as well promote
named CONS, named PLUS, named ADD1, etc.

Date: 12 APR 1980 1819-EST
From: JONL at MIT-MC (Jon L White)
Subject: Inconsistency in various DOs
To: MOON at MIT-MC
CC: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG LISPM) at MIT-MC

    Date: 10 April 1980 05:17-EST
    From: David A. Moon <MOON at MIT-MC>
    Subject: Flushing old-style do
    DO (old as well as new style) is very heavily used,  and there is nothing
    to be gained by flushing the old style other than an extremely minor
    simplification of documentation.  
Either you missed the first part of these communications, about syntax
of DO and DOTIMES, or you're simply confused.  The "gain" for flushing
old-style DO is to free up the constraints on other DOers imposed
by the syntax which treats an atomic first "argument" as an abbreviated
variable specification, rather than a "name" for the DO.  That is,
DOTIMES and other yet-to-be-invented DOers are constrained by popular
opinion to interpret an atomic first arg as a "name", rather than leaving 
that for some other operation like DOTIMES-NAMED -- that was the only 
practical point mentioned in all the mail to my inquiry about the syntax
(DOTIMES <symbol> ...).
   As it happens, the LISPM blew it by not flushing old-style DO's
in the very beginning.  Since all maclisp code had to be mildly "massaged"
to get it onto LISPM, there would have been no difficulty mechanically
rewriting the old DO into the new (actually, much maclisp code needed
a ***great*** deal more massaging than just a mechanical inspection);
at runtime, a "maclisp-support" flag would permit obslete constructs
to be used.  As it also happens on LISPM, neither is there a DOTIMES-NAMED, 
nor is the syntax (DOTIMES <symbol> ...) permissible for a named DOTIMES.
Of course, this inconsistency in the current situation is preferable
to the temporary perturbation that would result from trying to flush
old-style DOs, but it's a shame to perpetuate further inconsistencies
because of a failure to see the issues clearly.
   Speaking of issues, how important a loss is it that there has to
be a DO-NAMED?  How big a loss would it be to programmers if they
had to type PROG-NAMED rather than PROG?  Admittedly these "named"
constructs are crucial to interpreters and compilers, but I'd be
curious hear what proportion of DO/PROG usages by J. Random Loser
actually use the "named" feature.  If its extremely low (say, below 2%)
then it would seem counter-productive to constrain the future
language constructs just to save typeing a rare "-NAMED".  The 
Vision people, the Constraints guys, and the ACTOR builders might
be the logical ones to provide input here.

Date: 12 APR 1980 1715-EST
From: DUFTY at MIT-MC (Dennis L. Doughty)
To: (BUG LISP) at MIT-MC
CC: (BUG EMACS) at MIT-MC


Today, several times, after loading liblsp;lispt fasl and ^T ing to
the LISPT, the editor job did not initialize in lisp mode but rather
in text mode.  This caused some problems, for when I tried C-M-Z or
M-Z to transfer info to the LISP superior I merely got the message
(console connected with lisp) and no reading from the editor was done.
After I did M-X Lisp Mode$ all the transfer commands worked fine.

RIVEST@MIT-ML 04/12/80 12:39:03
To: (BUG LISP) at MIT-ML
Why doesn't DIFFERENCE behave like MINUS when there is only one argument?
It's not consistent with what - does for FIXNUMS.
	Ron Rivest


Date: 12 APR 1980 1146-EST
From: JONL at MIT-MC (Jon L White)
Subject: arcane functions in maclisp
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 11 April 1980 02:06-EST
    From: Alan Bawden <ALAN at MIT-MC>
    Well I was just poking around and I found these SUBRs
    that I can't seem to find documented anywhere:
       GCPROTECT   GETSP   NORET  
    Anyone wanna satisfy my curiosity??
Apparently these escaped getting into the 1974 Moonual, although
I believe they were in the 1970 InterimLispUsersGuide.  Mostly
they are of use to LAP, FASLAP, FASLOAD and some LISP coders who
need to allocate binary-program space
   GCPROTECT -  If first arg is a symbol, merely sets the flag in
	the symbol-header which says "compiled code need me";  such
	symbols will never be GC'd.  Otherwise, it does a hash-table
	look-up of the s-expresssion on an internal array (stored in
	the cell labelled "GCPSAR:") just like INTERN;  so you get
	EQification for random list structure, which is what FASLOAD
	does in order to minimise duplication in "constant" structures.
	If second arg is "?", then it merely does a lookup, with no
	entering - sort of like INTERNDP.  One other crinkle added to
	this function was for the benefit of the "OWL" system:  if
	the value of the symbol "GCPROTECT" is non-null, then this
	"interning" action is not done, but instead each structure 
	(except symbols, of course) is freshly consed up.	
   GETSP - SUBRs etc are stored upwards beginning at BPORG, and after 
	each such loading (or assembling) BPORG is updated;  arrays are 
	stored downwards beginning at BPEND, and after each array creation, 
	BPEND is updated.  GETSP merely ensures that the difference between 
	BPEND and BPORG is at least as large as its argument, relocating
	arrays upwards if necessary; thus if a loser wants to grab some 
	binary-program space for himself, he should call this function.
   NORET - After a GC has been run, one of the last things done is to
	check how big the difference between BPEND and BPORG is;  if it
	 is more than several ITS pages, then an array-relocation phase
	is done in order to move BPEND downwards.  Originally, in the
	pre-paging ITS days, this relocation actually returned core and 
	swapping pages to the system, but nowadays, it merely prevents 
	your LISP address space from being eaten up by dead space between
	the last loaded SUBR and beginning of array storage.  One might
	set NORET to non-null, thereby preventing this action, if he
	wants to grab a bug chunk of binary-program space for his own use.

Date: 12 APR 1980 0133-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: Autoload from several files
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

I don't understand your message, but why can't you just write your own
AUTOLOAD handler?

Date: 11 APR 1980 0337-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: JONL at MIT-MC
CC: EJS at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

I think flushing the old-style DO would be a very foolish thing to do.
It would break lots of old code.  Who wants to have to go through old 
code converting the DOs there to new-style DOs?  (I suppose someone 
out there recommending flushing the old-style DO has an automatic 
converter to the new-style or is willing to write one?)  This is very 
different from the CATCH, THROW -> *CATCH, *THROW change because there 
every CATCH and THROW was affected, so writing an automatic converter 
was trivial.

Date: 11 APR 1980 0206-EST
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG LISP) at MIT-MC

Well I was just poking around and I found these SUBRs
that I can't seem to find documented anywhere:

GCPROTECT  I found references to this in old BUG-LISP mail
but not explanation of what it does.

NORET  simply sets the symbol NORET to its argument, but who
looks at the value of NORET?

GETSP  I gather this has something to do with arrays?

Anyone wanna satisfy my curiosity??

Date: 11 APR 1980 0107-EST
From: WGD at MIT-MC (William G. Dubuque)
Sent-by: BIL at MIT-MC
To: (BUG LISP) at MIT-MC

In a macsyma break loop, while trying to load RWK's debug I seem
to get ;(GETDDTSYM IAPPLY) CAN'T GET DDT SYMBOL - FASLOAD
This is the first time it has happened to me; it seems to depend
upon the current Macsyma environment somehow or another.

Date: 10 APR 1980 2337-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: Flushing old-style DO.
To: EJS at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

    Date: 10 April 1980 23:18-EST
    From: Eric J. Swenson <EJS at MIT-MC>

        Date: 10 April 1980 22:53-EST
        From: Alan Bawden <ALAN at MIT-MC>
        To:   EJS
        cc:   BUG-LISP, BUG-LISPM at MIT-AI
        Re:   Flushing old-style DO.

        There is a saying about such ideas: "you're in charge!".
    -----
    I don't understand this.  Please explain.
-----
It means that you proposed something that sounds nice but is
impossible to implement (think of all the code that uses old-style
DO!) so we put you in charge of the project confident that it will
never happen!

Date: 10 April 1980 22:53-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: Flushing old-style DO.
To: EJS at MIT-MC
cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-AI


There is a saying about such ideas: "you're in charge!".


Date: 10 April 1980 22:45-EST
From: Eric J. Swenson <EJS at MIT-MC>
Subject:  DOTIMES or REPEAT, and old-style DO flushable?
To: JONL at MIT-MC
cc: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, BUG-LISP at MIT-MC,
    BUG-LISPM at MIT-MC

I've long thought that the time had come to flush the old-style DO.  I
don't think it presents a substantial saving of coding space, and being as
un-general as it it, is not worth keeping.

Date: 10 APR 1980 1341-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

If I have a function FUN which is defined in file BAR but requires the
FOO file environment preloaded in order to win, then I can't make FUN
autoload. I would like to be able to say
 (DEFPROP FUN ((DSK WHATEVER) BAR FASL) AUTOLOAD)
in the FOO file (after setting up appropriate environment). But if
I have initially done 
 (DEFPROP FUN ((DSK WHATEVER) FOO FASL) AUTOLOAD)
I get FUN undefined after autoload. The ability to have the autoload
guy keep a list of the TRUENAMEs it has tried stopping after it hits a
loop (or I surely wouldn't care if it looped forever if I was dumb enuf
to make the thing circular ... it's no worse than typing (PROG A (GO A))
and Lisp doesn't try to diagnose that) -- in any case, having Lisp look
to see if the new autoload property is the same file (or maybe has same
truename) as the previous file and if not, then retry the autoload
would be very useful to me in some circumstances with my Fortran stuff
which requires an environment setup beforehand. The setup is sufficiently
expensive that doing it if I am not ever going to call the functions is
not worthwhile, so I lose either the storage used by the setup or the
ability to have translated routines autoload ... Certainly enough goes on
in an autoload that the extra little check in the case of an undefined 
function after autoload would not be noticed by anyone...? -kmp

GSB@MIT-ML 04/10/80 10:39:43
To: (BUG LISP) at MIT-ML
(LET (( (A . B . C .) (HUNK 'FOO 'BAR 'BAZ) ))
   (BREAK FOO))
==> ((LAMBDA (NIL) (BREAK FOO)) (HUNK 'FOO 'BAR 'BAZ))
without even a complaint.


Date: 10 April 1980 09:57-EST
From: Richard L. Bryan <RLB at MIT-MC>
Subject: SHARPM/GRINDEF fails on "FUNCTION"
To: LSH at MIT-MC, BUG-LISP at MIT-MC

    Date: 10 APR 1980 0923-EST
    From: LSH at MIT-MC (Lars S. Hornfeldt)

    	From: Lars S. Hornfeldt <LSH at MIT-MC>
    	Subject: GRINDEF of something that contains FUNCTION
    . . . .
Sorry about the keyboard bounce sending earlier verbosity.
Anyway, this is fixed.

Date: 10 April 1980 09:55-EST
From: Richard L. Bryan <RLB at MIT-MC>
Subject: SHARPM/GRINDEF fails on "FUNCTION"
To: LSH at MIT-MC, BUG-LISP at MIT-MC

    Date: 10 APR 1980 0923-EST
    From: LSH at MIT-MC (Lars S. Hornfeldt)

    	From: Lars S. Hornfeldt <LSH at MIT-MC>
    	Subject: GRINDEF of something that contains FUNCTION
    	Example:
    	(defun test (x) (mapcar (FUNCTION (lambda (y) y)) x))

    	(GRINDEF test)                  now starts:

    	(defun test (x) (mapcar         and then gives the ERROR:
    	;QUOTE NON-FIXNUM VALUE

    	When replacing FUNCTION with '  it works.

    Complement: It's necessary to have   (SHARPM FASL MC LISP)
    	loaded also, before or after (GRN    FASL MC LISP),
    	for the error to occur.

Date: 10 APR 1980 0923-EST
From: LSH at MIT-MC (Lars S. Hornfeldt)
Subject: SHARPM/GRINDEF fails on "FUNCTION"
To: (BUG LISP) at MIT-MC, LSH at MIT-MC

	From: Lars S. Hornfeldt <LSH at MIT-MC>
	Subject: GRINDEF of something that contains FUNCTION
	Example:
	(defun test (x) (mapcar (FUNCTION (lambda (y) y)) x))

	(GRINDEF test)                  now starts:

	(defun test (x) (mapcar         and then gives the ERROR:
	;QUOTE NON-FIXNUM VALUE

	When replacing FUNCTION with '  it works.

Complement: It's necessary to have   (SHARPM FASL MC LISP)
	loaded also, before or after (GRN    FASL MC LISP),
	for the error to occur.

Date: 10 APR 1980 0759-EST
From: LSH at MIT-MC (Lars S. Hornfeldt)
Subject: GRINDEF of something that contains FUNCTION
To: (BUG LISP) at MIT-MC, LSH at MIT-MC


Example:

(defun test (x) (mapcar (FUNCTION (lambda (y) y)) x))

(GRINDEF test)                  now starts:

(defun test (x) (mapcar         and then gives the ERROR:
;QUOTE NON-FIXNUM VALUE

When replacing FUNCTION with '  it works.

Date: 10 APR 1980 0517-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Flushing old-style do
CC: JONL at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

DO (old as well as new style) is very heavily used, and there is nothing
to be gained by flushing the old style other than an extremely minor
simplification of documentation.  Let's concentrat on something
at least marginally worthwhile.

Date: 9 April 1980 21:16-EST
From: Richard M. Stallman <RMS at MIT-AI>
Subject:  Old-style DO flushable?
To: HENRY at MIT-MC
cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI

Let's not flush old-stye DO, and let's not flush CATCH and THROW
either.  The extra functionality of new style DO and *CATCH and *THROW
is good, but we don't gain anything by forcing people to stop using
the old forms.


Date:  9 APR 1980 2019-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: EB at MIT-AI

(SETQ MSGFILES () )
(PLUS 4 T)  ==>  run an error break
(ERRSET (PLUS 4 T)) ==> die in unrecoverable reg pdl overflow and MPV

Date:  9 APR 1980 1935-EST
From: JONL at MIT-MC (Jon L White)
Subject: DOTIMES or REPEAT, and old-style DO flushable?
To: H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

The overwhelming response is to keep DOTIMES in the flavour of
a "DO" rather than a "REPEAT";  that is, the argument against
extending is based on the premise that there will have to be
"named" capability for DOTIMES.  
    Date: 8 April 1980 22:40-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    Subject:  DOTIMES
    .  .  .  we should consider 
    the case of named DOTIMES's -- this syntax would meet with 
    later problems if we decided we wanted something like that.
But at least some, myself included, feel the need for a very 
simple REPEAT syntax
    Date: 8 April 1980 22:12-EST
    From: Henry Lieberman <HENRY at MIT-AI>
    Subject: DOTIMES
    Instead, I propose REPEAT for this:
     (REPEAT (NUMBER-OF-TIMES) ...)
    This kind of repetition is so common 
    its worth having a clear syntax for it.
and 
Date: 9 April 1980 13:24-EST
    From: Jack Holloway <H at MIT-AI>
    Subject: DOTIMES
    .  .  .
    (and it's too bad we can't flush old-style DO so we
    wouldn't need DO-NAMED)  .  .  .
    If you really want that, why not use the InterLISP name RPTQ 
    or something?  Or, (DOTIMES (IGNORE X) ...) isn't so bad...
But since we're talking about it, has anyone given thought recently
to actually flushing the old-style DO syntax?  It certainly becomes
less useful if you have DOTIMES and a REPEAT as mentioned above.
The maclisp world is under one edict to flush old styles: on 
Sept 17, 1978  we introduced *CATCH and *THROW and announced the 
impending collapse of maclisp CATCH and THROW.  Is it time to
introduce RPTQ (or REPEAT) and take aim at old-style DO?

Date:  9 APR 1980 1800-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: FORMAT
To: GSB at MIT-MC, (BUG LISP) at MIT-MC

(format () "~{~A~}" ())
seems never to return.

Date: 9 April 1980 13:24-EST
From: Jack Holloway <H at MIT-AI>
Subject: DOTIMES
To: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI

Besides the cogent argument in favor of a named DOTIMES
(and it's too bad we can't flush old-style DO so we
wouldn't need DO-NAMED), letting (DOTIMES X ...)
mean (DOTIMES (G3453 X) ...) has the extremely nasty
property that there is a context which wants a value
in which you can only specify it by means of a variable,
and not by an expression.  This is like the old
computed-GO or STATUS-MACRO kludge, only backwards.
If you really want that, why not use the InterLISP
name RPTQ or something?  Or, (DOTIMES (IGNORE X) ...)
isn't so bad...

Date:  9 APR 1980 0456-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

CWH@MIT-MC 04/08/80 14:33:24
The GC flag was on the (STATUS FEATURES) list at one point and has since
disappeared.

I think you are mistaken about this.  MOON's GC scheme for JPG;SUPRV > 
did not use (STATUS FEATURES) to get his version of #+GC to work.

Date: 8 April 1980 22:40-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  DOTIMES
To: JONL at MIT-MC
cc: BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC

    Date: 8 April 1980 18:01-EST
    From: Jon L White <JONL at MIT-MC>
    To:   BUG-LISP
    cc:   BUG-LISPM
    Re:   DOTIMES

    Would anyone object if the syntax (DOTIMES <atom> (...)) ...
-----
Just for the record, having already talked to you on this, we should consider
the case of named DOTIMES's -- this syntax would meet with later problems
if we decided we wanted something like that.
-kmp

DHD@MIT-ML 04/08/80 21:39:22 Re: For what its worth...
To: (BUG LISP) at MIT-ML
I think it makes sense to have a flag so that if some of us would like
everything to come out in lowercase we could.  If this flag was defaultily
nil, meaning things would normally come up in uppercase, that wouldn't
break anything.  Pnames could still be in uppercase internally.  (I presume
this was what Dave Tourensky (sic?) was suggesting, I'm just supporting
the idea).  Would this be too hard to implement or too inefficient?

what ever happened to base 10.?

-dhd.

Date:  8 April 1980 2134-EST
From: Dave Touretzky at CMU-10A
Subject: more on lower case
To:  bug-lisp at MIT-MC

I wan't thinking of error messages when I sent my lower case suggestion.
I was thinking of s-expressions, and especially code.  I note that most
of the Lisp code written at MIT is in lower case, because ITS users have
EMACS.  If upper case is that winning, why don't they write all their Lisp
code that way?

We poor slobs who are forced to edit inside of Lisp and then write the
code out again have no choice about case.  I hate reading upper case
code.  As JoSH points out, the parentheses stand out much better in
lower case.  I don't know about VT52's, but most non-brain damaged
terminals have readable lower case fonts.

However, RWK has a point.  It would be bogus to store characters
internally in the inverted case from their external representation.  So
I guess I am suggesting that we make the default character
representation (internal and external) be lower case.  Rutgers LISP-20
does this, and so does the UNIX Franz Lisp.  I find both to be much more
readable than my upper case MacLisp code.

-- Dave Touretzky

Date:  8 Apr 1980 2011-EST
From: JoSH <JoSH at RUTGERS>
Subject: The Case for Lower Case
To: bug-lisp at MIT-MC, dave.touretzky at CMU-10A

Lower case IS easier to read, and Mixed case is even easier than
that.  But especially in Lisp, lowercase makes lots of sense. 
By comparison with:

 (LABEL FOO (LAMBDA (BAR) (COND ((NULL BAR) NIL) (T (FOO (CAR BAR)))))),

 (label foo (lambda (bar) (cond ((null bar) nil) (t (foo (car bar))))))

is almost legible.  The difference is of course that the parens stand out.

I've "lowered" Rutgers lisp by having READ convert everything to lowercase.
This works on an uppercase-only terminal just as well as anywhere else.
It works out to be a lot easier to take, ie reading the code.  I don't
really care what Maclisp does, but several months of experience suggests
that you would benefit from the change.

(The only way i could see the change breaking extant code would be if some-
one used varying case to distinguish atoms.  Surely this deserves to lose.)
	--JoSH
-------

Date:  8 APR 1980 2003-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: EJS at MIT-MC, Dave.Touretzky at CMU-10A

one additional note -- as much as i would like to change them, i'm not
sure if it's a good idea to change lisp error messages ... there does
exist code that does EQ checks for certain messages and which will do the
wrong thing if you change the case...  some lead time must be given, if this
change is to be made, for such code to be corrected appropriately. i'm not
even sure if such changes are worth it -- NIL, Lispm, etc. have winning error
message case. changing maclisp isn't really worth anyone's time.

Date: 8 April 1980 19:37-EST
From: Eric J. Swenson <EJS at MIT-MC>
To: KMP at MIT-MC
cc: BUG-LISP at MIT-MC, Dave.Touretzky at CMU-10A


Kent, you misunderstood ... I think.  By lowercase, I don't mean to make
everything lowercase.  Capitalizing initial letters of sentences looks
nice, and when typing out a function name, or variable name in an error
message, the uppercase PNAME is FINE.  I think upper-case only messages
are very impersonal.  Distinguishing between computer output and user
input can be relatively accomplished by wise choices of spacing.  

You said, "In the final analysis, if you care about case, you....".
What we are advocating is not user-written error messages, but LISP
interpreter error messages.  

Date:  8 Apr 1980 1918-EST
From: Jon Solomon <JOSH.JSOL at RUTGERS>
Subject: [JOSH.JSOL: Re:  the case for lowercase]
To: bug-lisp at MIT-MC


	Sorry, I forgot to forward this message.
                ---------------
   --------
DATE:  8-Apr-80 19:16
FROM: JOSH.JSOL
Subject: Re:  the case for lowercase
To: EJS at MIT-MC
In-Reply-To: Your message of 8-Apr-80 1915-EST


	It should not be to difficult to change the error messages to lower
case. I am also all for it.

(So who asked me anyway??????)
/Jsol
   ========
                ---------------
-------

Date:  8 APR 1980 1923-EST
From: KMP at MIT-MC (Kent M. Pitman)
Sent-by: ___031 at MIT-MC
To: Dave.Touretzky at CMU-10A
CC: (BUG LISP) at MIT-MC

I disagree completely. I think that uppercase is much preferrable to
lowercase in places where you want not to worry about case. eg, it looks
like you forgot to upcase the first letter of your sentence if you do
things like:

	this is a sentence.  so is this.  mr. foo was here today.

whereas

	THIS IS A SENTENCE.  SO IS THIS.  MR. FOO WAS HERE TODAY.

looks perfectly fine. non-computer people are bothered by the lack of
capitalization at the beginning of textual sentences and in my observation,
are less bothered when it's something they can't see (ie, all uppercase). 

Secondly, since most people on upper/lower terminals tend to do input in
lower case, program output that has not dealt with case coming out in upper
is also a feature because it distinguishes prompting from input. eg,

	WHAT ANIMAL ARE YOU THINKING OF? I'm thinking of a dog.

If the default case is lower, then to achieve this end maybe you would
force the guy to type in upper case?

Thirdly, many people get themselves stuck with all-upper keyboards. As
obnoxious as it is that people continue to sell these things, we might as
well not go out just asking for trouble. I have found myself stuck, 
occasionally, on those losing things and was very glad that programs
had pity on them.

In the final analysis, if you care about case, you should specify it with
|...| or "..." and use PRINC instead of PRIN1 as you do now -- note how
neat it looks when I upcase those words in this text -- makes them stand
out -- gives a nice visual distinction between code and text doesn't it?

-kmp

ps if you want, i can send you instructions for how to mung up the lisp
 read syntax so that things will downcase instead ... but it hardly seems
 worth it.

pps I wouldn't object to mixed-case error messages -- which is what ejs is
 surely advocating (not only lower-case).

ppps This isn't a question of printers, it is a question of readers. let
 me know if you're confused on that issue.


Date: 8 April 1980 19:17-EST
From: Eric J. Swenson <EJS at MIT-MC>
Subject:  Lower-case
To: RWK at MIT-MC
cc: BUG-LISP at MIT-MC


I think that the error messages could be implemented as lowercase strings
with all printing of PNAMES retaining their uppercase status.  The text, 
however, could be represented by lower-case without breaking much.

Date: 8 April 1980 19:15-EST
From: Eric J. Swenson <EJS at MIT-MC>
Subject:  the case for lowercase
To: BUG-LISP at MIT-MC

I'm all for changing the error messages to Lowercase.  I agree, it is
much easier to read in lowercase.  

Date:  8 APR 1980 1853-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___130 at MIT-MC
Subject: Lower-case
To: (BUG LISP) at MIT-MC

I'd always heard that UPPERCASE WAS EASIER TO READ.  It depends heavily
on your font, but it's definately true (subjective opinion) on a VT52.

Yet, I do find lower case more aesthetic.  But you don't want to make
how things print be different from the default read syntax, and you do
want to make it possible to FORCE things to print with upper-case (with
slashification if necessary).  Thus you must either change all the atoms
to use lower-case instead of upper in their PNAMES (which will affect,
if not break, everything using EXPLODE etc.)  Else lower case must be
represented as upper case internally, and slashified upper case be represented
as lower case internally, and then invert them on output.

I think the best way to implement this change is with careful aplication of
a time machine.

Date:  8 April 1980 1752-EST
From: Dave Touretzky at CMU-10A
Subject: the case for lowercase
To:  bug-lisp at MIT-MC

Wouldn't it be nice if MacLisp's output was normally in lowercase?  It's
well known that lowercase is easier to read.  The big question is, of
course, how much stuff would break if we made the change?  Alternatively,
how much would it cost to make output case be a switch?

Date:  8 APR 1980 1801-EST
From: JONL at MIT-MC (Jon L White)
Subject: DOTIMES
To: (BUG LISP) at MIT-MC
CC: (BUG LISPM) at MIT-MC

Would anyone object if the syntax
  (DOTIMES <atom> (...))
were permissible, to mean
  (DOTIMES (G0012 <atom>) (...))
where G0012 is a random gensym.

Date:  8 APR 1980 1729-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

(SETQ A '(A . B)) (LET (ERRSET) (ERRSET (PRINT (RPLACA A A) TYO) T))
This gives ;BKPT PDL-OVERFLOW - I claim it should just do
;PDL-OVERFLOW and then return to the ERRSET.

Date:  8 APR 1980 0622-EST
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG LISP) at MIT-MC

Multiple line JCL doesn't work.

Date:  6 APR 1980 1627-EST
From: HMR at MIT-MC (Harry M. Rath)
To: (BUG LISP) at MIT-MC

There are a number of symbols that should be expunged in FASEND that are
ending up in FASL files.  Somebody should go through and add them sometime.
If FASLIST would write to a file it would be easy to add them.

Date:  5 APR 1980 1733-EST
From: cwh at MIT-MC (Carl W. Hoffman)
Sent-by: RHB at MIT-MC
To: (BUG MACSYMA) at MIT-MC
CC: (BUG LISP) at MIT-MC

Doing <alt><alt>control-P seems to lose with the Macsyma tty-return scheme.
When the Macsyma tries to print out something, that succeeds, but immediately
afterward the tty-return handler gets run and the message "Job A wants the tty"
gets printed and the Macsyma goes blocked.  This may be a bug in Lisp.
If anything, the tty-return handler should be run before the typeout happens.

Date:  5 APR 1980 1607-EST
From: KMP at MIT-MC (Kent M. Pitman)
Sent-by: ___076 at MIT-MC
Subject: (LOAD'((LISP) GRINDE))
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

Probably you lost because your device default was set wrong. Eg,
(DEFAULTF '((AR5 FOO) BAR BAZ)) (LOAD '((LISP) GRINDE))
is a known way to cause this. You should avoid getting your defaultf
set to a non-disk device. There are problems with that that haven't been
resolved very well. -kmp

Date:  5 APR 1980 0619-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

Somehow I got a macsyma into a state where 
(load '((lisp)grinde)) gave a "NO SUCH DEVICE" error.

GSB@MIT-ML 04/04/80 02:01:35 Re: reader changes
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-ML
I want to punt on the reader changes.  I am not convinced i can make
them in a reasonable manner, and don't right now have the time
to find out.  Maybe in the version after this one...


Date:  3 APR 1980 0937-EST
From: JONL at MIT-MC (Jon L White)
Subject: Incompatible changes for next LISP
To: CWH at MIT-MC, GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date:  2 April 1980 15:46-EST
    From: Carl W. Hoffman <CWH at MIT-MC>
    How about turning on # by default sometime in the near future?
    Particularly now that people are writing code which attempts to run on both
    the Lisp Machine and ITS.  " would also be nice, but less critical.
Yea, I'd like to see # and " standardized by now - how about you sending
out a general note to the *ITS community to see if anyone objects. 
Also, GSB should send out his note about READ always flushing the
space terminating an atom, and the addition of a new function which
returns both the thing read and the terminating character.  Since
these are incompatible changes (turing on # and ", and having READ always
flush the terminator), there will have to be a probe to the user community;
I wish you two would respectively do the part you're interested in.

Date:  1 APR 1980 0909-EST
From: RWK,JONL at MIT-MC
Sent-by: HMR at MIT-MC
Subject: Why SUSPEND should not do a GC
To: ALAN AT MIT-MC at MIT-MC, GSB AT MIT-MC at MIT-MC
To: HIC AT MIT-MC at MIT-MC, JPG AT MIT-MC at MIT-MC
To: HENRY AT MIT-AI at MIT-MC, DDM AT MIT-AI at MIT-MC
To: SJOBRG AT MIT-AI at MIT-MC, MILLER AT MIT-AI at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date:  3 March 1980 19:39-EST
    From: Jon L White <JONL at MIT-MC>
    Subject: SUSPEND to stop doing a gc
    To: ALAN at MIT-MC, GSB at MIT-MC, HIC at MIT-MC, JPG at MIT-MC,
	HENRY at MIT-AI, DDM at MIT-AI, SJOBRG at MIT-AI, MILLER at MIT-AI
    cc: NIL-I at MIT-MC

    (Original note to be found in NIL mail file on MC)

Besides the afore-mentioned reasons for SUSPEND to not do a GC, we've hit
on another:  It makes investigating GC related problems a lot easier.
I.e. if you have something which fails after hours of cycles, you can
run up almost to the point of failure, SUSPEND, and debug from there.
You can't do that if it invokes the GC.  This just saved me mucho work
debugging a GC-DEAMON hack.

Date:  1 APR 1980 0206-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(SETQ A '(A B C D))
(A B C D)
(POP (CDDR A))
;LAMBDA UNDEFINED FUNCTION OBJECT

Date:  1 APR 1980 0205-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(PUTPROP 'FOO '(A B) 'BAR)
(A B)
(POP (GET 'FOO 'BAR))
;Loading DEFMAX 44 (sigh)
;Loading MLMAC 9 (hmmm)
;Loading MACAID 82 (what have I done?)
;Loading SETF 245 (good grief!)
;|GET SETF-X-INVERT| UNBOUND VARIABLE

...gee, after all that work.
-kmp

Date: 30 March 1980 23:57-EST
From: Jonathan A. Rees <REES at MIT-MC>
To: REES at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 29 March 1980 03:54-EST
    From: Jonathan A. Rees <REES at MIT-MC>
    To:   BUG-LISP
    (SPRINTER '(A . (B .)))
    gives NIL UNDEFINED FUNCTION IN UUO CALL.
Sorry, false alarm, obviously.

Date: 30 MAR 1980 0159-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: GRINDEF/SETF
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

GRINDEF should know that SETF is like SETQ.

Date: 29 MAR 1980 1457-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: SFAs are almost as much fun as HUNKs!
To: (BUG LISP) at MIT-MC

In a bare lisp 1914 the following dialog took place:

;;;An SFA that simply passes its output on to someone else:
(defun foo-function (foo op arg) 
  (caseq op
	 (tyo ((lambda (f) 
		 (cond ((or (< arg 0) (> arg 177))
			(tyo 133 f)	;strange negative numbers are printed
			(prin1 arg f)	;enclosed in square brackets.
			(tyo 135 f))
		       (t (tyo arg f))))
	       (sfa-get foo 0)))
	 (which-operations '(tyo))))
FOO-FUNCTION 

;;;Make one:
(setq foo (sfa-create 'foo-function '1 '|Foo|))
#SFA-|Foo|-70740 

;;;Stuff it with someone to talk to:
(sfa-store foo 0 tyo)
#FILE-OUT-|TTY:* *|-70014 

(setq terpri t)			;just to be sure (the default these days)
T 

(print '(a b c) foo)
(A B C)				;looks fine
T 

(setq terpri nil)		;used to be the default
NIL 

(print '(a b c) foo)
[-4]A [-3]B [-4]C)		;well, there are the funny negative numbers
T				;but where is my open paren??

;;;If I remove the code to print the square bracketed negative numbers
;;;then the open parens come back.

Date: 29 MAR 1980 1325-EST
From: JONL at MIT-MC (Jon L White)
Subject: STRING bug, and NILAID on twenex
To: SJK at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 25 Mar 1980 0713-PST
    From: Scott at SRI-KL (Scott J. Kramer)
    Subject: 3 MacLisp/Nilaid bugs
    [1] TO-STRING losses after converting several long SYMBOLs to STRINGs.  I
	 tested this on smaller SYMBOLs and it apparently worked.  It doesn't
	 work in either MacLisp or Nilaid on ITS or 20x, but work okay in NIL
	 simulation on ITS.
This was a bug in STRING's GC-DAEMON function, which I've just fixed on
the ITS systems.  I don't understand how NIL could have avoided the problem,
since it was due to the actual length of your string being a non "INUM"
fixnum, and hence getting prematurely swept-up by the GC.
    [2] DEFAULTF in Nilaid on 20x is wrong.
    ((PS MACLISP) * FASL *) 
Twas a bug in the NILAID.INI file - just now fixed it.
    [3] OPEN doesn't work in either MacLisp or Nilaid for file without
	 extensions on 20x.
I guess this hasn't been hacked yet - how important is it?


Date: 29 MAR 1980 1256-EST
From: JONL at MIT-MC (Jon L White)
Subject: PROBEF losing?
To: EBM at MIT-MC
CC: (BUG LISP) at MIT-MC

    EB@MIT-AI 03/25/80 04:24:42 Re: Compiler Bug
    To: (BUG Lisp) at MIT-MC
    After fruitlessly searching for hours to find a bug in my code, I have
    discovered that the bug is not mine but the compiler's.  Consider the following
    pared-down example:
    (defun foo (x)
       (let (((a b c) x))
	  (cond ((probef a)
		 (list a b c))
		(t nil))))
    .  .  .
I'm really sorry you lost so much time tracking this thing down - it's
*not* a complr bug - someone had added code to PROBEF failing to note
that it is supposed to preserve several accumulators.  So I've patched
the installed lisp, and edited in the one line necessary in the source.

Date: 29 MAR 1980 0902-EST
From: JONL at MIT-MC (Jon L White)
Subject: Return of pure SETQ but
To: FAHLMAN at CMU-10A
CC: RWK at MIT-MC, (BUG LISP) at MIT-MC, TOURETZKY at CMU-10A

    Date: 26 March 1980 1141-EST (Wednesday)
    From: Scott.Fahlman at CMU-10A
    Subject: Return of the creature...
    The old bug that gave you an ill mem ref and punted to the monitor when
    you setq T seems to be back on CMUA.  Guess we forgot to pound a wooden
    stake through its heart.  I'll try to look for it someday soon and see if
    it really is the same lossage, but if anyone wants to fix it sooner, feel 
    free.  The offending code was in the handling of "write into read-only
    memory" errors and had to do with the fact that KAs left the PC incremented
    and KLs did not (or vice versa).  Has anyone been messing with this?
I see what the trouble is - not the KL versus KA problem but a bug 
in the way Bob (Kerns) installed the new "WITHOUT-INTERRUPTS" feature.
The macro BNDTRAP, in the dec10 version, inserts two extra instructions
between the label and the offending instruction, thereby thwarting the
attempts of the pure-page-interrupt handler to "recognize" it.  I've
added a "label" argument to BNDTRAP, and modified all the usages in
the *LISP file, but Kerns should think about it too before we reassemble.

Date: 29 MAR 1980 0756-EST
From: JONL at MIT-MC (Jon L White)
Subject: PPN property for "LISP"
To: CFFK at MIT-MC
CC: RWK at MIT-MC, (BUG LISP) at MIT-MC

    Date: 26 March 1980 17:58-EST
    From: Charles F. F. Karney <CFFK at MIT-MC>
    (defaultf '((arc cffk) foo bar))
    (grindef foo) ==> ;(load ((arc lisp) grinde fasl)) no such device
We're about ready to reassemble a new lisp (version 1986 or so) and
will have this corrected - I believe it only requires a "PPN"  property
for the atom "LISP" so that there appears to be a "LISP" device
on the ITS systems (a "LISP" device has been in use on the TOPS-10
systems for some time now).

Date: 29 MAR 1980 0354-EST
From: REES at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC

(SPRINTER '(A . (B .)))
gives NIL UNDEFINED FUNCTION IN UUO CALL.

Date: 28 MAR 1980 0921-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(SSTATUS MACRO /# '+INTERNAL-/#-MACRO 'SPLICING)
causes a .VAL 0; -- I would think something just a wee bit more forgiving
would be in order -- that's likely to be a common error with people. I'm
not suggesting anything DWIM-ish, maybe just 
;ILLEGAL ARGUMENT SOMEWHERE OR OTHER - SSTATUS
or something like that -- if it typed out (QUOTE SPLICING) it would help a lot.
-kmp

Date: 27 March 1980 13:32-EST
From: Alan Bawden <ALAN at MIT-AI>
Subject: *sigh* HUNKs *sigh*
To: BUG-LISP at MIT-AI

I find that HUNKSIZE when given a hunk like: (#777777 .)
.VALUEs .  Now I will admit that this is a hunk of questionable
value or validity, but at least a reasonable error condition
might be expected.

Date: 27 MAR 1980 0632-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: REES at MIT-MC, KMP at MIT-MC

Why can't I say
(DEFUN (FOO EXPR LSUBR) MACRO MACRO) 
I get the following error:
;((FOO EXPR LSUBR) MACRO MACRO) WRONG FORMAT - DEFUN
I would like a LEXPR/LSUBR which uses the lambda variable 'MACRO'.

In the compiler, I get an "Illegal DEFUN format" diagnostic. 

I feel my programming style being cramped.
-kmp

Date: 27 March 1980 04:43-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: LSUBR GET
To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI
cc: GLS at MIT-AI, GJS at MIT-AI

I was about .9 serious about my propsoed LSUBR GET.  However, that proposal
is in conflict with another for (GET sym propname [defaultval]), which
I also support.  Maybe the LSUBR GET could be called GET* ?  Or maybe
just not implemented?  Oh well.  LSUBR GET is easily coded as a macro;
the defaulted GET less so, and probably more useful.


Date: 27 March 1980 02:54-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: LSUBR GET
To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI
cc: GLS at MIT-AI, GJS at MIT-AI

Boy, would it be neat in certain kinds of programming for
GET to be an LSUBR!  (GET x p1 p2 p3 ... pn) =>
(GET ... (GET (GET (GET x p1) p2) p3) ... pn)
Great for super property-list hackers (like GJS).


Date: 26 MAR 1980 1758-EST
From: CFFK at MIT-MC (Charles F. F. Karney)
To: (BUG LISP) at MIT-MC

(defaultf '((arc cffk) foo bar))
(grindef foo) ==> ;(load ((arc lisp) grinde fasl)) no such device

Date: 26 March 1980 1141-EST (Wednesday)
From: Scott.Fahlman at CMU-10A
Subject: Return of the creature...
To:  Dave.Touretzky at CMU-10A, bug-lisp at MIT-AI
Message-ID: <26Mar80 114133 SF50@CMU-10A>


The old bug that gave you an ill mem ref and punted to the monitor when
you setq T seems to be back on CMUA.  Guess we forgot to pound a wooden
stake through its heart.  I'll try to look for it someday soon and see if
it really is the same lossage, but if anyone wants to fix it sooner, feel 
free.  The offending code was in the handling of "write into read-only
memory" errors and had to do with the fact that KAs left the PC incremented
and KLs did not (or vice versa).  Has anyone been messing with this?
-- Scott


Date: 26 MAR 1980 0648-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

In a fresh LISP, (MERGEF '(1 2 3) DEFAULTF) gives an ILOPR; error.
I think some form of bad file specification error would be more 
appropriate.

Date: 25 MAR 1980 2209-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: (HUNK 'FOO)
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

(HUNK 'FOO) now prints correctly.

As for (HUNKP (HUNK)) ==> NIL, I agree, we should just punt.

Date: 25 MAR 1980 2134-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: HUNKs are my favorite things.
To: (BUG LISP) at MIT-MC

Why is a hunk of no things NIL?
Well (HUNKP NIL) returns NIL and not T so why don't we just punt?
Also currently (HUNK 'FOO) returns something that prints as
(#777777 . FOO .) in XLISP.

Date: 25 MAR 1980 1334-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: TO-STRING
To: SJK at MIT-MC
CC: (BUG LISP) at MIT-MC

Did you try your example on MC?  There used to be a bug in MAKE-STRING that was
fixed.  Try brining over a new STRING FASL and STRAUX FASL and see if the
problem goes away.  Also, bring over a new EXTEND FASL, there was a bug there
that used to screw string GCing in another way.

Date: 25 March 1980 11:48-EST
From: Robert W. Sjoberg <SJOBRG at MIT-AI>
To: BUG-LISP at MIT-AI
cc: SJOBRG at MIT-AI

I am having trouble with the wholine status variables.  When I do

(sstatus who1 166 0 5 0)	;all numbers in octal
(sstatus who2 'LINE)
(sstatus who3 5)

the result is "LINE   0".  On the other hand, if I do

(sstatus who3 5_18.)

then I get "LINE   5".  If I do

(sstatus who3 1000005)

then I get "LINE   1".  Am I reading the documentation wrong?  I want
LINE in who2, and a decimal integer in the low 18 bits of who3, with
the top half of who3 not printed.


Date: 25 Mar 1980 0713-PST
From: Scott at SRI-KL (Scott J. Kramer)
Subject: 3 MacLisp/Nilaid bugs
To: bug-lisp at MIT-MC

[1] TO-STRING losses after converting several long SYMBOLs to STRINGs.  I
     tested this on smaller SYMBOLs and it apparently worked.  It doesn't
     work in either MacLisp or Nilaid on ITS or 20x, but work okay in NIL
     simulation on ITS.

!na:

NILAID 90

NIL 
(load '((scott) loss))
T 
(loss)
1. This is a line to determine how long it takes TO-STRING to barfThis is a line
 to determine how ..... a line to determine how long it takes TO-STRING to barf
2. This is a line ... to barf
   {time and boredom pass}
10. This is .... TO-STRING to barf
11. 
;(NIL . 1. . 39143. . (NIL . 190. . 39141. . (NIL . 379. . 39138. . (NIL . 39139
. . 39135. . (NIL . 39136. . 39132. . (NIL . 39133. . 39129. . (NIL . 39130. . 3
9126. .

  {it goes on for awhile, then...}

 .) .) .) .) .) .) .) .) .) .) STRING bug detected by STR:GC-DAEMON

;BKPT FAIL-ACT

			*	*	*

Here's the LOSS function I used to demo this:

(do ((i 1 (1+ i)))	 ;Where are we
    (())		 ;Do forever
    (print i)		 ;Show index
    (princ (to-string s)))	 ;"s" is a very long SYMBOL (947. chars)

----------------------------------------------------------------------
[2] DEFAULTF in Nilaid on 20x is wrong.

defaultf 
((PS MACLISP) * FASL *) 

----------------------------------------------------------------------
[3] OPEN doesn't work in either MacLisp or Nilaid for file without
     extensions on 20x.
!v test.*.* 

   PS:<SCOTT>
 TEST..1;P775252            1 550(7)       25-Mar-80 06:26:54 SCOTT     

(open '|<scott>test..1|)
;(OPEN |<scott>test..1|) FILE NOT FOUND

;BKPT IO-LOSSAGE
----------------------------------------------------------------------

I heard a rumor that STRINGs aren't supposed to work in MacLisp but I
thought I'd pass this along anyways.

-sjk
-------

EB@MIT-AI 03/25/80 04:24:42 Re: Compiler Bug
To: (BUG Lisp) at MIT-MC
After fruitlessly searching for hours to find a bug in my code, I have
discovered that the bug is not mine but the compiler's.  Consider the following
pared-down example:

(defun foo (x)
   (let (((a b c) x))
      (cond ((probef a)
	     (list a b c))
	    (t nil))))

If FOO is called on a three-element list whose first element is the name
of an existing file, FOO should return a copy of that list.  But if
FOO is compiled with XC (907, in Lisp 1984) the resulting compiled function
returns the wrong value, e.g. (foo '(|lisp;defvst fasl| 1 2)) should
return (|lisp;defvst fasl| 1 2) but in fact returns
(|lisp;defvst fasl| |lisp;defvst fasl| 2).



Date: 24 March 1980 18:58-EST
From: Jonathan A. Rees <REES at MIT-MC>
Subject:  HUNK printer hooks
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC

It is NOT TRUE that the hunk hooks in the new Maclisp are "specific to
a certain use."  Kerns and I have gone to pains to make sure that they
are general.  It IS true that the new features are not documented; I'm
not sure what the plans are for documentation, there is probably more
to say than wants to be said in LISP NEWS, so a file may appear on
LSPSRC; or on one of the info directories.  Contact one of us if you
can't wait for the official word.  We are hesitant to release these
hooks as features, because we don't have the manpower to maintain them
for any purposes besides those of the Nil project, but...

Re the normal hunk printer: KMP tells me that the bug you reported
has been fixed in XLISP.  GRINDEF also does the right thing, which I guess
is to print (cons '(a . b . c .) '(e . f . g .)) as
((A . B . C .) . (E . F . G .)).

Date: 23 March 1980 20:34-EST
From: Edward Barton <EB at MIT-AI>
Subject: Files
To: BUG-LISP at MIT-AI

XC on AI wouldn't run because it couldn't find the right Lisp
file for its pure pages; I couldn't use COMPLR because new
DEFVST will not load into that Lisp.  Consequently I did the
following:

(1) Renamed COMLAP;XC.DMP 907 to XC.OLD 907
(2) FTP'ed COMLAP;XC.DMP 907 from MC

This message documents those actions.


Date: 21 MAR 1980 2120-EST
From: ALAN at MIT-MC (Alan Bawden)
Subject: READing HUNKs
To: (BUG LISP) at MIT-MC

Well If we are going to try and have READ grok hunks then the
following should be fixed:

(cons (hunk 1 2 3) (hunk 1 2 3))
((1 . 2 . 3 .) 1 . 2 . 3 .)	;Hmmm... the printer seems to have made 
				;an interesting optimization!

'((1 . 2 . 3 .) 1 . 2 . 3 .)	;Let's see if the reader can hack it...
((1 . 2 . 3 .) . 1 . 2 . 3 .)	;Doesn't look good...

(typep *)
HUNK4				;Nope


Sigh.


While I have you all listening let me plead once again for a hook in
the printer to allow me to redefine the way hunks print.  Since many
people have built structure packages on top of hunks, it doesn't seem
too unreasonable to provide a simple way to change the way they print.
I know there is such a hook now that is specific to a certain use.  I
would hope that the people using this hook would be willing and able
to build their hacks on top of some more general hook that the rest of
us could use for our own purposes.  Please?

Date: 21 MAR 1980 0359-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: Print strangeness
To: EB at MIT-MC
CC: (BUG LISP) at MIT-MC

'Twas 3 bugs:  one apiece in DEFVST, PRINT, and PRINT-OBJECT.
I thought I had noticed such a strangeness before, but couldn't
reproduce it.  Thanks for pointing it out.

Date: 20 MAR 1980 2032-EST
From: JONL at MIT-MC (Jon L White)
Subject: DISPLACE
To: DLW at MIT-MC
CC: (BUG LISP) at MIT-MC, NIL at MIT-MC

Uh, after having read all my mail, I see what prompted
your enquiry.   There is a point to what KMP has been
saying, which none of the discussion seems to have
noticed, that by making DISPLACE to be not very hairy
then:
   1) it can serve as the canonical RPLACA and RPLACD
      for **any** of the various macro-displacing schemes
      which have abounded in the past two years - there is
      the danger of one complicated macro-scheme thinking 
      that it is the *only* choice. 
   2) it can be the canonical place where the question of 
      clobbering a "pure" cell must be handled.  RPLACA and 
      RPLACD are open-coded by maclisp, and one probably
      wouldn't want the same  pure-page-trap action/error to 
      be done for them as for DISPLACE.  A close-compiled
      function like DISPLACE can rather easily do a "purep?" 
      check by looking into the maclisp internal tables.
No, this purity check hasn't yet been done, but as you say, 
"we should reason together about what the right thing is and 
what should be done about it."
    By the bye, I assume that everyone who has pitched in
a opinion so far is on one of the two mailing lists, BUG-LISP
and NIL.  So it you didn't get this note, and had a strong
opinion, you should complain (I suppose).

EB@MIT-AI 03/20/80 20:00:30
To: (BUG Lisp) at MIT-MC
Can you explain the following strange behavior in printing?
I am particularly interested in why the trace of BAR sometimes
(but not always) omits the second and third arguments when
the first argument is a structure....  This is making it difficult
for me to get useful information out of tracing my functions.

:XLISP
LISP 1984
Alloc? n
*
(defvst foo a b c)
;Loading DEFVST 78 
;Loading EXTEND 102 
;Loading EXTMAC 63 
;Loading DEFMAX 44 
;Loading VECTOR 23 
;Loading MLMAC 5 
;Loading MACAID 81 
;Loading DEFMACRO 115 
FOO
(setq prinlevel 2.)
2
(setq foo1 (cons-a-foo a '((1 2 3))))
;Loading LET 80 
#{FOO
;Loading TMLMAC 10  A }
(defun bar (x y z) nil)
BAR
(trace bar)
;Loading TRACE 66 
(BAR)
(bar foo1 '(a b) '(c d))
(1 ENTER BAR (#{FOO A }  ))
(1 EXIT BAR NIL)
(bar '(1 2) '(3 4) '(5 6))
(1 ENTER BAR ((1 2)(3 4)(5 6)))
(1 EXIT BAR NIL)
NIL
(bar (cons-a-foo) '(1 2) '(3 4))
(1 ENTER BAR (#{FOO} (1 2) (3 4))
(1 EXIT BAR NIL)
NIL


Date: 20 MAR 1980 1944-EST
From: JONL at MIT-MC (Jon L White)
Subject: DISPLACE
To: dlw at MIT-AI
CC: (BUG LISP) at MIT-MC, NIL at MIT-MC

    Date: 20 March 1980 16:42-EST
    From: Daniel L. Weinreb <DLW at MIT-AI>
    The Lisp documentation in LISP NEWS is typically done without much
    thought; . . .  MACLISP does not need lots of
    little functions like (LAMBDA (X Y) (RPLACA X Y) (RPLACD X Y) X)
    . . .  						. . .  LISP NEWS
    was not handed down on engraved tablets--we should reason together
    about what the right thing is and what should be done about it.
Not to be picky about your conceptions of LISP NEWS, but this happens to 
be the entry in LISP NEWS for DISPLACE, dated 
"Sunday  Sept 17,1978   FM+11H.57M.58S.   LISP 1742  -HIC, JONL-"
"[5] DISPLACE now treats atomic arguments differently.
    Its definition is now like:
    (DEFUN DISPLACE (X Y)
           (AND (ATOM X) (ERROR '|-- not a list. (DISPLACE)| X))
           (COND ((ATOM Y)
    	      (RPLACA X 'PROGN)
    	      (RPLACD X (NCONS Y)))
    	     (T (RPLACA X (CAR Y))
    		(RPLACD X (CDR Y)))))"
By the bye, what prompted your comment?

Date: 20 March 1980 16:42-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: DISPLACE
To: BUG-LISP at MIT-MC, NIL at MIT-MC

The Lisp documentation in LISP NEWS is typically done without much
thought; it should not be an inflexible restriction on the rest of the
future of the definition of MACLISP.  MACLISP does not need lots of
little functions like (LAMBDA (X Y) (RPLACA X Y) (RPLACD X Y) X)
built into the system when they are used in a small percentage
of programs and are quite simple to write.  What IS needed in the
system is powerful tools to make the language extensible, tools
that are NOT easy to write every time you need them.  LISP NEWS
was not handed down on engraved tablets--we should reason together
about what the right thing is and what should be done about it.


Date: 20 MAR 1980 0951-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC, NIL at MIT-MC

Consider also the following:

;;; (SET-ARRAY val type (arrayobj subscript1 subscript2 ...))
;;;  stores val in arrayname

(DEFUN SET-ARRAY MACRO (FORM)
  (LET (((VAL TYPE REF) (CDR FORM)) (OBJ))
       (SETQ OBJ (CAR REF))
       (WITHOUT-INTERRUPTS
	(DISPLACE REF `(ARRAYCALL ,TYPE ,OBJ ,@(CDR REF)))
	(DISPLACE FORM `(STORE ,REF ,VAL)))))

Assume that arrayobj will eval to an array object. If the form that gets
bound to REF is pure, the ''wrong thing'' will happen -- REF will not
get displaced FORM may ... so then you get something that looks like

(STORE (arrayobj s1 s2 ...) val)

Other cases are possible to construct. Note that these are uses of DISPLACE
in macro definitions and consistent with *all* information heretofore 
distributed about what DISPLACE does. My argument is that there needs to
be a DISPLACE for forming code incrementally. DISPLACE does this already.
I use it for that application in my Fortran translator and several other
packages I'm sure ... There needs to be a different operator which is more
tolerant -- but people that call it should be clearly aware when they are
doing so that it will, in some sense, not care if the DISPLACE fails...

-kmp

Date: 20 MAR 1980 0855-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC, NIL at MIT-MC

Wednesday  June 14,1978   FQ+1D.8H.19M.18S.   LISP 1633  -HIC-

Changes that affect ITS NEWIO:
...
[1] PUSH, POP, and DISPLACE FEXPR's in interpreter
...
    SUBR:  (DISPLACE X Y) ==>  (PROGN (RPLACA X (CAR Y)) (RPLACD X (CDR Y)) X)
...
--------
This was what was announced in Lisp news a month afterward. I think it's
fine if it was originally intended for use with MACRO's but it was given
a very precise definition if you ask me ... The fact that it was later
extended to handle DISPLACE'ing atoms into itself was not unreasonable
as it provided an upward compatible extension. The proposed change that you
are asking for is not upward compatible. It says that if it fails to 
accomplish what it has been documented to do, it may not err out and I
may just find out later at random ... I have used DISPLACE all over in my
code because it was defined in a general fashion. I like the definition as
is and find it immensely useful.

Take an example of SUBST -- its stated purpose is to do substitution -- it
was only an accident that it does copying. Would you say then that it is
reasonable to change how it operates -- perhaps making it more conservative
about copying, like SUBLIS is? I should hope not.

I think a 2-year-old description of the functionality of something should
stand. HIC chose to document its function, for good or bad, in Lisp. If
the function has any contract, that is surely it.

I see a very bad thing happening to MacLISP in recent days. It is being
treated more and more like a set of midas macros for booting up a better
lisp. While I think it is good to see the new semantics brought about,
I do not agree that the way to do it is to introduce funny little variables
here and special case crocks there that only serve to support the 
implementors of the up-and-coming world and generally make the language
harder and harder to explain, less and less elegant ... Maybe the thing
to do is freeze MacLISP and then we wouldn't have to worry. Existing
code could continue to run -- new code could be developed for NIL and
such...

-kmp

Date: 20 March 1980 07:50-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: DISPLACE
To: ALAN at MIT-MC, KMP at MIT-MC
cc: BUG-LISP at MIT-MC, NIL at MIT-MC

I have to agree with Alan on your use of DISPLACE.  The original
intent of it was to provide a canonical macro displacer.
If it is not intended to be that, then it shouldn't have been provided
in the first place;  that wasn't what was wanted or needed.


Date: 20 MAR 1980 0745-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: Wrong function
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

From LISP NEWS:
THURSDAY  MAY 25,1978  FM+3D.8H.53M.31S.     NCOMPLR 769   -JONL-

...

	DISPLACE is intended for use as a macro-displacing function;
	thus if (DEFUN FOO MACRO (X) (MUMBLE X))  is a macro definition,
	then (DEFUN FOO MACRO (X) (DISPLACE X (MUMBLE X)))  will cause
	the macro call to be displaced by its code after the first
	expansion.

You have been using DISPLACE for the wrong purpose.  You've already lost this
battle; it already turns (DISPLACE X 'Y) into a (PROGN Y).  I think your
arguement has degenerated into (unintentional) obstructionism.  Call your
function something else, and let us make DISPLACE more useful for it's intended
purpose.  Sorry, charley, I think the rest of the world has already gobbled
that name for another purpose.

Date: 20 March 1980 07:39-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: DISPLACE
To: KMP at MIT-MC
cc: BUG-LISP at MIT-MC, NIL at MIT-MC

You have got to be kidding.

Do you really use DISPLACE in situations where you could just as well
say RPLACA and RPLACD?  What possible reason could there be for adding
a DISPLACE to maclisp that had this simple definition?  As I
understand it, the reason DISPLACE was added in the first place was to
factor out of all the displacing macros in the world the common final
step they ALL HAD to do.  I thought the definition of DISPLACE was
sufficiently bizarre that no one could ever make the mistake of
considering it for use other than in a displacing macro.

I would argue that you have been misusing DISPLACE, and we should be
allowed to make this change even if it breaks some of your code.

Date: 20 March 1980 06:58-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  DISPLACE
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, NIL at MIT-MC

    Date: 18 March 1980 23:10-EST
    From: Alan Bawden <ALAN at MIT-MC>
    To:   JONL, REES
    cc:   BUG-LISP
    Re:   DISPLACEing macros and purified code.

    Is there any reason that the function DISPLACE couldn't check the
    purity of its first argument and NOT displace if it is pure?? (Simply
    return the second argument.)

    I realize that this makes the contract of DISPLACE even more unusual
    than it is (I seem to remember resistence to the PROGN hack for this
    reason) but after all the whole point of DISPLACE is that it should be
    the correct function to call to do "what you always want a displacing
    macro to do"...
----
No, it's not. I disagree strongly with what's been done to DISPLACE and what 
you're trying to further. Please choose another name for the thing 
you're trying to  evolve...

I have code all over that uses DISPLACE according to its originally defined
meaning which was simply a short form of RPLACA/RPLACD pair ... Such code
is probably sufficiently debugged that your change won't hurt me, but I think
the whole philosophy is wrong. There needs to be a general-purpose thing
which errs out on atoms and pure stuff and only works on lists. Common names
should be used for very general operations -- if you want make DISPLACE hairy, 
give it a hairy name -- like MACRO-DISPLACE. The name displace should be used
for the very simple concept.

As nice as it is to have things that operate in a 'generic' way,
accepting tons of different args and dispatching appropriately, don't think
people can't still be screwed by it. Teco is a good example -- things can be
hard to debug because the error you die on may not be related to the error
you actually made if the system is too forgiving. If I try to DISPLACE pure
space or an atom, I want to know about it when it happens. Not an hour later
when I find that something I thought I'd displaced wasn't really displaced.
In the special case that I am MACRO-DISPLACE'ing, maybe I don't really care
because I know that it don't make any difference functionally if the DISPLACE
happens or not ... but that's a much different functionality.

Date: 19 MAR 1980 0424-EST
From: JONL at MIT-MC (Jon L White)
Subject: correction to TTY processing note
To: ben at MIT-ML
CC: (BUG LISP) at MIT-MC

The note which I just sent you suggested opening the TTY, in order
to do more clever output, by a line like
    (OPEN '((TTY) FOO BAR) '(OUT IMAGE SINGLE))
this should have been
    (OPEN '((TTY) FOO BAR) '(OUT IMAGE TTY))

Date: 19 MAR 1980 0411-EST
From: JONL at MIT-MC (Jon L White)
To: ben at MIT-ML
CC: (BUG LISP) at MIT-MC

    BEN@MIT-ML 03/14/80 17:14:29
    To: (BUG LISP) at MIT-ML
    On the TOPS-10 at Tufts.
    1.  (getchar 'foo 0) appears to loop, rather than return NIL
    as advertised.  Similarly for negative args.  Too-large args
    work correctly, return NIL.
I've just corrected this in the source, although the "wheels"
have already been set into motion to send out maclisp tapes
(Ty Sealy is doing it) and you probably won't have this update,
unless (horrors!) the mailing is held up so long that the new
system is installed around before then.
    2.  Is there any way to get decent rubout processing?  TOPS-10
    will let me handle my terminal i/o reasonably enough to do rubouts
    correctly in the monitor and several programs, but not in LISP.
    (I have a Teleray 1061.)
Well, I don't think there is much maclisp can do by itsels - some
people have been writing packages with special knowledge about
terminals, and using a file object created by
(OPEN '((TTY) FOO BAR) '(OUT IMAGE SINGLE))
which is supposed to allow you to do output in "raw" mode
(for TOPS-10, this uses IONEOU).  You might want to correspond
with FAHLMAN@CMUA on this point to see what's new there.

Date: 18 March 1980 23:10-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject: DISPLACEing macros and purified code.
To: JONL at MIT-MC, REES at MIT-MC
cc: BUG-LISP at MIT-MC


Is there any reason that the function DISPLACE couldn't check the
purity of its first argument and NOT displace if it is pure?? (Simply
return the second argument.)

I realize that this makes the contract of DISPLACE even more unusual
than it is (I seem to remember resistence to the PROGN hack for this
reason) but after all the whole point of DISPLACE is that it should be
the correct function to call to do "what you always want a displacing
macro to do"...

Date: 18 MAR 1980 2202-EST
From: JONL at MIT-MC (Jon L White)
Subject: MACRO-EXPANSION-USE, in COMPLR
To: REES at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 16 March 1980 14:04-EST
    From: Jonathan A. Rees <REES at MIT-MC>
    Subject:  Purcopied code which needs to macroexpand
       Some macros like FBOUNDP that are defined using DEFBOTHMACRO can't
    be called inside the compiler, because they consist of pure EXPR code
    which hasn't been MACRO-EXPANDed.  When a macro inside this code goes
    to displace the call it tries to write on a pure page.  Seems to me
    that this is a bug in the DEFMACRO package (it should be more careful
    when displacing - this is difficult since we lack a PUREP predicate),
    although it could also be argued that either COMPLR (who is guilty of
    PURCOPYing EXPR code) or DEFBOTHMACRO (who arranges to avoid the
    MACRO-EXPANDsion) is at fault.  I currently get around this by doing
    (setq defmacro-displace-call 'macromemo), which I suppose is alright.
Setting "defmacro-displace-call" affects the compilation of the macros - 
you really want to affect the runtime environment.  Any facility which 
PURCOPYs code likely to contain macros should ascertain that 
MACRO-EXPANSION-USE is also set to either () or MACROMEMO.  By the bye,
there are only two states of  "defmacro-displace-call" - () and non-().

Date: 18 MAR 1980 1521-EST
From: EJS at MIT-MC (Eric J. Swenson)
To: (BUG LISP) at MIT-MC


How about making LOAD and other namelist hacking functions accept strings
as arguments.  For example:  (load "foo;bar baz").  This would be logical 
and compatible with Multics MACLISP.  

Date: 18 MAR 1980 0928-EST
From: PRATT at MIT-MC (Vaughan Pratt)
To: (BUG LISP) at MIT-MC

Is grindef supposed to work correctly in conjunction with the standard more-
processing?  It seems like it gets confused about whether an s-expression
will fit on the current line when that line follows ##MORE##.

Date: 16 MAR 1980 1404-EST
From: REES at MIT-MC (Jonathan A. Rees)
Subject:  Purcopied code which needs to macroexpand
To: (BUG LISP) at MIT-MC

   Some macros like FBOUNDP that are defined using DEFBOTHMACRO can't
be called inside the compiler, because they consist of pure EXPR code
which hasn't been MACRO-EXPANDed.  When a macro inside this code goes
to displace the call it tries to write on a pure page.  Seems to me
that this is a bug in the DEFMACRO package (it should be more careful
when displacing - this is difficult since we lack a PUREP predicate),
although it could also be argued that either COMPLR (who is guilty of
PURCOPYing EXPR code) or DEFBOTHMACRO (who arranges to avoid the
MACRO-EXPANDsion) is at fault.  I currently get around this by doing
(setq defmacro-displace-call 'macromemo), which I suppose is alright.
   (For all you people out there who wonder what DEFBOTHMACRO is,
don't ask.  It's a feeble Maclisp trick, in search of a better name,
that tries to be similar to the Lisp machine's DEFSUBST.)

Date: 16 MAR 1980 1209-EST
From: REES at MIT-MC (Jonathan A. Rees)
Subject:  DEFVST
To: EB at MIT-AI
CC: (BUG LISP) at MIT-MC


I found out why you're losing.  You're generating a LAP file.  If you
compile without making a LAP file, you'll win.  This is because DEFVST
puts hunks in the eval-mungeables which are destined for the FASL
file, and nobody ever went to the trouble of making LAP understand
HUNKs.  When I compiled your file TEST 10, even on AI which has the
not-quite-up-to-date version of DEFVST, I had no problem with 
(STRUCT-TYPEP (FOO)).

Date: 15 March 1980 18:41-EST
From: Mark L. Miller <MILLER at MIT-AI>
Subject: TTY Handling on Twenex
To: BUG-EMACS at MIT-AI, BUG-Lisp at MIT-MC, MACRAKIS at USC-ISIE

If that is feasible, I'd love to get a copy!  -- Mark


EB@MIT-AI (Sent by WELG@MIT-AI) 03/15/80 17:44:47 Re: DEFVST
To: REES at MIT-MC
CC: (BUG Lisp) at MIT-MC
    Date: 15 March 1980 07:36-EST
    From: Jonathan A. Rees <REES at MIT-MC>

        Date: 14 March 1980 23:37-EST
        From: Edward Barton <EB at MIT-AI>
        Re:   DEFVST
	...
    What you want to say is not (eval-when (compile) (defvst ...)), but
    simply (defvst ...), at top level in your file.
    ...
    Use an incantation such as
      (eval-when (eval load compile)
        (cond ((status nofeature DEFVST) (load '((lisp) defvst))))) 
  
     ... if you mean that you don't want the macros cons-a-barf, barf-a, etc.
    to get output to the FASL file, just do
      (eval-when (compile)
        (setq defmacro-for-compiling () defmacro-displace-call ()))
    before the top level occurrence of defvst (but if you have other DEFMACROs
    you do want compiled, be sure to reset these magic variables to T).

Consider the following file:

(eval-when (eval compile load)
  (or (status feature defvst)
      (load '((lisp) defvst))))

(eval-when (compile)
    (setq defmacro-for-compiling nil defmacro-displace-call nil))

(defvst barf a b c)

(eval-when (compile)
    (setq defmacro-for-compiling t defmacro-displace-call t))

(defun foo ()
  (cons-a-barf a 1 b 2 c 3))

When FOO is loaded compiled, (struct-typep (foo)) is NIL.  Naturally this
causes foo-manipulating functions to lose.  Why does this happen?



Date: 15 MAR 1980 1449-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: GETSYNTAX
To: (BUG LISP) at MIT-MC
CC: ALAN at MIT-MC

A GETSYNTAX function can be found in HMR;GETSYN >
It only works compiled...

Date: 15 March 1980 07:36-EST
From: Jonathan A. Rees <REES at MIT-MC>
Subject:  DEFVST
To: EB at MIT-AI
cc: BUG-LISP at MIT-AI

    Date: 14 March 1980 23:37-EST
    From: Edward Barton <EB at MIT-AI>
    To:   BUG-LISP at MIT-AI
    Re:   DEFVST

    What is the proper way to make DEFVST constructions intelligible
    to the compiler but unavailable at runtime?
       (eval-when (compile) (defvst barf a b c))
       (defun foo () (cons-a-barf a 1 b 2 c 3))
    seems reasonable, but this causes the result of (FOO) to produce
    a hunk whose struct-typep is nil and which contains "UNBOUND"
    for at least one component. 

What you want to say is not (eval-when (compile) (defvst ...)), but
simply (defvst ...), at top level in your file.  This will make sure
that the information that struct-typep wants to look at is available
at runtime, and should fix the problem of whatever it was being
UNBOUND.  I notice that since you use struct-typep, you need to have
DEFVST around at runtime; you might make sure it's loaded before your
defvst is encountered by the loader.  Use an incantation such as
  (eval-when (eval load compile)
    (cond ((status nofeature DEFVST) (load '((lisp) defvst))))) 
instead of letting struct-typep autoload, if that's what you're doing.

I'm not sure what you mean by 'DEFVST constructions', but
if you mean that you don't want the macros cons-a-barf, barf-a, etc.
to get output to the FASL file, just do
  (eval-when (compile)
    (setq defmacro-for-compiling () defmacro-displace-call ()))
before the top level occurrence of defvst (but if you have other DEFMACROs
you do want compiled, be sure to reset these magic variables to T).  (Too
bad the Maclisp compiler doesn't have COMPILER-LET, which would be the
right way to bind those flags!)



Date: 14 March 1980 23:37-EST
From: Edward Barton <EB at MIT-AI>
Subject: DEFVST
To: BUG-LISP at MIT-AI

What is the proper way to make DEFVST constructions intelligible
to the compiler but unavailable at runtime?

(eval-when (compile)
  (defvst barf a b c))

(defun foo () (cons-a-barf a 1 b 2 c 3))

seems reasonable, but this causes the result of (FOO) to produce
a hunk whose struct-typep is nil and which contains "UNBOUND"
for at least one component.  (where FOO is loaded compiled)


BEN@MIT-ML 03/14/80 17:14:29
To: (BUG LISP) at MIT-ML
On the TOPS-10 at Tufts.

1.  (getchar 'foo 0) appears to loop, rather than return NIL
as advertised.  Similarly for negative args.  Too-large args
work correctly, return NIL.

2.  Is there any way to get decent rubout processing?  TOPS-10
will let me handle my terminal i/o reasonably enough to do rubouts
correctly in the monitor and several programs, but not in LISP.
(I have a Teleray 1061.)

Thanks.
				Ben


Date: Friday, 14 March 1980  11:15-PST
From: MACRAKIS at USC-ISIE
To: Bug-Lisp at MC, Bug-Emacs at AI
Subject: TTY Handling on Twenex

Is there any chance that the part of Emacs/Teco that handles display terminals
on Twenex can be incorporated into Twenex Lisp as the TTY output routine or at
least as ONE TTY output routine?

Date: 14 March 1980 08:09-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: Image tty output
To: MILLER at MIT-AI
cc: BUG-LISP at MIT-AI

As near as I can tell from the code, LISP is trying very hard
to make (OPEN 'TTY: '(TTY IMAGE OUT)) actually output only
the characters you TYO, which is what I thought it did.
There are explicit checks not to auto-terpri etc. on an
image-mode tty.  Now maybe the code is broken, but that is what
it is supposed to do.


Date: 14 MAR 1980 0546-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(DEFUN G (X) (LIST (CXR X 2.) (CXR 2. X)))

The compiler does not diagnose this as an error. Arg order is, I suspect,
one of the most common errors when dealing with CXR's, and having it flag
this trouble at compile time would be a win if not too hard. (CAR 2.) and
(CDR 2.) already generate useful diagnostics.

Date: 14 MAR 1980 0541-EST
From: REES at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC
CC: EB at MIT-AI


A minimal function which produces EB's bug is as follows:

(DEFUN LOSS (X)
  (LIST (CXR 2 X)
	(CXR 3 X)
	(CXR 4 X)
	(CXR 5 X)
	(CXR 6 X)
	(CXR 7 X)))

Evidently the compiler's particular strategy for compiling CXRs commits
it to eating up registers.

EB@MIT-AI 03/14/80 04:32:24 Re: Compiler Error
To: (BUG Lisp) at MIT-MC
Could someone please fix this?


AI ITS.1168. DDT.1388.
TTY 43
11. Lusers, Fair Share = 73%
1. memory errors in 17.7 hours.
EB$0U EB0$U--Mail--:Postponed
*GAG 0
*:QC

LISP COMPILER 907 [by 906, in LISP 1914]
_TEST

(COMMENT **ERROR**  NIL No free acs - FREEREGAC in function FILE-INFO)
;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% 
;BKPT BARF
47041)   XCT 11   :PRINT EB;DSK:TEST >

(eval-when (eval compile)
   (load '((liblsp) for))
   (setsyntax '/# 'splicing '+internal-/#-macro))

(eval-when (eval compile)
   (defvst file-block
           filepos
           dir-block
           name
           ext
           version
           d-namestring
           d-its-credate
           d-its-credate-atom
           source-namestring
           source-its-credate
           source-credate-atom
           source-num-words
           full-dump-tape-num ; or NIL
           private-tape-block
           last-retrieval-request
           last-retrieval-request-atom
           pending-status ; NIL, (RETRIEVE-AS namestring), (DUMP-ON tape-bloc!
k),
                          ; (DUMP-ON FULL-DUMP)
           valid
             ))

(defmacro concat (x y) `(implode (append (explode ,x)(explode ,y))))

(eval-when (eval compile load)
   (setq file-info-format '(filepos dir-block name ext version d-namestring d!
-its-credate
                                   d-its-credate-atom source-namestring
                                   source-its-credate source-credate-atom
                                   source-num-words full-dump-tape-num
                                   private-tape-block last-retrieval-request
                                   last-retrieval-request-atom
                                   pending-status valid)))

(defun file-info (fb)
   #.`(list
       ,@ (for field in file-info-format
           collect (list (concat 'file-block- field) 'fb))))

*$$0U
AI ITS 1168  Console 43 Free. 04:29:34


Date: 13 MAR 1980 2155-EST
From: GZ at MIT-MC (Gail Zacharias)
Subject: Rawtyo and cursorpos
To: JONL at MIT-MC, MILLER at MIT-AI
CC: (BUG LISP) at MIT-MC

Not only is cursorpos not always sufficient, it is often unreliable.
For example, contrary to its documentation, (cursorpos 'b) when in column
0 will *NOT* just wrap around to the right margin but move up one line also,
at least on a Teleray.  Same for 'x. (I would assume that accounts for the
rubout-past-continuation-line bug in lisp read functions).  Additionally,
when the previous line was a continuation line ("!" in last column), 
(cursorpos 'b) seems to sometimes move past the !, sometimes not, sometimes
not move at all.  Basically at this point I don't trust (cursorpos) to
do anything for me in the borders of the screen (first/last line/column).

gls@MIT-AI (Sent by ___047@MIT-AI) 03/13/80 07:36:05 Re: RAWTYO, etc.
To: MILLER at MIT-AI
CC: (BUG lisp) at MIT-MC
Why doesn't (OPEN 'TTY: '(OUT IMAGE)) do what you want?


Date: 13 March 1980 07:22-EST
From: Mark L. Miller <MILLER at MIT-AI>
To: MILLER at MIT-AI, JONL at MIT-MC
cc: BUG-LISP at MIT-AI

Dear Jonl,
I have been trying to understand your reply to my msg ...

    Date: 9 JAN 1980 2128-EST
    From: JONL at MIT-MC (Jon L White)

        MILLER@MIT-AI 01/09/80 07:36:28 Re:  SUPER-IMAGE Output
    	There ought to be a way to OPEN a TTY file in "SUPER-IMAGE" mode, or a
        builtin "RAWTYO" function.  These would, on ITS, prefix any special
        characters with a control-P...

    I believe that the idea of the CURSORPOS function was to abstract out the
    various "terminal hacking stuff", and refer to them as symbolic arguments
    (or numeric positions) to CURSORPOS.  Indeed, the maclisp implementation 
    of CURSORPOS does the appropriate "lock-out" so that control-p codes are
    not separated from the preceeding control-P.  Shouldn't you do that too?
    namely, just add to the code for CURSORPOS in the midas listing?

I am not sure if I am misunderstanding your point, but it seems like you are
oversimplifying the problem here.  The user of LISP ought to be able -- when
necessary -- to do anything he could do from MIDAS, directly from LISP.  For
example, send strange escape codes if he knows what he is doing.  It is just
not possible for the clever author of CURSORPOS to anticipate all possible
cases and make them totally device independent.  Consider the case of what I
was actually doing: driving a printer from the auxiliary port of a CRT where
both the printer and the CRT were variable entities and where different
instantiations required different protocols.  You might add a (cursorpos 'aux)
feature, say, but then what about a terminal like a C100 which can have
many devices strung off of it on DIFFERENT aux ports?  Striving for generality
and terminal independence is nice, but sometimes you have to be allowed to
get a bit crufty to get the job done...           Regards, Mark


Date: 12 MAR 1980 2351-EST
From: HMR at MIT-MC (Harry M. Rath)
Subject: LISPT, CHNTB, LDDT, SYMBOLS, AND SCREWAGE
To: (BUG LISP) at MIT-MC, RLB at MIT-MC, JLK at MIT-MC

Ah, I've found what was causeing all my lossage, I think.
Loading LDDT without symbols is a screw.  J*STADR and friends
do not get defined, being GETDDTSYM'd values which are passed to
(STORE (ARRAYCALL FIXNUM JOB J*STADR) ..) and such.  This is certainly
what was causing the job interrupt handler to be clobbered with 4000
(and later .ATOM CRLF), and quite likely it was also causing the array
to get clobbered just enough to cause the channel to not get deallocated
by the GC.  Probably this has been the source of all my bugs.

I added the syms J.STADR and J.CRUFT to XTRSYMS, but in the meantime maybe
LDDT should explicitly load symbols if needed?

Date: 12 March 1980 12:05-EST
From: "Guy L. Steele, Jr." <GLS at MIT-MC>
Subject: Inconsistent and UnInformative Error Messages
To: KMP at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC
cc: TEACH at MIT-MC

    Date: 11 MAR 1980 0221-EST
    From: KMP,ALAN at MIT-MC
    Sent-by: ___023 at MIT-MC

    ((LAMBDA (X Y) (+ X Y)) 1 . 2)
    ;((? 1 NIL NIL) (X Y)) TOO MANY ARGUMENTS SUPPLIED - APPLY

    ((LAMBDA (X Y) (+ X Y)) 2 . 3)
    ;#201300 UNEVALUABLE DATUM - EVAL

    ((LAMBDA (X Y) (+ X Y)) 3 . 4)
    ;LAMBDA UNDEFINED FUNCTION OBJECT

    ((LAMBDA (X Y) (+ X Y)) 4 . 5)
    ;((? 4 NIL NIL) (X Y)) TOO MANY ARGUMENTS SUPPLIED - APPLY

    ((LAMBDA (X Y) (+ X Y)) 5 . 6)
    ;((? 5 NIL NIL) (X Y)) TOO MANY ARGUMENTS SUPPLIED - APPLY

    (QUIT)
    :KILL

    : We suspect that this generalizes. Perhaps a bit of error checking on
      the poor little actual args list would be in order? This bug was
      uncovered by some poor guy in :TEACH;LISP who had just figured out
      why (LAMBDA (X) X) didn't work and had FINALLY figured out that
      ((LAMBDA (X) ...) ...) was the thing to do in order to suppress the
      LAMBDA UNDEFINED FUNCTION message ... almost. Sigh. 

Of course, this happens because the interpreter is just doing a NULL
check instead of an ATOM check when cdr'ing the argument list.  Hence
it cdr's through the number and into some accumulator, and different
accumulators contain diferrent interesting junk.

Date: 11 MAR 1980 0652-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: GJC at MIT-MC, JPG at MIT-MC

Forwarded to you in case you are interested:
GJC@MIT-MC 03/10/80 17:23:56
I was loading TRACE in macsyma, and ddt took the tty to display
a message. the macsyma got wedged. could not p
PURGP;(ATTY;) 66563>>MOVEM ....
it did g

Date: 11 MAR 1980 0221-EST
From: KMP,ALAN at MIT-MC
Sent-by: ___023 at MIT-MC
Subject: Inconsistent and UnInformative Error Messages
To: (BUG LISP) at MIT-MC
CC: TEACH at MIT-MC

((LAMBDA (X Y) (+ X Y)) 1 . 2)
;((? 1 NIL NIL) (X Y)) TOO MANY ARGUMENTS SUPPLIED - APPLY

((LAMBDA (X Y) (+ X Y)) 2 . 3)
;#201300 UNEVALUABLE DATUM - EVAL

((LAMBDA (X Y) (+ X Y)) 3 . 4)
;LAMBDA UNDEFINED FUNCTION OBJECT

((LAMBDA (X Y) (+ X Y)) 4 . 5)
;((? 4 NIL NIL) (X Y)) TOO MANY ARGUMENTS SUPPLIED - APPLY

((LAMBDA (X Y) (+ X Y)) 5 . 6)
;((? 5 NIL NIL) (X Y)) TOO MANY ARGUMENTS SUPPLIED - APPLY

(QUIT)
:KILL

: We suspect that this generalizes. Perhaps a bit of error checking on
  the poor little actual args list would be in order? This bug was
  uncovered by some poor guy in :TEACH;LISP who had just figured out
  why (LAMBDA (X) X) didn't work and had FINALLY figured out that
  ((LAMBDA (X) ...) ...) was the thing to do in order to suppress the
  LAMBDA UNDEFINED FUNCTION message ... almost. Sigh. 


Date: 10 MAR 1980 0559-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: For your convenience...
To: JONL at MIT-MC
CC: NIL at MIT-MC, (BUG LISP) at MIT-MC

I note an awful lot of your code uses these cute little
|+internal-something-or-other/|| things with mixed case to
keep people from typing them accidentally. needless to say,
this makes typing them in rough when you really do want them.

Hence, I have *the answer* ... for only 50cents and 2 boxtops,
you too can use kmp's emacs CASE? library. Merely do 
MM Load LibraryKP;CASE?
on mc and you'll get this neat definition for / which peeks for
a | and if it finds one immediately following it, will mung the
case of the previous atom in some uniquely determined way for
that given atom... eg, typing

+internal-foo-macro/|

will (at the time you type the /|) result in ...

|+iNtERnal-fOO-mACRo/||

Without any extra effort, you will have generated a fine unique atom.
This special offer is available for a limited time only, so hurry --
get yours today...

			-kmp

BYRON@MIT-ML 03/09/80 22:25:48 Re: DESETQ
To: (BUG LISP) at MIT-ML
The documentation for DESETQ in LISP NEWS doesn't say much about the
value returned by it.  Currently it seems to return the value
of the "rightmost" variable being setq'ed.  I suggest that it might
actually be useful to return the value of the undestructured
expression, which wouldn't otherwise be available without
explicitly using a temporary variable.


Date:  9 MAR 1980 0721-EST
From: HMR at MIT-MC (Harry M. Rath)
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

Fixed, and patched on ITS.

GSB@MIT-ML 03/09/80 07:00:56 Re: in XLISP
To: (BUG LISP) at MIT-ML
Flatc is broken.  (Flatc 1) loops infinitly, apparently thinking it
is cdring down something.


GSB@MIT-ML 03/07/80 12:41:10
To: (BUG LISP) at MIT-ML
My tty prescan doesn't work with READLINE.  It gets in an infinite loop
in NCONC, called from RDA4.  Apparently LPNF has an illegal value
such that it is nconcing a pname portion onto a pointer it only thinks
is on the stack (CPOPJ, hence infinite loop).  My guess is that someone
somewhere isn't saving LPNF, since the prescan has the property that
READLINE gets called when the prescan gets called to do a READLINE.
Supporting this is the evidence that patching the prescan routine
to save and restore LPNF causes the lossage to go away.


GSB@MIT-ML 03/07/80 10:06:34 Re: tty prescan
To: (BUG LISP) at MIT-ML
If the tty prescan gets called a second time within the same read,
the car of BFPRDP does not contain the atom READ, but rather some
garbage, and this piece of randomness gets passed in to the ttyscan.
  ----
I don't know if this will work for the system supplied ttyscan (probably
not because internal crocks), but possibly the "hook" that calls it
could work with read & readline and have a flag that says it hasn't
been called yet, and if that flag is set, not use the buffered back
characters before callinng it.  This would alleviate the (tyipeek) (read)
problem, which causes the first to manifest itself (eg, input like
"t(foo)").
----
On the same line, probably the "toplevel-read" routine should, before
doing a (tyipeek) to see if there is a break character, do a LISTEN
on TYI (only, of course, if INFILE and ^Q indicate that input at that
point should come from there).


Date:  6 MAR 1980 0209-EST
From: JONL at MIT-MC (Jon L White)
To: KMP at MIT-MC, LSH at MIT-MC
CC: (BUG LISP) at MIT-MC

Sad to say, one of these is the "FILESYSTEM-TYPE" and the other
is the "OPSYSTEM-TYPE".  When all traces of code which depend upon
the next-to-last thing of the features list being something particular,
then these two status calls can have their data word removed from
the features list.  Well, maybe (STATUS FILESYSTEM-TYPE) at least
can be removed.

Date:  6 MAR 1980 0206-EST
From: KMP,LSH at MIT-MC
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC

(STATUS FEATURE) in a bare Lisp 1914 on MC returns a list that has ITS 
mentioned twice.

Date:  5 March 1980 14:30-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject:  PUT/GET
To: NIL at MIT-MC
cc: BUG-LISP at MIT-MC

I also propose that GET be renamed *GET and GET be allowed an optional
extra argument which would specify the return value. eg,

                        *
		(GET sym  prop [ default ])

(*= Or appropriate surrogate such as CDR-able list...)

would return the sym's prop property or default if no such property existed.
The default default should still be () for compatibility AND because that's
an awfully reasonable thing to return most of the time anyway...

One might even want to allow a fourth argument (setp, default ()) which said 
whether or not to actually add DEFAULT as a property if it was unseen (saves
having to scan the plist later or having to do SETPLIST to get around it ...

Maybe there should be a *PUT which does a PUT without looking to see if the
property already exists -- just does the splice.

Given the proliferation of PUT/GET functionality, I think it's worthwhile
to at least examine some of the functionality we often try for and what we
have to do to get it ... A few more options, discretely located as defaultable
args, would not seem unreasonable. Comments?

-kmp

Date:  5 March 1980 08:54-EST
From: Mark L. Miller <MILLER at MIT-AI>
Subject: CAR and CDR
To: Dave.Touretzky at CMU-10A, RWK at MIT-MC
cc: KMP at MIT-MC, HIC at MIT-MC, BUG-LISP at MIT-MC


Of course, you could rename them to, e.g., "LHS" and "RHS" for "Left Hand
Side" and "Right Hand Side".  This would address the composition argument
in favor of CAR and CDR: CADR -> LRHS (left-hand-side of right-hand-side),
CDADADR -> RLRLRHS, and so on.   It's easy to provide these as macros.

Later, you can explain that the original names are CAR and CDR, and isn't
that silly, etc.
     Regards, Mark


Date:  5 March 1980 08:33-EST
From: Mark L. Miller <MILLER at MIT-AI>
Subject: PUT/GET
To: RWK at MIT-MC, NIL at MIT-MC, MULTICS-LISP-PEOPLE at MIT-MC,
    BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC

I vote "yes" for the proposal.  I am always having to explain to
new LISP-ers (e.g., my students) why there are so many exceptions and
inconsistencies.  Upward compatibility is nice and all that, but
maybe NIL is a good chance to clean up a lot of "historical" lossages...
  Regards, Mark


gls@MIT-AI (Sent by RICH@MIT-AI) 03/04/80 14:40:42 Re: (EXPT 2.0 -127.)
To: jpg at MIT-MC
CC: (BUG lisp) at MIT-MC
The reason it doesn't underflow is that it is representable!
Indeed, because the exponent is excess-128., the smallest
exponent represents a FSC-factor of 2^-128., and then
the mantissa is between 0.5 (incl) and 1.0 (excl).  Therefore
even (EXPT 2.0 -129.) is representable (and works).
(EXPT 2.0 -130.) is not representable, and underflows to 0.0
when ZUNDERFLOW is set.


Date:  4 March 1980 14:37-EST
From: "Guy L. Steele, Jr." <gls at MIT-AI>
Sender: RICH at MIT-AI
To: MOON at MIT-AI
cc: GLS at MIT-AI, BUG-DDT at MIT-AI, BUG-LISP at MIT-AI,
    BUG-ITS at MIT-AI, BUG-TECO at MIT-AI, BUG-EMACS at MIT-AI,
    BUG-LISPM at MIT-AI, cpr at MIT-MC

Last note from RICH was really from GLS.

Date:  4 March 1980 14:34-EST
From: Charles Rich <RICH at MIT-AI>
To: MOON at MIT-AI
cc: GLS at MIT-AI, BUG-DDT at MIT-AI, BUG-LISP at MIT-AI,
    BUG-ITS at MIT-AI, BUG-TECO at MIT-AI, BUG-EMACS at MIT-AI,
    BUG-LISPM at MIT-AI, CPR at MIT-MC

One obvious application of the Greek/Front key on the PDP-10
is that all such characters could be self-inserting in TEX format;
thus typing  would insert "\alpha", etc.  I don't know how much
more convenient this would make it to type weird formulas in TEX.


Date:  3 MAR 1980 2337-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Use of New Keyboards with ITS.
To: JLK at MIT-MC
CC: CPR at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG ITS) at MIT-MC, (BUG TECO) at MIT-MC

I don't think ITS is going to be able to accomodate all of the new
modifier bits.  There are no free bits in the present internal
(18-bit) character code.  I don't think making Greek input work
is very important, since we certainly aren't going to go to the
very large amount of trouble required to make Greek output work
and have a more-than-7-bit printing-character set.

It would be nice to make Super and Hyper work to ITS, although there
are not enough bits available.  Note that shift-lock has already been
recycled.  Shift is sort of recycled and sort of vestigially still
there; it could be recycled for this.  It isn't necessary to be able to
represent all 16 combinations of the "bucky bits"; for instance there
are 8 combinations of 0, 1, or 2-adjacent buckies.

Since the function keys are there, you may as well make up top+>40
codes for them.  Some of the function keys map into keys on the old
keyboard; see the #\ table in LMIO;READ for something from which this
mapping can be derived, as we are doing it on the Lisp machine now.
From memory, it's clear-screen->form, delete->vt, clear-input->clear,
macro->back-next (but should be system->backnext in your case), terminal->esc.

It's not obvious that new keyboards will ever be attached to the AI TVs.
We might, and we might not.  It would involve slowing down the keyboard
scanner substantially, and we might have to put some buffering in the
keyboard microprocessor.

Date:  3 March 1980 21:41-EST
From: John L. Kulp <JLK at MIT-MC>
Subject:  Use of New Keyboards with ITS.
To: MOON at MIT-MC
cc: CPR at MIT-MC, BUG-DDT at MIT-MC, BUG-LISP at MIT-MC,
    BUG-ITS at MIT-MC, BUG-TECO at MIT-MC

We are going to hook up a new kbd to the PTV system in the next few
days, and the obvious question comes up about how to encode all
the function keys.  I suppose they could be handled the way
they are on the old keyboard, namely send chars with the TOP bit +
100 + <code>.  In order to distinguish them from the old kbd,
how about encoding them in 140-177?  Presumably the extra modifier
bits (SUPER, HYPER, and GREEK) need to be allowed (that uses up
all the bits available in the intelligent terminal protocol, unless
we want to flush SHIFT and SHIFT-LOCK).  It doesn't much matter
what the encoding is, as long as its documented.  I guess any
part of the system which masks off the high modifier bits or
otherwise depends on them being zero will have to get looked at.

ITS presumably wants to know about the SYSTEM key (treat like BACK/NEXT).

Its about time DDT knew about CLEAR (or CLEAR INPUT on the new kbds) which
should behave like ^D.  Also, HELP, STOP OUTPUT (^S, actually this should
probably be defined to do an output hold at the terminal, followed by an
output reset from the remote process (as is currently done)), ABORT (^G), END
(^C), RESUME ($P), etc.

TELNET and SUPDUP should be informed about the NETWORK key.

Various programs should know about END, ABORT, RESUME, BREAK, QUOTE, HELP,
STATUS (I'm not saying every program in the world should be retrofitted
to know about these, but the basic ones -- DDT, TECO, LISP -- probably
should).

I suspect that not much is going to happen on this until AI TV's start
getting new keyboards, but I would at least like to see the encoding
defined now, so that where only simple changes are required, they
can be done quickly when desired.


Date:  3 MAR 1980 1604-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

I just fixed SUSPEND so as not to call CLOSE on the contents
of V%TYI and V%TYO if they are already closed.  A problme ensues
if for some reason the page with the CLOSE code onit has
already been flushed. (e.g., by interactions with the LISPT PATCH
kludge, which fiddles around with the page containing IFORCE,
which just happens to be the same page as CLOSE).

Date:  3 March 1980 07:44-EST
From: Robert W. Kerns <RWK at MIT-MC>
Subject: PUT/GET
To: NIL at MIT-MC, MULTICS-LISP-PEOPLE at MIT-MC, BUG-LISPM at MIT-MC,
    BUG-LISP at MIT-MC

I want to put (PUT <sym> <tag> <value>) like (PUTPROP <sym> <value> <tag>)
but with the args in the right order into LISP.  This makes
(SETF (GET ...) ...) easier to do right WRT order of evaluation, and
makes a lot more sense.  This is consistant with all the other ACCESS/STORE
frobs except for the other exceptions....

However, it may be argued that we should not usurp the name PUT from the
user, and that we shouldn't even be usurping GET.  Personally, I lean
somewhat to using the name PUT on the theory thta such widely used things
deserve to be short, but other suggestions for the name are PUT-PROP, with
GET-PROP also existing, equivalent to GET.  So I'm throwing it out here
so we can all agree on a name and be consistant with each other.
Comments?  Flames?

Date:  3 MAR 1980 0332-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

If (expt 3.0 -127) underflows to 0.0, why can't (expt 2.0 -127)?
It gives 5.87747175E-39 .

Date: 29 February 1980 22:22-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject: IOTA-ifying LOAD
To: BUG-LISP at MIT-MC
cc: RLB at MIT-MC, BGS at MIT-AI, SJOBRG at MIT-AI, GSB at MIT-ML

There was much confused mail on the subject, this is not really intended for
reply unless someone finds something erroneous -- mostly I am just summarizing
for the record...

(1) IOTA or its hand-written equivalent is the right thing for user code 
    to use in init files.

(2) Lisp LOAD does not correctly UNWIND-PROTECT loading. The following
    will hold the being-loaded file open...
    (1) Failure to return.
        A simple example -- if you define a DOCTOR program and then make
        the last form in the file be (DOCTOR), you'll lose until that call
        returns, you'll be holding the file open. The file doesn't close
        until Lisp tries to read for a next form and fails. Hence, even if
        all the useful text in a file has been read, it may not be that the
        whole file has been read. This is not a bug.
    (2) Unusual return from LOAD.
        ERROR's and THROW's which terminate a LOAD will also not cause a
        CLOSE to happen at the right time. This is a bug and should be
        fixed ... someday ... when one of us has the time ... but I agree
        it is really something which deserves being attended to at some 
        point.

-kmp

Date: 29 FEB 1980 2019-EST
From: RWK,KMP at MIT-MC
Sent-by: KMP at MIT-MC
Subject: READER, (TYIPEEK T)
To: (BUG LISP) at MIT-MC

The bugous behaviour of (TYIPEEK T) and splicing macros has been improved!
It no longer lets user code clobber AR2A (it's read table), by refetching
the readtable after the call (if somebody SETQ's READTABLE in a splicing
macro he'll now win (or lose, depending on your point of view)).  However,
(TYIPEEK T) will still lose, returning most likely a space.  Since it's
not possible to make this do the truely right thing, (since as I recall it's
described as returning the first meaningful character, and that turned out
to be that non-flushing splicing macro), I propose to not fix this.  I
only looked at it to fix ending up in the "nothing terminates" mode that
resulted when a random S-expression ended up in AR2A instead of the
readtable...

Date: 29 February 1980 10:42-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: FDEFINE
To: BUG-LISP at MIT-AI
cc: GLS at MIT-AI

I patched the source of FDEFINE in QMISC to fix my complaint;
it now uses CERROR, and if you return a value from the CERROR
it takes that as a new FUNCTION-SPEC to which to apply
the redefinition.



Date: 29 FEB 1980 0807-EST
From: JONL at MIT-MC (Jon L White)
Subject: Erroneous Report
To: (BUG LISP) at MIT-MC

    Date: 28 February 1980 09:13-EST
    From: Jon L White <JONL at MIT-MC>
    Subject: MAKHUNK, in lisp version 1978
    Apparently, if there is a pure-hunk area, and yuou (PURIFY 0 0 'BPORG)
    then after suspending and restarting, (MAKHUNK n) will cons up a 
    hunk off that pure page.
'Twas another problem - I misread a bit in the ST (segment table) into
thinking the hunnk was pure.

Date: 28 February 1980 10:35-EST
From: Charles Rich <RICH at MIT-AI>
Subject:  EVALHOOK and STORE
To: BUG-LISP at MIT-AI
cc: SJOBRG at MIT-AI

The interaction of EVALHOOK with the special way STORE
treats its first argument is still not quite right, which
causes STEP to blow up.  Let me first review the
fix that was made to EVALHOOK a year or so ago.

---------
When EVALHOOK was initially installed, evaluation
of the form

	(STORE (ARRAYCALL NIL A I) X)

caused the following sub-form to be
passed to the EVALHOOK function for evaluation:

	(ARRAYCALL NIL A I)

This of course caused an error because the relationship
between STORE and ARRAYCALL here is not really nested function
evaluation, but a special communication hack involving leaving
things in internal registers.

So, it was decided that the correct behavior of EVALHOOK
would be to treat STORE specially and pass only the forms "A" and "I" above to the
EVALHOOK function for evaluation.
----------

The related new problem which has come to my atttention now
is when a macro is used instead of ARRAYCALL above, such as
the following

	(DEFUN A MACRO (F)
		 (LIST 'ARRAYCALL NIL 'A (CADR F)))

Then calls to store look like:

	(STORE (A I) X)

In this case the sub-form 

	(A I)

is first passed to the EVALHOOK function for evaluation (which is correct,
since the macro has to get expanded).  The evaluation of this form
returns

	(ARRAYCALL NIL A I)

But at this point, the interpreter should recall that it is inside of
STORE and behave just as it did above, i.e. pass only "A" and "I" to
the EVALHOOK function for evaluation.  However, what is does now
is pass this whole form to be evaluated, which causes an error
for the reason explained above.

So I would appreciate if you would fix the interpreter so that it
watches out for this situation with STORE and does the right
thing.  I know this is a crock, but the root of the crock is
with STORE.

Thanks, Chuck Rich.

P.S. You might suggest the answer is to put code in STEP to treat
STORE specially, but this seems like the wrong modularity.
Furthermore, the current problem is really just an extension of the older
problem, which was solved by fixing EVALHOOK.

Date: 28 FEB 1980 0913-EST
From: JONL at MIT-MC (Jon L White)
Subject: MAKHUNK, in lisp version 1978
To: (BUG LISP) at MIT-MC

Apparently, if there is a pure-hunk area, and yuou (PURIFY 0 0 'BPORG)
then after suspending and restarting, (MAKHUNK n) will cons up a 
hunk off that pure page.

GSB@MIT-ML 02/28/80 04:03:36
To: KMP at MIT-MC, CWH at MIT-MC
CC: (BUG COMPLR) at MIT-MC, (BUG LISP) at MIT-MC
    Date: 28 FEB 1980 0255-EST
    From: KMP at MIT-MC (Kent M. Pitman)
    If you are convinced you want to bypass error handlers, use ^G instead
    of ERROR to signal a totally fatal lossage and make things bomb out to
    lisp toplevel. QUIT is also a winning function for this.
    -kmp
I presume that this is in reply to the complaint about the behaviour of
(EVAL-WHEN (COMPILE) (ERROR '|FOO|)).  Using ^G, or even worse (QUIT)
to give an error is about the worst choice you can make.  If you want
errors to abort a compilation, there is the QUIT-ON-ERROR flag.  Even
if the user doesn't specify that as an option, knowledgable macros or
systems can set it on him if they think that the error would screw
him to the wall.


Date: 28 FEB 1980 0255-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

If you are convinced you want to bypass error handlers, use ^G instead
of ERROR to signal a totally fatal lossage and make things bomb out to
lisp toplevel. QUIT is also a winning function for this.
-kmp

Date: 28 FEB 1980 0105-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

How about putting FIRSTN into Maclisp?  Its defined in Macsyma, so don't worry
about making it autoloadable.

Date: 28 February 1980 00:41-EST
From: Alan Bawden <ALAN at MIT-MC>
To: GZ at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 28 FEB 1980 0034-EST
    From: GZ at MIT-MC (Gail Zacharias)

    (setq x (quote #'foo)) ---> ((function foo))
    I thought it was supposed to return (function foo).  ??.

I'll bet you did a (setsyntax '/# 'macro '+internal-/#-macro) instead
of a (setsyntax '/# 'splicing '+internal-/#-macro), right?

Date: 28 FEB 1980 0034-EST
From: GZ at MIT-MC (Gail Zacharias)
To: (BUG LISP) at MIT-MC

(setq x (quote #'foo)) ---> ((function foo))
I thought it was supposed to return (function foo).  ??.

Date: 27 FEB 1980 2229-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

When compiling a file via :CL <file>, and the file contains the form

(EVAL-WHEN (COMPILE) (ERROR '|foo|))

the error message goes to the unfasl file and the compiler goes on to finish
compiling the rest of the file, thus clobbering the previous fasl file and
giving no sign that anything went wrong except for the message in the unfasl
file.  It should stop the job instead.

Date: 27 FEB 1980 1459-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

I am going to make a maclisp tops-20 tape
tonight.  Anything I need to know?

Date: 27 February 1980 10:54-EST
From: Richard L. Bryan <RLB at MIT-MC>
Subject: Inits opening stuff
To: BUG-LISP at MIT-MC
cc: KMP at MIT-MC, BGS at MIT-AI, SJOBRG at MIT-AI, GSB at MIT-AI

    Date: 27 February 1980 08:23-EST
    From: Brian G. Schunck <BGS at MIT-AI>
    ...
    That's okay for init files, but what about general loads?
    The problem yesterday was caused by a user doing
      (LOAD '((DSK FOO) JUNK DATA))
    several times until he got his small, trivial file of test
    data setup correctly for his application.  The LOAD never
    did a CLOSE after reading in the file, and the computation
    never got anywhere close to doing a GC, which would have
    forced closing. ...

It seems clear that LOAD should have no use for its channel after it exits.
Error breaks, *RSET traps, etc., due to the LOAD should have INFILE available,
but that's all still within the context of the LOAD.  Hence, the LOAD 
internals should be "in" an UNWIND-PROTECT-like "construct" to make sure
LOAD's channel got closed.  See KMP's IOTA.
   If the luser insists on reLOADing from inside his error breaks, there's
little that can be done about it, but in the common (^G) case, this would
fix it.
   An alternative, but harder to implement, way would be for gc to treat a
"space" of I/O channels sort of the way it treats list space, etc., with
respect to gcmin/gcmax.  If no ALLOC for IOCHAN space were done to increase
the number of chans avbl past an initial default (3 tty + 2 dsk?) then 
GC-OVERFLOW would run on IOCHAN space ...

JONL@MIT-ML 02/27/80 07:43:27 Re: PURQIX files on LISP;
To: GSB at MIT-ML
CC: (BUG LISP) at MIT-ML
    GSB@MIT-ML 02/27/80 03:38:11
    whoever installs the PURQIX files on LISP; should clean up unneeded
    ones.  I would think that no more than one would be necessary.
I've been guilty of :INSTALLing some xlisp's and not reaping AI and ML.
On MC, we *do* need, at least temporarily (for a day or two) multiple
copies, while latent features are being discovered, but on AI and ML,
only one copy should be free from the clutches of the "Instant Reaper".


Date: 27 February 1980 08:23-EST
From: Brian G. Schunck <BGS at MIT-AI>
Subject: Inits opening stuff
To: kmp at MIT-MC
cc: SJOBRG at MIT-AI, GSB at MIT-AI, BUG-LISP at MIT-AI

    kmp@MIT-MC (Sent by ___045@MIT-MC) 02/26/80 17:03:20 Re: Inits opening stuff
    GSB gave me the magic incantation:
     (CLOSE (PROG1 INFILE (INPUSH -1)))
    to solve the problem.

That's okay for init files, but what about general loads?
The problem yesterday was caused by a user doing
  (LOAD '((DSK FOO) JUNK DATA))
several times until he got his small, trivial file of test
data setup correctly for his application.  The LOAD never
did a CLOSE after reading in the file, and the computation
never got anywhere close to doing a GC, which would have
forced closing.  And the result of this was that the system
got more hopelessly wedged than I have ever seen it get!!!


Date: 27 FEB 1980 0443-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC, GLS at MIT-MC

I am temporarily de-installing the new LET and CASEQ grind properties until
I get the latest round of 'misfeatures' worked out ... Grind.441 has this
(un)fix.
-kmp

GSB@MIT-ML 02/27/80 03:38:11
To: (BUG LISP) at MIT-ML
whoever installs the PURQIX files on LISP; should clean up unneeded
ones.  I would think that no more than one would be necessary.


Date: 26 FEB 1980 1936-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: GRINDEF
To: GLS at MIT-AI
CC: (BUG LISP) at MIT-MC

Sorry, GLS, that's sorta my bug. On the basis of some wrong assumptions about
what a poorly documented grinder (Grindef) did with certain arguments to one
of its functions, I constructed a [not really] 'better' grinding form for it.
I recognized the bug the other day but have not been able to decipher the code
enough to know what the right thing is -- so far I only know why what's there
loses. Perhaps in the meantime I will de-install the LET grindfn's ... Plans
are being made for an all new pretty printer (again) ... NIL will need one
anyway, so it's probably the right time to go about it in a serious (and most
importantly -- documented) way. 
-kmp

Date: 26 February 1980 19:32-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Sender: GLS0 at MIT-AI
Subject: GRINDEF bites the bag on LET
To: BUG-LISP at MIT-AI
cc: GLS at MIT-AI

GIRINDEF seem to lose completely on LET-forms.  For example:


(DEFUN OPTIMIZE-0 (FUNCLIST TSTLIST) 
  (CONS (LIST 'DEFUN
	      (CAR (CAR FUNCLIST))
	      (CADR (CAR FUNCLIST))
	      (LET ((SEXPR-0 (LET ((BODY (CDDR (CAR FUNCLIST)))) (COND ((NULL (CDR BODY)) (CAR BODY)) (T (CONS '
														PROGN BODY)))))) 
		 (COND ((ATOM SEXPR-0) SEXPR-0) (T (EXPAND-0 SEXPR-0 TSTLIST NIL NIL)))))
	(COND ((NULL (CDR FUNCLIST)) NIL) (T (OPTIMIZE-0 (CDR FUNCLIST) TSTLIST)))))

Looking at the code, I notice that the bindings of LET are ground as a block.
The bug may be related to this.  In any case, I object loudly to this anyway.
If all the variables won't fit on one line, I want them all on separate
lines where I can see them by a simple vertical scan.  (Same goes for
arguments to functions, right?)


Date: 26 FEB 1980 1506-EST
From: JONL at MIT-MC (Jon L White)
Subject: "open" init files from LISP
To: sjobrg at MIT-AI
CC: (BUG LISP) at MIT-MC, bgs at MIT-AI

LOAD will normally cause a file to be closed, *** if *** it 
successfully reads to the end;  often a person's LISP.INIT file
will remain hanging open because there is no reason to read
the whole file.   The trick I use for init files is to
have the last form in the file be a PROG or something which
will among other things explicity close INFILE.   Generally
the need for such a "trick" is that the init file does some
kind of THROW out of the loop which is "loading" it.
But as for why this loser had lots of dsk channels open while
doing multiple LOADs, maybe each load manages to abort 
abnormally somehow?

Date: 26 February 1980 13:46-EST
From: Robert W. Sjoberg <sjobrg at MIT-AI>
Sender: HAASS at MIT-AI
To: BUG-LISP at MIT-AI
cc: BGS at MIT-AI

AI recently suffered a pretty severe slowdown (namely nothing
at all could be done concerning the disk, but everything else
was fine), which MMCM traced to all the disk channels being
eaten up.  There were about 12 of them devoted to a Lisp,
in which the user was only doing "(load '((...) foo >))" type
stuff, and each time another disk channel got eaten.  No
gc'ing was done between the loads.  Apparently, all these
files were still open.

I have often noticed that my Lisp INIT file will still be
open a couple of hours into my job.  Is this a "feature"
of loading?  Is there any reason why it can't close a file
once it's been read?

Comments appreciated.


Date: 26 FEB 1980 0327-EST
From: HMR at MIT-MC (Harry M. Rath)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

Do you think STRT should check for being passed a non-file-array, instead of
getting IOC errors and the like?

Date: 23 FEB 1980 0721-EST
From: REES at MIT-MC (Jonathan A. Rees)
Subject: DEFVST bug
To: EB at MIT-AI
CC: (BUG LISP) at MIT-MC

    Date: 23 February 1980 04:45-EST
    From: Edward Barton <EB at MIT-AI>
    ...

Problem fixed.

Date: 23 February 1980 04:45-EST
From: Edward Barton <EB at MIT-AI>
Subject: DEFVST
To: BUG-LISP at MIT-AI

Maybe someone can tell me what is wrong in the following example.
I can't seem to find it myself.

Let the file T1 contain the following:

(eval-when (eval compile)
   (or (status feature defvst)
       (load '((lisp)defvst))))

(defvst foo a b c)

(defun foo-1 ()
   (cons-a-foo))

Let the file T2 contain the following:

(defun foo-2 ()
   (cons-a-foo))


Suppose I compile T1 and load it into a LISP, then load T2
(source) into the same LISP.  FOO-1 will return a FOO, while
FOO-2 will load DEFVST and VSAID and give an error

;(FOO) defvst-construction|

,

(PLIST 'FOO) in that LISP reveals a STRUCT=INFO property that
has STRUCT-TYPEP true of it.


Date: 22 FEB 1980 0300-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

DEFVAR should check to see if the variable is bound before setting it.

Date: 22 FEB 1980 0110-EST
From: REES at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC

In Lisp 1941, (MAKHUNK 1024.) returns an object of typep RANDOM.
It appears that HNKLOG has increased from 10 to 11 with the new
Lisp versions, but the code isn't prepared to handle this boundary
case.

Date: 21 February 1980 07:54-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: LINMODE AND READLINE
To: BEN at MIT-ML
cc: BUG-LISP at MIT-AI

What you observe is indeed the case, but it is not clear
that this is a bug.  Line mode says that input comes in complete
lines.  However, S-expresions do not, and certainly after
the read-eval-print loop has read the expression (READLINE)
there is still a <cr> left there.  Perhaps what you wanted was
(PROGN (CLEAR-INPUT) (READLINE))
FOOBAR
returning "FOOBAR".  In any case, you do need something to
swallow any extra input lying around.  (Again, consider
typing all on one line:
(SETQ X (READLINE)) (PRINT X)
Then X would get " (PRINT X)", and the PRINT would not be evaluated.)


Date: 20 Feb 1980 1831-PST
From: Maclisp at SRI-KL (Jon L. White)
Subject: (SSTATUS LINMO T)
To:   bug-lisp at MC

This is broken in Twenex version of Lisp 1941, please make sure this works
before making this the new Lisp.
-------

BEN@MIT-ML 02/20/80 17:04:47
To: (BUG LISP) at MIT-ML
I am using MACLISP under TOPS-10 at TUFTS.

If you are running with (SSTATUS LINMODE T)
and do (READLINE),
the <CR> that terminates the line on which you input
to the interpreter seems to remain on the input queue,
gets seen by READLINE, and causes it to return immediately
with a null line.

				Ben Kuipers


Date: 20 FEB 1980 1108-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(SSTATUS MACRO /% '(LAMBDA () (TYI)    ()  ) SPLICING)
(SSTATUS MACRO /@ '(LAMBDA () (TYI) '(ABCD)) SPLICING)

(TYIPEEK T)     %A       a
=Returns=> 141

(TYIPEEK T)     @A       a
=Returns=> 141

; This seems un-intuitive to me. -- Macros that do (TYIPEEK T) to find 
; the start of the next token are gonna lose big.

%A 'A
=Returns=> A
'@A
=Returns=> ABCD

; So these macros work correctly in 'normal use'

; You're going to love this one now...

(sstatus macro /# '+internal-/#-macro splicing)
(tyipeek t)
#+MACLISP (QUIT)
... This never returns -- I can type just like I am typing now and there
is no problem ... type type type ... ))))))))))) .... still no return value.
I must still be lost in the tyipeek ... 
;BKPT ^B
3
=Returns=> 3
P 
... is it fixed? no ... sigh ... 

Date: 20 FEB 1980 0805-EST
From: JONL at MIT-MC (Jon L White)
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC, WJL at MIT-ML

    GSB@MIT-ML 02/15/80 20:08:18 Re: wjl's "reader bug"
    If the garbage collector is called by a conser, and it runs
    the gc-daemon, and the gc-daemon uses EXACTLY the number of
    cells of that type that were freed, things lose big because
    when AGC returns the conser assumes that its freelist is non-0.
    In this example, AGC was called from ACONS, and when it returned
    FFS was 0, so the EXCH A,@FFS clobbers NIL, etc.
VERY good analysis, here!  I've just put in some code into GCBIB
(the midas source file for lisp with the GC in it) to run the
"panic" error if, after GC-DAEMONing, some space has a null freelist.
This will be testible in LISP 1941 (and > versions), which should
be XLISP today.

Date: 20 FEB 1980 0435-EST
From: JONL at MIT-MC (Jon L White)
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 16 February 1980 14:17-EST
    From: George J. Carrette <GJC at MIT-MC>
    compiling the file GJC;TCTYP >
    gives BOUND-VARS undefined function in UUO call.
    This was called by DEFUN& someplace.
Fixed - trouble was a typo in DEFMACRO file.

Date: 20 FEB 1980 0157-EST
From: JONL at MIT-MC (Jon L White)
Subject: IOTA losing?
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 15 February 1980 07:16-EST
    From: Kent M. Pitman <KMP at MIT-MC>
    (DEFUN SMART-PROBEF (FILE) 
	   (AND (ERRSET (IOTA ((STREAM FILE '(IN NODEFAULT))) T) NIL) T))
    when used with a non-existent file -- eg,
    (SMART-PROBEF '((DSK FOO) BAR BAZ))
    -- returns NIL but leaves interrupts turned off(?) ... doing
    <Control-G> T<space> (NOINTERRUPT T) (NOINTERRUPT NIL)
    should illustrate the state of the world after this has been done.
Weird code is being produced by IOTA - A simplified version of the problem 
may be seen as follows:
 (DEFUN KMP-LOSES () (ERRSET (UNWIND-PROTECT NIL (OPEN '((DSK BOO) BAR BZ)))))
The "OPEN" is being done as part of the "clean-up" code, and that is where
the "error" occurs;  ERRSET doesn't bind/restore the "UNREAL" variable,
so that is why it is left off.  Although this is implementationally a bug in
ERRSET, it probably isn't worth fixing now;  I'd suggest heartily that you 
don't have error-producing code in the "clean-up" part of an UNWIND-PROTECT.  
(Yes, it would break a lot of code to try to "fix" ERRSET- since another slot 
on its stackframe would be needed).

Date: 20 FEB 1980 0130-EST
From: JONL at MIT-MC (Jon L White)
Subject: STEPPers on STORE
To: sjobrg at MIT-AI
CC: (BUG LISP) at MIT-MC

    Date: 15 February 1980 09:40-EST
    From: Robert W. Sjoberg <SJOBRG at MIT-AI>
    To: BUG-LISP at MIT-AI, BUG-STEP at MIT-AI
    .  .  .
    When I use the Rich Stepper, and try stepping through the
    macro expansion, everything is fine up to the step where
    the next thing to be eval'd is
    (store (arraycall fixnum foo 4) -37238.)
    Now, if I type <rubout>, everything is fine.  However, if I
    type <space> or M, I usually get a DIDN'T EVAL TO GOOD ARRAY
    REFERENCE - STORE.
Probably a bug in the stepper - you cant split the "evaluation" of
the array reference, in this case the "(arraycall fixnum foo 4)"
from the store;  possibly the stepper is splitting it in order to
allow you to "step" thru it?

Date: 20 FEB 1980 0120-EST
From: JONL at MIT-MC (Jon L White)
To: REES at MIT-MC
CC: RWK at MIT-MC, (BUG LISP) at MIT-MC

    Date: 18 February 1980 00:24-EST
    From: Jonathan A. Rees <REES at MIT-MC>
    Subject: PUSH on macroexpanded forms
      There WAS a bug before I recompiled the source for SETF.  
    .  .  .  
    suffer confusion when the source doesn't reflect the current state of
    the FASL (esp.  when you delete the source that the installed FASL was
    created from).  I had both these problems in this instance.
So what was the bug?  Was it merely corrected by recompiling?  It appears
that you didn't change the source for SETF?

Date: 20 FEB 1980 0113-EST
From: JONL at MIT-MC (Jon L White)
Subject: SELECTQ
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 18 February 1980 06:03-EST
    From: Carl W. Hoffman <CWH at MIT-MC>
    SELECTQ is missing from the interpreter.
Actually, SELECTQ and FBOUNDP are auto-loadable macros
in XLISP - we hope to make a crossover to a new lisp soon.

Date: 20 FEB 1980 0016-EST
From: JONL at MIT-MC (Jon L White)
Subject: STRING package on LISP
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC, REES at MIT-MC, RLB at MIT-MC

It was my intention last week, before my untimly demise of
a cold/flu/februray-blahs, to install the latest lisp, which has
an internal symbol needed for the "STRING-PURECOPY" function.  But
if you have a lisp with symbols loaded, then it will get the 
symbol definiton from DDT.  Even if you don't want to load symbols,
there is hope - just do (DEFPROP GRBPSG <any-fixnum> SYM) before
loading the STRING package, and at worst you'll lose when tyring
to purcopy some compiled string.

Date: 19 FEB 1980 2247-EST
From: GZ at MIT-MC (Gail Zacharias)
To: (BUG LISP) at MIT-MC

  Readline echoing seems to get out of wack if you rubout past a continued
line.  It then goes to a line above the one you expect to be on.
It processes the characters right, but what you get is not what you see.


Date: 19 February 1980 09:26-EST
From: Kent M. Pitman <KMP at MIT-MC>
Subject: Forwarded Mail
To: BUG-LISP at MIT-MC

    Date: 18 February 1980 10:20-EST
    From: Jonathan A. Rees <REES at MIT-MC>
    To:   KMP

    To get **SELF-EVAL**s to GRINDEF correctly it is sufficient
    to load LISP;SENDI FASL


GSB@MIT-ML 02/18/80 12:48:35 Re: format
To: (BUG LISP) at MIT-ML
CC: REES at MIT-ML, RLB at MIT-ML
I have installed a new format version.  The previous version is
FORMAT OFASL and FORMAT OAUX, the previous OFASL is OOFASL.
This one claims to understand strings.  If (status feature string),
then if (stringp s), then CHAR-N and STRING-LENGTH are used.
The variable *FORMAT-STRING-GENERATOR is a function to call with
one argument, a list of character codes, to get a return "string"
value.  It defaults to MAKNAM.  CHAR-N and STRING-LENGTH are assumed
ncallable.  As far as i can tell it works with strings, but the 
string package on LISP now no longer even loads in!  It barfs about
some ddtsym being undefined!
    Remember that if for any reason this must be deinstalled (i don't
think it should, i have been using it for 2 weeks, and a couple
people here have autoload properties for FORMAT directly pointinng 
to LSB) the AUX file must be deinstalled also.


Date: 18 Feb 1980 0614-PST
From: Scott at SRI-KL (Scott J. Kramer)
Subject: Twenex MacLisp screw (rilly?)
To: bug-lisp at MIT-MC

!l:

LISP 1920
Alloc? n


* 
(tyi)a			 {Standard (TYI), no problem}
141 
(tyi)A
101 

(sstatus linmo t)T	 {Turn on Twenex RDTTY crock, can we use TEXTI JSYS
			  perhaps??}

(tyi)a	 <---{Had to type <cr> to activate due to use of RDTTY JSYS}
141 

(fasload qtrace)	 {KMP's QTRACE package, to demo this bug}
117453 
(qtrace ledit jsys)

;Loading TRACE 66 (LEDIT JSYS) 
(ledit)			 {Run the thing!}

         {Typed <sp> here, no <cr> needed, doing a (TYI TYI)}
                              |
                              |
                              V
(1 ENTER LEDIT NIL) --Break?--  [Yes]   
;BKPT LEDIT

QUIT*                  {^G quit}

;BKPT ^B               {Typed ^B here}
(ledit)                {Rerun LEDIT, still QTRACEd}
                                   
          {Typed <sp> here but it hangs until <cr> is typed}
                              |
                              |
                              V
(1 ENTER LEDIT NIL) --Break?--           <cr>
 [Yes]
;BKPT LEDIT

QUIT*                {^G quit}
(ledit)

(1 ENTER LEDIT NIL) --Break?--            {Still hangs}
 [Yes]
;BKPT LEDIT
***************************************************************************

There is a problem with (TYI TYI) hanging in "RDTTY mode" which appears
to be caused by the ^B interrupt.  Also, what is the possiblity of using
TEXTI and staying in (STATUS LINMO) => () mode and having rubout processing?
The problem shown above causes minor disasters in things like STEP which
wants a <sp> to continue stepping and it is frustrating to naive users who
don't know to type <sp><cr> to get it working.

	-sjk
-------

Date: 18 FEB 1980 0809-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: More on GFN
To: (BUG LISP) at MIT-MC
CC: RLB at MIT-MC, REES at MIT-MC, RWK at MIT-MC

Ok, EVAL-WHEN has been made to grind correctly and the documentation at the
head of the file has been reversed so that recent changes are at the TOP 
where they are easy to see.

As to the HUNK stuff, hopefully someone can put this info in  .INFO.;LISP NEWS
for me when the next set of info goes into there -- I don't know what the
format is that things have to be in if there is a standard -- but anyway:

There is a variable named HUNKSPRIN1. If it is NIL, then HUNKs will be printed
as CONS's. Additionally, if HUNKP is NIL, regardless of the setting of 
HUNKSPRIN1, hunks will display as CONS's. If HUNKSPRIN1 is non-NIL, it should
be set to the name of a printer which can be used to SPRINTER an s-expression.
It follows the 'familiar' (l n m) arg convention of most of the grind package
functions... Sprint a list l in space n leaving room for m pending parens.
Additionally, the value of HUNKSPRIN1 should have a HUNKGFLATSIZE property
which is a function of one arg that returns the flatsize of that object when
sprintered. The default value of HUNKSPRIN1 is STANDARD-HUNKSPRIN1 which
is provided to sprinter HUNKs in a nice (?) way ...

Hopefully REES will shortly follow with his information about how to make
make the **SELF-EVAL** guys display nicely using SPRINTER.

The new features cost us 300 words of code. Sorry about that.

-kmp

Date: 18 FEB 1980 0603-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

SELECTQ is missing from the interpreter.

Date: 18 FEB 1980 0024-EST
From: REES at MIT-MC (Jonathan A. Rees)
Subject: PUSH on macroexpanded forms
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC

  There WAS a bug before I recompiled the source for SETF.  
  [Attention Maclisp/NILCOM maintainers (who are you?  The files's
author was Jonl, but I know that he is working on other things): test
out changes you make to the Lisp source files when you make them,
otherwise someone else (like me) has to go and debug your errors, or
suffer confusion when the source doesn't reflect the current state of
the FASL (esp.  when you delete the source that the installed FASL was
created from).  I had both these problems in this instance.

Date: 17 February 1980 17:24-EST
From: Robert W. Kerns <RWK at MIT-MC>
Sender: ___055 at MIT-MC
Subject: Read syntax of ^J.
To: BUG-LISP at MIT-MC
cc: JPG at MIT-MC

Sometime since lisp 1861, the read syntax of linefeed was made into
a whitespace character from it's former status of ignored.  This
means that things like FOO/<cr><lf>BAR now reads as FOO/<cr> and a second
token of BAR.  (but not |FOO/<cr><lf>BAR|, since | does it's on syntax hacking)
On the theory this was mere temporary brain fade while changing the syntax of
RETURN, I've changed it back in the source.  On confirmation of the brain fade
theory, I'll patch it into the current lisp so existing code with this
admitedly old-fashioned way of doing this will once again work.

Also, I have found and am fixing the bug with open-paren's and **SELF-EVAL**'s
in XL.

Date: 17 FEB 1980 0909-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

A new GRINDEF has been released. This features 'correct' printing of
HUNKs. This feature can be turned off by doing (SETQ HUNKSPRIN1 NIL)
for people afraid this new 'feature' will break their code. It is
possible to define your own hunk printer. I'll write doc on how to do
that soon. Jonathan REES is working on writing a printer for the
**SELF-EVAL** things in the extended support packages. Also fixed
in the new GRINDEF is the pretty sprinter'ing of LAMBDA's and LET's.
I forgot to do EVAL-WHEN's in this pass. That will come soon.
The new GRINDEF is GFN 437 (LISP;GFN FASL) on AI,ML,MC. The old
version is LISP;GFN OFASL on MC.
-kmp

Date: 17 February 1980 04:09-EST
From: Robert W. Kerns <RWK at MIT-MC>
Sender: REES at MIT-MC
Subject: PUSH on macroexpanded forms
To: REES at MIT-MC
cc: BUG-LISP at MIT-MC

I don't see any problem when I try your example.  It should only be barfing
about MACROEXPANDED being an obscure format if MACROEXPANDED isn't getting
defined as a macro by the loading of DEFMAX.  Perhaps you're suffering from
obarray dyslexia?

Date: 16 FEB 1980 1600-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: WGD at MIT-MC

What total lossage. Sigh. TERPRI gets rebound to NIL in a bare lisp when
you type . This should get fixed to caused rebinding to T in a breakpoint.
-kmp

Date: 16 FEB 1980 1417-EST
From: GJC at MIT-MC (George J. Carrette)
To: (BUG LISP) at MIT-MC

compiling the file GJC;TCTYP >
gives BOUND-VARS undefined function in UUO call.
This was called by DEFUN& someplace.

GSB@MIT-ML 02/15/80 20:08:18 Re: wjl's "reader bug"
To: (BUG LISP) at MIT-ML
CC: WJL at MIT-ML
If the garbage collector is called by a conser, and it runs
the gc-daemon, and the gc-daemon uses EXACTLY the number of
cells of that type that were freed, things lose big because
when AGC returns the conser assumes that its freelist is non-0.
In this example, AGC was called from ACONS, and when it returned
FFS was 0, so the EXCH A,@FFS clobbers NIL, etc.


WJL@MIT-ML 02/15/80 11:51:05
To: (BUG LISP) at MIT-ML
When I load wjl1;dosel 5 into my lisp (bare except for my lisp
init), it clobbers nil with a number .09375 which occurs many
times in the file.  Glenn looked and determined it was happening
in read somewhere.

Date: 15 FEB 1980 1140-EST
From: REES at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC


(PROG () (DO () (T (RETURN 'FOO))))

... obviously ought to return FOO.  But it craps out instead,
saying that there's an illegal GO or RETURN not inside a PROG or DO.
Quelle lossage!

Date: 15 FEB 1980 1041-EST
From: REES at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC


PUSH loses on MACROEXPANDED forms.  Example:

(DEFMACRO KAR (X) `(CAR ,X))
KAR
(DEFUN KARP (Y X) (PUSH Y (KAR X)))
KARP
(KARP 'A '((B)))
(A B)					;So far so good.
(KARP 'A '((B)))

At this point it re-autoloads DEFMAX, and then barfs with
"MACROEXPANDED Obscure format -- SETF".

Date: 15 February 1980 09:40-EST
From: Robert W. Sjoberg <SJOBRG at MIT-AI>
To: BUG-LISP at MIT-AI, BUG-STEP at MIT-AI
cc: SJOBRG at MIT-AI

I have noticed the following for some time now and have decided to
send you this note.

I often use macros of the form

(declare (special foo))
(setq foo (array nil fixnum 10.))
(defmacro etc (x) `(arraycall fixnum foo ,x))

and then invoke them with either

     (setq bar (+ 5 (etc 1)))	;a fetch
     (store (etc 4) -37238.)	;a store

When I use the Rich Stepper, and try stepping through the
macro expansion, everything is fine up to the step where
the next thing to be eval'd is

(store (arraycall fixnum foo 4) -37238.)	;following the above example

Now, if I type <rubout>, everything is fine.  However, if I
type <space> or M, I usually get a DIDN'T EVAL TO GOOD ARRAY
REFERENCE - STORE.

Comments?


Date: 15 FEB 1980 0716-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC

### Sorry for half-finished message before -- ^C key doubled ###

The following code:

(EVAL-WHEN (EVAL COMPILE) (LOAD'LIBLSP/;IOTA))
(DEFUN SMART-PROBEF (FILE) 
       (AND (ERRSET (IOTA ((STREAM FILE '(IN NODEFAULT))) T) NIL) T))

when used with a non-existent file -- eg,

(SMART-PROBEF '((DSK FOO) BAR BAZ))

-- returns NIL but leaves interrupts turned off(?) ... doing

<Control-G> T<space> (NOINTERRUPT T) (NOINTERRUPT NIL)

should illustrate the state of the world after this has been done.
This is buggy in both compiled and interpreted code.
-kmp

Date: 15 FEB 1980 0710-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

The following code:

(EVAL-WHEN (EVAL COMPILE) (LOAD'LIBLSP/;IOTA))
(DEFUN SMART-PROBEF (FILE) 
       (AND (ERRSET (IOTA ((STREAM FILE '(IN NODEFAULT))) T) NIL) T))

when called on a non-existent file -- eg,

(SMART-PROBEF '((DSK FOO) BAR BAZ)

Date: 15 FEB 1980 0553-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: LABEL
To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC
CC: (FILE [AR2:KMP;LABEL ODDITY]) at MIT-MC

Did LABEL go away? COMPLR says it won't support it. But the interpreter
still supports:

  ;; 'Normal' recursive factorial

(DEFUN RECURSIVE-F (X)
       ((LABEL FOO #'(LAMBDA (X)
		        (COND ((ZEROP X) 1.)
			      (T (TIMES X (FUNCALL FOO (SUB1 X)))))))
	X))

  ;; ... and (you guessed it, lossage fans) ... the iterative version ...

(DEFUN ITERATIVE-F (X)
       ((LABEL FOO #'(LAMBDA (X)
			     (SETQ FOO 1)
			     (DO ((X X (1- X)))
				 ((< X 2) FOO)
				 (SETQ FOO (TIMES X FOO)))))
	X))

Date: 15 FEB 1980 0447-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

#O only works if the immediately following token is a number.
It should work in cases like (SETQ X #O '(10 20 30)).

Date: 13 FEB 1980 2320-EST
From: JONL at MIT-MC (Jon L White)
Subject: XLISP
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 13 February 1980 05:48-EST
    From: Alan Bawden <ALAN at MIT-MC>
	Date: 13 FEB 1980 0539-EST
	From: REES at MIT-MC (Jonathan A. Rees)
	(VECTOR) returns NIL.  Shouls return #().
    Gee, in my lisp (VECTOR) produces an error (undefined function)!
XLISP has autoload properties for some of the NIL-compatibility stuff.
A CLASS-like system is being supported.

Date: 13 February 1980 05:48-EST
From: Alan Bawden <ALAN at MIT-MC>
To: REES at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 13 FEB 1980 0539-EST
    From: REES at MIT-MC (Jonathan A. Rees)

    (VECTOR) returns NIL.  Shouls return #().

Gee, in my lisp (VECTOR) produces an error (undefined function)!

Date: 13 FEB 1980 0539-EST
From: REES at MIT-MC (Jonathan A. Rees)
To: (BUG LISP) at MIT-MC

(VECTOR) returns NIL.  Shouls return #().

Date: 12 February 1980 22:37-EST
From: Robert W. Kerns <RWK at MIT-MC>
Sender: REES at MIT-MC
To: BUG-LISP at MIT-MC

The code for QUIT and VALRET is totally bugous.
(QUIT 5) should do a .BREAK 16,(D).  Probably it should do it in this case even
if %OPBRK is not on, since the user explicitly asked that a .BREAK be done.
What it IS doing is horrible.  First off, it tries to kill the job.  Then it
.VALUE's if %OPBRK is off, else finally does the .BREAK 16,(D) you asked for
(although of course the job has already been killed by this point).  Then if
you managed to save the job from that first .LOGOUT, and continue from your
(QUIT 5) (which would NOT kill the job, merely return to DDT with an error)
it will  try to kill your job again (persistant bastard, ain't it), and if
it survives that, does a (VALRET '/:VK/ ) before finally returning.
Such persistence in doing the wrong thing is almost to be admired....

Date: 12 FEB 1980 2229-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

In Lisp.1861, (VALRET) valret's :VK.
In Lisp.1914, (VALRET) kills the job.

I prefer the 19th century style as VALRET should not be dangerous.
With an arg, it seems to do ok -- it's just the no-arg case that's
botched up.

-kmp

Date: 12 FEB 1980 2138-EST
From: JONL at MIT-MC (Jon L White)
Subject: ATOM applied to a hunk?
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC, REES at MIT-MC, Carl at MIT-AI

Carl, Jonathan, and I just re-hashed the old question of
ATOM versus HUNKs last week - admittedly it is too late
to change the meaning of ATOM (to be "not listp") when
there are still users who prefer the more limited use 
of it.  But in fact I think I've fixed SUBST for hunks
today - will be in the next release of LISP;  regardless
of the "ATOM" question, hunks must be considered
destructurable by the various funcitons which trace over
structure - e.g., PRINT, FLATSIZE, EQUAL, SUBST, PURCOPY.

Date: 12 February 1980 21:33-EST
From: Alan Bawden <ALAN at MIT-MC>
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 12 FEB 1980 1243-EST
    From: JONL at MIT-MC (Jon L White)

    (SUBST () () (HUNK 1 2 3 4))  MAKES A ** LIST **

also (append (hunk 1 2 3 nil) '(b c)) makes (1 b c).
Now perhaps you could argue that append is a list-hacking
function and that this is therefore reasonable.  But other behaviors
could also be justified:

1) subst hacks non-atomic structure and should make hunks, while append
   hacks lists and thus should barf since it is about to treat a hunk as
   a list.

2) subst and append are both cons-hacking functions and they should both do
   the same thing (both barf or both do what they do now).

3) subst and append are both non-atom hacking functions and should
   make conses or hunks as appropriate.

I have always thought it was a pain that hunks are not atoms.  It
seems that whenever one writes code that deals with lists that include
structures made of hunks (like those produced by a defstruct), one really
wants ATOM to return nil for hunks.  Oh well, too late to change it now!

Date: 12 February 1980 1521-EST
From: Dave Touretzky <Dave.Touretzky at CMU-10A>
Subject: non-null termination of list
To:   bug-lisp @ mc

With *RSET on, the mapping functions check for lists that don't end in
NIL, and signal an error if appropriate.  The error is signalled on the
*RSET user interrupt channel.  I think it would be better to signal on
another channel, such as WRNG-TYPE-ARG.  The reason is that most *RSET
interrupts are really trivial *RSET-traps that FIXIT (the CMU MacLisp
debugger) throws away.  The only exception I am aware of is the non-null 
termination of list error signalled by MAPC and friends.  In this case
the user probably does want to enter a debug loop so he can look at the
list in error.  The easiest fix appears to be to change the mapping
functions to signal their errors on a "serious" interrupt channel
instead of the catch-all one.

Yes, I realize that since the test is controlled by *RSET it is correct to
signal on the *RSET channel, or at least it seems reasonable to do so.  But
give my suggestion some thought anyway.

-- Dave Touretzky

Date: 12 FEB 1980 1243-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(SUBST () () (HUNK 1 2 3 4))  MAKES A ** LIST **

Date: 12 February 1980 03:15-EST
From: Christopher Fry <CFRY at MIT-AI>
To: BUG-LISP at MIT-AI

Doing meta-. on TV-BEEP gets to the DEFVAR for the variable definition, not the
function definition.  Presumably when there is one of each the function definition
should be preferred.



EB@MIT-AI 02/11/80 18:31:21
To: JONL at MIT-MC
CC: (BUG Lisp) at MIT-MC, KMP at MIT-MC
    Date: 11 FEB 1980 1325-EST
    From: JONL at MIT-MC (Jon L White)
        . . . 
    KMP has a utility, IOTA, to handle "clean-ups" after file loading. 

IOTA does not solve the problem which I described.  IOTA allows a user
to WRITE a version of LOAD, FASLOAD, etc. which does cleanups after
file loading automatically, but it does nothing to the SYSTEM versions.
That means that the USER of a file that makes temporary changes on loading,
not the WRITER, has to follow a special loading procedure if he is to be
protected in the event of a quit.  It is this to which I object.  It is
not properly the concern of the user of a package what changes that
package makes temporarily during loading; that is the concern of the
package author.  It is not possible to properly confine the necessity of
knowing unless the necessary UNWIND-PROTECT is part of the standard system
LOAD.

    On the other
    hand, Interlisp permits comments to be included right in with the souce
    text (by storing them, I believe, in a special "comments" area).

Just to set things straight, it stores them in ordinary LIST space and
works just like Maclisp (COMMENT ...).  You may have in mind the
NORMALCOMMENTSFLG=NIL feature of Interlisp whereby comments are not read
in but are stored as short comments (lists) of a special format indicating
the file and position in the file of the actual text.  This scheme works
poorly because executable Lisp dumps containing such comment pointers
often outlive the source file versions containing the actual comments.


Date: 11 FEB 1980 1325-EST
From: JONL at MIT-MC (Jon L White)
To: eb at MIT-AI
CC: (BUG LISP) at MIT-MC, (BUG @) at MIT-MC, sjobrg at MIT-AI

    Date: 10 February 1980 14:55-EST
    From: Edward Barton <EB at MIT-AI>
    Subject: Per-file options
    A recent reply to someone asking about commas in (comment ...) 
    constructions recommended doing (SSTATUS MACRO ...) to turn off
    the commas, then possibly later re-enabling commas with another
    (SSTATUS MACRO ..) call.  In order to turn off mcommas for a particular
    file only, presumably there would be a SSTATUS at the beginning and
    another at the end of the file.
    . . . 
KMP has a utility, IOTA, to handle "clean-ups" after file loading.   But
the particular problem here really is something different;  it was Bob 
Sjoberg who sent the comment last week about commas in the text part of 
a lisp "(COMMENT ...)".   I spoke with him verbally Saturday about the 
root of the problem, and it is essentially this - there is yet no 
system-wide standardization for commentary text.  By this, I mean
that while the @ program looks for "(COMMENT ...)" in lisp source files,
and indexes these lines, it does not look for any of the kinds of commentary
which are independent of the lisp reader syntax;  if @ were to look for
comments which began, say, 
;;;@ <some comments I'd like tabulated in my @ listing>
then we'd at least escape the conflict with the lisp reader.  On the other
hand, Interlisp permits comments to be included right in with the souce
text (by storing them, I believe, in a special "comments" area), so something
like the maclisp "(COMMENT ...)" still has a place.  An interim solution
is to use |'s around the text of your comments, e.g.
(COMMENT |I hadn't thought about doing this; at least, not before now.|)
or, if one has strings enabled in maclisp, he could use " instead of |.

Date: 10 February 1980 14:55-EST
From: Edward Barton <EB at MIT-AI>
Subject: Per-file options
To: BUG-LISP at MIT-AI

A recent reply to someone asking about commas in (comment ...) 
constructions recommended doing (SSTATUS MACRO ...) to turn off
the commas, then possibly later re-enabling commas with another
(SSTATUS MACRO ..) call.  In order to turn off mcommas for a particular
file only, presumably there would be a SSTATUS at the beginning and
another at the end of the file.

If loading of that file is then aborted, naturally commas will be left
turned off.  This illustrates a general problem; namely, there is no
way that I know of to make certain changes temporarily in loading,
compiling, or whatever a file, without leaving things wrong or
inconsistent if there is a quit.

Would it be unreasonable to have some variable AFTER-LOAD-FORMS or
something which loading functions would bind, initially to NIL,
and then mapcar eval'ing down when loading is complete?  There
could also be an UNWIND-PROTECT in LOAD which would do the same
things, perhaps with there being some way for forms to tell whether
a normal load-termination or a quit was occurring.  This would allow
users to push forms onto AFTER-LOAD-FORMS and be sure they would
be evaluated, regardless of whether there was a quit or whether loading
terminated normally.  Then they could reset the things that they clobber
and truly make things per-file.  A similar list could be used by the
compiler, and perhaps other things that I haven't thought of.



Date: 10 February 1980 02:41-EST
From: Kent M. Pitman <KMP at MIT-MC>
To: SJOBRG at MIT-MC
cc: BUG-LISP at MIT-MC

    Date: 9 February 1980 08:37-EST
    From: Robert W. Sjoberg <SJOBRG at MIT-AI>
    To:   BUG-LISP at MIT-AI

    Is there any easy way to have commas in a (comment ... ) without having to
    slashify them, and without COMPLR complaining about them not being inside
    backquotes?
-----
Yes, there is. You can turn off comma. This can be done by doing...

(SSTATUS MACRO /, NIL)

and you can re-enable it later (if you need to) with...

(SSTATUS MACRO /, '|+INTERNAL-,-macro/||)

I think probably if you do (SETQ |`-,-level/|| 1.) you will probably
win also, without disabling , from its normal use.  You won't
get error messages if you mess up with commas and use them in bad places
but they will disappear ok when used out of context in (comment ...) unless
they see a ")" right after them or something like that .... I recommend the
'clean' way with just turning off the /, macro tho'.

-kmp

Date: 9 February 1980 08:37-EST
From: Robert W. Sjoberg <SJOBRG at MIT-AI>
To: BUG-LISP at MIT-AI

Is there any easy way to have commas in a (comment ... ) without having to
slashify them, and without COMPLR complaining about them not being inside
backquotes?


Date:  6 February 1980 2103-EST (Wednesday)
From: Scott.Fahlman at CMU-10A
Subject: Echo hacking
To:   bug-lisp @ mit-ai
Message-ID: <06Feb80 210324 SF50@CMU-10A>


Concerning my earlier note on turning off echos:

We have solved the problem with a LAP function.  i would still be
interested in learning if there is a way of doing it from within Lisp.
-- Scott


Date: 6 February 1980 20:09-EST
From: Alan Bawden <ALAN at MIT-MC>
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC

    Date: 6 FEB 1980 0838-EST
    From: JONL at MIT-MC (Jon L White)

    ...

     A partial solution is for ALAN to re-install DEFSHARP so that any file
    which thinks it needs this security could do its own local definition
    for "#:", and we could propogate a general prohibition for using "#:"
    for anything else until the question has been fully settled.  (By the bye, 
    I'd really like to see DEFSHARP be defaulty loaded - it is now with the
    maclisp SHARPM file).

I really don't see why a special form for defining sharpsign macro
characters is any better than SETSYNTAX-SHARP-MACRO which is a
function that can be called to set up a new sharpsign macro.  When I
originally wrote DEFSHARP for my own sharpsign macro in MacLisp, it
was intended to be an internal convience macro since I was going to be
defining a lot of sharpsign macros at the same time.  I had no
intention that it should escape beyond the bounds of that file.

Date: 6 February 1980 16:11-EST
From: Howard I. Cannon <HIC at MIT-MC>
Subject:  Double standard for keywords
To: JONL at MIT-MC
cc: MMCM at MIT-MC, MOON at MIT-MC, BUG-LISP at MIT-MC,
    BUG-LISPM at MIT-MC

I STRONGLY agree, as I have for a long time, that the keyword and user
package should be seperate.  Having the keyword package be a superior
of user seems fine to me.  We shoulD DEFINITLY bite the bullet and do this.

Date:  6 February 1980 1320-EST (Wednesday)
From: Scott.Fahlman at CMU-10A
Subject: Echo suppression?
To:   bug-lisp @ mit-ai
Message-ID: <06Feb80 132034 SF50@CMU-10A>


I have a user here who wants to write a drawing package in MACLISP.
He wants to give single character commands and have them do things
but not echo the character typed.  Is there an easy way (or any way,
for that matter) to do this in TOPS-10 MACLISP?

-- Scott


Date: 6 FEB 1980 1347-EST
From: JONL at MIT-MC (Jon L White)
Subject: Double standard for keywords
To: MMCM at MIT-MC, MOON at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

  Date: 6 February 1980 12:54-EST
  From: Mike McMahon <MMCM at MIT-AI>
  Subject:  Bridging the colon gap 
  It is a total crock that the keyword package is the same as the user package.
  I understand that it was moderately convenient at the time it was first im-
  plemented, and that it avoided some problems in the cold load; however these
  should have gone away long ago.  Teaching users not to put in the colons is
  decidedly a bad practice, it can only lead to their confusion, and as well 
  not allow for MACLISP compatible code outside of the user package. Unless
  there are nearly insurmountable problems i am not aware of, i propose biting
  the bullet and fixing this at the same time as the other incompatible changes
Yes, this is precisely the problem - that the system began without the colons,
then *some*, but not all users began using the, leaving us in the current
state where both are needed.  Had the colon (or better yet, package prefix)
been necessary earlier, we wouldn't be in this state now.  
  Date: 6 February 1980 13:31-EST
  From: David A. Moon <MOON at MIT-MC>
	    "The problem, as you remember, is that many people are 
	  confused as to how to type keywords - most believe that the colon is 
	  necessary."
  No, Jonl.  The colon IS necessary, and if any believe otherwise they
  are the ones who are confused.  The fact that it sometimes works not
  to type it is a bug and a crock, it is still necessary.
As your comments about the keywords to open show, the colon really isn't
necessary in user code - if it were, then maclisp would have no problem
with the "double standard".  Would you  (MOON) be in favor of MMcM's
suggestion to "bite the bullet"?

Date: 6 FEB 1980 1331-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Keywords
To: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, JONL at MIT-MC

This got left out of my previous message to (bug lispm) and jonl.

	  "The problem, as you remember, is that many people are 
	confused as to how to type keywords - most believe that the colon is 
	necessary."

No, Jonl.  The colon IS necessary, and if any believe otherwise they
are the ones who are confused.  The fact that it sometimes works not
to type it is a bug and a crock, it is still necessary.

Date: 6 FEB 1980 0947-EST
From: JONL at MIT-MC (Jon L White)
Subject: Out-of-core maclisp system stuff
To: ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 5 February 1980 22:38-EST
    From: Alan Bawden <ALAN at MIT-MC>
    I consider it a bug that the DEFMAX package must be loaded in order
    ...  Why should a utility function like FORMAT require such runtime
    support? ... If these functions are really all that necessary then perhaps
    we should make them part of the default MacLisp world instead of
    pussyfooting around with this autoloading gubbish.  
Aside from the fact that DEFMAX is about .3K words and FORMAT is about 3K,
isn't this part of your complaint satisfactorily answered by the second
part of it?
    ... Just looking at the source of DEFMAX I don't see any reason that 
    these functions should
    be polluting my lisp environment since I no longer even use the
    standard DEFMACRO.
By the bye, did you ever use the "standard" DEFMACRO?  Apart from
coalescing the two main streams of "memoizing/displaceing" prevalent
around the labs here, it does it destructuring by defaulting to LET,
thereby modularizing the destructuring component.  I see also that
the LISPM  system-supplied version of DISPLACE is inadequate for doing
the "updating" kind of macroexpansion suggested by Ken Kahn - namely
that if you redefine a macro (admittedly by use of DEFMACRO rather
than MACRO), all previous expansions are automatically invalidated.

Date: 6 FEB 1980 0838-EST
From: JONL at MIT-MC (Jon L White)
Subject: Bridging the colon gap 
To: HIC at MIT-MC
CC: ALAN at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

This "keyword package" question has given rise to a number of
kludgy partial solutions, but none seems to have fully taken hold
yet - until one does, we'll likely encounter complaints, such as
yours (below) against "#:" , and I'd like to take this opportunity
to apprise the bug-lisp/bug-lispm communities of the basic problem.
    Date: 6 February 1980 01:53-EST
    From: Howard I. Cannon <HIC at MIT-MC>
    I suggest not having this.  It seems like a total kludge to me, and
    I see no reason to snarf this either A) ambiguous, or B) potentially
    useful # macro character.  I find it hard to believe that the MacLisp
    reader can't be hacked to throw away everything before a : in a symbol,
    if some flag was turned on, or somesuch.  This seems like a more
    appropriate place for a the kludge.
For MACLISP, we wouldn't want just to throw away the prefix of a colon - 
for example, it is quite desirable for SI:MUMBLE and CL:MUMBLE to be
distinct symbols.  The problem, as you remember, is that many people are 
confused as to how to type keywords - most believe that the colon is 
necessary.  Until it actually becomes necessary (e.g., having a separate 
keyword package), there exists the necessity in MACLISP of having something
which a user can write which will work both now and in the future.
"FOO" is the current state, and if the keyword package happens,  then ":FOO"
or "KEY:FOO", is the future state;  for the LISPM, there is no trouble in 
bridging this gap, but maclisp can't bridge it simply by tossing out the 
colon prefix arbitrarily.  That's why the selectivity of the kludgy "#:" 
is needed.  
   A partial solution is for ALAN to re-install DEFSHARP so that any file
which thinks it needs this security could do its own local definition
for "#:", and we could propogate a general prohibition for using "#:"
for anything else until the question has been fully settled.  (By the bye, 
I'd really like to see DEFSHARP be defaulty loaded - it is now with the
maclisp SHARPM file).
   Another possible solution is RMS's, namely just get people to stop 
putting colons in front of keywords, and let system-programmers take
their lumps about distinguishing the keyword when in the SI package.
This has the desirable feature that all keywords appear *without* colons,
but it may be hard to turn the hands of the clock back to state where
this can be standardized.
   Finally, it might be noted that this is not exclusively a maclisp
compatibility problem (although prominently so now), but in any situation 
where one wants to say, *selectively*, "use the package feature, if enabled",
some such "feature" would be desirable.

Date: 6 FEB 1980 0749-EST
From: JONL at MIT-MC (Jon L White)
Subject: default settings for DEFMACRO
To: GSB at MIT-MC, ALAN at MIT-MC
CC: (BUG LISP) at MIT-MC

    ALAN@MIT-MC 02/05/80 23:09:57
	Date: 5 February 1980 22:50-EST
	From: Glenn S. Burke <GSB at MIT-ML>
	There are certain macros which exist in FORMAT which really don't need
	to be there.  Because they are there, however, DEFMAX gets autoloaded
	when |forget-macromemos/|| gets called as they get defined.
    Well shouldn't such macros be surrounded by (EVAL-WHEN (EVAL COMPILE) ...)s ??
The documentation on NIL/MACLISP's DEFMACRO features suggest using
the two switches DEFMACRO-FOR-COMPILING and DEFMACRO-DISPLACE-CALL - 
it is the latter switch, which when "on" requires a call to 
|forget-macromemos/||.  Typically, a file will globally DECLARE these
switches "off", define its temporary macros, then set them back on; or
you can get local options, e.g.
   (DEFMACRO (MYCONS DEFMACRO-FOR-COMPILING () DEFMACRO-DISPLACE-CALL () )
	     (X Y &OPTIONAL (AREA TEMP-CONS-AREA) &AUX (OUTP (GC-SIZE AREA)))
	(AND OUTP (SETQ AREA (GET-NEW-AREA)))
	`(&INTERNAL-ALLOCATE ,area ,x ,y))
All this stuff is documented, both in the source for DEFMACRO and in
the LISP.NEWS file, about second or third page down.

ALAN@MIT-MC 02/05/80 23:09:57
To: GSB at MIT-ML
CC: (BUG LISP) at MIT-ML
    Date: 5 February 1980 22:50-EST
    From: Glenn S. Burke <GSB at MIT-ML>

    There are certain macros which exist in FORMAT which really don't need
    to be there.  Because they are there, however, DEFMAX gets autoloaded
    when |forget-macromemos/|| gets called as they get defined.
    In the next version (maybe a week to guarantee its safety?)
    they won't be in there by default.  But you will get DEFMAX if you
    load any macro which uses the lisp default DEFMACRO, for the same
    reason.

Well shouldn't such macros be surrounded by (EVAL-WHEN (EVAL COMPILE) ...)s ??


Date: 5 February 1980 22:50-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: FORMAT using DEFMAX
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-ML

There are certain macros which exist in FORMAT which really don't need
to be there.  Because they are there, however, DEFMAX gets autoloaded
when |forget-macromemos/|| gets called as they get defined.
In the next version (maybe a week to guarantee its safety?)
they won't be in there by default.  But you will get DEFMAX if you
load any macro which uses the lisp default DEFMACRO, for the same
reason.


Date: 5 FEB 1980 2238-EST
From: ALAN at MIT-MC (Alan Bawden)
To: (BUG LISP) at MIT-MC

I consider it a bug that the DEFMAX package must be loaded in order
for FORMAT to work.  I don't see the connection at all between the
two.  Why should a utility function like FORMAT require such runtime
support?  Am I going to lose the next time someone rewrites GRINDEF or
TRACE?  If these functions are really all that necessary then perhaps
we should make them part of the default MacLisp world instead of
pussyfooting around with this autoloading gubbish.  Just looking at
the source of DEFMAX I don't see any reason that these functions should
be polluting my lisp environment since I no longer even use the
standard DEFMACRO.

Date: 5 FEB 1980 0708-EST
From: JONL at MIT-MC (Jon L White)
Subject: PRINT
To: (BUG LISP) at MIT-MC

Just to re-iterate for the record, the symbol  /2^-N  prints
out as  2^-N  ,  which fails to read back in properly.

Date: 4 February 1980 16:43-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: #+LISPM on ITS
To: KMP at MIT-MC, BUG-LISP at MIT-MC
cc: BUG-LISPM at MIT-ML, "(FILE [GSB1;CONDIT CRUFT])" at MIT-ML

When we designed a conditionalization feature for LSB, it was decided
that anything that had to understand a "foreign" syntax in order to
flush it was a loss.  We do it by
  {predicate any-text-at-all-with-balanced-curly-braces}
The predicate is read by READ and evaluated.  (ONLY-FOR LISPM) is
like #+LISPM.  If it evals to NIL, the text is flushed (splicing readmacro
style);  otherwise it is left there, and global flag hacks cause the matching
right brace to disappear (but it will act as a break).
The restrictions are that this conditionalized structure is a reader
break, and that the contained text must have matching braces.  There
is currently no way to "quote" them, so if one or the other must appear
in the text, a matching one should be placed nearby, appropriately
commented out.  (I think midas has crocks like this, but i'm not sure.)
The feature is that no understanding of the stuff being conditionalized
is necessary.  This greatly simplifies the usage in the long run, and
tends to prevent screws like the one you mentioned, even if only by
limiting their number to those that come from not balancing the braces
or something like that.  (The one i ran into using #Q was conditionalizing
the readin of a small-flonum.)
    I'm not necessarily advocating the adoption of something like this,
but i would be greatly grossed out if hacks were put in to "sort of"
make the sharpsign conditionalization work this way.  Then again, if
people want this as a general feature, the conditionalization stuff
could be separated out of LSB.