Date: 7 Jun 1979 1531-PDT
From: Guy Steele <GLS at SU-AI>
Subject: Proposed FORMAT features
To:   BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI
CC:   GLS at SU-AI   

(a) Let some modifier, e.g. :, make G be a relative GOTO rather than
    an absolute one.  This is useful for processing some argument twice.
    (Maybe this already exists if * can take a negative arg?!)
(b) Let , _, and  (right, left, and double arrow) also be modifiers.
    If the field width is fixed, then these modifiers cause the stuff
    to be right, left, or center justified within the field.  I have
    often wanted a right-justified ~S or a left-justified ~D.




Date: 7 JUN 1979 1501-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Very small hunks
To: (BUG LISP) at MIT-MC

Well, I've never used 1-length hunks so (NIL . <thing>) for hunk1's in
MAKHUNK[NIL] mode seems best to me (given that CXR[0] is what it is).
If no one else objects, the change seems fine. Having anything but 
#777777 in that slot is an improvement.

Date: 7 JUN 1979 0934-EDT
From: JONL at MIT-MC (Jon L White)
Subject: (HUNK 'A) when MAKHUNK = NIL
To: GSB at MIT-MC
CC: KMP at MIT-MC, RWK at MIT-MC, (BUG LISP) at MIT-MC

 I vote for (NIL . A)  rather than (A) or even (#777777 . A).
the reasoning is semi-backwards compatibility, that no #777777 frobs
appear in list structure (that is supposed to be an "illegal" 
pointer!), and also consistency in what (CXR 0 (HUNK <froblet>))
returns.

GSB@MIT-ML 06/07/79 08:06:01 Re: makhunk complaints
To: KMP at MIT-ML, RWK at MIT-MC
CC: (BUG LISP) at MIT-ML
(hunk 'a) => (#777777 . A) 
doesn't seem all that bad, since the cxr 0 of it is A.  If it gave
(A), then the cxr 0 of that would be NIL.
I think the right thing was done in this respect, however it
may be reasonable for the CAR of the returned frob to be NIL, but
i'm not positive about that, especially in the case of a HUNK2.


Date: 7 JUN 1979 0045-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

In XLISP, (SETQ MAKHUNK NIL) (HUNK 'A) => (#777777 . A) instead of (A) which
former lisps returned....

Date: 6 JUN 1979 1832-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
Subject: Trace with nonstandard Prin1
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

I think I mentioned this a long time ago, but here goes again...
It would seem very useful to be able to set the printing function
in a Trace at tracing time, not using whatever Prin1 happens to be
around at print time.  There are two cases:
1. I know how to print something specially (eg a Macsyma expression);
2. non-standad Prin1's used by my system screw up Trace printout.
Both seem like reasonable cases.  Note that you can always define
a function to simulate using runtime Prin1, but not vice versa.
My recollection is that Trace once worked the way I suggest, using
in fact the Trace-time Prin1 as the run-time Prin1.  Tha in itself
is not necessarily the way to do things, but it's a start, as you can
easily enough do ((lambda (prin1) (trace...)) ...).

Date: 6 JUN 1979 1819-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC

Should (hunk) perhaps create (or use a unique) Hunk2 with -1 in both halves?
It currently returns Nil, but I can imagine its being useful to have full
symmetry in the meaning of Hunk with n args.  Alternatively, (hunk) could
give an error.

SJOBRG@MIT-AI 06/06/79 10:09:14
To: (BUG LISP) at MIT-AI
I'm still having problems with NIL type arrays.
Now, I put stuff into them, and things are fine for a while.
Then suddenly, when I go back to look at one, all its elements
have been clobbered with (NIL NIL NIL NIL ... ).  What would
cause this sort of crap?


Date: 6 JUN 1979 0859-EDT
From: JONL at MIT-MC (Jon L White)
Subject: .info.;LSPORD >
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

This file is generated by the function GENFNS, from the file
COMLAP;GENFNS > and GENFNS FASL.    Just FASLOAD it into
a current lisp, do "(GENFNS)", and sit back an relax.   QUUX
started this  hac, and it is mostly automated, but from time
to time, it has to be updated with "special knowledge" about
the meaning of various lisp functions.

Date: 6 JUN 1979 0857-EDT
From: JONL at MIT-MC (Jon L White)
Subject: |forget-macromemos/||
To: JPG at MIT-MC, CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

The loading into MACSYMA of the DEFMAX file is not at all
harmful, although it is a minor bug in DEFMACRO that it got
loaded in this particular case.  I have just fixed this bug.
Mostly, the problem is due to the fact that the output of
DEFMACRO would like a few helper functions in the runtime
environment, and lisps with version number less than about 1820
don't have autoload properties for these functions.

GSB@MIT-ML 06/06/79 07:04:31
To: (BUG LISP) at MIT-ML
(apply 'foo argument-list)
where FOO is a macro gives the error
IMPROPER USE OF MACRO - EVAL
This doesn't help debugging at all.


Date: 5 JUN 1979 1934-EDT
From: CWH at MIT-MC (Carl W. Hoffman)
Subject: Macro lossage
To: (BUG LISP) at MIT-MC, (BUG MACSYM) at MIT-MC

The function |forget-macromemos/|| is defined as a subr in
the current Macsyma.  I don't know how it got in there since
it should only be autoloaded from LISP;DEFMAX and shouldn't
be needed by Macsyma at runtime.  Its presence is also causing
DEFMACRO to lose since LISP;DEFMAC uses this to determine when
to load DEFMAX.

Date: 5 JUN 1979 0332-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

(Also, in XL, (SETQ MAKHUNK NIL) ;should be doing CONSes
(HUNK 5)
(#777777 . 5)
If this is to be compatible, it should return (5).
While I have no particular objections to this other than incompatibility,
I don't think it's enough of a feature to want to install!

Date: 5 JUN 1979 0326-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: XLISP Hunk display
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

(SETQ MAKHUNK T)

(HUNK 'A NIL) => (NIL( .)

(HUNK 'A 'B)  => (B( .)

(HUNK 'A 'B 'C) =>  (A . BC .)

(HUNK 'A 'B 'C 'D) => (A . B . CD .)

Is this the shape of things to come? I was rather a fan of balancing
open and close parens... kinda thought it was more aesthetic...

Date: 4 JUN 1979 1655-EDT
From: JONL at MIT-MC (Jon L White)
Subject: SYS:.FASL DEFS
To: bkph at MIT-AI
CC: (BUG LISP) at MIT-MC

thru three links, this pointed to L;DEFNS >, which had gotten
deleted in a foul-up on AI.  I just restored it by FTP from MC.

BKPH@MIT-AI 06/04/79 16:51:07
To: (BUG LISP) at MIT-AI
Sigh, what is the new alias for SYS: .fasl defns?

Date: 4 JUN 1979 1605-EDT
From: JONL at MIT-MC (Jon L White)
Subject: RENAMEF bug found!
To: FAHLMAN at CMU-10A
CC: (BUG LISP) at MIT-MC

Your analysis of the RENAMEF bug on TOPS-10 was right on.
Many people will appreciate that;  I've fixed up the source
and am reassembling now.  Tnx very much, Scott.   Most certainly,
the RENAMEF bug explains the mysteriousl bug yo had associated
with DELETEF.

SJOBRG@MIT-AI 06/04/79 15:08:40
To: (BUG LISP) at MIT-AI
I've run into a real problem, both in the interpreter and in compiled
code.  Apparently an array is getting clobbered, but I don't see how.
The file is SJOBRG; BIBL BUG (source), and to get the symptoms, do
	(setq IFOB (open '((sjobrg) thbibl >) '(in ascii)))
	(read-biblio-file)

As each of 120 entries are read, its index will be printed.
If you ^B anywhere up to about 80, and look at the array
element (biblio-entries 0), it will contain a list, as it
should.  However, later, or after it finishes, if you
examine the same array element, it will probably contain
an infinitely recursing list of NIL, or some fixnum garbage
(it isn't that consistent).


Date:  4 Jun 1979 0048-PDT
From: CSD.SCHNEPPER at SU-SCORE
Subject: follow-up on IO bug in MACLISP
To: bug-lisp at MIT-AI
Cc: admin.mrc at SU-SCORE


I connected to scratch and everything works ok so long as i dont do
    "(uwrite dsk |csd.schnepper|)" or a "(uwrite)" with the default
directory |csd.schnepper|.  but "(uread (dsk |csd.schnepper|) foo bar)"
works fine.

				Dave Schnepper CSD.SCHNEPPER @ SCORE

-------


Date:  4 Jun 1979 0051-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: more details on CSD.SCHNEPPER@SCORE's complaint
To: Bug-LISP at MIT-AI

His account was renamed by copying his files to a temporary directory,
KILLing the old account, and creating a new one with the same directory
number as his old one (for FINGER, BBOARD, and SYSMSG, which are keyed
on directory number, so he wouldn't see all the messages again).  The
problem looks like:

@MACLISP

LISP 1804 with NEW I/O
Alloc? n


*
(UWRITE)?Illegal op executed
@

This happens both to him and to me if I CONNECT to him.  To see if it
was name-dependent, I created a directory for him on my MRC: disk
structure, and MACLISP when connected there tried to write on <GAMES>
because the right half of the directory number for the MRC: directory
was the same as PS:<GAMES>!!!!!

Obviously MACLISP does not understand about structure names, and is
probably making some horrible assumption about what to do with the
left half of a directory number.

Also, that error message is completely uninformative - I poked around
a bit in DDT before giving up in disgust.  MACLISP is worse in its
crashes than the Tops-20 monitor is.  At the least, a crash message
should give the PC of the losing instruction, and also if it was a
JSYS that barfed it should print out the message for the JSYS error
code (the ERSTR JSYS).  Better yet, MACLISP should always use ERCAL
or ERJMP after JSYS's and recover reasonably from JSYS errors.
-------


Date:  4 Jun 1979 0033-PDT
From: CSD.SCHNEPPER at SU-SCORE
Subject: IO bug in MACLISP
To: bug-lisp at MIT-AI
Cc: admin.mrc at SU-SCORE


I seen to have found the following bug.. My original account name Here
at SCORE was recently changed to correct a mis-spelling in it.  After
Admin.MRC here changed it MACLISP started losing on a '(UWRITE)'
to wit, it gave '?Illegal instruction' and returned to the monitor.
MRC and i determined that none of my files were causing the bug
and he suggested I pass it on to you.
			Thanx,
				David Schnepper CSD.SCHNEPPER @ SCORE

-------


Date: Sunday,  3 June 1979 1827-EDT
From: Scott.Fahlman at CMU-10A
Subject: TOPS-10 RENAMEF bug found.
To:   bug-lisp @ mit-mc
CC:   touretzky at CMU-10A
Message-ID: <03Jun79 182740 SF50@CMU-10A>


JONL,
More good news.  I have discovered the source of the RENAMEF bug
in TOPS-10 MACLISP.  Once again, I would like you to look over the
suggested fix and install it in the master file if it seems OK to
you.

RENAMEF can take either file arrays or strings or lists.  If we pass
it a list pointing to a closed file, we end up at RENAM2 which
opens the file, renames it, and then (the instruction before RENAM4)
does a JRST RENAM1.  At RENAM1, the first argument is treated as a
file array, and updated entries are stuffed into the appropriate
slots.  If the first arg was a list, this code is still executed
and smashes 6 words of random list space, with totally unpredictable
consequences.  The code at RENAM1 is all fairly new, by the way.
It does not appear in the source we have (I forget the version
number of that).

What we want is to jump to RENAM1 if we have an array first argument
and to RENM1A otherwise.  I believe there is a marker left in AR1
from which this can be determined.  (Set up near the entry to
RENAM2.)  A quick and dirty patch is just to change RENM2A+22 to
JRST RENM1A.  This skips the array updating even where it would be
appropriate, but avoids the random clobberation.

I suspect that this problem has been responsible for a number of phantom
bugs.  In particular, after making the above patch I was unable to
invoke the DELETEF bug mentioned in an earlier note, so maybe it was
the RENAMEF bug all along.  Once the fix is installed, we will see
whether the system works noticeably better.

Regards,
Scott


Date: 3 JUN 1979 0630-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: XLISP Bug?
To: (BUG JONL) at MIT-MC
CC: (BUG LISP) at MIT-MC, RWK at MIT-MC, HIC at MIT-MC, GLS at MIT-MC

(HUNK 'A)
returns
(#777777 . A)
when MAKHUNK is set to T ... Is this how 1-hunks will print? That's pretty
ugly. What happened (in all lisps) to the ability to recognize a hunk  cuz
it printed with a trailing dot, .. eg: (A . B . C .) ... if you had left
that in you could have hunks print as
(A .)
(A . A .)
(A . A . A .)
and so on ... This would make them visually distinguishable from dotted
pairs. You could even make the lisp reader smart enuf to recognize this 
syntax and turn the object into a hunk as I think the syntax is unambigous.
That might be a feature. I'm not that attached to hunks that i would cry
if someone objected but ... 

Comments anyone?

Date: Saturday,  2 June 1979 2307-EDT
From: Scott.Fahlman at CMU-10A
Subject: TOPS-10 bug revisited.
To:   bug-lisp @ mit-mc
CC:   touretzky at CMU-10A
Message-ID: <02Jun79 230747 SF50@CMU-10A>


Correction to my previous message:
The fix is only needed, and will only work on CMUA.  On CMUB, the saved PC
is indeed the instruction AFTER the loser.  I will attempt to find out if
the difference is a difference between the level 5 and level 6 DEC monitors
or is a difference in hardware between the KL and KA.  Or perhaps it is
an idiosyncracy of our much-hacked CMU monitor.  Obviously this is where
the bug came from.  I wonder how many other things like this there are.
-- Scott


Date: Saturday,  2 June 1979 2235-EDT
From: Scott.Fahlman at CMU-10A
Subject: TOPS-10 bug fixed.
To:   bug-lisp @ mit-mc
CC:   touretzky at CMU-10A
Message-ID: <02Jun79 223537 SF50@CMU-10A>


Jonl,
I finally dug in and found the "write into read-only memory" bug that
we have been bitching about lately.  The problem is with an instruction
at MEMERR+5 in the TOPS-10 version.  The line is

SA% 10$ SOS IPSPC(F)	;Make the PC point to the offending instruction.

The assumption here is that after a protection violation interrupt on
TOPS-10 the stored PC points to the instruction after the one that lost,
and therefore needs to be set back by one.  But in fact, the stored PC
points to the losing instruction itself.  I have made MEMERR+5 a NOOP
with DDT, and it fixes the (SETQ T NIL) and (SETQ NIL T) cases, at least.
It also makes it possible for a MACHINE-ERROR interrupt handler to catch
any case which slips through the other tests, instead of letting such
problems punt back to the system.  (Without the fix, the losing PC value
caused a flameout somewhere in $IWAIT.)

I would appreciate it if you could look over this fix and if it looks OK to
you to add it to the master source.  I'm still too new at this to start
installing fixes without a second opinion.

We still have problems with DELETEF and RENAMEF, but maybe I can locate these
too.

Cheers,
Scott

Date: 2 JUN 1979 2107-EDT
From: JOHAN at MIT-MC (Johan de Kleer)
To: (BUG LISP) at MIT-MC

The CR problem in TNX has been fixed.
LISP 885, and COMPLR 884 don't seem to have any TNX related problems.

SJOBRG@MIT-AI 06/01/79 10:43:54
To: (BUG LISP) at MIT-AI
This is not a complaint, just something for your information.
Some time ago, and on and off during the last year, I compiled
a list of sources for various aspects of Lisp.  The sources
include the original Lisp "Moonual", the new (at least newer)
Lisp manual, and the LISP NEWS archive file.  References are
by page number and/or date and section number, as appropriate.
I haven't had time to update it since January, and it is very
incomplete as far as "concepts" listings, etc.  It is in Lisp-
like notation, which might be amenable to machine lookup.
Would any of you like to comment on it, perhaps make some
suggestions?  I would prefer not to be the one to maintain it
if it is found to be somewhat useful (I certainly use it when
looking up something about Lisp of which I am unsure), and
several people have urged me to make its existance known).
Feel free to make corrections if you notice them, and additions.

The file is AI: SJOBRG; LIX >.

Thanks.


Date: 1 JUN 1979 0222-EDT
From: JOHAN at MIT-MC (Johan de Kleer)
To: (BUG LISP) at MIT-MC

The latest MACLISP now runs on TNX and TOPS-20; and I have modified
the source and tested so that all the bugs except the CR problem
are fixed in the TNX version.

For TNX this will be LISP 824.

Date: 1 JUN 1979 0029-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC, MOON at MIT-MC, JPG at MIT-MC

I have removed myself from BUG-LISP

Date: 31 MAY 1979 0413-EDT
From: JONL at MIT-MC (Jon L White)
Subject: LINEREAD
To: TOURETZKY at CMU-10A
CC: JONL at MIT-MC, (BUG LISP) at MIT-MC, FAHLMAN at MIT-MC

Some time ago you had an anomaly with trying to read a "line"
of s-expressions.  The problem was primarily in that the reader
tosses out the "white-space" character which terminates an atom,
and thus your TYIPEEK didn't see the expected <cr>.  I have
written a full LINEREAD, following the style of READLINE, and
put it on the LIBDOC and LIBLSP directories at MC, and on
the C380ML5P directory at CMUA.  You might peruse the source
(LINERE.LSP) to see all the gory details.  Note that 
(TYIPEEK 'T <file>)  will scan characters, tossing out worthless
ones, until some character is encountered which will "start"
an s-expression.

Date: 31 MAY 1979 0024-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: MAR Break Handler
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC, RWK at MIT-MC, KMP at MIT-MC

RWK's fix to the (SETQ T <mumble>) type errors seems to have fixed the
MAR Break lossage (also gave PURPG; error when you tried to run the
example from .INFO.;LISP NEWS) .. The example now wins. Thanx a lot, Bob.
-kmp

Date: 30 May 1979 15:10-EDT
From: Richard L. Bryan <RLB at MIT-MC>
Subject: Settting readmacro characters - GETSYNTAX
To: JONL at MIT-MC, touretzky at CMU-10A
cc: BUG-LISP at MIT-MC


    Date: 29 MAY 1979 0422-EDT
    From: JONL at MIT-MC (Jon L White)

    The accepted winning way to set readmacros is
       (SETSYNTAX 59. 'SPLICING oldsemi)
    there would be no complaint from complr about that one.  The
    misleading thing is that there is no function GETSYNTAX.

See MC:LIBDOC;GETSYN RLB3 for a GETSYNTAX which has been 
around since July 1978.

Date: 29 MAY 1979 1313-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC

|ab| prints as such, but
|a| prints as /a and
|abcd| as |abcd|.
If ^@ is going to be printed out at all, it might as well be done
uniformly!

Date: 29 MAY 1979 0805-EDT
From: JONL at MIT-MC (Jon L White)
To: RWK at MIT-MC, JPG at MIT-MC, DCP at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG MACSYMA) at MIT-MC

    Date: 29 MAY 1979 0635-EDT
    From: JONL at MIT-MC (Jon L White)
    
	Date: 28 MAY 1979 1332-EDT
	From: RWK at MIT-MC (Robert W. Kerns)
	Subject: BOTCHED PATCH FIXED
	
	. . .   However, I note that there is no trace of this
	patch in the source at all!
	
    I have just put this in the source, so it will be in subsequent assemblies.

Upon reflection, this should *** not *** be in the source - this was a
temporary patch due to this complr bug

    Date: 17 MAR 1979 0014-EST
    From: moon,dcp at MIT-MC

    A call to set compiles into
    a JSP T,.SET which smashes TT, but COMPLR doesn't know that it smashes TT.

Since this complr bug was fixed shortly after its reporting, I hope that
any FASL file that had this manifestation has been recompiled, so
that the "patch" in lisp can be flushed.

Date: 29 MAY 1979 0635-EDT
From: JONL at MIT-MC (Jon L White)
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG MACSYMA) at MIT-MC, JPG at MIT-MC

Thanks for finding these bugs.

    Date: 28 MAY 1979 1332-EDT
    From: RWK at MIT-MC (Robert W. Kerns)
    Subject: BOTCHED PATCH FIXED
    
    The patch to .SET pushed TT onto FXP around a PUSHJ P,BIND ...however,
    if BIND gets PURPG interrupt stuff for the SFX'ed frob at SETXIT gets
    pushed onto FXP, so what gets popped is not what got pushed, and what
    is left is not what what SPWIN was looking for.  So I changed the patch
    on MC to save TT onto FLP instead of FXP.  This fixes the (SETQ T NIL)
    getting a PURPG error.  However, I note that there is no trace of this
    patch in the source at all!
    
I have just put this in the source, so it will be in subsequent assemblies.
But this isn't the problem with the CMU version, which still bombs out.
I guess we'll have the "opportunity" to try out AIDDT.

    RWK@MIT-MC 05/28/79 05:17:27 Re: DEFMAC in MACSYMA

    FOOBAR!  loading DEFUN& in MACSYMA does not load DEFMAX, while
    in a bare LISP it does.  The result is that MACROEXPAND doesn't get
    defined in MACSYMA, but it does in a bare LISP.  It does this even
    if you do (SETQ AUTOLOAD '+INTERNAL-AUTOLOAD).  I don't know what's
    going on.  I can't find where in DEFMAC it ever causes DEFMAX to get loaded.
    But it seems to in a bare LISP!
    
This is now fixed.  Apparently it was caused by a phase error in my 
updating of DEFMAC - the new LISP will have initial AUTOLOAD properties
for MACROEXPAND etc, and hence won't require the superfluous settings
from every macro defined by defmacro.

Date: 29 MAY 1979 0422-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Settting readmacro characters
To: touretzky at CMU-10A
CC: (BUG LISP) at MIT-MC

    Date:    28 May 1979 0253-EDT
    From:    DAVE.TOURETZKY at CMU-10A 
    Subject: COMPLR loses on sstatus splicing macro
    
    I have a little function that changes and restores the readmacro
    property associated with ";".  It restores it by doing
      (sstatus macro 59 oldsemi splicing)
    which is a perfectly legal call.  COMPLR complains that SPLICING was not
    declared special.

    ... <barfage> ...

The accepted winning way to set readmacros is
   (SETSYNTAX 59. 'SPLICING oldsemi)
there would be no complaint from complr about that one.  The
misleading thing is that there is no function GETSYNTAX.

Date: 28 May 1979 1707-EDT
From: Dave Touretzky <Dave.Touretzky at CMU-10A>
Subject: solution to RENAMEF losing on LIB:
To:   bug-lisp @ ai
CC:   dm20 at CMU-10A

I asked Craig Everhart, a local TOPS-10 wizard, what it would take to
stop LOOKUP from looking on the LIB: device for RENAMEF, without losing
any flexibility (such as setting an ALIAS, or using SFD's.)  His answer
appears below.  (It's long...)


- - - - Begin forwarded message - - - -
Date: Monday, 28 May 1979 1540-EDT
From: Craig.Everhart at CMU-10A
Subject: Re: LIB me alone
To:   DAVE.TOURETZKY at CMU-10A
CC:   Scott.Fahlman at CMU-10A
Message-ID: <28May79 154012 CE10@CMU-10A>
In-Reply-To: DAVE.TOURETZKY's message of 27 May 79 18:40
Origin:  C410CE10 at CMU-10A; 28 May 1979 1542-EDT

The bizarre thing happens when the LOOKUP finds the file on library
scanning; even if there is a library set, if the LOOKUP on the file
finds it without scanning libraries, the RENAME will work.  The problem
is that if it does find it using library search, the RENAME will fail
with some bizarre error -- ill seq of UUOs, I believe.  Doing an ENTER
to go into Update mode on the file will fail similarly.  And, no, there's
no way to ask LOOKUP not to search your libraries.

That's the general problem.  I've never tried to solve it in the context
of SFDs, but the solution generalizes to them.  Basically, if you really
want to know whether the RENAME will fail, you have to look at the place
where the file you found came out to being; you then (by hand) compare
that place with what you know to be the user's default directory path.
If the file is on the default path, you know you got the file without
resorting to library search, so you know the RENAME will fail.  If the
file is NOT on the default path, you got it from searching libraries,
or from searching SYS automatically, or from searching NEW, then SYS,
automatically.

The previous paragraph has an error; the directory path you compare the
file's path to is the default path for the job ONLY if there was no
PPN or path given to the LOOKUP.  If there was such a path, it supersedes
the job's spec entirely.  The bogus thing is that if you give LOOKUP a PPN or
path, the job's library, SYS, and NEW bits stay active.

Therefore, the algorithm is to find the principal path used by the LOOKUP.
This will be either the PPN or path given to the LOOKUP, or the default
path for the job.  Then, find the path where the file really is (with a
PATH. UUO), and see if you could have found the file using the principal
path that the LOOKUP used.  If so, a RENAME will zap the file; if not,
the RENAME will get some obscure error.

Elaboration of the above.  Any core image that does this kind of hackery
might as well find the job's default path at startup; you get this by
giving the PATH. UUO an argument of -1 and remembering the block of
directory info it gives you; this will look like a word of bits, a PPN,
and up to six SIXBIT SFD names.  The useful bit in the word of bits is
a bit called the scan switch.  If this is set to scanning, LOOKUPs that
look for files in the path and don't find it in the leaf directory will
try again in the next directory up the chain, ending in the UFD.  If the
bit is set to no-scanning, the LOOKUP will fail after the file isn't
found in the leaf directory.  Anyway, if the PATH. you give to determine
the job's directory path fails, use GETPPN to find out what the job's
default disk area is.

You can feed the LOOKUP UUO either zero in the directory field (PPN
word), or a PPN, or a pointer to a path block.  To get a path you
can use in the comparison, use the following.  If you gave LOOKUP
a zero (didn't specify a path or PPN), use the job's default path.
If you gave LOOKUP a path block, use it.  If you gave LOOKUP a
PPN, [I think] use a path block consisting of that UFD and NO
SFDs.

After a LOOKUP, you can feed PATH. a channel number, and it will tell
you just where the file that the LOOKUP found is.  This gives you the
requisite other path.

To compare paths, first you check if they're identical from the UFD
to the first zero or the sixth SFD.  If so, you got a match.  If not,
and if scanning is enabled in the path you fed LOOKUP (or job default,
etc., as above), see if the file's path is an initial subsequence of
the path LOOKUP saw.  If so, you match; if not, or if scanning isn't
enabled, you don't match.  If you didn't match, you then know you
found the file through library or SYS or NEW search, and a RENAME
(as well as an ENTER to go into update mode) will fail.

Simplification in the world of no SFDs:
If there are no SFDs in use (as at CMU), this process can be
simplified.  In this case, nobody feeds LOOKUPs pointers to PATH
blocks, since you can achieve the same effect by putting the PPN
word in the place you'd stick a pointer.  Getting the job's default
path amounts to feeding PATH. a -1, but only saving the one word
it returns as the default directory; if this fails, GETPPN will
work, as before.  PATH. given the channel on which a file has been
LOOKUPed, will return the PPN where the file lives; alternately, one
can use an extended LOOKUP, and the PPN word after one of those is
ALWAYS the UFD where the file was found.  (The 4-wd LOOKUPs fail
in this case since they overwrite the PPN with a perversion of the
file size.)  The check for did-LOOKUP-have-to-search-library
then amounts to seeing if the PPN where the file really is is
the same as the PPN: (if gave-LOOKUP-a-PPN then PPN-I-gave-LOOKUP
else job-default-PPN).


This is really a mess, I know.  The case that looks at SFDs is
particularly a mess.  The simplest thing to do may simply be to
try the RENAME and offer some intelligent interpretation for the
funny error code.  However, if you do the more general solution,
you'll be able to say stuff like

	File X.Y[C380ML5P] found on library search -- not deleted

rather than

	File X.Y found on library search -- not deleted

and the user will be perhaps less confused.

		Hope this clarifies your alternatives.

		Craig
- - - - End forwarded message - - - -


Date: 28 MAY 1979 1332-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: BOTCHED PATCH FIXED
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

The patch to .SET pushed TT onto FXP around a PUSHJ P,BIND ...however,
if BIND gets PURPG interrupt stuff for the SFX'ed frob at SETXIT gets
pushed onto FXP, so what gets popped is not what got pushed, and what
is left is not what what SPWIN was looking for.  So I changed the patch
on MC to save TT onto FLP instead of FXP.  This fixes the (SETQ T NIL)
getting a PURPG error.  However, I note that there is no trace of this
patch in the source at all!

Date:    28 May 1979 0253-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: COMPLR loses on sstatus splicing macro
To:      bug-lisp at MIT-AI
cc:      SCOTT.FAHLMAN

I have a little function that changes and restores the readmacro
property associated with ";".  It restores it by doing
  (sstatus macro 59 oldsemi splicing)
which is a perfectly legal call.  COMPLR complains that SPLICING was not
declared special.

Obviously COMPLR is confused about the weird way in which sstatus macro
takes its arguments.  Personally, I find the some-are-evaled-and-some-aren't
format of (sstatus macro) rather retarded, and would rather see that changed
than poor little COMPLR.    -- Dave


Date: 27 May 1979 22:39-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: Replies to ` query
To: JONL at MIT-MC, RBR at MIT-MC, KMP at MIT-MC, RWK at MIT-MC,
    KEN at MIT-MC, PRATT at MIT-MC, MACRAK at MIT-MC
cc: BUG-LISP at MIT-MC

sigh.

Date:    27 May 1979 2147-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: correction to last message
To:      bug-lisp at MIT-AI
cc:      SCOTT.FAHLMAN

Since the source file is SLURP.HIC, you should say
(SLURP C410DT50 SLURP HIC), and (UNSLURP SLURP HIC).  The proper
reply is (UNSLURPED SLURP HIC).  Sorry about the confusion.


Date:    27 May 1979 2133-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: RENAMEF doing damaging things
To:      bug-lisp at MIT-AI
cc:      SCOTT.FAHLMAN

There is a bug in RENAMEF similar to the DELETEF bug reported earlier.
The file SLURP.HIC on C410DT50 may be used to demonstrate the problem.
Simply run NEWLSP and say (SLURP C410DT50 SLURP MCL) followed by
(UNSLURP SLURP).  The reply will be something like (UNSLURPED . #10064).
The correct reply is (UNSLURPED SLURP MCL).

Look at the function DSKOUT1.  Put BREAK's around the two calls to
RENAMEF and do the rename's by hand from another job.  Notice that the
problem disappears.  

The above should be done using the standard LISP.INI file that appears
on C380NT00.  I hope this gets fixed soon.


Date: 27 MAY 1979 1225-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: # as an initial READ character macro
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

In clarification of my previous message - too many people think that if
a thing autoloads, that it will just be there. Which is nice I guess,
but unfortunately, many people (myself, RWK) have at least one and often
several different (often completely conflicting) # macros ... I think it
would make the world too confusing for there to be introduced at this point
a 'standard' # in addition to the hundreds of nonstandard ones ... it's not
like "`" where everyone that had one had in essence the same thing. # has
classically been used for too many functions. I even use it as a normal alpha
in some of my files. Please don't make me /-ify it at this point...As few
people as are still writing in MACLISP these days (ie, haven't switched to
designing NIL, are just maintaining Macsyma, or are working on Lisp machine)
I don't think it's that useful ... people might be able to remove the load
message from their files, but they might as well leave it there if it already
is - that much extra ascii on disk is not gonna hurt... 

	-kmp

Date: 27 MAY 1979 0922-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Replies to ` query
To: RBR at MIT-MC, KMP at MIT-MC, RWK at MIT-MC, KEN at MIT-MC
To: PRATT at MIT-MC, MACRAK at MIT-MC
CC: (BUG LISP) at MIT-MC, JONL at MIT-MC

Soon there will be a new BACKQ package for maclisp, which willl
have the option of generating "macroified" code, with the name
|`-expander/|| as a primary eval-time macro.  This option will
be exercised if BACKQUOTE-EXPAND-WHEN is "EVAL" (or in general
anything except "READ), and otherwise the expansion will occur
at read-in time just as at present.  Three other internal markers:
|-,-/||  |-,@-/||  and |-,.-/||    The latter one is for NCONC
instead of APPEND, and thus we can have `(A ,@B)  generate
(APPEND A B ()), thus copying B, but `(A ,.B)  generate
(APPEND A B).  Note that `(,.A B) would generate (NCONC A B).
[this idea, for ",." comes from RBR, I think].
GRINDEF would print out a form just like it was read-in, using
the READMACROINVERSE feature;  however, there is a flaw in this
feature in that readmacros won't appear in the CDR part of
a list;  thus you never see '(A . 'B)  grindef'd out that way.
For the same reason, it would be somewhat of a pain to get
`(A . ,B) to grindef out that way, but `(A ,@B) and `(A ,.B)
both win.  Note the weird commutation:  `(A . ,B) works the
same as `(A ,. B)  ??
All the aforesaid "markers" and macros would be on the obarray,
so that any PRINTing or GRINDEFing (regardless of the success of
the READMACROINVERSE attempts)  would be readable back in with
no loss of functionality.
Any further comments?

Date: 27 MAY 1979 0818-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

I'VE REMOVED THE QIO CONDITIONALS FROM THE MOST RECENT SOURCES.  THE
LAST VERSION WITH ALL THE (WORTHLESS!) CONDITIONALS IN IT WAS UNIFIED
AND STORED AS ML:LISP;LISP 817
ONE QUES? HAU ABOUT USING THE VALUE OF "MAKHUNK" FOR THE SWITCH
THAT DETERMINES WHETHER TO USE "HUNK2" SPACE (AS OPPOSED TO LIST SPACE).

Date: 27 MAY 1979 0229-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

I'M FIXING FASLAP TO OUTPUT HUNKS NOW, BUT HAVE TO SQUEEZE AN
INSTRUCTION IN JUST AFTER LDLHNK:
	MOVE TT,T
IN THE SOURCE, THERE IS A MORE GENERAL CORRECTION BEING APPLIED
AT HUNKF0.
   ALSO, IT'S TIME AGAIN TO WARN LOSERS OF A HUNK2 SPACE, FOR WHICH
(HUNK 1) AND (HUNK 1 2)  WOULD USE INSTEAD OF LIST SPACE;  FOR
THOSE UNCHANGEABLE, BACKWARD-COMPATIBLE LOSERS, THERE WILL BE A
SWITCH (SAY, THE VALUE OF THE SYMBOL "HUNK") WHICH IF NULL WILL
MEAN USE LIST SPACE INSTEAD OF HUNK2 SPACE.

Date:    26 May 1979 2108-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: DELETEF loses when LIB: used
To:      bug-lisp at MIT-AI
cc:      SCOTT.FAHLMAN

TOPS-10 allows users to set a pseudo-device called LIB: to point to
an arbitrary account.  File lookups that fail for the user's directory
are tried on LIB: before giving up.  This is a useful feature; I often
set my LIB: to C380ML5P (the MacLisp account) to run NEWLSP quicker.

However, DELETEF appears to also be using the LIB: lookup option, and
thus bombing with a protection failure whenever I delete a non-existent
file that does happen to exist on the LIB: account.  This happens more
frequently than you might think, as COMPLR tries to delete .FAS files
while compiling.  If I have no .FAS file, but one does exist on
C380ML5P, it flames out.

It is possible to not use the LIB: lookup when seeking a file; PIP does
so (and thus so does the TOPS-10 DELETE command.)  MacLisp should do
likewise.


Date: 25 MAY 1979 1342-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(SETQ NIL NIL) causes an embarrassing trap.

Date: 24 MAY 1979 1246-EDT
From: EAK at MIT-MC (Earl A. Killian)
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 24 May 1979 05:33-EDT
    From: Jon L White <JONL at MIT-MC>
    To:   EAK
    cc:   BUG-LISP

    2) As for display-style rubout processing - there is some problem
       in that TOPS-20 does not provide a general protocol for cursor
       control on "glass" terminals.  Probably the best thing to do is 
       to use RDTTY for input which will allow rubbing-out to be done
       by the 20X system, but which will likely require (SSTATUS LINMODE T).

I understand that 20X loses in this respect, but since BS-SP-SP wins
on most reasonable terminals, it would be nice to have a mode where
that is used wherever X would be on ITS.

MACRAK@MIT-ML 05/24/79 09:07:27
To: (BUG LISP) at MIT-ML
Is there any way to incorporate a multi-word literal into
lap code, like Midas's
  movei a,[jrst .+1
	   jrst .-1]  ?

Date: 24 MAY 1979 0533-EDT
From: JONL at MIT-MC (Jon L White)
To: EAK at MIT-MC
CC: (BUG LISP) at MIT-MC

Re your two questions of May 23:
1) It has long been a feature of MACLISP that <cr> is a classed
   as a "control-character", and hence invisible (unless "slashed")
   to the SYMBOL parser.
2) As for display-style rubout processing - there is some problem
   in that TOPS-20 does not provide a general protocol for cursor
   control on "glass" terminals.  Probably the best thing to do is 
   to use RDTTY for input which will allow rubbing-out to be done
   by the 20X system, but which will likely require (SSTATUS LINMODE T).

Date:    23 May 1979 2101-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: funny-looking eval thingie on stack
To:      bug-lisp at MIT-AI

I am trying to make FIXIT, my MacLisp debugger, invisible to the
user.  This means it has to know what parts of itself will appear on
the stack so it can edit them out.  I found a rather strange thing
on the stack today, that apparently only gets built when a uuo call
to EVAL, made inside of the function DEBUG, is snapped.  The stack item
looks like  (APPLY -nnn (EVAL (#24016 -1)) -mmm).  Where do those weird
arguments come from?

The file AI:SEF;FIXIT LOG is a log of a brief terminal session demonstrating
this bug.  The source code for FIXIT is on AI:SEF;FIXIT 1, and the FASL file
was created by :QC at AI.  The utility function ERUN is used in the bug demo
to print out the stack.  Its definition is in AI:SEF;FIXUTL 1.

Please let me know if this oddity is due to a bug, or if I must take it
into account in FIXIT's stack editing routine.  Thanks,  -- Dave Touretzky


EAK@MIT-AI 05/23/79 13:19:00
To: (BUG LISP) at MIT-AI
Is it considered a feature that FOO<cr>FAH reads in as FOOFAH???

Also, is there a way to turn on display style rubout processing
on 20X?

Date:    23 May 1979 2216-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: funny-looking eval thingie on stack
To:      bug-lisp at MIT-AI


I am trying to make FIXIT, my MacLisp debugger, invisible to the
user.  This means it has to know what parts of itself will appear on
the stack so it can edit them out.  I found a rather strange thing
on the stack today that apparently only gets built when a uuo call
to EVAL, made inside of the function DEBUG, is snapped.  The stack item
looks like  (APPLY -nnn (EVAL (#24016 -1)) -mmm).  Where do those weird
arguments come from?

The file AI:SEF;FIXIT LOG is a log of a brief terminal session demonstrating
this bug.  The source code for FIXIT is on AI:SEF;FIXIT 1, and the FASL file
was created by :QC at AI.  The utility function ERUN is used in the bug demo
to print out the stack.  Its definition is in AI:SEF;FIXUTL 1.

Please let me know if this oddity is due to a bug, or if I must take it
into account in FIXIT's stack editing routine.  Thanks,  -- Dave Touretzky


Date: 22 May 1979 19:43-EDT
From: Howard I. Cannon <HIC at MIT-MC>
To: MACRAK at MIT-MC, BUG-LISP at MIT-MC

It is a knownproblem that LABEL does not work if STATUS EVALPUNT is
T.

pratt@MIT-ML (Sent by JMJ@MIT-ML) 05/22/79 17:43:00
To: (BUG LISP) at MIT-ML
Sorry, that last message was from me. (pratt)


JMJ@MIT-ML 05/22/79 17:42:32
To: (BUG LISP) at MIT-ML
As far as I can tell, COMPLR still isn't setting NOLDMSG correctly.
Try compiling a file starting (CGOL)


Date: 22 MAY 1979 1548-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC

Suppose I want to change the place where an interrupted program will continue.
What location does my interrupt handler have to clobber?

Date: 21 MAY 1979 0932-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: BackQuote query
To: (BUG LISP) at MIT-MC

(1) For reasons of helping out beginners w/ how backquote works conceptually
 I wish that you would leave the version of it that completely disappears
 (ie, turns into LIST, LIST*, etc) at least accessible on LIBLSP; if not
 actually switchable by a variable as to which the user prefers.

(2) Can GRINDEF be patched to look for `(A . ,B) ? I can understand why
 the question was was asked (ie, that it will automagically do the right
 think w/ `(A ,@ B) but I think having `(A . ,B) to be important [1] and
 in any case, for a pretty printer to lose on a major form is bad... 
 Enforcing programming style on the basis of pretty-printer is the just
 the opposite cause-effect relation that one should be looking for.

(3) [Hack!] It has been pointed out (if you really wanna get funny about it)
 that you could have `(A . ,B) => (HUNK 'A '|,-`-mark| (list B)) and the
 evaluator would never even notice the mark was there! Any pretty printer
 that wanted to notice that a certain form had been assembled w/ backquote
 could do so.... [Re-emphasize: not a serious suggestion (heaven forbid someone
 should implement this and I have to live w/ it!) ... just pointing it out
 formally for the record.]

(4) I am also concerned with what happens when something of this form is
 printed into a file and later restored. The current implementation of
 backquote is autoloading (?) ... it should be made clear that |,-`-mark|
 and it's brother must autoload as well. Otherwise you'll lose when you 
 save and restore something before having called "`" explicitly.

(5) Given that 1,2, and 4 above can be made to work correctly, I guess I
 would not gripe too much if it changed.

-kmp

ps (I don't use Defmacro)


Date: 20 MAY 1979 2352-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC

LABEL doesn't work: this is clearly an effect of not eval'ing
non-functional atoms in function position, but it's a pity that
Label doesn't work in one way or another.  One possibility is
that 
	((label f ...) ...)
should first give f a function cell
	MACRO (lambda (l) (cons (eval (car l)) (cdr l)))
and then proceed in the usual way to bind f etc.

Date: 19 MAY 1979 1708-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
Subject: Error handling
To: (BUG LISP) at MIT-MC

Let (f) be an infinite recursion.  Now consider the following:
(3)
;3 undef fn
;bkpt undef
(f)
;3 undef fn
;pdl-overflow
Why is the undef fn message repeated?  And why doesn't pdl-overflow
do (in effect) a ^X like other errors within errors?

Date: 19 MAY 1979 1134-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
Subject: New backquote.
To: (BUG LISP) at MIT-MC

The idea is nice, but I woul prefer that the internal names be a little
nicer if we're going to see so much of them.  Even un-grinef'd code
should be marginally readable.  I suggest something like
(|`-expander| (|`,| . B) (|`,@| . D)).  These names shouldn't be too
much in demand.

By the way, there is a bug with readmacro inverse which screws up
on forms like (quote . a); this is not an unreasonable form to have
around: consider '((cond . docond) (quote . doquote)) , for example.
One curious anomaly is that '(quote . x) prints out as ''#232342
but (quote . y) gives an error message saying that y isn't a list
(arg to length); this presumably has something to do with the 
predictor?

GSB@MIT-ML 05/18/79 03:29:10 Re: RUBOUT
To: (BUG LISP) at MIT-ML
Is the rubout function ever going to get fixed?
It still moves up one line too many when wrapping around to the previous 
line.  (Because ^PB does this wraparound;  it should just use either
one or two ^PX's depending on the print size of the character;  ITS does
all the rest.)
For that matter, the fact that +INTERNAL-TTYSCAN-SUBR doesn't bind TERPRI
to T when it reprints the buffer causes more gross lossage with this
because of the auto-terpri.


Date: 17 MAY 1979 1152-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC

It's a pain tha commas outside of backquotes cause errors.  This
means that (comment ...) type comments can't conveniently contain
commas--as you know, this type of comment is used for generating
tables of contents.  Sigh.  I suppose I'll just have to use
(comment ;...
) or (comment |...
|) or something.

Date:    17 May 1979 0634-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: fretry and unwinding
To:      bug-lisp at MIT-AI

I don't think fretry is unwinding the pdl far enough.  If I
have a stack frame that looks like (EVAL -251386 (GORP) -249423)
and I do (FRETRY -251386 '(EVAL () (FROZ) ())), the call to FROZ
should replace the call to GORP, right?  But instead, FROZ appears
just below GORP on the stack.  In other words, fretry has a fencepost
error when counting functions to unwind off the pdl.


Date:    17 May 1979 0225-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: more lossage in NEWLSP
To:      bug-lisp at MIT-AI
cc:      SCOTT.FAHLMAN

I hate to keep doing this, but there seems to be another bug in
NEWLSP.  Specifically, upon leaving a CASEQ inside a PROG, the
PROG gets exited too.  Here's how to reproduce the problem.

	.run newlsp
	(slurp c410dt50 fixit mcl)
	(foo 1)
	<space>
	T

What this does is (a) invoke the debugger, and (b) attempt to print
the value of the variable T.  In NEWLSP, the debugger will print T = T,
and then print T ? because the function DEBUG1 returned NIL.  Doing
the exact same thing in MACLSP gets you the T = T, but DEBUG1 returns
a frame and no error message is printed.

The code to print a variable value is the T clause of a CASEQ in DEBUG1.
Tracing and stepping both indicate that the PROG is exited when the
CASEQ returns, while in MACLSP execution proceeds to the next expression,
which is (RETURN (OR FRAME ITEM)).


Date: 16 MAY 1979 1718-EDT
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

1.e reads as 10.0
2.3e reads as 2.29999998E+23
in general, A.Be reads as A.BeAB .  This is weird!
Also,
(2.3.4) reads as (2.3 0.4)
(2.e.3) reads as (200.0 0.3)

Shouldn't these things give errors??
(Macsyma has some of the same peculiarities in lexical analysis,
but the parser picks up the problems.  e.g. 2.3.4 gives "0.4 not
an infix operator")

Date: 16 MAY 1979 0926-EDT
From: JONL at MIT-MC (Jon L White)
Subject: BUG-OF-THE-YEAR-AWARD
To: touretzky at CMU-10A, fahlman at CMU-10A
CC: (BUG LISP) at MIT-MC

I hereby award to myself and Dave Touretzky the BOTYA
distinction, for having snaked out that told sneaky
loser, the disappearing cold-water FRETURN blues.
It seems that the various UserInterruptBReaK service
routines were correctly saving and restoring the PROG
pdl level variable, so that the sequence
  PROG-a==>Good-Frame==>UIBRK==>PROG-b==>FRETURN-to-GoodFrame
would indeed unwind thru PROG-b and UIBRK back to
the pdl level of Good-Frame, with the PROG-pdl-level 
restored to PROG-a;  *** but the PROG-pc-counter (label "PA3")
was left at the point in PROG-b ***.  This bug may even
account for other reproducible but unilluminated and
mysterious phenomena;  a correction has been applied
and is available on the ITS machines as SYS:TS NLISP
and at CMU as [c380ml5p]NEWLSP.  Try it and send
comments to bug-lisp.

Date: 16 MAY 1979 0452-EDT
From: JONL at MIT-MC (Jon L White)
To: fahlman at CMU-10A
CC: (BUG LISP) at MIT-MC

I found a minor glitch in the FRETRY stuff, so edited the
source here at MC, and reassembled a version 1814 for CMU.
Seems this time that some of the ilgl mem refs have gone
away.  Don't ask me why.   But anyway, [c380ml5p]NEWLSP is
the non-ddt version, and [c380ml5p]COMPLR is a compiler
composed from this NEWLSP.

Date: 16 MAY 1979 0354-EDT
From: JONL at MIT-MC (Jon L White)
Subject: CMU version
To: (BUG LISP) at MIT-MC

I just assembled the lates sources, and LINKed up at
CMUA, thereby getting a version that dies with ilgl mem
ref while tring to load in the compiler.  But if I LINK
it up with a DDT, the the problem goes away.   Usual
application of Murphy's law, that a watched problem
goes away??

Date: 16 MAY 1979 0256-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Complaint about (SSTATUS TERPRI ...)
To: miller at MIT-AI
CC: (BUG LISP) at MIT-MC

In the entry of .INFO.;LISP NEWS, dated MARCH 03,1977  there is a
comment about use of TERPRI, reproduced below.  The compiler is putting 
out error messages merely to try to badger you into "shaping up", before 
the horrible day when it **really** disappears.  Why not next week?
. . .
	[3F] WE ARE PHASING OUT (STATUS TERPRI).  PLEASE ELIMINATE
	     FROM YOUR PROGRAMS IF POSSIBLE.  IN NEWIO YOU CAN SET
	     THE LINEL OF A FILE TO 0 INSTEAD, OR YOU CAN BIND
	     THE TERPRI VARIABLE.
. . .

Date: 15 MAY 1979 2256-EDT
From: MILLER at MIT-AI (Mark L. Miller)
Subject: sstatus in qcomplr
To: (BUG QCOMPLR) at MIT-AI, LISP at MIT-AI, (BUG LISP) at MIT-AI
CC: MILLER at MIT-AI


what is wrong with (sstatus terpri nil) ?
qcomplr now generates a warning that this is "possibily illegal".
what is the right way to do this if this is not?

thankyou!  -- mark


GLS@MIT-MC 05/15/79 02:03:01
To: GLR at MIT-AI, (BUG LISP) at MIT-AI

    GLR@MIT-AI 05/13/79 19:40:55
    Now that comma has been gobbled as a character for
    the backquote read macro, why don't we make a comma
    that is outside a backquote just mean eval the next
    sexpr (ie. a #, on the LISPM).


If you did that, then you couldn't get a read-time evaluation within
a backquoted form.  The two ideas (, within ` and comma without it)
are only superficially similar, and the mechanisms should be orthogonal.



Date: Monday, 14 May 1979 2210-EDT
From: David McDonald <David.McDonald at CMU-10A>
Subject: Re: another problem with MacLisp read routine
To:   DAVE.TOURETZKY at CMU-10A
CC:   bug-lisp @ mit-ai, Fahlman at CMU-10A
Message-ID: <14May79 221046 DM20@CMU-10A>
In-Reply-To: DAVE.TOURETZKY's message of 14 May 79 19:49

Dave,
	You probably should also have mentioned that the read table
entry for <cr> has been modified to behave like a space.  That is,
	(SSTATUS SYNTAX 13. (STATUS SYNTAX | |))
This may have some bearing on the problem.
		- Dave.


Date:    14 May 1979 2049-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: another problem with MacLisp read routine
To:      bug-lisp at MIT-AI
cc:      SCOTT.FAHLMAN, DAVID.MCDONALD

JONL,
	I am having another problem with the MacLisp read
routine.  I hesitate to call it a bug, due to my last
experience, but it sure isn't doing what I want it to.
Specifically the problem is that, with (sstatus linmode nil),
sometimes (READ) will accept <space> or <cr> as a terminator,
and sometimes it won't.  The case where it won't is when
a 1 character symbol or number is the second element of a 
line being read by LINEREAD (defined below).

Examples:

(TRACE TYI TYIPEEK READ)
(SSTATUS LINMODE NIL)

(LINEREAD) foo xyz<cr>	; works

(LINEREAD) foo 12<cr>	; works

(LINEREAD) foo 1<cr>	; doesn't work; requires ")" to terminate

(LINEREAD) foo x<cr>	; also doesn't work


The lineread function is defined as:

(DEFUN LINEREAD NIL
  (PROG (VAL NXTCHAR)
        (SETQ VAL NIL)
   LOOP (SETQ VAL (NCONC VAL (NCONS (READ))))
   LOOP2 (SETQ NXTCHAR (TYIPEEK))
        (COND ((= NXTCHAR 13.) (RETURN VAL))
              ((OR (MEMQ (ASCII NXTCHAR) '(| | |)|))
                   (= NXTCHAR 131.))
               (TYI)
               (GO LOOP2)))
        (GO LOOP)))

What is it that's going wrong?   -- Dave


Date: 14 MAY 1979 0635-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

What happened to the nice error messages (SETQ NIL 1) or (SETQ T 1)
used to give?  Typing these to LISP 1785 goes up to DDT.

GLR@MIT-AI 05/13/79 19:40:55
To: (BUG LISP) at MIT-AI
Now that comma has been gobbled as a character for
the backquote read macro, why don't we make a comma
that is outside a backquote just mean eval the next
sexpr (ie. a #, on the LISPM).


Date: 11 MAY 1979 0256-EDT
From: FFM at MIT-MC (Steven J. Kudlak)
To: (BUG LISP) at MIT-MC


:versio
ML ITS.1144. DDT.1353.
USR:TESTER HACTRN, TTY 35
*
:ti
Thursday, May 3, 1979  2:22:06 AM EDT  NM+6D.16H.8M.45S.
*

lisp^K!

LISP 1785
Alloc? n


* 
(setq t nil)
PURPG; 66214>>MOVEM 12,@-1(16)   
:syssys QUIT? 
:symlod sys;ts lisp
*lispgo/   SETOM AFILRD   lispgo$g


* 
(setq foo 'bar)
BAR 
(setq nil t)
PURPG; SPWIN>>MOVEM F,@-1(FXP)    
lispgo$g



* 
(setq bar 'baz)
BAZ 
(cons foo bar)
(BAR . BAZ) 


TYIXCT)   XCT R   

Date: 10 May 1979 18:32-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: PROG-LET
To: GLS at MIT-MC, JONL at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC

    I don't think that PROG is particularly pretty anyway and 
for this reason am not really in favor of the idea of hairing
it up like LET to make it more 'fashionable'.

    I also disagree with the idea of extending each of these things
one at a time. If you are going to extend PROG, it would make sense
to extend PROGV (did it make its way into NIL?) and any other operators 
that do this sort of binding, perhaps adopting some regular naming
system so that there wouldn't be a lot of hard names to remember.
Otherwise, I fear a lot more hair will be called for in manuals. ie,

	(LAMBDA <type-A-bvl> <body>)  ; Atom or list of atoms
	(PROG <type-B-bvl> <body>)    ; list of atoms
	(PROGV <type-C-bvl> <vals> <body>) ; evaluates to list of atoms
	(LET <type-D-bvl> <body>)     ; atoms, structures, you name it...
	(DEFUN <name-specs> <type-E-bvl> <body>) ; all that and more (&AUX,...)
	(DO <type-F-bvl> <exit-stuff> <bvl>) ; extended subset of LET syntax

    I think it would be nice to move toward regularizing at least some
of these that are similar, so that the language does not develop infinitely
many special cases. (eg, in (shudder) Fortran, one of the common gripes is
having to remember that this form takes arbitrary expressions, this one only
takes integers, this one any integer or variable that is positive, ...)

    One point in favor of the making PROG itself extended... the form

	(PROG (BASE IBASE FOO BAR)
	      (SETQ BASE 10. IBASE 10.)
	      ...)

has within it a timing screw that forces one to do 

	(LET ((BASE 10.) (IBASE 10.) (FOO) (BAR))
	     (PROG ()
		   ...))
or the even worse

	(DO ((BASE 10.) (IBASE 10.) (FOO) (BAR)) () ...).

Why? If ^B is typed (or some error (eg an interrupt loses)) and 
a breakpoint results, you get a bad value for IBASE error. Forcing
the programmer to give up PROG for a non-looping DO or nested LET/PROG 
seems even more ugly than the original idea of just using a PROG...

Btw, to whoever suggested having LET destructure into PROG (if PROG
had this feature installed), - that would leave no guard against
having GO's and RETURN's in the LET. People with programs like:

	(PROG (...)
	      ... (LET (...) ... ( ... (RETURN T) ...) ...) ...)

would find themselves (provided they got past the dot context errors)
with a program that didn't run the way they meant it to any more...
So let's not even consider that idea.

	-kmp

ps Isn't one of these addressee's redundant? (BUG-LISP or NIL)
    - I forget which one

Date: 10 May 1979 14:23-EDT
From: "Guy L. Steele, Jr." <GLS at MIT-MC>
Subject: PROG-LET
To: JONL at MIT-MC, BUG-LISP at MIT-MC
cc: NIL at MIT-MC


    Date: 9 MAY 1979 2021-EDT
    From: JONL at MIT-MC (Jon L White)

    Would any one object to a version of LET, say called "LET-PROG",
    which is like let, but does a PROG action rather than a PROGN action?
    This would allow the destructuring provided by LET be available
    in a PROG context.
       (PROG-LET ((<v1> <e1>) ... (<vn> <en>)) <body>) 
    turns into something like
       (LET ((<v1> <e1>) ... (<vn> <en>))
            (PROG () 
    	      <body>))
    If there's real argument/interest, there could also be PROG-LET*

I guess I don't see why just
	(LET ...
	     (PROG () ... ))
isn't acceptable.  In particular, with a name as long as LET-PROG,
you don't save much at all (one column) in the rightward indentation
drift, which is the typical motivation for such collapsings.

Date: 9 MAY 1979 2316-EDT
From: JONL at MIT-MC (Jon L White)
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC, NIL at MIT-MC

So why won't PROG do?
    Date: 9 MAY 1979 2309-EDT
    From: MOON at MIT-MC (David A. Moon)
    Subject: PROG-LET
    To: JONL at MIT-MC, (BUG LISP) at MIT-MC
    CC: NIL at MIT-MC
    
	Date: 9 MAY 1979 2021-EDT
	From: JONL at MIT-MC (Jon L White)
	Subject: PROG-LET
	To: (BUG LISP) at MIT-MC
	CC: NIL at MIT-MC
	
	Would any one object to a version of LET, say called "LET-PROG",
	which is like let, but does a PROG action rather than a PROGN action?
	This would allow the destructuring provided by LET be available
	in a PROG context.
	   (PROG-LET ((<v1> <e1>) ... (<vn> <en>)) <body>) 
	turns into something like
	   (LET ((<v1> <e1>) ... (<vn> <en>))
		(PROG () 
		  <body>))
	If there's real argument/interest, there could also be PROG-LET*
    Wouldn't it be upward-compatible just to use PROG?
Because none of the current LISP systems allow destructuring in the
PROG variables, and poooor MACLISP doesn't even allow init forms.
The LET macro package could expand into PROG if all such features
were imbedded in PROG.

Date: 9 MAY 1979 2309-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: PROG-LET
To: JONL at MIT-MC, (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

    Date: 9 MAY 1979 2021-EDT
    From: JONL at MIT-MC (Jon L White)
    Subject: PROG-LET
    To: (BUG LISP) at MIT-MC
    CC: NIL at MIT-MC
    
    Would any one object to a version of LET, say called "LET-PROG",
    which is like let, but does a PROG action rather than a PROGN action?
    This would allow the destructuring provided by LET be available
    in a PROG context.
       (PROG-LET ((<v1> <e1>) ... (<vn> <en>)) <body>) 
    turns into something like
       (LET ((<v1> <e1>) ... (<vn> <en>))
            (PROG () 
    	      <body>))
    If there's real argument/interest, there could also be PROG-LET*
Wouldn't it be upward-compatible just to use PROG?

Date: 9 MAY 1979 2021-EDT
From: JONL at MIT-MC (Jon L White)
Subject: PROG-LET
To: (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

Would any one object to a version of LET, say called "LET-PROG",
which is like let, but does a PROG action rather than a PROGN action?
This would allow the destructuring provided by LET be available
in a PROG context.
   (PROG-LET ((<v1> <e1>) ... (<vn> <en>)) <body>) 
turns into something like
   (LET ((<v1> <e1>) ... (<vn> <en>))
        (PROG () 
	      <body>))
If there's real argument/interest, there could also be PROG-LET*

Date: 9 MAY 1979 1132-EDT
From: McLure at MIT-MC (Stuart M. Cracraft)
Sent-by: ___063 at MIT-MC
To: (BUG LISP) at MIT-MC

In maclisp, doing (fasload desc fasl dsk liblsp) and a subsequent 
(describe uread) while supduping from Sri results in the top line
being re-written and made essentially unreadable with the resultant
description.		McLure@SRI-KL.

Date: 8 MAY 1979 0331-EDT
From: JONL at MIT-MC (Jon L White)
Subject: READ confusing TYIPEEK
To: dave.touretzky at CMU-10A
CC: (BUG LISP) at MIT-MC, fahlman at CMU-10A, david.mcdonald at CMU-10A

After reading a symbol which is terminated in some way other
than by right parens or space, the reader does a "putback" of a
pseudo-space (ascii "value" 131.) into the read stream.  This
is somewhat necessary for the operation of the current reader,
and would be quite a pain to try to change.  admittedly it is
a loss for TYIPEEK after such an operation, but you might try
using (READLINE) instead of (LINEREAD).

Date:    8 May 1979 0311-EDT
From:    DAVE.TOURETZKY at CMU-10A 
Subject: bug in MacLisp read routine
To:      bug-lisp at MIT-AI
cc:      DAVE.TOURETZKY, SCOTT.FAHLMAN, DAVID.MCDONALD

There appears to be a bug in the MacLisp read routine whereby,
if the last atom on a line is in ||'s, immediately after READing
this item TYIPEEK returns 131 instead of 13 (carriage return).
Since the value 131 isn't even in ascii, something is clearly
bogus here.  The following lines should be sufficient to reproduce
the behavior I described:

(DEFUN LINEREAD NIL
  (PROG (VAL NXTCHAR)
        (SETQ VAL NIL)
   LOOP (SETQ VAL (NCONC VAL (NCONS (READ))))
   LOOP2 (SETQ NXTCHAR (TYIPEEK))
        (COND ((EQUAL NXTCHAR 13.) (RETURN VAL))
              ((MEMQ (ASCII NXTCHAR) '(| | |)|))
               (READCH)
               (GO LOOP2)))
        (GO LOOP)))

(TRACE READ READCH TYIPEEK)

(LINEREAD) FOO<cr>	; works correctly

(LINEREAD) |FOO|<cr>
()<cr>			; the () is needed to terminate the
			; LINEREAD

(LINEREAD) |FOO| )	; also works correctly

Please reply to this message, whether you can fix the problem
immediately or not.

Thanks.  -- Dave Touretzky


Date: 8 MAY 1979 0310-EDT
From: JONL at MIT-MC (Jon L White)
Subject: FRETRY
To: FAHLMAN at CMU-10A
CC: (BUG LISP) at MIT-MC

I just edited in the (minimal) code to do FRETRY.  Semantics
are: first arg is a pdl-ptr justt as for FRETURN, second is a
4-list as would be output by EVALFRAME except that only the
first and third items are "noticed".  Thus a form is either
evaluated after breaking up the stack, or else a function is
applied to args (after breaking up etc.).  To test it out,
there is an ITS assembled version AI:LISP:BBLISP 812QIO

Date: 7 May 1979 15:17-EDT
From: Howard I. Cannon <HIC at MIT-MC>
Subject:  FILEPOS on TOPS-20/SAIL
To: RWK at MIT-MC, BUG-LISP at MIT-MC
cc: KMP at MIT-MC, Scott at SRI-KL

Both of these systems (SAIL and TOPS-20) seem to have broken filepos's.  I
will look into it when I next get the chance.

Date: 7 MAY 1979 0356-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC, Scott at SRI-KL

    Date: 3 May 1979 19:06-EDT
    From: Kent M. Pitman <KMP at MIT-MC>
    To:   Scott at SRI-KL
    cc:   RWK
    Re:   [Re: [Re: Maybe you could...? I answered all but FILEPOS error]]

        Date:  3 May 1979 1532-PDT
        From: Scott at SRI-KL (Scott J. Kramer)
        In-reply-to: Your message of 3-May-79 1229-PDT

        ... Filepos will only accept a value up to about 42000(10) and barfs at
        anything beyond...  I'm not sure where to go from here, any suggestions
        or should I stop wasting my time? (not really, this is a learning
        experience) I could split the file in half if there's any easy way to
        decrement the pointers.  Oh heck, time to get some sleep. Take it ez...
        -Scott -------

    Breaking it up into several files is pretty hairy but can probably be
    done. I would suggest re-writing this using a software-file-array that
    knows how to jump between files, but I don't think you know what you need
    to do that. Maybe you should spend some time looking at .INFO.;LISP SFA
    and learning what SFA's do... They are a way of creating a 'virtual
    file' in software. 

    Maybe RWK can suggest something?
    -kmp
So why does FILEPOS barf on this?  Is this a TWENEX lossage?  Or is
MACLISP doing something wrong?

Date:  7 May 1979 0112-EDT
From: Scott.Fahlman at CMU-10A (C380SF50)
Subject: Retry function for debugger.
To:   BUG-LISP @ MIT-AI
CC:   fahlman at CMU-10A, touretzky at CMU-10A
Message-ID: <07May79 011249 SF50@CMU-10A>


We (meaning mostly Dave Touretzky) are working on a new debugging package
for MACLISP.  One common need is to crawl a few levels up the stack,
change something that caused the bug (edit a function, etc.), then retry
everything below this level.

To do this right, we need a new function (FRETRY x).  This would be just
like FRETURN, except that it retrys the function associated with the
argument (a pdlptr) rather than returning a given value from it.  The
stack would be peeled back to the pdlptr position before the form is retried.

This is not a class AAA priority.  We can fake the effect, but only by a lot
of very ugly hacking which leaves the old losing stack intact, jumps back
over it, and makes it invisible during baktrace.  It seems to me that FRETRY
(or whatever you want to call it) should be easy to do, given that FRETURN
already exists.  And it cleans things up tremendously.  It seems to me to
be a logical part of the LISP virtual machine.
-- Scott Fahlman


Date: 6 May 1979 14:39-EDT
From: Mark L. Miller <MILLER at MIT-AI>
Subject:  Interrupts in 20X MacLisp
To: MILLER at MIT-AI, BUG-LISP at MIT-AI, steve at SRI-KL,
    DEKLEER at PARC-MAXC2

More generally, as I understand it, there are many characters (^C, ^G)
which are hard-wired in 20X maclisp.  This is a gross loss (please
correct me if I am confused!).  [I realize DEC may be at fault!]

In general, any programming system which does not support (or at least
ALLOW under some degree of user effort) full 128 character,
character-at-a-time I/O (preferably 256 chars) is a loss for a CS
research&development system.  For example, you cannot simulate (much less
implement for serious use) Emacs!  Every char should be user-redefinable,
as an interrupt included.  The more compromises that are made with this,
the worse off you are.  If it cannot be fixed, it will eventually
contribute to the outside world's decision that Lisp not be taken
seriously.

Regards, Mark


Date: 6 May 1979 13:46-EDT
From: Mark L. Miller <MILLER at MIT-AI>
Subject: LEDIT on TOPS-20 and TNX.
To: DEKLEER at PARC-MAXC2
cc: MILLER at MIT-AI, BUG-LISP at MIT-AI, RMS at MIT-AI,
    steve at SRI-KL


I think there is a way in Emacs to start a lower fork, and have
the MacLisp be the inferior job.  That is, to me, at least as good
(if not better) than the other way around.  (Ideally, of course,
you should be able to do it in either direction).

Mark


Date:  5 MAY 1979 1238-PDT
From: DEKLEER at PARC-MAXC2
Subject: LEDIT on TOPS-20 and TNX.
To:   steve at SRI-KL, miller at MIT-AI, bug-lisp at MIT-AI

A partial answer to all the people asking about LEDIT.

A LEDIT for INTERLISP exists.  (It was developed at SRI by
Boyer.) If you want to see the code I can mail it to you.
However, this version is quite hairy to put it mildly.  I
could implement a much simplified (and only  slightly less
efficient) version, except for one thing: the interrupt
system.  The problem is that the interrupt system is shared
amongst the processes in ways I dont understand.  For
example, if you start a EMACS below your MACLISP and type
say ^x you will be back in MACLISP!!!  At least in TNX (and
I think it is the same in TOPS-20) all the usual ways of
munging the interrupt table lose;and you have to explicity
enable and disable  all the interrupts as you move between
EMACS and MACLISP.  This means you (MACLISP) has to know
what it wants all the interrupts to be and explicitly do
ATI's and DTI's.  This is what the TOPS-20 INTERLISP-LEDIT
system does.  I havent found a place in MACLISP to do this,
is there a way?  The problem is that it is impossible to get
the entire state of the interrupt system for a process from
from TNX (and TOPS-20, I think).

You might also look at the code for EXEC in INTERLISP, it is a piece
of LISP code.

Masinter just walked in and suggested another way to do it --
I'll send anoter msg if it works.
-------


Date: 5 MAY 1979 0409-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(PROGV '(A (B 0) C) '(Z Z Z) ...)
could give a better error msg than
;(NIL . Z) NIL CLOBBERED

Date: 4 MAY 1979 1752-EDT
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 I/O
To: (BUG LISP) at MIT-MC

Some bugs I' recently aware of
1) OPENs on the TTY device have a low probability of winning, in particular
   (OPEN '((TTY)) '(IN FIXNUM SINGLE TTY)) produces a file object which
   barfs when you try IN on it;  some other options even cause an Ilgl mem
   ref.  
2) OPEN with the APPEND option fails.

MILLER@MIT-AI 05/04/79 11:46:33
To: (BUG LISP) at MIT-AI
CC: MILLER at MIT-AI
 I agree with Scott@SRI-KL re. the need for a valret.  But probably it
should be possible for the valret to work in a LOWER fork, so that
valret-ting a string which loads a non-"ephemeral" does not clobber the
Lisp!
 Or, does 20X MacLisp have anything analogous to the SUBSYS function in
InterLisp?  It would be VERY useful (e.g., for implementing a decent LEDIT
protocol!).
 perhaps the SUBSYSfunction should take TWO args, the first, a string like
"EXEC", ala Interlisp; the second, a string appropriate for valret-like
capabilities.  VALRET would then be AS IS, to be used with appropriate
caution.  Then you could do something like this:
    (defun Ledit fexpr (X)
           (comment need a way to pass info down, e.g., X, -- any ideas?)
           (cond (emacs-handle (subsys emacs-handle
                                       '|CONTINUE/
|))
                 (t (setq emacs-handle
                          (subsys 'EXEC '|EMACS/
|)))))
    Regards, Mark


Date:  4 May 1979 0738-PDT
From: Scott at SRI-KL (Scott J. Kramer)
Subject: Valret in TWENEX maclisp
To: bug-lisp at MIT-AI

Is there an equivalent to valret in TWENEX maclisp?	-Scott
-------


Date: 4 MAY 1979 0408-EDT
From: MMCM at MIT-MC (Mike McMahon)
Subject: filepos
To: (BUG LISP) at MIT-MC
CC: scott at SRI-KL

the problem is that F.FLEN is the number of words rather than bytes
in the file, so you can only read 1/5 of the it.
part of this seems to stem from FBT.AP being defined to 0 while OPEN3G
seems to expect it to mean the same thing as on ITS (ie random access
possible).

Date: 3 MAY 1979 2153-EDT
From: DCP at MIT-MC (David C. Plummer)
To: (BUG LISP) at MIT-MC

sorry, I forgot I was in base eight!!

Date: 3 MAY 1979 2151-EDT
From: DCP at MIT-MC (David C. Plummer)
To: (BUG LISP) at MIT-MC

(status daytime) doesn't, at least it gave (25 62 37) when the time was
21:51:15 on May 5, 1979.

Date: 3 MAY 1979 1337-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Floating-print
To: (BUG LISP) at MIT-MC

9.22336325E+18 prints out as 9.2233633E+18, which sadly reads in
as one lsb higher.

Date: 3 MAY 1979 1124-EDT
From: JONL at MIT-MC (Jon L White)
Subject: GRINDEF and "grind init" files
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC


EOPEN is merely a pseudonym for OPEN (except on the SAIL system,
where it hacs the double-starting-point files of the Stanfrob
system).  The reason why there is an ERRSET around an OPEN,
rather than the logical PROBEF, is that PROBEF was never hacked
to take the NODEFAULT option.  Another reason is that the change
to the init file scheme was unwise in choosing the name "*" as
the first file name for anything.

Date: 3 MAY 1979 0813-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Half Bug / Half Already-fixed Bug
To: (BUG LISP) at MIT-MC

I have been getting 

Loading GRINDEF 420
;(OPEN ((DSK KMP) * GRIND) (NODEFAULT)) FILE NOT FOUND

for a long time now at various random times...I have just figured
out why ... Rather than a PROBEF, GFN seems to do

(ERRSET (FUNCALL (COND ((STATUS FEATURE SAIL) 'EOPEN) (T 'OPEN)) ...) ())

There seem to be two bugs here ... 

1. The file never gets closed (I haven't fixed this ... I don't know what
    EOPEN does so am hesitant to fiddle with the code following it)

2. If the open fails, presumably the ERRSET is supposed to harmlessly trap
   the error - but if ERRSET (var) is bound, it doesn't - the error still
   BKPT's ... so I have fixed it up to be

     ((LAMBDA (ERRSET) (ERRSET ...)) NIL)

   in version 421 of GRIND. 

If someone could look at bug (1) mentioned above tho' it would be nice.
Presumably the file array will get closed next time the garbage collector
runs but that's pretty hackish...

Also, if someone could give me info on what EOPEN does that's different
from OPEN, maybe it is something compatible with my IOTA package and
we could use IOTA in this case...

Thanx. -kmp

GSB@MIT-ML 05/02/79 13:31:34 Re: DIRECTORY
To: (BUG LISP) at MIT-ML
doesn't know about file authors.


Date: 2 May 1979 09:51-EDT
From: Mark L. Miller <MILLER at MIT-AI>
To: KMP at MIT-MC, BUG-LISP at MIT-MC
cc: NIL at MIT-MC


Ouch.  LAST may be a misnomer, but then so is CDR.  Are you guys
implementing a better Lisp, or inventing a new language related to Lisp?

Why not leave LAST alone and write two trivial macros, LASTEL and LASTCDR?
(Or have LASTEL and LASTCDR, and supply old-style LAST as a builtin macro
for compatibility?)

There is a lot to be said for compatibility.  When compatibility is out, at
least avoid recycling names!

Regards, Mark


Date: 1 MAY 1979 0844-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC


    ANDYA@MIT-AI 04/30/79 22:02:35
    The point of stopping that I mentioned in my other message is
    (inf0;) clro3) .call clrin9 (reset)
 
Is there any chance of this being fixed?  The problem is that this reset
is being done with interrupts off.

Date: 1 MAY 1979 0516-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(defmacro foo (mumble '&aux (exlnm (explodec mumble)))
   (workupon mumble exlnm))
doesn't seem to calculate the explodec at the right time.

Date: 1 MAY 1979 0249-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

I wonder if the lisp function LAST should not become in NIL
and/or MACLISP  two functions: LAST (like NTH) and LASTCDR 
(like NTHCDR) ... 

would break some code, but I've always thought LAST was a 
misnomer since it gets more than the last element...

-kmp

jis@MIT-AI (Sent by HENRY@MIT-AI) 04/26/79 22:22:33
To: (BUG LISP) at MIT-AI
CC: JIS at MIT-AI
	Arraycall gives the error message "TOO MANY ARGUMENTS SUPPLIED" when the error
in fact may be too FEW arguments. I.e.

(array foo t 3 4) ==> foo
(setq foo (get 'foo 'array)) ==> #T-mumble-mumble..

(arraycall t foo 0 0) ==> nil ;this is ok
(arraycall t foo 0)

TOO MANY ARGUMENTS - APPLY ((NIL . 0) (NIL . 262141))

			-Jeff


Date: 24 April 1979 02:21-EST
From: Howard I. Cannon <HIC at MIT-MC>
To: KMP at MIT-MC, BUG-LISP at MIT-MC


    Date: 24 APR 1979 0054-EST
    From: KMP at MIT-MC (Kent M. Pitman)
    Sent-by: TURNIP at MIT-MC

    How come
    (DEFUN EXPR LEXPR X) 'works' - ie, doesn't err out, but
    (DEFUN LEXPR EXPR X) doesn't... 

    I should think they're both errors since the first two frobs can come
    in either order... 
    -kmp
-----
The name and the flag cannot come in either order.  This is a fairly old change.

Date: 24 APR 1979 0054-EST
From: KMP at MIT-MC (Kent M. Pitman)
Sent-by: TURNIP at MIT-MC
To: (BUG LISP) at MIT-MC

How come
(DEFUN EXPR LEXPR X) 'works' - ie, doesn't err out, but
(DEFUN LEXPR EXPR X) doesn't... 

I should think they're both errors since the first two frobs can come
in either order... 
-kmp

Date: 23 April 1979 22:18-EST
From: Howard I. Cannon <HIC at MIT-MC>
Subject: (PRINT x) returns T
To: JONL at MIT-MC, moon at MIT-AI
cc: BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC, glr at MIT-AI


    Date: 23 APR 1979 2208-EST
    From: JONL at MIT-MC (Jon L White)

    What was the idea you had in mind when you said "frivolous"?
    Won't the lispm incompatibility make code difficult to translate,
    e.g.  (AND (TEST X) (PRINC '|Here, X = |) (PRINT X) (PRINC '|(lbs)|))
    since the last PRINC wouldn't be done when X is null.
------
Yes, this is an incompatibility, but we believe that code like this is
cretinous anyway (yesh, this is glossing over the issue).  The utility
of having PRINT return its arg is greater than the utility of supporting
such losing code.

Date: 23 APR 1979 2208-EST
From: JONL at MIT-MC (Jon L White)
Subject: (PRINT x) returns T
To: moon at MIT-AI
CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, glr at MIT-AI

What was the idea you had in mind when you said "frivolous"?
Won't the lispm incompatibility make code difficult to translate,
e.g.  (AND (TEST X) (PRINC '|Here, X = |) (PRINT X) (PRINC '|(lbs)|))
since the last PRINC wouldn't be done when X is null.

Date: 23 APR 1979 2203-EST
From: JONL at MIT-MC (Jon L White)
To: GLR at MIT-MC
CC: (BUG LISP) at MIT-MC

I don't like the idea of EOF closing any thing that the
reader currently has "open", such as
1) supplying enough close parens to balance
2) supplying a <cr> for a hanging ";"
3) supplying a <space> in order to terminate a symbol or number
4) any other such guessing games.

Date: 23 APR 1979 1136-EST
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC

My impression is that Trace used to use the value of Prin1 at the time
of installing the trace, while now it uses the runtime value of Prin1.
Is there any mechanism for specifying the printing function at trace
installation time nowadays?  It would be very useful for Libmax;Ftrace,
which is a tracer that uses a Mathlab-oriented Prin1.  (Perhaps it
never worked in the way I say; nonetheless, that way would be useful.)

Date: 19 April 1979 16:08-EST
From: Howard I. Cannon <HIC at MIT-MC>
To: KMP at MIT-MC
cc: BUG-LISP at MIT-MC, RWK at MIT-MC


    Date: 19 APR 1979 1201-EST
    From: KMP at MIT-MC (Kent M. Pitman)

    (PROGN (NOINTERRUPT T)
           (UNWIND-PROTECT
    	(NOINTERRUPT T)
    	(NOINTERRUPT T)
    	(NOINTERRUPT NIL)))

    Why is NOINTERRUPT set to NIL at the end of this sequence?
-----
FIXED.

Date: 19 APR 1979 1201-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC, RWK at MIT-MC

(PROGN (NOINTERRUPT T)
       (UNWIND-PROTECT
	(NOINTERRUPT T)
	(NOINTERRUPT T)
	(NOINTERRUPT NIL)))

Why is NOINTERRUPT set to NIL at the end of this sequence?

Date: 17 April 1979 11:44-EST
From: Robert W. Kerns <RWK at MIT-MC>
To: BUG-LISP at MIT-MC

In a fresh LISP do:

(SETQ FOO (NCONS NIL))
(RPLACA FOO FOO)

;BKPT
;BKPT
;BKPT PDL-OVERFLOW
<control-G>
Watch it blow out to DDT with PDL-overflow interrupt.

Date: 16 APR 1979 1349-EST
From: MOON at MIT-MC (David A. Moon)
To: GLR at MIT-AI
CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC

    GLR@MIT-AI 04/15/79 14:53:06
    To: (BUG LISPM) at MIT-AI
    In the LISPM, (print 'FOO)  returns FOO
    In Maclisp, it returns T

In my opinion this is a bug in Maclisp.  Maclisp's print used to return
its argument on the 10, and still does on Multics.  It was changed for
frivolous reasons.

GLR@MIT-AI 04/16/79 11:28:46 Re: +INTERNAL-/;-MACRO
To: (BUG LISP) at MIT-AI
The ; macro blows up if it comes to the end of a file before
a carriage return.  It should just return.

Right now a (load file) will work for

(print 'foo)	;this prints foo
<EOF>

and won't work for

(print 'foo)	;this prints foo<EOF>




Date: 14 April 1979 15:59-EST
From: Howard I. Cannon <HIC at MIT-MC>
Subject: bugs in tops-10 lisp (from FININ@mit-ai)
To: DEWOLF at WPAFB-AFAL
cc: BUG-LISP at MIT-MC, FININ at MIT-AI

    [1] .INI files
       Initialization files are not being read properly.  More
       often than not, some characters in a .INI file are mis-read.
-----
Can you give a specific example of this.  INI files seem to work on other systems.
Sending an init file that fails would be greatly appreciated.
-----
    [2] Supressing a .INI file
       There is no way to supress the reading of a .INI file.  Specifically,
    	RUN COM:NLISP;
    	RUN COM:NLISP; . 
-----
Yeah, on eof these days when I get off my butt....
-----
    [3] BPS space fixed
       From Peter Dewolf[1,762] on April 5, 1979 at 2:44 PM
       I recall seeing (during my scan of lisp.new) that they were adding assembly
       conditionals based on processor type--ka, ki, kl.   If you are on a ki or kl
       running under a virtual memory monitor, you can do core allocation with PAGE.
       UUOs, which allow you to allocate a page anywhere you want.  The only thing
       you have to be careful of doing is shrinking core with a CORE UUO, which will
       deallocate the non-contiguous pages too.  Given this fact, I wonder why they
       complain about tops-10?  Maybe they don7t want to do much work on a tops-10
       version of maclisp, and hence do not want to have to write code that will
       check if you are using a vm monitor (which is easy to check) and do page. uuo
       core allocation if so.  (another probelm with that is that individual users
       may or may not have the ability to go virtual.  I would hope that they could
       use page. uuos within their physical cormax, though!)
-----
Use of Tops-10 VM is planned.  I will probably hack this during the summer sometime
at CMU, and will have a version ready for release by September if all goes well.
-----
    [4]  ^U disabled
      From Peter Dewolf[1,762] on April 5, 1979 at 2:36 PM
      is it my imagination, or does ^U no longer work in nlisp to erase the
      current line?
     
 Yes indeed, ^U has been disabled.  I don't know if there is a substitute,
     or if one can be programed easily.
-----
Hmmm...yeah, default is character mode I/O.  If you do an (SSTATUS LINMODE T) you
will probably get ^U processing.
-----
    As a whole, this versions seems to run pretty well.
-----
Thanks!


--Howard

Date: 13 APR 1979 1409-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___051 at MIT-MC
Subject: Correction
To: (BUG LISP) at MIT-MC

It's the LOAD option in the inner file's EVAL-WHEN that causes the forms
to go to the output file.  This is still a screw, it means that a file either
has to be set up to be loaded interpreted but uncompilable, or vice versa.

Date: 13 APR 1979 1406-EST
From: rwk at MIT-MC (Robert W. Kerns)
Sent-by: ___051 at MIT-MC
Subject: EVAL-WHEN, AGAIN!
To: (BUG LISP) at MIT-MC

It seems that if you do
(EVAL-WHEN (COMPILE) (LOAD 'FOO))
where FOO contains (EVAL-WHEN (COMPILE) ...)
that it outputs the forms in FOO's EVAL-WHEN to the fasl file.  BAD NEWS!
How about EVAL-WHEN inside an EVAL-WHEN reverting to the old definition?
Much better than these infinite screws I'm getting!

Date: 12 APR 1979 1101-EST
From: JONL at MIT-MC (Jon L White)
Subject: SYSCALL - number of args
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC

Code seems to be checking for 2 or more args, so this is
simply a glitch in the atom-header for syscall.  Have patched
and fixed source.

Date: 12 APR 1979 1051-EST
From: JONL at MIT-MC (Jon L White)
Subject: Your note of 4/12/79 on EVAL-WHEN
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

When compiling a file, the definition of EVAL-WHEN is
changed, so that
(EVAL-WHEN (COMPILE) (LOAD '|mumble|))
will actually happen (without this change, EVAL-WHEN only
evaluates when EVAL is in the condition list).  Unless there 
is some switch, currently lacking, there is no way for
LOAD and/or MAKLAP to distinguish the state in which the
EVAL-WHEN above happens, and that in which a form from the
file |mumble|  happens.  Does this imply that EVAL-WHEN is
only fully-definable at toplevel?  What does LISPM do
with respect to this problem?

Date: 12 APR 1979 1045-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___074 at MIT-MC
Subject: SYSCALL of two args
To: (BUG LISP) at MIT-MC

Why does SYSCALL require that you give it at least 3 arguments, including
at least one call argument, when there are system calls which don't require
any call arguments???

Date: 11 Apr 1979 (Wednesday) 1235-EST
From: DEWOLF at WPAFB-AFAL
Subject: bugs in tops-10 lisp (from FININ@mit-ai)
To:   jonl at MIT-AI, bug-lisp at MIT-AI


Dear Jonl et. al.;

I'm enclosing a file which describes some of the problems
that we've encountered in the new lisp.  The major one
has to do with the reading of .INI files.  Lisp seems to
get garbled characters when it reads one.

--------------------------------------------------------------
This file documents bugs and problems in the new Lisp.  

[1] .INI files
   Initialization files are not being read properly.  More
   often than not, some characters in a .INI file are mis-read.

[2] Supressing a .INI file
   There is no way to supress the reading of a .INI file.  Specifically,
	RUN COM:NLISP;
	RUN COM:NLISP; . 
   do not work.

[3] BPS space fixed
  From Peter Dewolf[1,762] on April 5, 1979 at 2:33 PM
  sigh.    One would have hoped that the bibopification of tops-10 lisp
  would not have precluded expansion of bps.

   From Maclisp[5,720] on April 5, 1979 at 2:44 PM
   MIT claims that this is due to a misfeature of TOPS-10.  On ITS, List
   spaces grow from one end of core and BPS space grows from another.  BPS
   space should always be contiguous.  As I have been told, on TOPS-10, one
   can only expand core in one direction.

   From Peter Dewolf[1,762] on April 5, 1979 at 2:44 PM
   I recall seeing (during my scan of lisp.new) that they were adding assembly
   conditionals based on processor type--ka, ki, kl.   If you are on a ki or kl
   running under a virtual memory monitor, you can do core allocation with PAGE.
   UUOs, which allow you to allocate a page anywhere you want.  The only thing
   you have to be careful of doing is shrinking core with a CORE UUO, which will
   deallocate the non-contiguous pages too.  Given this fact, I wonder why they
   complain about tops-10?  Maybe they don7t want to do much work on a tops-10
   version of maclisp, and hence do not want to have to write code that will
   check if you are using a vm monitor (which is easy to check) and do page. uuo
   core allocation if so.  (another probelm with that is that individual users
   may or may not have the ability to go virtual.  I would hope that they could
   use page. uuos within their physical cormax, though!)
   

[4]  ^U disabled
  From Peter Dewolf[1,762] on April 5, 1979 at 2:36 PM
  is it my imagination, or does ^U no longer work in nlisp to erase the
  current line?
 
 Yes indeed, ^U has been disabled.  I don't know if there is a substitute,
 or if one can be programed easily.
 
	Tim

--------------------------------------------------------------

As a whole, this versions seems to run pretty well.

Tim



BAKER@MIT-AI 04/11/79 10:27:50 Re: Maclisp
To: JONL at MIT-AI, (BUG LISP) at MIT-AI
CC: BAKER at MIT-AI
I don't know whether Maclisp is using the appropriate TTCALL functions
for TOPS-10.
1.  If I do (setq foo (open '((tty) foo bar) '(output ascii single))),
it ignores the tty and opens the thing as a disk file anyway.  The only
way I can get a tty output stream is by doing:
(setq foo (open '((tty) foo bar) '(tty output ascii single))), in which
case, it takes various defaults (such as "image" from the current
"tyo" file, and refuses to open it in ascii mode.

2.  Maclisp still does the wrong thing even in ascii mode output to
the tty.  The initial tyo has the attributes (tty output ascii single),
yet when (tyo 9.) is done, it sends the tab to the tty in image mode,
tthus the system can't convert it to blanks.  Doing
(princ (implode '(9))) does the same thing, so its not a property of
only tyo.

3.  Maclisp should use the TTYCALL "OUTCHR" to output characters singly
in ascii mode, "OUTSTR" to output characters in block mode in ascii,
and "IONEOU" to output 8 bit image characters~.  In other workds, on TOPS-10,
you must look at the file type to determine which instruction to
use before outputting a character.

4.  This is clearly a change from the previous version of Maclisp, in which
OUTCHR was use for everything.  Now, it appears as if IONEOU is used for
everything, which is not an improvement.  (The problem shows up in grindef,
which outputs tabs for its spacing requirements, which don't get converted
into spaces if IONEOU is done.  the problem also shows up with the terpri
switch, which is now ignored, and "print" no longer generates crlf whether
or not the terpri switch is on.

5.  For student use, the tyo is better left in ascii mode, while for
clever control of terminals, one would rather use image mode.

6.  Give me a call at (716)-275-5860 if you have any questions.


Date: 10 APR 1979 2245-EST
From: gls at MIT-MC (Guy L. Steele, Jr.)
Sent-by: RZ at MIT-MC
Subject: FORMAT
To: (BUG LISP) at MIT-MC
CC: (BUG lispm) at MIT-AI

Unfortunately FORMAT has a gross incompatibility between LISPM
and MacLISP, namely the treatment of T as the stream argument.
In MacLISP NEWIO, T has standardly denoted the value of TYO
(i.e. the tty) (subject to ^W), while NIL has meant the "standard
output" (i.e. TYO subject to ^W plus OUTFILES subject to ^R).
Now to FORMAT, NIL means "make a string", so that can't be used
as in NEWIO.  So on LISPM T means "standard output".

My suggestion is that the MacLISP FORMAT be changed so that T
is specially recoggnized and caused to mean "standard output"
(by being changed to a NIL file specification).  The theory is
that most programs could then be mmade compatible between LISPM
and MacLISP.  If it is necessary in MacLISP to get the effect
of T as a file specification, (T) can be used instead.

GLS@MIT-MC 04/10/79 16:10:29 Re: Question about 12-bit I/O from Knight displays
To: SJOBRG at MIT-AI, (BUG LISP) at MIT-AI
The user-supplied TTYINT function will get TWO arguments.
One is the file object for the interrupting tty, and the other
is the character which caused the interrupt.  For a 12-bit
tty this will be a 12-bit character.  It is up to the user
function to filter out unwanted CTRL/META combinations
itself.  It is a crock, I'm sorry, but it is a way to do the job.
Sigh.



JOHAN@MIT-AI 04/10/79 14:56:19
To: (BUG LISP) at MIT-AI
Running QC on AI with JOHAN;CBUG 5 and my compiler init file produces
"    RESTORE lossage in function MOVE-CURSOR
;%%%%%%%%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%%%%%%"




SJOBRG@MIT-AI 04/10/79 14:00:23 Re: Question about 12-bit I/O from Knight displays
To: (BUG LISP) at MIT-AI
CC: SJOBRG at MIT-AI
Suppose I want to re-open my tty in 12-bit input mode, using the
function GLS suggested in an earlier LISP NEWS report.  This
correctly sets the tty interrupt (via (sstatus ttyint ... )) to
require the CTRL key before invoking any of the standard system
functions.  However, how do I get it to require the CTRL key on
non-standard functions?  For example, I have ^E wired to the
LEDIT-TTYINT function.  I can't (according to Ch. 3 of the 
Lisp manual) just say
     (sstatus ttyint 5 'LEDIT-FUNCTION)
since that doesn't guarantee that 5 (when input as a TOP'ified
char) won't invoke LEDIT.  Nor can I say
     (sstatus ttyint 5 205)
since channel 5 is not a standard system function (gives NIL).

What do I do?


Date: 10 April 1979 06:55-EST
From: Richard L. Bryan <RLB at MIT-MC>
To: JONL at MIT-MC, CWH at MIT-MC
cc: BUG-LISP at MIT-MC

If the LISP editor is made autoloadable, why not translate it from MIDAS 
back into LISP?  Who was Binford, anyway?

Date: 10 APR 1979 0158-EST
From: JONL at MIT-MC (Jon L White)
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

I use the in-core editor frequently.  Probably would not hurt
to make it autoloadable, or even extend its functionality, but
I'd like at least the current capability.

Date: 10 APR 1979 0142-EST
From: DCP at MIT-MC (David C. Plummer)
To: (BUG LISP) at MIT-MC

try:
(progn (tyipeek) (read))
and give it input of  the character 1  then the character space.
(tyipeek) whould do a wait, and read should see "1 " as a completed
form, aparently it doesn't. If the input is  "1 6 "  it returns
1 from the progn then returns 6 from the regular lisp reader.
Is this right??  I would view this as wrong behavior.

Date: 9 APR 1979 1845-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Lisp MAR Break handler lossage
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

(STATUS/SSTATUS FEATURE MAR ...) seems to not work as documented.
doing
(LOAD '((DSK JONL) MAR BUG))
will run an example of the bug automatically.

Date:  9 Apr 1979 (Monday) 0248-EST
From: DEWOLF at WPAFB-AFAL
Subject: (from Finin@mit-ai)
To:   jonl at MIT-AI, bug-lisp at MIT-AI


Re: rubout processing on tops-10

Is there any SIMPLE way to get maclisp to backspace over
rubbed-out chars typed on the TTY?  Like telling maclisp
that one is using a glass type terminal?  I don't even care
if the rubout processing is super dumb, requiring manual
^L's or ^K's.  

I used to win (in LISP 1137 w/o newio or bibop) by changing
^H's syntax and re-defining ^H's interupt function and then
using ^H as the rubout character.  Actually,  I'd like to
continue to use ^H as the rubout, as:
  (1) This is the rubout char used by almost everyone throughout
	the rest of the system.
  (2) Our most common TTY is the Hazeltine 1500 which has rubout
	as a shift key (sigh).

Tim 




PRATT@MIT-AI 04/08/79 07:49:09
To: (BUG LISP) at MIT-AI
AI:PRATT;LOSING LISP lost at
MPV; 11540


Date: 8 APR 1979 0134-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

Does anyone still use the "edit" function in lisp?  Would it be possible to
remove it from the default lisp and make it autoloadable?  This might buy
macsyma some badly needed address space.  (How much?)

Date:  5 Apr 1979 2304-EST
From: Scott.Fahlman at CMU-10A (C380SF50)
Subject: Problems in TOPS-10 MACLISP
To:   BUG-LISP @ MIT-MC
Message-ID: <05Apr79 230454 SF50@CMU-10A>


Hi,
We're having lots of problems with relatively simple bugs that, instead
of trapping back to MACLISP, cause the LISP to flame out to the TOPS-10
monitor.  In particular, things like SETQ'ing NIL and FASLOADing too
much into the fixed BPS allocation cause a fatal trap back to the system.
Which makes it hard to debug the losing code.  I seem to recall that there
is a way in TOPS to get hold of such errors in the user program, and I think
I remember some code in the MACLISP source listing that claimed to be for
this purpose, but either I was hallucinating (I can't find it now) or it
is busted.  Anyway, if it's a relatively easy fix it is something that we
really could use.

We're also having a weird problem with RENAMEF clobbering things that it
should have no way of getting at, like the CDR of a list that is being
MAPCARed, with the car eventualy going to RENAMEF.  It looks like it's
clobbering something on the stack or the contents of a register or something
of the sort.  Sorry I can't be clearer about the problem -- we're trying
to get a nice clean case to send you, but it seems to show up only within
certain hairy functions we've written (Touretzky's SLURP package).  When
we get a clean form of the bug we'll send it.  In the meantime, if anything
occurs to you (as in "Oh yeah, the old RENAMEF bug is back") we'd like to
hear about it.

Thanks,
Scott Fahlman

GLS@MIT-AI 04/05/79 03:31:26 Re: Backquote
To: (BUG lisp) at MIT-MC
CC: GLR at MIT-AI
A fairly weird idea is instead of having a non-backquote quote,
to have a non-evaling comma.  Suppose that ";" were a non-evaling
comma (its only effect is to cancel one level of backquoting for
comma-searching purposes: hence `;foo = (QUOTE FOO)).
Then instead of `(foo ',bar) one could write `(foo `;,bar),
in which the ; would cancel the inner ` so that the outer `,
not the inner one, would see the ,.  However, I cannot see any
situation in which one would want to write ; except directly
after a `.  So why not compress the two into a single
character so that "`;" is represented just by "'".  QED


HIC@MIT-MC 04/04/79 15:02:34
To: glr at MIT-AI, (BUG LISP) at MIT-AI
There is one place that a backquote is not equivalent to a quote:

`(foo ',bar)

evals to:

(foo '<the value of bar>)

I don't believe that this can be done without the use of a non-backquote quoter.



glr@ai (Sent by NIS) 04/04/79 11:53:29
To: (BUG LISP) at MIT-AI
CC: GLR at MIT-AI
	Why do we have both a quote and a backquote macro?
Every place that quote is used now, backquote would serve as
well.  So why don't we just rename quote to backquote?
	Using backquote in place of quote doesn't need to cost
much either.  Backquote could assume that it will normally be doing
a quote, but will change its mind if the sexpression has a comma
in it.  The comma check can be done very quickly by having comma
set a flag as it is read in.
	The advantages of this change are admittedly slight.
The backquote character is freed for some other use and some
redundancy is removed from lisp read table.


PRATT@MIT-AI 04/03/79 04:57:39
To: (BUG LISP) at MIT-AI
How come CHARPOS won't accept a list of file objects as its argument?
Is there some other way of getting a program that normally outputs
to one file to output to several files?  (In the presence of CHARPOS
of course.)


Date: 3 APR 1979 0210-EST
From: JONL at MIT-MC (Jon L White)
Subject: SPRINTER saying "eload" upon autoloading
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC

FIXED.  

Date: 3 APR 1979 0201-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

In a fresh MACSYMA, type ^^ to get into LISP, then 
'(1 2 3)  (SPRINTER *) 
gives  Call to an undefined function EOPEN.


EGBERT@MIT-DMS 04/02/79 23:15:32
	Is there any documentation for using Maclisp on TOPS-20, such as what
isn't supported, differences in I/O, and where to put inits?  I hope to be
using it extensively on XX.
	Thanks.

					Ed Gilbert

^_



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

(MAPCAN '(LAMBDA (X) 'A) '(X Y))
gives the error message:
;A ATOMIC ARG TO LAST

This doesn't aid any in debugging ... could you make the error say
something maybe about MAPCAN? Thanx.


Date: 31 MAR 1979 2310-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, HIDAY at MIT-AI

LISP now increments its GENSYM number on (GENSYM 'FOO)
THis has been fixed in the source and patched on all systems.

Is a system message in order??   Have lots of people been screwed by this?

GLS@MIT-AI 03/31/79 21:12:29
To: (BUG LISP) at MIT-AI
I must agree with HIDAY: DAM and others have had to write incredibly
contorted code because (GENSYM 'X) does not do an increment.


HIDAY@MIT-AI 03/31/79 16:07:45
To: (BUG LISP) at MIT-AI
(gensym 'foo) does not increase its decimal numbers.


JOHAN@MIT-AI 03/31/79 13:04:02 Re: tnx-lisp
To: (BUG LISP) at MIT-AI
At LFGBLK, the default version number is 99999.  Namestring sometimes
fails or has an unwelcome side effect:

[1]  Namestring should always succeed if the string given it is
syntactically correct.  However, *sometimes* if you name string an
existing file without specifying a version number, GETJFN will give
you error : No such version.  namestring will always succeed
on nonexistant file names.  This appears to be a TNX bug.  Hackers
here claim that output file groups are not guaranteed to work.

[2]  A side effect of many namestrings is to cause the version number of
the existing file set to 99999.  eg.  If EMACS is haning onto file foo.lsp;89
and you read that file into lisp, and then go back to the original EMACS
and do ^x^s you will write ot foo.lsp;99999.  I see that the no acess by
other forks bit is on, so maybe someone is aware of this problem.  But I
dont think that bit does anything.  (Or I am confused about what is means).

Solution:  Make RH of LFGBLK -3.  This is equivalent to '*' which is
always the right thing.


Date: 31 MAR 1979 0255-EST
From: JIS at MIT-MC (Jeffrey I. Schiller)
To: (BUG LISP) at MIT-MC


	If you do a (tyi 13. <file-object>) tyo gives you at
line-feed along with the carriage return when you are outputting to a
file. The problem is that the line-feed is delayed until the next character
is tyoed. Ie. if you do a (tyo 13. <file-object>) then a
(filepos <file-object> (sub1 (filepos <file-object>))) and then some more
i/o. instead of having just the carriage return (13.) like one would
expect, you wind up with just the line-feed (10.).

	If I have Gc stats turned on during a program hacking these
things the base  for output to the console seems completely screwed up.
i.e.

;GC DUE TO LIST SPACE
; ^{ [34%] LIST  AB [78%] FIXNUM .... get the picture.

At one point Lisp blew up with an illegal machine operation.

	If someone is willing to look into this I can cause the
base problem to happen at will. along with the tyo problem

			-Jeff

Date: 30 MAR 1979 0531-EST
From: MACRAK at MIT-MC (Stavros M. Macrakis)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

|a/<cr>b| and |a/<cr>/<lf>b| print out identically, even though
exploden knows the difference.  Note that simpler cases do strange
thing--it tries to be clever about | vs. / , but still manages not
to distinguish the two.

GLS,GJS@MIT-AI (Sent by GLS@MIT-AI) 03/29/79 21:43:23 Re: FORMAT
To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI
FORMAT should have something which is like ~S but
which uses SPRINTER or something instead of PRIN1.


Date: 29 MAR 1979 1806-EST
From: SUN at MIT-ML (Alex Sunguroff)
Subject: The tops-10 padding problem.
To: (BUG LISP) at MIT-ML
CC: RPG at MIT-ML

No it is not a tops-10 problem but a LISP problem since
it is a feature of 1804 and not of 1771. The p[roblem
is first evedent by the fact that the * at top-level is
missing part of the time.  Where it really shows up however
is when ^K or ^L is used and the first 5 characters are
never printed.  Anyway it used to be fine in all lisps
before 1804 (i.e. 1771 for example).

Also 1804 still has the truname bug (did I already report that??)

Ah well, I made a COMPLR with CCLOAD which now works fine.
Everything else looks ok.  Ah, I looked in the code and saw
code that was attempting to grab the pure page violations
of setqing t and nil. But that code must be turned off, since
the monitor gets the trap.


See you around.


Date: 27 MAR 1979 1626-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC, RWK at MIT-MC

The previous was from me.

Date: 27 MAR 1979 1625-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC, RWK at MIT-MC

Foo!  (moby!)

The interrupt handler for ^S doesn't seem to check for TYO being an SFA
before getting the "channel" to do an output reset on!!!  Needless to
say, this can cause gross lossage when your losing VT52 types on for you
at unexpected moments.  And the only way to continue the LISP is to
open the channel from DDT so you can fake it out.

Can this get patched please??

Date: 22 MAR 1979 0751-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-10 version
To: (BUG LISP) at MIT-MC

The "HALT" instructions just after GTNPS3 and ALIMPG
really should do something more gracefule - such as what
FASLOAD does when it can't get more core.

Date: Tuesday, 20 March 1979  15:32-EST
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: BUG-LISP at MIT-MC
Subject: READTABLES

    Date: Tuesday, 20 March 1979  11:28-EST
    From: EDMOND
    To:   EKillian
    Re:   Lisp
    
	    I seem not to be able to find the format of READTABLE or OBARRAY
    or other useful internal things.  Could I get you to help?  Thanks.
    -WBE
    -------

Can you point us to documentation on SETSYNTAX and other ways of
hacking readtables.

HIC@MIT-MC 03/19/79 21:21:33
To: DDM at MIT-AI, (BUG LISP) at MIT-AI
I really need more info on your PURPG in order to do anything about it.  Perhaps you could
disown the job and send me a note when it happens again.



DDM@MIT-AI 03/19/79 20:36:03
To: (BUG LISP) at MIT-AI
The new version of lisp, PURQIO 1785, blew up on me (fatally - had to G it)
with the gleefull message:
 purpg;66214>>movem 12,@-1(16)  12/  cam 13352  / popj 14,
My attempt to suspend and save the relic failed due to an unclosable file, but
the bug repeated itself -- though apparantly not at the same point as the
first time.


GLD@MIT-AI 03/18/79 09:50:28
To: (BUG LISP) at MIT-AI
The following crashes lisp:
(uread (plogo) up)
^q
(up)
Up opens line T31 for reading & writing.  If T31 sends:
FOO
  ANY LINE WHATSOEVER
then lisp will crash when the cr after "whatsoever" is typed.


Date: 17 MAR 1979 0911-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: HUNK2, etc.
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

It would break existing MACSYMA code (SOLVE) to change this.  Please do
not do it without LOTS of notice.  I'd also like to hear what the "problems"
are that this causes!  What is the difference between HUNK2 and LIST space
besides the result of TYPEP and HUNKP?  I will admit I've sometimes wished
HUNKP returned T for HUNK2's, but that's not so bad.  It's easy enough to
write a CARCDRP macro to be (OR (LISTP X) (HUNKP X)) etc.

Date: 17 MAR 1979 0142-EST
From: JONL,RLB at MIT-MC
Sent-by: JONL at MIT-MC
To: (BUG LISP) at MIT-MC

Why, Oh Why? do (HUNK 1) and (HUNK 1 2) cons up LIST cells?
Many problems would be solved if they actually caused the
consification of HUNK4 cells.  Would anyone object to that?
This could be patched into the current LISP, but the relatively
nicer solution (a HUNK2 space) would call for reassembly.

Date: 17 MAR 1979 0014-EST
From: moon,dcp at MIT-MC
Sent-by: DCP at MIT-MC
To: (BUG LISP) at MIT-MC

A call to set compiles into
a JSP T,.SET which smashes TT, but COMPLR doesn't know that it smashes TT.

Date: 12 MAR 1979 1354-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Free List
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: MRG at MIT-MC


    Date: 12 MAR 1979 1100-EST
    From: KMP at MIT-MC (Kent M. Pitman)

    Don't you think the free list in Lisp wastes a lot of space? If the right
    half of every cell is going to be NIL anyway, why not use only half of the
    space on the free storage list for info about where the list is and free
    the remaining cells for something useful?
    -kmp
------
But if the remaining cells were being used for something useful, they would not be free....

Date: 12 MAR 1979 1100-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Free List
To: (BUG LISP) at MIT-MC
CC: MRG at MIT-MC

Don't you think the free list in Lisp wastes a lot of space? If the right
half of every cell is going to be NIL anyway, why not use only half of the
space on the free storage list for info about where the list is and free
the remaining cells for something useful?
-kmp

Date: 11 MAR 1979 1510-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, PRATT at MIT-AI

MC:COMLAP;BACKQ >
is the one that is used in MacLISP

PRATT@MIT-AI 03/11/79 14:57:46
To: (BUG LISP) at MIT-AI
Is there a Lisp definition of ` on-line somewhere?


Date: 10 MAR 1979 1724-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC


KATSU has been helped with his array problem...he did not realize 
that G0003 was  a gensym and uninterened.

KATSU@MIT-AI 03/10/79 15:19:02
To: (BUG LISP) at MIT-AI
The file KATSU;TEMP > was dumped using DUMPARRAYS, and
LOADARRAYS on it is doing funny things, like not creating
an accessible array.  After the LOADARRAYS, it returns a
list like
     ((G0002 TEST 1))
where the original array was named TEST, but G0002 and TEST
both have NIL plists.  Neither are they bound.  So where
is the array that is supposedly to have been loaded?


Date: 9 MAR 1979 1818-EST
From: SUN at MIT-ML (Alex Sunguroff)
To: (BUG LISP) at MIT-ML
CC: RPG at MIT-ML

Well you win a few , you lose a few. In general
1804 is better, but it still has an old bug
and it has aquired a awful new one.
The new one is that you optimized the output
to be so fast that tere is no padding (or not enough)
for some terminals at 9600 baud (like Hazeltine 2000's).
The first  four chars are being lost. Hazeltines are semi-unique
in that they need padding after the <CR>. (TI 733's
need that type of padding too.)

Old bug: TRUENAME lies. Truename and the other nameing
functions (except for DEFAULTF) give the wrong PPN
for a file object.  Instead of returning the true PPN of the filethey give the PPN found in the UNAME or UDIR.
So the helpful debugging hint is "why does DEFAULTF work?"

Oh well, keep 'em comin'.


HIC@MIT-MC 03/09/79 07:22:58
To: PRATT at MIT-AI, (BUG LISP) at MIT-AI

    PRATT@MIT-AI (Sent by PRATT1@MIT-AI) 03/09/79 00:31:24
    (funcall '(lambda (x) x) 0)
    0
    That much I understand.
    (funcall ''(lambda (x) x) 0)
    0
    Funny, I expected an error message.  Oh well, I guess LISP keeps eval'ing
    the first arg to funcall till it is a function.  Kludgy, but consistent with
    earlier practice.
    (funcall '''(lambda (x) x) 0)
    ;(QUOTE (QUOTE (LAMBDA (X) X))) UNDEFINED FUNCTION OBJECT
    Oh my god, what's going on here?
--------
There is this completely and utterly wierd code in eval in the interpreter that allows
a form in the functional position to be evaluated ONE extra time (though it could be set
differently).  This is a compoletely wierd crock and I don't know why whoever decided to
implement did so, but....arg, is this poor!!



PRATT@MIT-AI (Sent by PRATT1@MIT-AI) 03/09/79 00:31:24
To: (BUG LISP) at MIT-AI
(funcall '(lambda (x) x) 0)
0
That much I understand.
(funcall ''(lambda (x) x) 0)
0
Funny, I expected an error message.  Oh well, I guess LISP keeps eval'ing
the first arg to funcall till it is a function.  Kludgy, but consistent with
earlier practice.
(funcall '''(lambda (x) x) 0)
;(QUOTE (QUOTE (LAMBDA (X) X))) UNDEFINED FUNCTION OBJECT
Oh my god, what's going on here?


Date: 8 MAR 1979 2031-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: JIS at MIT-MC

(MAPCAR 'QUOTE '(8 7 5))
returns an error
;((QUOTE . 8) ?) WRONG NUMBER OF ARGS TO FSUBR

This error seems to be the wrong one. ...  Should be something
more to the effect that the arg format is wrong. .. i.e., it
was expecting (8) (7) (5) instead of 8 7 5  (FSUBR's take args
that are supposededly guaranteed lists.) It strikes me
that the proper semantics is for MAPCAR to (NCONS ..) each thing
being passed to an FSUBR ... hmmmm...

Also, (FUNCALL 'QUOTE 'A) gives back
#74012 
with no error message. Could *RSET => T please check
for something in this line? Maybe for general format of 
arg in a FUNCALL of an FSUBR/FEXPR...?


GSB@MIT-ML 03/07/79 16:13:48
To: (BUG LISP) at MIT-ML
CC: (BUG COMPLR) at MIT-ML
Could someone please put a PDLNMK function into lisp?
I would prefer not to have to constantly redefine it in unrelated
files.


Date: 6 MAR 1979 2213-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC

MC:.INFO.;LISP NEWS seems to have had it's last block clobbered with
GLPT source.  It's on the right pack for it to have happened when the
drive died a while back.

Date:    5 Mar 1979 1654-EST
From:    DAVE.TOURETZKY(C410DT50) at CMU-10A 
Subject: consp
To:      bug-lisp at MIT-AI

Why is there no consp in MacLisp?  I have been using
(eq (typep x) 'list) instead.  Is there a better way
to determine whether something is a cons cell or not?

					-- Dave Touretzky @ CMUA


PRATT@MIT-AI 03/01/79 18:47:00
To: (BUG LISP) at MIT-AI
(This bug is probably caused by something I did wrong, but...)
Why is DEPTH bound to what looks like a JRST in AI:PRATT;FUNNY DEPTH ?
What sort of thing might I be doing wrong that would produce such an effect?
(If you want I'll tell you how to get to this state.)


GSB@MIT-ML 02/28/79 08:49:17
To: (BUG LISP) at MIT-ML
charpos doesn't use a value returned from a wrng-type-arg break, at
least in the case of one argument:
(charpos 'foo)
;FOO NOT SFA OR FILE
;BKPT WRNG-TYPE-ARG
(return (list tyo))
;FOO NOT SFA OR FILE
;BKPT WRNG-TYPE-ARG
...


Date: 26 FEB 1979 1611-EST
From: JOHAN at MIT-MC (Johan de Kleer)
Subject: TENEX MACLISP
To: (BUG LISP) at MIT-MC

The reason that OPEN with 3 args loses is that it constructs a
string using "." instead of ";" to append version number.  (This
is an incompatibility between TENEX and TOPS-20.)

Fix by patching 6btns0+11 with MOVI 7,73 instead of MOVI 7,56.  How
do I fix the source.
johan

Date:    26 Feb 1979 1301-EST
From:    DAVE.TOURETZKY(C410DT50) at CMU-10A 
Subject: bug in new LISP compiler
To:      bug-lisp at MIT-AI

The MacLisp compiler on [c380ml5p]/A tries to deletef the old .fas file.
Unfortunately, if it can't find a file to delete on the regular account,
it looks on the library account (set by the LIB command) and tries to
delete the file there.  If such a file exists, it usually is protected,
so the deletef fails and the compiler goes into a break.

The solution to this problem is simply to restrict the compiler (or
better yet, the deletef function itself) from looking on the library
account if one is specified.  Of course, functions such as uread and
fasload should still use the library.

							-- Dave Touretzky


Date: 25 FEB 1979 1742-PST
From: DEKLEER at PARC-MAXC2
To:   bug-lisp at MC

Because of bug in TENEX open, compiler cannot load its
initialization file. i.e. (load (probef xxx)) can never work.
johan
-------

Date: 25 FEB 1979 2029-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: (+1 5)
To: DHD at MIT-MC
CC: (BUG LISP) at MIT-MC

Maybe you want (1+ 5)?

Date: 24 FEB 1979 2312-EST
From: JOHAN at MIT-MC (Johan de Kleer)
To: (BUG LISP) at MIT-MC
CC: dekleer at PARC-MAXC

The long gtjfn just before jfn6bt is defaulting the device incorrectly.
i.e. (mergef '|<dekleer>readline.lsp| nil) fails while
(mergef '|dsk:<dekleer>readline.lsp| nil) succeeds.  Solution
(patch) is to deposit 0 into lfgblk+2.  Note that this is an incompatibility
between TENEX and TOPS-20.

Also note that although (open (mergef '|<dekleer>readline.lsp| nil)) works
(open (mergef '|<dekleer>readline.lsp;1| nil)) loses.  Problem is that
OPEN seems to do incorrect things with file extension if it is non empty
i.e. || or *.

GLS@MIT-AI 02/23/79 21:35:23 Re: (read)(+1 5) => (1 5)
To: DHD at MIT-AI
CC: (BUG lisp) at MIT-MC
This is in fact correct.  In general, numbers may be preceded by
an optional "+" sign, and so "+1" reads as the integer "1".  However,
the "+" is normally elided on printout, as it is unnecessary.


DHD@MIT-AI 02/23/79 21:05:49
To: (BUG LISP) at MIT-AI
(READ)(+1 5) --> (1 5)

Date: 23 FEB 1979 1726-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: allfiles lossage
To: MOON5 at MIT-MC, (BUG LISP) at MIT-MC, JLK at MIT-MC

MOON's suggested fix has been made in the source and reassembled on MC.

Date: 23 FEB 1979 1717-EST
From: MOON5 at MIT-MC (David A. Moon)
Subject: allfiles lossage
To: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC, JLK at MIT-MC

The 5*2000 should be 6*2000, actually 6*<2000-11.>.  I missed this
typo when I read the code the first time myself

Date: 23 FEB 1979 1232-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC

Looking into this ALLFILES/ .GLPR/.;  problem, I find that ALLFILES is looking
at the first word of the image directory which seems to be a pointer to the
descriptor.  ALLFILES then checks to see if this is less than 5*2000 = 12000
which it is not (its actual value is 12534).  Now I have no idea what this
means, so can someone tell me if the check in ALLFILES is wrong or is a
descriptor pointer of 12534 is reasonable?  Does this have anything to do
with the fact that .GLPR.; is a recently created directory?

JONL@MIT-MC 02/22/79 20:55:54
To: GLS at MIT-AI
CC: (BUG LISP) at MIT-MC
As I've sadly discovered with the NILAID package using HUNKs to
emulate VECTORs, the lack of a HUNK2 space in maclisp means
that vectorp often cant work right.  And another thing, these
hunks really ought to be readible, though maybe something like
#H(1 . 2 . 3 . 5 . 0)  would be acceptable.

Date: 22 FEB 1979 0221-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: PI (Program Interrupt) Lossage
To: (BUG LISP) at MIT-MC
CC: KEN at MIT-MC, RWK at MIT-MC, (FILE [KMP;DSK:KMP XMAIL]) at MIT-MC

(DEFUN (PI MACRO) (FORM)
       (LET ((TEMP (GENSYM)))
	    `((LAMBDA (,TEMP)
		      (UNWIND-PROTECT ()
				      (NOINTERRUPT ,TEMP)
				      ,@ (CDR FORM)))
	      (NOINTERRUPT (SETQ ,TEMP (NOINTERRUPT T))))))


(NOINTERRUPT NIL)
NIL
(PI (TYI) (TYI))<Control-G><Control-G>
NIL
(NOINTERRUPT NIL)
NIL
(PI (TYI) (TYI))QUIT

The QUIT is the <Control-G> quits taking effect. Why didn't they 
happen when the (NOINTERRUPT ()) was done?

Date: 21 Feb 1979 1316-PST
From: Dick Gabriel <RPG at SU-AI>
To:   bug-lisp at MIT-MC    

 21-Feb-79  1150	KMP at MIT-MC (Kent M. Pitman)
To:   BUG-LISP    
Date: 21 FEB 1979 1450-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Apologies if I've sent this request before, but I need it again and
am much disappointed with the alternatives. Can we please get a
(STATUS SITE) or (STATUS MACHINE-NAME) or something that returns MC,
MULTICS, AI, or whatever. I am not satisfied with shaky solutions
like (GETL (CONS () (STATUS FEATURES)) '(MC AI DM ML MULTICS ...)) 
or with (CADR (REVERSE (STATUS FEATURES))) or whatever the place it is
'usually' found is... This seems important enough to have in a named
location. Thanx.

I don't think that these shakey solutions are all that bad especially if
you figure out the site name at startup time when disk io is slowing you
down anyway. The proposed solution, of course, would require that all
of the sites be available, such as: AI,MC,ML,DM,MULTICS,SAIL,CMU... 
			-rpg-



Date: 21 FEB 1979 1450-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Apologies if I've sent this request before, but I need it again and
am much disappointed with the alternatives. Can we please get a
(STATUS SITE) or (STATUS MACHINE-NAME) or something that returns MC,
MULTICS, AI, or whatever. I am not satisfied with shaky solutions
like (GETL (CONS () (STATUS FEATURES)) '(MC AI DM ML MULTICS ...)) 
or with (CADR (REVERSE (STATUS FEATURES))) or whatever the place it is
'usually' found is... This seems important enough to have in a named
location. Thanx.

Date: 21 FEB 1979 1430-EST
From: JONL at MIT-MC (Jon L White)
To: GSB at MIT-ML
CC: (BUG LISP) at MIT-MC

I made the change to LISP source for the ^S problem.  On the
TOPS-10/20 systems, you cant make ^S an interrupt character, since it
is involved with the X-ON, X-OFF protocol.  I just patched PURQIO
on MC:, and will do so later to ML: and AI:

Date: 21 FEB 1979 0427-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: GLS at MIT-MC

(DEFUN FOO () (TYI))

(SSTATUS TTYINT 1. '(LAMBDA (X Y) (TYI) (TYIPEEK)))

(FOO)^AB

Does not return the ascii numeric val for B until another activation
char is typed, despite the fact that the TYI has the char available
at the time of return from interrupt level, the job goes back to sleep
and waits for another activation char. Not just any activation char,
mind you, space doesn't work... right off. Eg,

(FOO)^AB<Space><Space><Space><Space>... doesn't return

(FOO)^AB<Space><Space>() says ;B UNBOUND VARIABLE

(FOO)^AB<Space>B<Space> says ;BB UNBOUND VARIABLE (This is clearly wrong!)

(FOO)^AB<Space><Space>B<Space> says ;B UNBOUND VARIABLE ;B UNBOUND VARIABLE
  which is ok except I'll bet it (harmlessly) ate the first Space.

I didn't make this case up just to complain. It manifested itself in
an actual program I was writing. 

-kmp

Date: 20 FEB 1979 2338-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

is LENGTHF supposed to work on files open for writing?
It seems to always return 0 (at least for fixnum output mode).

Date: 20 Feb 1979 2121-EST
From: PDL at MIT-DMS (P. David Lebling)
To: JLK at MIT-MC
Cc: (BUG ITS) at MIT-MC, GLS at MIT-MC, (BUG LISP) at MIT-MC
In-reply-to: Message of 20 Feb 79 at 2022 EST by JLK@MIT-MC
Subject: DIRHNG Strangeness
Message-id: <[MIT-DMS].101437>

DM's Comsys uses it to detect new mail in the COMSYS directory, and I haven't
ever encountered the problem you describe.  It even does it from a Muddle,
so it sounds roughly analogous to your case.
	pdl



Date: 20 FEB 1979 2022-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG ITS) at MIT-MC
CC: GLS at MIT-MC, (BUG LISP) at MIT-MC

I had this strange occurrence having to do with the DIRHNG device, namely
the Gould spooler uses it to detect when files are written into .GLPR.;
Somehow this directory got wedged in a state where ALLFILES in LISP returned
NIL for it, when .GLPR.^F returned a list showing files.  Now as far as I
can tell, the only thing ALLFILES does is to open files to .FILE. (DIR)
etc. and I guess this lost somehow.  Anyway, when ITS got reloaded, everything
was winning again with no changes to either ALLFILES or the spooler.
I doubt you can learn anything from this report, but I just thought you
might want to know there is something strange here in case it happens again.
Are there any other frequently used programs that use DIRHNG?

Date: 19 FEB 1979 2247-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC, ITS at MIT-MC

(ALLFILES '( ((DSK /.GLPR/.)) )) returns NIL.
(ALLFILES '( ((DSK /.GLPT/.)) )) returns a list of files.

The former won eariler today, so I assume the directory got clobbered somehow.
Reading .FILE. (DIR) etc does win, so I don't know how ALLFILES is losing.
This is needed by the Gould spooler, so it would be a help if it could be
fixed.

Date: 19 FEB 1979 2224-EST
From: JONL at MIT-MC (Jon L White)
Subject: HUNKs (Ugggh!)
To: (BUG LISP) at MIT-MC

(HUNK 3)  cons'es up a list cell, instead of some HUNKn cell.
CXR and RPLACX wont work on it.

Date: 19 FEB 1979 1919-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

I helped JLK

Date: 19 FEB 1979 1203-EST
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

How do I trap an error when opening a file on the CLI device.
(errset (open '((cli) foo hactrn) '(out ascii)))  tries to type out a message
no matter what I do (with ^W T, IO-LOSSAGE set to NIL, etc.).  I need to suppress
the typeout for a job like the Gould spooler which doesn't have a TTY.

GLS@MIT-AI 02/19/79 02:31:39 Re: Apropos of BIM's complaint
To: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI
As a rule of thumb, it would seem that you almost never want normal
grinding format if the car of a form is non-atomic; in 9 out of 9.7 cases
you usually want miser mode if it won't all fit on one line.  (COND, LET,
((LAMBDA ...) ...), DO are all cases in point.)  SO maybe GRIND should be changed foor this
as well as fixing it specifically for LET.


BAKER@MIT-AI 02/18/79 20:17:48 Re: arrays in Maclisp
To: JONL at MIT-AI
CC: BAKER at MIT-AI, (BUG LISP) at MIT-AI
How about removing the restrictions against 0-dimensional arrays and having
dimensions with 0 elements, etc.  When writing a comprehensive array package,
it is much easier if the boundary conditions are simple, which they are not
when dealing with arrays in MACLISP.  Also, having *array be the only array
creating function is a little ackward; an array function which included
one argument which was the list of dimensions would be preferable.  (I realize
that I can simulate it using LISP's APPLY function, but it would be preferable
not to.

Date: 18 FEB 1979 1118-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

In reply to the semi-recent request for opinions about the what the
default should be for (STATUS FLUSH). I would prefer 
(STATUS FLUSH) => T
as the default. I often forget and end up dumping out huge files.
People who dump out lisps should be sophisticated enough to understand
the dangers of a lisp going away and are not likely to get screwed by
lisp's going away. It's more likely someone will be careless and dump
out an extra 40K without noticing ... -kmp

Date: 18 FEB 1979 0346-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: Confused Code
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC


            
    Date: 18 FEB 1979 0326-EST
    From: RWK at MIT-MC (Robert W. Kerns)
    Sent-by: ___012 at MIT-MC

    IOCERR+13/ HRRZ R,-3(F)
    IOCERR+14/ SKIPL R
    IOCERR+15/ JRST IOCER8

    Is this supposed to make sense?  Since IOCER8 always clobbers R,
    this is identical to a JRST IOCER8.  Maybe the HRRZ is spurious?

Try looking at the source code.  It has some macro-ized stuff
that arranges that a sequence involving a HRROI R, appears for
every IOC handler declared by the code (in much the same manner as an INTPRO).
As it happens, there are presently no such handlers in the code, so it does
indeed produce a silly-looking sequence of instructions.  I suppose it
could suppress the SKIPL if there are no handlers, but I was lazy when
I wrote that code.  (I was even more lazy in not defining a handler or two!)

Date: 18 FEB 1979 0326-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___012 at MIT-MC
Subject: Confused Code
To: (BUG LISP) at MIT-MC

IOCERR+13/ HRRZ R,-3(F)
IOCERR+14/ SKIPL R
IOCERR+15/ JRST IOCER8

Is this supposed to make sense?  Since IOCER8 always clobbers R,
this is identical to a JRST IOCER8.  Maybe the HRRZ is spurious?

ALAN@MIT-AI 02/17/79 03:05:36
To: (BUG LISP) at MIT-AI
The function DISPLACE when given a second argument of NIL fails
to detect that NIL is an atom and produces (NIL) instead of (PROGN NIL)
as is should.

RICH@MIT-AI 02/13/79 09:04:37 Re: BB$X
To: (BUG LISP) at MIT-AI
CC: GLR at MIT-AI, JOHAN at MIT-AI
Thanks to JOHAN for pointing out the problem:  if you control-Z
out of a lisp, you can't BB$X it since it is waiting at
interrupt level.  If you CALL out of it, BB$X works ok, and
assumedly will still work if  you pop out with some random
machine error.  


Date: 12 Feb 1979 1755-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: 1802
To:   bug-lisp at MIT-MC    

	LISP 1802 + COMPLR 868 replies with "incorrect syntax - MAKLAP"
for all possible input at SAIL.
			-rpg-



rich@MIT-AI (Sent by GLR@MIT-AI) 02/12/79 18:37:07 Re: BB$X
To: (BUG LISP) at MIT-AI
doesn't work anymore!  I tried starting a bare lisp.  Then
ctl-z'ed it and typed $^K, then BB$X.  It blew up!??


Date: 10 FEB 1979 2339-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

How about making SETSYNTAX take an optional fourth argument which would be
the readtable in which to make the modification. 

Date: 10 FEB 1979 2317-EST
From: JONL at MIT-MC (Jon L White)
Subject: ASSLIS, DEFMAC, and DEFUN&
To: (BUG LISP) at MIT-MC

A previously "lost" notice
    JONL@MIT-MC 02/10/79 12:47:58 Re: ASSLIS
    A few three-letter abbreviations flushed: MSA, and all "xxO" meaning oldio
    A few more added: SAI is standard SAIL mnemonic, SA1 sets the "hisegment"
       flag to zero to get a one-segment assembly, SAP sets the "paging" flag
       to one (and "hisegment" to zero) for a paging version.  Similar suffixes
       apply to REL and CMU (i.e., RE1, REP, CM1, CMP)
    ^_
And another one
    JONL@MIT-MC 02/01/79 04:10:39 Re: DEFMAC and DEFUN&
    A fence-post error in the processing of &rest's
    has been fixed
    ^_

Date: 10 FEB 1979 2315-EST
From: JONL at MIT-MC (Jon L White)
Subject: BUG-LISP goes where?
To: (BUG LISP) at MIT-MC

Recently I mailed something to "LISP", and noticed that it went
to MC:LISP;LISP MAIL, a file which otherwise has been usused since
about August 1978.  Could we merge this with the various MC:BUG LISPn
files, and insert a mailer link for LISP the BUG-LISP?
  While we are on the subject of anachronisms, how about slowly flushing 
all the oldio conditional code from the source?  It is very cluttered
now , and there are several unified versions lying around with all the
oldio stuff in them, in case anyone whould ever want to know what
it was all about.  Possibly with all the losing oldio stuff gone,
a unified source might fit into an EMACS buffer!

Date: 10 FEB 1979 2206-EST
From: JONL at MIT-MC (Jon L White)
Subject: NAMELIST
To: (BUG LISP) at MIT-MC

(NAMELIST '|AB|)  gives the wrong error message.
An attempt to return the corrected value by
(RETURN '(|ABC|))
yields a nasty ill opr.
In looking for this bug, I noticed the line
	POP FXP,1+CMU
which presumably wants to be
	POPI FXP,1+CMU
???.  But thats not the problem.  Will investigate further.

Date: 10 FEB 1979 1229-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

UNWIND-PROTECT was losing a coupla days ago. At that time the losing cases
were (even in interpreted code):
 (PROG () (UNWIND-PROTECT (RETURN T) (PRINT 'FOO)))
 (UNWIND-PROTECT (ERR) (PRINT 'FOO))
 (SETQ A 0.) (UNWIND-PROTECT (PROGN (SETQ A 1.) (TYIPEEK)) (PRINT 'FOO))^G
Cases 2 and 3 were fixed (apparently) by RWK's patch. Case 1 still loses.
Can someone please look at this? Thanx. -kmp

Date: 8 FEB 1979 2136-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC

UNWIND-PROTECT has been broken at least since 1750.  I think
I see the problem though.  Will check further.

Date: 8 FEB 1979 1942-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Gross and unforgiveable UNWIND-PROTECT lossage
To: (BUG LISP) at MIT-MC

(SETQ A 1.)
(UNWIND-PROTECT (PROGN (SETQ A 2.) (TYIPEEK))
	        (SETQ A 1.))^G
A<Space>
2.

... it's been losing a long time this way ... say several days at least.
Maybe longer. RLB's been complaining of IOTA not properly closing files
but I bet this is why... -kmp

Date: 8 FEB 1979 1333-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: And yet even more SFA lossage
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: GSB at MIT-MC


The SFA-CALL W-O and SFA-GET W-O are related to each other in only a very small way.
They might, or might not, be the same, but it makes no difference
anyway.

Date: 8 FEB 1979 0643-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: More on SFA's
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-ML

There seems to be no provision for allowing

(SSTATUS TTYINT <n> <function>)

to work if TYI is set to an SFA.
-kmp

Date: 8 FEB 1979 0612-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: And yet even more SFA lossage
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC

(CLEAR-INPUT <sfa>) sends back an error

;#SFA-|TTY-INPUT|-00000 NOT INPUT FILE

(Don't panic - I just don't remember what went in the 00000 slot) ...
(SFA-GET <sfa> 'WHICH-OPERATIONS) doesn't list CLEAR-INPUT even tho'
(SFA-CALL <sfa> 'WHICH-OPERATIONS ()) does.

I might note that this same discrepency between (SFA-GET <sfa> 'W-O)
and (SFA-CALL <sfa> 'W-O ()) exists for the already complained about
case of FILEMODE.


Date: 8 FEB 1979 0442-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Can lisp please be fixed to optimize *REARRAY in the following ways:

[1] If the array is being made smaller, just mung the header and leave
    the data.

[2] If the array is to be extended and the space exists contiguously
    after the current end of the array, the header should be changed
    and the extra space zero'd.

Please excuse (explain?) any bugs in my model of things, but I am hoping
something like this can be done. Loading of Fortran subroutines will 
have to do moby *REARRAY'ing on occasion and it would be nice to have it
be smart...

Thanx. -kmp

Date: 8 FEB 1979 0407-EST
From: gsb at MIT-MC (Glenn S. Burke)
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC

the ^W initial ttyint blindly does a .CALL (RESET) on the <f.chan>th
slot of the ttycons of the input channel, whatever that may be (ie sfa)

GSB@MIT-ML 02/07/79 22:23:01 Re: iocins
To: (BUG LISP) at MIT-ML
the change from an XCT to PUSHJ ain't documented anywhere that i can find.
(Although IOCINS itself is in LISP NEWS)


KDF@MIT-AI 02/07/79 18:59:57
To: (BUG LISP) at MIT-AI
At times when running code, I get a TOO MANY DEFERED INTERRUPTS error, which
drops me out of my lisp compleatly.  THis is especially annoying, as I ususally
have no files open at the time.  It most often occurs when doing (baktrace),
but not necessarily so.  Does anyone have some suggestions?  A way of 
restarting a lisp that bombed out in such a fashion would also be appreciated.
		Thanks.
		  Ken


GSB@MIT-ML 02/07/79 18:06:33
To: (BUG LISP) at MIT-ML
(SETSYNTAX <char> 'SINGLE NIL)
doesn't fix up the character translation entry like it should if
the char was a macro, leading to some gross anomalies...


Date: 6 FEB 1979 1837-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

If I define " as a read macro character that TYI's til another ",
the following loses:

(PRINT ";")

because Lisp's tty-prescan doesn't see the matching ')' - it thinks it
is commented out ... sigh. Is there a syntax bit I can set that tells
lisp to mind its own business about things between "'s? 

ALSO...

If I type

"FOO<Space><Rubout><Rubout><Rubout><Rubout><Rubout>

I would like to have the " be able to throw to a tag in READ saying that
it didn't get anything. Could it be arranged to have READ have such a 
CATCH frame in it - if something NCONS'd were received (Lisp could NCONS
the result) then it would win and if something atomic were returned 
the READ could return an end-of-file on the tty?

As it is now I just return NIL but I see no reason a value should get
printed by Lisp's main read-eval-loop for over-rubbed-out things...??

-KMP

Date: 6 FEB 1979 1641-EST
From: GSB at MIT-MC (Glenn S. Burke)
Subject: ^S ttyint
To: (BUG LISP) at MIT-MC

The initial (STATUS TTYINT) for control-S is 23 (19.), but there is
no internal handler for this;  it should have the same (STATUS TTYINT)
as control-W (which it used to).

SJOBRG@MIT-AI 02/06/79 12:49:25
To: (BUG LISP) at MIT-AI
CC: BEE at MIT-AI, SJOBRG at MIT-AI
I WANT TO DO THE (OF ALL CRETINOUS THINGS) FOLLOWING.
I HAVE A 7-TRACK MAGTAPE IN PDP-11 DOS FORMAT, WHICH I AM
VERY FAMILIAR WITH.  THE ":COPY" WORKS FINE ON THIS,
CREATING THE RIGHT FILE, BUT OF COURSE, UNABLE TO READ
PAST THE EOF ON ONE COPY COMMAND.  LISP PERMITS ME TO
OPEN A FILE IN FIXNUM MODE VIA
        (SETQ TAPE (OPEN '((MT0 *) * *) '(IN FIXNUM)))
AND I CAN READ IT FINE USING (IN TAPE).  HOWEVER, IT
BOMBS OUT AT END-OF-FILE.  I PROVIDE MY OWN EOFFN, WHICH
WORKS FINE ON DSK FILES, BUT IS NEVER EXECUTED ON THE
MT0 FILE.  INSTEAD, I GET AN IOC ERROR IN LISP, AND A
NASTY DDT MESSAGE THEREFROM.  I HAVE SHOWN THIS TO
BEE, SO MAYBE HE KNOWS MORE ABOUT IT.  I'LL BE GLAD TO
SHOW ANYONE WHO CAN HELP ME.

SINCE THE TAPE WE HAVE SHOULD BE RETURNED TO DEC SOON,
A PROMPT SOLUTION WOULD BE APPRECIATED.

THANKS... BOB


Date: 5 FEB 1979 2254-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

(ARGS 'OPEN) returns (0 . 4) ... In an incredible feat of daring-ness on my
part, I tried
(OPEN '|DSK:KMP;DELETE THIS| '(OUT) 'FOO)
and
(OPEN '|DSK:KMP;DELETE THIS| '(OUT) 'FOO 'BAR)
to determine what the undocumented args do. I got a 'WRONG NUMBER OF ARGS TO 
LSUBR' message. 

(ARGS 'OPEN) should return (0 . 2)

-kmp

Date: 5 FEB 1979 1956-EST
From: JONL at MIT-MC (Jon L White)
Subject: Multiple-user access to file directories
To: (BUG ITS) at MIT-MC
CC: (BUG LISP) at MIT-MC

I've noticed several messages on BUG-LISPM recently of the
flavor "will whoever modified such-a-such a file please fix his bugs".
I would be nice if ITS, like TOPS-20, kept account of who created
a file.  Not only would it help the LISPM types who have 6 or so
persons working on the project, but it would alleviate other crunches.
For example, I generally like to have a copy of the most recent
version of a file which I've worked on, in order to trace the evolution
of my work on it, and I've asked others on the LISP mailing list
to respect this wish, at least to the extent of giving me a couple
days notice when there is the need to do additional reaping on the 
directory.  The GFR, in effect, gives at least two weeks notice by
reaping only files at least that old.
   But in the past month, HIC has deleted all my "old-work" files
on three separate ocasions, even after I specifically asked him for
this "several day" consideration;  the most recent losses were only
30 hours old!  Indeed, part of the problem is that there was no way
for him to know that RPG, rather than me, made the latest additions.
I would like to plead, strongly, for this "creator/author" record
to be put into ITS.
   I'll admit that this problem, both on LISPM; and on L;, occurs primarily
when there is a rapid pace of development, by several (possibly
cooperating) persons.  On the other hand, many projects go thru
such a phase, so it is likely to recur again and again.

JONL@MIT-MC 02/05/79 18:19:57 Re: Default setting of (STATUS FLUSH)
To: (*MSG *ITS) at MIT-MC
CC: (BUG LISP) at MIT-MC
Would any object if (STATUS FLUSH) were initially T instead of null?
Remember that this affects only the dumping of the system pure code
when a second argument is given to SUSPEND.

Date: 5 FEB 1979 0843-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: NAMESTRING, NAMELIST
To: (BUG LISP) at MIT-MC


Why does TYO and TYI print with a |TTY:* *| in the middle yet namestring
goes and returns (MERGEF <stuff-in-middle-of-printname> DEFAULTF) 
which is => |TTY:KMP;_LISP_ >| which is ugly.

Why does (NAMESTRING MY-SFA) where my SFA looks like #SFA-|Console Output|-...
return |DSK:KMP;_LISP_ >| ....??? That's pretty random. In fact, 
(NAMESTRING T) and (NAMESTRING NIL) return that too and I'm not sure they
should.

If SFA's ever get repaired, it would be nice if NAMESTRING and NAMELIST
could be potential ops to them.

--kmp

Date: 5 FEB 1979 0639-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

When I do:

(CAR 'A B)

the error message is "B" unbound variable. Why does it eval args
before it checks number of args??

PRATT@MIT-AI 02/04/79 11:57:51
To: (BUG LISP) at MIT-AI
I'm confused as to what is happening!  When I compile AI:PRATT;JUNK > without
setting fixsw, the MOD function so defined when applied to (-3 7) yields 4
as intended.  When I set fixsw and recompile, I get -3.  What is going on?!!!


Date: 4 FEB 1979 1119-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: TOPS-20 VERSION
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

I have seen this happen before on various tops-20's...
on what system did you experience this lossage??

Date: 4 FEB 1979 0741-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC, RLB at MIT-MC

BTW this is the full text of CWH's mail wrt the mail I just sent:
CWH@MIT-MC 02/04/79 03:40:48
The Macsyma undefined function handler seems to act strangely when
given certain lisp forms.  If FOO is undefined and BAR is unbound, then
(FOO BAR)
gives an error that BAR is unbound, and does not say that FOO is undefined,
which exactly the wrong thing to do.  MacLisp will signal the undefined
function error first, and doing the opposite can be extremely confusing,
particularly if FOO is a fsubr or macro.  The other case it can't seem to
handle is the case where an atom has a macro property which is an atom.  I'm
not sure if lisp handles this case via the undefined function handler or if
eval knows about it. 

Date: 4 FEB 1979 0735-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: CWH at MIT-MC
CC: JLK at MIT-MC, (BUG LISP) at MIT-MC, RLB at MIT-MC, JPG at MIT-MC

CWH@MIT-MC 02/04/79 01:58:34
MACSYMA UDF handler evals args first before determining that function
does not exist.

BTW, this might be a LISP bug.  As JLK, RLB, MRG, JONL, HIC, and I 
probably all remember it was a real bitch to get a user UNDF-FNCTN 
(sic) handler to work at all.  Levels of evaluation were a real problem, 
and the user handler does not fit in well in the LISP system.  When HIC 
and I last left it, he (and JONL I think) determined that it was not 
worth the effort to track down all the problems to get it to work 
perfectly, and what MACSYMA has was thought to be the best compromise 
possible.

Date: 4 FEB 1979 0317-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 VERSION
To: (BUG LISP) at MIT-MC

A dumped lisp will generally get two memory-protect failures,
upon attempt to RUN it.  Problem is the dumping deletes zero-filled
pages, and the LISP is incorrect in what it thinks has to be
explicitly page-created.

Date: 4 FEB 1979 0206-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Yet another SFA lossage
To: (BUG LISP) at MIT-MC

(RUBOUT ...) when TYO is set to an SFA loses. This isn't fair since
[1] My SFA supports CURSORPOS
[2] My SFA would say that it is a TTY output file if Lisp would
    look at what's in (STATUS FILEM)
The error message complains it isn't a TTY output channel.
(CURSORPOS 'X TYO) under the same circumstances wins, so why doesn't
rubout? I'd be willing even to make a rubout OP for my SFA-HANDLER ...

Date: 3 FEB 1979 0717-EST
From: MILLE0 at MIT-AI
To: (BUG LISP) at MIT-AI
CC: (BUG INQUIRE) at MIT-AI


When you log in as MILLE0, being already logged in as MILLER,
then do MILLER$$^S MILLER$^S L^K, Lisp does not find your
init file on the Miller; directory.  Is this supposed to be
a feature, that it looks on users2?  Is theree yet another
MSUSUVUNAME$$$$^^^^^S name I must set now?

(Sorry if I sound annoyed.  Just tired I guess.)
Mark
ps. to Inquire/Password hackers.  Its bad enough without the
total screwage you get with a 6 character name.  Its enough
to make one use a shorter name!  Running inquire on the poor
slob!


BYRON@MIT-ML 02/01/79 11:14:56
To: (BUG LISP) at MIT-ML
(arraycall fixnum b 1) where b is a 2-dimensional fixnum array object
gives error
;((nil . 1) (nil . 777775)) TOO MANY ARGUMENTS SUPPLIED - APPLY
when too *few* arguments have actually been supplied.


Date: 31 JAN 1979 0338-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC, CWH at MIT-MC

Interesting....

(DEFUN FOO (A A)
  A)
(FOO 1 2)
=> 1

(DEFUN FOO (A A &OPTIONAL B)
 A)

(FOO 1 2)
=> 2

Maybe there should be error checking for duplicated arguments?

Date: 31 JAN 1979 0223-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: FAHLMAN at CMU-10A
CC: (BUG LISP) at MIT-MC, RPG at SU-AI

I am pleased to let you know that two new "versions" of LISP
have appeared at SAIL.

1) A single segment version that in theory will grow to 256K
2) A single segment version that starts at 256K and allocates
    memory as if it was on a paging system, thus giving you
    the advantages of the ITS/TOPS-20 binary program space
    allocation scheme.

It is probably possible to make these for Tops-10, though it has not been
tried yet, and I understand that CMU is interested.

It may also be possible to support KL10 VM.  If there
is interest in this project, then please let me know
personnaly, and perhaps we can work something out.

--howard

Date: 31 Jan 1979 0032-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Overly terse error messages.
To:   bug-lisp @ mit-ai
CC:   forgy at CMU-10A
Message-ID: <31Jan79 003234 SF50@CMU-10A>


Hello again,
Why doesn't the default error handler for GC overflow print out the name
of the offending space?  It appears that there is no way to retrieve this name
once the break has been taken -- or am I missing something?  I know that
a user can define his own handler to do this, but I feel that the default could
be more informative.  The screwee in this case is Lanny Forgy.
Cheers,
Scott Fahlman


Date: 30 JAN 1979 1421-EST
From: JONL at MIT-MC (Jon L White)
Subject: HIC's flaming about <1-qio>
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

I actually fixed a bug whereby
IFE USELESS+<QIO-1>,
failed.  The intent, I suppose, of the originator, was to get
the conditional whenever USELESS was "off" and QIO was "on".
But it wont work that way since QIO-1 producing a "-1" when
QIO is "off" spuriously balances the"+1" from a USELESS being "on"
You may note that I also suggested using "\" instead of "+" for
disjunctions.

Date: 30 JAN 1979 1413-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: compound IFE and IFN conditionals
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

I seem to remember being yelled at for suggesting you not
run your comments of the end of a page, and now you are commenting on
qio-1 and 1-qio.  God damn it, if it loses in some
case then it should be fixed.....if not, do as the situation
calls for...if it doesnt matter, who cares.....what I objecc to is all of the
gratuitous changes being made to the thing, instead of doing real development in
the areas that need it....i am trying to get something accomplished here, and
worruing about 1-qio, or qio-1, or use of or instead of plus, is just
too goddamned nit picky or me!!!

Date: 30 JAN 1979 1314-EST
From: JONL at MIT-MC (Jon L White)
To: BEE at MIT-MC, JLK at MIT-MC
CC: (BUG LISP) at MIT-MC

Also, am trying to get the various TS LISP, TS OLISP, TS OOLISP
to point to similar things on the three machines.  I gues the
intent for now is to have OLISP be version 1750, and OOLISP be 1633

Date: 30 JAN 1979 1313-EST
From: JONL at MIT-MC (Jon L White)
Subject: IOCER8+3  --  PUSHJ FLP,@IOCINS
To: BEE at MIT-MC, JLK at MIT-MC
CC: (BUG LISP) at MIT-MC

Well, whoever patched this in 1750 didn't change the source.  I
have patched it in 1785, and edited the source.

Date: 30 JAN 1979 1234-EST
From: JONL at MIT-MC (Jon L White)
Subject: GDDTS2:
To: (BUG LISP) at MIT-MC

Can anyone tell me the purpose of these two lines
	MOVEI TT+1,R70
	CAMN D,[SQUOZE 0,R70]
especially since R70 is in the LAPFIV table?

Date: 30 JAN 1979 1124-EST
From: JONL at MIT-MC (Jon L White)
Subject: compound IFE and IFN conditionals
To: (BUG LISP) at MIT-MC

Better to say <1-QIO> rather than <QIO-1>.  Although the latter
will work in conjunctions e.g. "IFE USELESS*<QIO-1>"  it will fail
in disjunctions e.g. "IFE USELESS+<1-QIO>".  Probably using "\"
rather than "+" is a win too, but it cant hurt to use the positive
form of the negation. (??)

Date: 30 JAN 1979 1034-EST
From: JONL at MIT-MC (Jon L White)
Subject: (STATUS MACRO <char>)
To: CWH at MIT-MC
CC: (BUG LISP) at MIT-MC

This returns a 2-list since there is both the function to be run, and
the indicator as to what kind of macro (ordinary, indicated by NIL, 
SPLICING, and for the future CHARACTER)

Date: 30 JAN 1979 1008-EST
From: JONL at MIT-MC (Jon L White)
Subject: (LET (|a| 4) (PRINT A))
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC

Yes, there was an inversion of order in one call to ERROR.  Fixed now.
Thanks for noting it.

Date: 30 JAN 1979 0248-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

I fixed defun& to no longer drop an argument with &REST.

Date: 30 JAN 1979 0109-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

(FORMAT T '|~r| 10.)

;(G0002 42) LOSING OUOTPUT FILE SPECS

Date: 29 JAN 1979 2047-EST
From: ELLEN at MIT-MC (V. Ellen Lewis)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, GSB at MIT-MC

See MC:ELLEN;LISP EXTENS for a discussion GSB and I had earlier
this evening about some proposed extensions to LISP.

Date: 29 JAN 1979 0433-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: KMP at MIT-MC
Subject: (DEFUN FOO (NIL) ...)
To: (BUG LISP) at MIT-MC

Foo.  (DEFUN FOO (NIL) ...) was causing DEFUN& to run, which of course
did nothing with the NIL, leading to PDL overflow.  I traced this down
to an incomplete TYPEP at DEF3B (atom check without NIL check), and
have updated source and am patching it in as well.

Date: 29 JAN 1979 0312-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

If I do 
(LET (|a| 4) (PRINT A))
I get 
;|Bad variable list in LET macro usage| (a 4)

- presumably you have an

(ERROR <form> <message>) rather than (ERROR <message> <form>) statement.
Remember the proper syntax in MacLISP tho you've changed it in NIL is
(ERROR <frob1> <frob2>) => ;<prin1'd frob2> <princ'd frob1>

Good thing this is getting changed since I can't see how it could be
harder to remember. -kmp

Date: 28 JAN 1979 1910-EST
From: RPG,GLS at MIT-MC
Sent-by: RPG at MIT-MC
To: (BUG LISP) at MIT-MC

A slight change to $DEV5 has been edited into the source on MC:
for 10$, nulls are always discarded on ASCII mode input, but never on
image mode input.  The nulls were screwing people badly.

Date: 28 JAN 1979 1735-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

(PLIST 'EDIT) => (FSUBR NIL)   in 1785
I patched on MC, not on any other machines, and didn't touch the source.

Date: 28 JAN 1979 1646-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

Why does (STATUS MACRO <character>) return (<macro function> NIL) rather
than just <macro function>?

Date: 28 Jan 1979 1428-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Bug in new defun& macro.
To:   bug-lisp @ mit-ai
Message-ID: <28Jan79 142806 SF50@CMU-10A>


Try doing the following:

(defun& foo (a b &optional (c 'c) (d 'd) &rest r)
(print `(start ,a and ,b and ,c and ,d and ,r)))

(foo 1 2 3 4 5 6 7 8)

I get (START 1 and 2 and 3 and 4 and (4 5 6 7 8)) which
is not right.  The rest argument is picking up the list
from 4 on instead of 5 on.  Other cases seem to work better.

Bugs aside, the new stuff is really nice.
-- Scott Fahlman


Date: 28 JAN 1979 0518-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___006 at MIT-MC
Subject: MERGEF lossage
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, RWK at MIT-MC

The second bug is that IDNDLS (a table of ROTC's to undo (R)-6 ROTC T,-6's)
was doing ROTC T,-n rather than ROTC T,n.  I have updated the source, and
will patch this fix in as well.

Date: 28 JAN 1979 0506-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___006 at MIT-MC
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, RWK at MIT-MC

Actually, I fixed a bug, but that unveils another worse bug.
I.e. the routine doesn't work at all, since what is in TT is zero,
not the 6bit frob to be compared.  So the bug I fixed obscured worse bug.
Guess I'll try to find this bug too.

Date: 28 JAN 1979 0501-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___053 at MIT-MC
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, RWK at MIT-MC

At IDND3+17, there was CAMN TT,(R) when what was intended was to use
R as an index into IDNTB, i.e. CAMN TT,IDNTB(R)

I have updated the source and patched it on AIMCML.

Date: 28 JAN 1979 0422-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC, JPG at MIT-MC

(LOAD '((JPG) MEDIT >)) dies in LISP 1785 looking for the file as 
((JPG JPG) MEDIT >).  This works in LISP 1750.

MILLER@MIT-AI 01/27/79 22:00:17 Re:  More Attention to Tops-20?
To: (BUG LISP) at MIT-AI

In Lisp News messages, it would be helpful to those of us
leaving I.T.S. for the Tops-20 world, if a little more
attention could be devoted to documenting that version
too.  For example, in describing the args to SUSPEND,
the I.T.S. version and the TOPS-10 version are mentioned,
but not the Tops-20 version.

Thanks, Mark


DHD@MIT-AI 01/27/79 20:51:19
To: (BUG LISP) at MIT-AI
Its hard to believe this went unnoticed before dumping, but

	(DEFUN FOO (&REST FOOBAR) FOOBAR)
	FOO

	(FOO 'BAR 'BAZ) --> (BAZ)

in other words, &rest appears to ignore its first arg (!).  I
checked the value of &REST and it was unbound.  Was this in-
tentional?  It works on the LISP machine.

MILLER@MIT-AI 01/27/79 19:54:47 Re:  What things return, and deserving to lose
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-AI, GLS at MIT-MC, NIL at MIT-MC

You might note that (Print X) does not return X anymore.  This was to
"protect us" from careless cons-ing, since when X was say a useless fixnum,
the complr would generate a useless Fxcons, etc.

However, since "we'd deserve to lose if we relied on the value", I always
end up doing either:

	((lambda (yech) (print yech) yech) X)
	or:
	((lambda (yech) (print yech) T) X)

instead, anyway, depending on whether I want no value or the actual value.
(I hear this is Fortranish, now...)  I used to use (ascii 0) instead of T,
but now this returns the (sometimes helpful) "||" (which really confuses
naive users of things built on Lisp!).

It is a bit embarrassing to go off into the "real world" and tell them how
elegant Lisp is, but then have to apologize about this kind of stuff.

Perhaps if complr were smarter about avoiding useless consing of return
values (perhaps GLS could think about this!) we could go back to the old
definition of things like (Print X) and win more.

In the end, cleanliness issues will win out over efficiency issues.  [But,
if you've been relying on (Print X) to return X, you deserve to lose!]

Mark


ALAN@MIT-AI 01/27/79 19:42:20 Re: DEFPROP and PUTPROP
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-AI, NIL at MIT-MC

I see no real reason for there to be a DEFPROP in the first place.
Why should there be a FEXPR for storing things in property lists?
The only possible justification is for ease of typing toplevel forms,
so who cares what they return? For convience lets keep them returning the thing
whose property list is affected, this is gauaranteed to be something whose
printed representation is short, and is anologous with DEFUN.

Date: 27 JAN 1979 1751-EST
From: KMP at MIT-MC (Kent M. Pitman)
Subject: DEFPROP and PUTPROP
To: GLS at MIT-MC
CC: NIL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 25 Jan 1979 2119-PST
    From: Guy Steele <GLS at SU-AI>

    Gee hiz.  Anyone who depends on the value of DEFPROP
    deserves to lose.  If we were really winning we would arrange
    for DEFPROP to return NO value (as in "MARVEL"!).

Sigh. I'm not sure if you are serious or not. Yes, it might be nice
if things like DEFPROP, etc. didn't return values but they do. I might
point out that the fact that they do is supposedly one of the big features
of Lisp. That you can make use of return values as in:

   (DEFUN PRINT-AND-RETURN-A-RANDOM-NUMBER ()
          (PRINT (RANDOM)))

rather than the fortran-ish style:

   (DEFUN PRINT-AND-RETURN-A-RANDOM-NUMBER ()        ; Yech
          ((LAMBDA (TEMP) (PRINT TEMP)) (RANDOM)))

or

   (DEFUN PRINT-AND-RETURN-A-RANDOM-NUMBER ()        ; Double-Yech
          (PROG (TEMP)
		(SETQ TEMP (RANDOM))
		(PRINT TEMP)
		(RETURN TEMP)))

You are saying I am foolish to rely on what it returns, but if you think
for a moment I hope you'll admit that I'm foolish only 'cuz I know better
about how the language was derived and maintained. Why shouldn't that be
perfectly well-defined? 

Most of these other things that assign values to things (and I use the
phrase 'assign values' loosely as in SETPLIST, RPLACA, SETQ, ... et al
as I mentioned in the note that started this) return the value of the thing
they set. Things that have a clearly defined, well-thought-out return-value
will make for much better compilation and generally nice program elegance.

Do you disagree? I think this is an important issue. I have received several
messages from people in the last year or so with the form "well, you're
foolish for relying on what <x> returns" and I would like to settle this.

-kmp

Date: 27 JAN 1979 1645-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

As Moon pointed out, the #+ scheme does not enable the inclusion of a form
conditional upon the presence of more than one feature (i.e. logical "and") and
logical "or" can only be done by the clumsy #+NIL <form> #+LISPM <form>.
Unless there are any objections, I'd like to adopt the
#+(AND <feature> <feature>) and #+(OR <feature> <feature>) for this purpose.

Date: 27 JAN 1979 1127-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

On ML, I moved SYS;PURQIO 1747 to LISP; in anticipation of its
beingg flushed.

Date: 27 JAN 1979 1112-EST
From: JONL at MIT-MC (Jon L White)
Subject: QIO flag in *LISP, and ASSLIS
To: (BUG LISP) at MIT-MC

There is no longer any reason to have the default value of this be 0,
so I changed it to 1.   ASSLIS  sub-names now reflect this is that
"ITS", "CMU", "REL", "SAI", "D20", "TNX"   all merely set the operating
system flag, and say nothing about the QIO flag.  In order to force 
ASSLIS to say somethign about the QIO flag, the following sub-names
force it to be 1:  "QIO", "CMQ", "RLQ", "SAQ";   the following
force it to be 0:         "CMO", "REO", "SAO"
And as before, "D10" and "MSA" try to make minimal versions for
TOPS-10 and SAIL.  Currently the SFA flag is triggered by the QIO
request.

Date: 27 JAN 1979 1031-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

On AI, I moved SYS;PURQIO 1633 and SYS;PURQIO 1742  to LISP;  in 
anticipation of flushing them.

Date: 27 JAN 1979 1011-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

I moved SYS;PURQIO 1747 to LISP directory, in anticipation
of flushing it.  There are no more pointers to it in LISP;LOCK >

Date: 26 JAN 1979 1445-EST
From: MOON at MIT-MC (David A. Moon)
To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC

#+MACLISP #+ITS (mumble) doesn't work, if you're not on a MACLISP
and also not on an ITS.  Perhaps the syntax #+(MACLISP ITS) would
be appropriate.  Or maybe AND or OR should appear at the front of the list.

Date: 25 Jan 1979 2119-PST
From: Guy Steele <GLS at SU-AI>
Subject: DEFPROP and PUTPROP
To:   kmp at MIT-MC
CC:   bug-lisp at MIT-MC   

Gee hiz.  Anyone who depends on the value of DEFPROP
deserves to lose.  If we were really winning we would arrange
for DEFPROP to return NO value (as in "MARVEL"!).



GSB@MIT-ML 01/25/79 23:27:50 Re: atom vs. null checks
To: (BUG LISP) at MIT-ML
in MC:LISP;NEW RECENT it is claimed that the mapping functions will 
make an atom check, but it doesn't say whether or not they will
just terminate or will error.  Since the atom check is not going 
to be done in compiled (+mapex) code, i think it should error out.
(Or if they will, what about the others, eg MEMBER?)


Date: 25 JAN 1979 0925-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: CWH at MIT-MC

Howcume there are two atoms "EDIT" in LISP?  Notice L;STRUCT * that
copies prior to now have two lines on the page subtitled
SUBTTL ATOMS FOR ODBALL FUNCTIONS AND VARIABLES
...
	MKFV EDIT,$EDIT,FSUBR,EDFUNL
	MRA EDIT
...
This causes (STATUS FEATURE EDIT) and (SSTATUS NOFEATURE EDIT) to lose.

ALAN@MIT-AI 01/25/79 00:57:50
To: CWH at MIT-MC
CC: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI

    CWH@MIT-MC 01/24/79 21:50:24
    Is there any reason why the # reader macro in LISPM2;MACROS can't be
    rewritten to win on toplevel forms when used as #m or #q?  The reason
    it loses right now is that it reads the form following the #m regardless
    of whether it is running in maclisp or on the Lisp Machine.  Can't it decide
    beforehand?

This is because the # macro is a splicing macro (it has to
be in order to make #q and #m work). MacLisp ignores all
splicing macros at top level.  I suggested (because of a
similar problem with using # after a "." as in (#/a . #/z))
that when a splicing macro returns a list of one thing it
should be treated as if it was non-splicing. This was
adopted for the case of being after a dot (since previously
it had errored out in a wierd way) but it was left the same
at toplevel.

I will change the # macro to work at toplevel by not reading
the next form untill it is sure it wants to make it go away,
but I should say that this is somewhat of a kludge since it
means that this all splicing macros can do at toplevel. (It
would be impossible to have a splicing macro that DID
something to the following form work at toplevel.) 

Date: 25 Jan 1979 0054-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: TOPS-10 I/O lossage.
To:   bug-lisp @ mit-mc
Message-ID: <25Jan79 005401 SF50@CMU-10A>


The situation is even worse than I reported earlier.  On input from
a fixnum file in block mode, the halt seems to occur as soon as a
new block must be read, not just at end of file.  Also, using IN
to pull in fixnums from a file in block mode seems to read all of
the first block of the file, but then reads the same block in over again
instead of slurping a new one.  Sigh!
-- Scott

Date: 24 Jan 1979 2110-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Correction to previous message.
To:   bug-lisp @ mit-mc
Message-ID: <24Jan79 211050 SF50@CMU-10A>


OOPS! Make that label BLTI6, not BLT16.  Crummy lineprinter we have
here.
-- Scott

Date: 24 Jan 1979 2106-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Lossage in TOPS-10 Fillarray.
To:   bug-lisp @ mit-mc
Message-ID: <24Jan79 210611 SF50@CMU-10A>


In TOPS-10 MACLISP, a call to FILLARRAY to transfer fixnums from a file
to an array, we get a HALT at user PC 441465 if and only if the end of file
is hit.  All other cases seem to work.  Apparently the EOF test at label
BLT16: is busted.  We need this flavor of FILLARRAY for the editor we are
doing.
-- Scott Fahlman

Date: 24 JAN 1979 1135-EST
From: JONL at MIT-MC (Jon L White)
Subject: LISP;LISP 1771, and LISP;RELRLQ 1771
To: (BUG LISP) at MIT-MC

I deleted these off SECOND: as they don't seem to be used.
There are backups on magtape, and on the XX machine as
<MACLISP>LISP.MID.1771   and   <MACLISP>LISP.REL-TOPS-10.1771
Hopefully, there will be a new REL version out soon.

Date: 23 JAN 1979 2040-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

Is there a good reason why (DEFPROP FOO BAR BAZ) returns FOO
while (PUTPROP 'FOO 'BAR 'BAZ) returns BAR? If not, I would like
to see this corrected at least in NIL and maybe in MacLISP too
if the general feeling is that no one depends on it's return value.
It is inconsistent with SETQ, SET, RPLACA, RPLACD, SETPLIST, PUTPROP.
If your argument is that (DEFUN FOO ...) returns FOO, then I would
like to challenge that and have it return the function object (lambda...)
that gets defprop'd... It would be nice to be able to think of
DEFPROP as just an FSUBR version of PUTPROP ... -kmp

Date: 23 JAN 1979 1202-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

I'm doing (TYI <sfa>) where the sfa function is interpreted, and gets
its chars from a list.  Unfortunately, someone somewhere is expecting
my sfa function to return a machine number in TT and is number consing it!!!
It is rare indeed that anything reasonable winds up in TT in this case.

Date: 22 JAN 1979 1202-EST
From: JOHAN at MIT-MC (Johan de Kleer)
To: (BUG LISP) at MIT-MC

(merggef `|dsk:<foo>a.b;3| nil) gets illegal op in tenex.

Date: 21 JAN 1979 0714-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: FORMAT
To: (BUG LISP) at MIT-MC

This was losing with ~% doing (TERPRI) rather than (TERPRI STANDARD-OUTPUT).
I fixed & recompiled onto LISP;.

MILLER@MIT-AI 01/19/79 21:53:16
To: EAK at MIT-MC
CC: (BUG CRTSTY) at MIT-AI, (BUG LISP) at MIT-AI, MMCM at MIT-MC
CC: CBF at MIT-MC, MOON at MIT-MC, KLH@SU-AI at MIT-MC

Thank you, sending octal 215 prior to image mode characters seems
to solve the problem.

Mark


Date: 19 JAN 1979 2010-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Could the interpreter be made to support and the compiler be made to
do the right thing so that

(DEFUN (FOO MACRO) (X) ...)

does not put |FOO MACRO| in the MACRO property? After all, if anything
of TYPEP RANDOM is found there in the Macro property, it ought to be
assumed a SUBR of one arg and SUBRCALL'd. That's what you do with 
things in the SUBR property isn't it? It doesn't seem reasonable to me
to have this indirection through an atom, and I find the name of the
atom chosen to be especially repulsive.

Thanx. -kmp

Date: 18 JAN 1979 1137-EST
From: EAK at MIT-MC (Earl A. Killian)
To: MILLER at MIT-MC
CC: (BUG CRTSTY) at MIT-MC, (BUG LISP) at MIT-MC, MMCM at MIT-MC
CC: CBF at MIT-MC, MOON at MIT-MC, KLH AT SU-AI at MIT-MC

    Date: 18 January 1979 00:06-EST
    From: Mark L. Miller <MILLER at MIT-MC>
    To:   BUG-CRTSTY, BUG-LISP
    cc:   MILLER, MMCM, CBF, MOON, KLH at SU-AI

    I have some software that attempts to drive a peripheral device
    (a printer, usually) through the AUX port of a CRT.  It is nothing
    very elaborate, a bunch of LISP TYO's.  The critical thing is that
    they use IMAGE mode TTY file.

    When running under :CRTSTY IQ120 these do not work.  My hunch
    is that CRTSTY is intercepting the RAW CONTROL and ESCAPE CODES
    and "converting them to something harmless".  By opening the file
    in IMAGE mode, I have effectively told Lisp NOT to convert things
    to something harmless.  Isn't there some way it can pass this bit
    of advice on to CRTSTY?

Put a %TDQOT (octal 215) in front of each character to be sent
untouched.

Date: 18 JAN 1979 0253-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

If what's in UNDF-FNCTN calls an undefined function, Lisp will .VAL 0
rather than something more reasonable. I wouldn't object to it either
recursing on itself (on the off chance that it could fix the problem!)
or doing a FAIL-ACT breakpoint in this case, but what it does now makes
it hard to debug a new UNDF-FNCTN handler ... -kmp

Date: 18 JAN 1979 0006-EST
From: MILLER at MIT-MC (Mark L. Miller)
To: (BUG CRTSTY) at MIT-MC, (BUG LISP) at MIT-MC
CC: MILLER at MIT-MC, MMCM at MIT-MC, CBF at MIT-MC, MOON at MIT-MC
CC: KLH at SU-AI


I have some software that attempts to drive a peripheral device
(a printer, usually) through the AUX port of a CRT.  It is nothing
very elaborate, a bunch of LISP TYO's.  The critical thing is that
they use IMAGE mode TTY file.

When running under :CRTSTY IQ120 these do not work.  My hunch
is that CRTSTY is intercepting the RAW CONTROL and ESCAPE CODES
and "converting them to something harmless".  By opening the file
in IMAGE mode, I have effectively told Lisp NOT to convert things
to something harmless.  Isn't there some way it can pass this bit
of advice on to CRTSTY?

As it stands, I have to re-LOGIN and pretend to be something harmless
(a random printing terminal) when I want to use the AUX port.

Thanks, Mark

Date: 16 JAN 1979 2005-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG MACSYM) at MIT-MC, (BUG LISP) at MIT-MC
CC: MATHLAB at MIT-MC

Macsyma was broken with symptoms that pointed toward Lisp also being broken.

In Lisp, BOUNDP always returned true. UNBOUND atoms returned a random form
#67... something i forget.

The losing lisp has been saved in SYS;PURQIO 1750O. I copied ML's lisp over
and things seem to be going ok.

The symptoms that were happening to Macsyma if you get strange mail about
it is that Macsyma started with (C2) instead of (C1). Also, unbound vars
printed as 00000000 (number of 0's uncertain).

-kmp

Date: 16 JAN 1979 1929-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: Fahlman at CMU-10A
CC: (BUG LISP) at MIT-MC

Are you aware that if a LISP is set up to run with a highseg
origin of 600000, then the lowseg MUST be 600000 large at
all times, from the moment the LISP starts running?  This is
a hardware limitation.  Also, I am not sure that MIDAS supports
non-400000 highsegs.

Date: 16 JAN 1979 1921-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC


LISP has a (STATUS SUBSYSTEM).  This is the official MacLISP name for
the frob. Having to remember and use
	(COND ((STATUS FEATURE ITS) (STATUS XJNAME))
	      ((STATUS FEATURE SAIL) (STATUS GETNAM))
	      ((STATUS FEATURE DEC10) (STATUS *GTPRG))
	      ((STATUS FEATURE DEC20) (STATUS GETNM)))
is too painful.

Date: 16 JAN 1979 1915-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: JIS at MIT-MC
CC: (BUG LISP) at MIT-MC


    (setq foo '(a b c `(d e f ,(plus 4 3))))

    (A B C (LIST (QUOTE D) (QUOTE E) (QUOTE F) (PLUS 4 3)))

    	The backquote macro does its work even though it appears
    within a quoted list. I know why it does this, I am just not sure
    if it is the "right" thing to do.....

It is definitely the right thing to do.  One of the
important things about LISP S-expression notation is that it
is reasonably "context-free", i.e. what a given string of
characters denoting a complete S-exprression parses into is
not dependent on the context of the larger S-expression in
which it is embedded.

Date: 16 JAN 1979 0834-EST
From: JIS at MIT-MC (Jeffrey I. Schiller)
To: (BUG LISP) at MIT-MC


(setq foo '(a b c `(d e f ,(plus 4 3))))

(A B C (LIST (QUOTE D) (QUOTE E) (QUOTE F) (PLUS 4 3)))

	The backquote macro does its work even though it appears
within a quoted list. I know why it does this, I am just not sure
if it is the "right" thing to do.....


			-Jeff

TFT@MIT-AI 01/15/79 22:09:29
To: (BUG LISP) at MIT-AI
I was in LISP and I attempted to (load '((liblsp)lispt fasl))
and I was thrown to DDT with the message DST; DSK: LISP BIN
NON-EXISTANT DEVICE  I know I don't have a dir---does lispt 
require one these days??


Date: 15 JAN 1979 1732-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: image-output on TTY for TOPS-10
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC, HGB at MIT-MC

I'm sure that what Henry wants can be hacked with moderate ease.  All the
flags are around, there'll just have to be a kludge when you try to do
image output to a TTY.  Perhaps I'll kludge it up under IN.  As I'll
be going to California with RG this Wednesday, I probably won't get a chance to
hack this until I get back (perhaps about two weeks).  But when I get back I'll
try to get something going.

Date: 15 JAN 1979 1543-EST
From: JONL at MIT-MC (Jon L White)
Subject: image-output on TTY for TOPS-10
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

Henry Baker is screaming for for this - probably is trying to do
a kind of EMACS under lisp.  Here is something he asked me the other
day - do you have any ideas?

I desparatly need some way of doing image mode output on the TTY!  Re-opening
the tyo file in image mode and re-ttyconsing doesn't do the actual image thing
on TOPS-10.  The right monitor call to use is:
	TTYCALL 15,char
for image mode (it outputs an 8 bit character "char").  This mode is called
"IONEOU" in the tops-10 manual.  Therefore, one can say:
	IONEOU char
instead.  For reference, the standard way to do character outtput on tops-10
is:
	TTYCALL 1,char
Since this is called "OUTCHR", one can also say:
	OUTCHR char
instead.  IONEOU sends the low 8 bits (and ignores high bits), while
OUTCHR sends the low 7 bits (and ignores high bits).
  

Date: 15 JAN 1979 0613-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC


    Date: 14 JAN 1979 2220-EST
    From: KMP at MIT-MC (Kent M. Pitman)

    Why does 

    :LISP
    Alloc? N
    (SSTATUS TTYINT 2. 2.)
     

    not cause a  Breakpoint?
------
If you would have done (STATUS TTYINT 2) before munging around, you would
have seen that the ^B break is handled by a function, not by the funny
internal things like ^G.  A number is meaningless, there is no handler for the number
2.

Date: 14 JAN 1979 2220-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Why does 

:LISP
Alloc? N
(SSTATUS TTYINT 2. 2.)
 

not cause a  Breakpoint?


Date: 14 JAN 1979 0433-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC

This is exactly what you want:

(DEFMACRO BIND-INTERRUPT-STATE (NEW-VALUE CODE)
  `(UNWIND-PROTECT () (NOINTERRUPT ,NEW-VALUE) . ,CODE))

It is sort of a kludge, but given the fact that UNWIND-PROTECT does the binding for you,
it'll work.  Of course, if CODE does a *THROW (or similar) this will lose, so perhaps
you want to hair it up by doing:

(DEFMACRO BIND-INTERRUPT-STATE (NEW-VALUE CODE)
  `(LET ((OLD-STATE (NOINTERRUPT T)))
	(NOINTERRUPT OLD-STATE)				;Just to read the current state
	(CATCHALL '(LAMBDA (TAG VALUE) (NOINTERRUPT OLD-STATE) (*THROW TAG VALUE))
		  (UNWIND-PROTECT () (NOINTERRUPT ,NEW-VALUE) . ,CODE))))

If NEW-VALUE is T, then I believe that this code is foolproof as once the NOINTERRUPT in the
UNWIND-PROTECT gets done, the old value is garunteed to get restored.  If it is NIL, then
you could lose in certain circumstances.  [I'm not really sure if it's 100% secure,
but it is damn close].

I personnally believe that the right thing to do is to make NOINTERRUPT a special
avriable like *RSET so that it can be bound by the standard mechainisms!

--howard

Date: 13 JAN 1979 1714-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Well, here we go again. I have a problem with NOINTERRUPT and UNWIND-PROTECT
and so on. I don't think that UNWIND-PROTECT is powerful enough to handle
the problem I have.

Situation: Interrupts may be on or off (they are set at random by some
   higher intelligence).

Goal: To turn off interrupts for a moment, execute a piece of code and
      guarantee that no matter what happens, interrupts will be left as
      they had been initially.

Examples of lossages:

[1] UNWIND-PROTECT seems to be restoring the interrupts to what they were
    at the end of the execution of its first arg. If there were a way it 
    could detect that the user had munged with interrupts and would leave
    things alone, then it would be okay. As is here is a case of where
    I think is is doing the wrong thing. (Remember the value of 
    (NOINTERRUPT arg) is the former value of NOINTERRUPT.

    (NOINTERRUPT NIL)
    NIL
    (UNWIND-PROTECT (PROGN (NOINTERRUPT T) (PRINT 'FOO)) (NOINTERRUPT NIL))
    FOO ; I hope interrupts are NIL here ...
    T
    (NOINTERRUPT NIL)
    T   ; Interrupts seem to have been T!

[2] Error recovery seems to override everything. I'd have thought there
    was at least enough power here (maybe even overkill) to get interrupts
    off at the end of this sequence, but doesn't do it!

    (NOINTERRUPT T)
    NIL
    (UNWIND-PROTECT (+ 'A 'B) (NOINTERRUPT T))
    ;B NON-NUMERIC VALUE
    ;BKPT WRNG-TYPE-ARG
    p
    ;BKPT *RSET-TRAP
    p
    *
    (NOINTERRUPT T) ;I hope interrupts are T already!
    NIL ; But they aren't!


What I would like is a way of saying to push interrupts and have them
reset when I exit. Something like UNWIND-PROTECT for interrupts. This
would probably be easy to write from Midas (though I bet impossible
to write from Lisp (discounting LAP)) and would be much more elegant than
some things I've tried.

Something like:

(PUSH-INTERRUPT <Form-to-evaluate>)

where <Form-to-evaluate> could reset interrupts as he liked knowing that
when the PUSH-INTERRUPT frame were popped, the world would be happy again.

Comments? -kmp

Date: 13 JAN 1979 1210-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

LISP has no (STATUS XJNAME).  This is the official ITS name for the frob.
Having to remember and use (STATUS SUBSYS) is too painful.

Date: 13 JAN 1979 0339-EST
From: JONL at MIT-MC (Jon L White)
Subject: ASSQ and ASSOC
To: (BUG LISP) at MIT-MC

Even in *RSET mode, these two lose if an element of the "alist"
is some random ilgl address rather than a pair.  I believe that
nulls are acceptable in place of pairs, however.

Date: 12 JAN 1979 2200-EST
From: JONL at MIT-MC (Jon L White)
Subject: BAKTRACE
To: (BUG LISP) at MIT-MC

Part of the output of baktrace goes to MSGFILES and part of it
goes to OUTFILES, giving an incorrect sequence of function calls
in the OUTFILES listing, and a few random symbols in MSGFILES.

Date: 12 JAN 1979 2159-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: ^G while inside UNWIND-PROTECT
To: RLB at MIT-MC, (BUG LISP) at MIT-MC

Now works.  I was trying to unpop SP all the way to 0, rather than
to its base!! Patched.

Date: 12 JAN 1979 1557-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: ^G while inside UNWIND-PROTECT
To: RLB at MIT-MC, (BUG LISP) at MIT-MC

I never said that there wasn't a bug, I simply said that it was precisly defined.

Date: 12 Jan 1979 1350-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: 128K+ Low segs on TOPS-10
To:   BUG-LISP @ MIT-MC
Message-ID: <12Jan79 135049 SF50@CMU-10A>


Jonl,
It seems that landing the high seg at other than 400000 octal
is handled by the loader on the KL system (note that none of
this applies to KA systems).  The lisp assembly source (in
MACRO-10) sets a parameter SHRST to 600000 if the assembly is for
CMUA, then does a TWOSEG SHRST and a RELOC SHRST to get stuff to
the right place.  I guess these are equivalent to .DECTWO and
.DECREL in MIDAS.
Other ways to accomplish the same goal are to use the TOPS-10
LINK program with a switch of /SET:.HIGH.:600000  or to
use the REMAP system call from within LISP at runtime.  But it
does look like the assembly and loading must be done with a high
seg at 600000 in mind at the time.  I think this would be the best
place for the high seg on CMUA as a default -- it would leave some room
for additional pure stuff, but would give us 1.5 times the available
space for user core.  If this does not seem to work for some reason,
I will get Cris Perdue to give you a call to bash out details.  He has
been the principal UCI-lisp hacker here, and is now moving to New
Hampshire to work for Ed Berg.
The inability to load SSAVE files with > 128K lowsegs is due to a
monitor bug.  A fix has been promised, but such things typically take a
year here.

-- Scott

Date: 12 JAN 1979 1042-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: ^G while inside UNWIND-PROTECT
To: (BUG LISP) at MIT-MC

Well, maybe the situation is well defined, but I still get MPV and sometimes
PURPG traps when I attempt the quit.  Specifically, type at a bare Lisp,

(defun x ()
       (*catch 'foo (unwind-protect (+ 0 0.0)
				    (nointerrupt ())
				    (*throw 'foo 'foo))))))

Just run (X) and at the ;WRNG-TYPE-ARG type ^G.
Obviously, $P never wins. Sometimes $G wins, sometimes 100$G wins,
and sometimes even 100$G loses.  I haven't figured out just how
to reproduce all these.

JONL, you said someone was pushing an extra word on INTPDL?

Date: 12 JAN 1979 1002-EST
From: SUN at MIT-ML (Alex Sunguroff)
To: (BUG LISP) at MIT-ML
CC: RPG at MIT-ML

Well JONL, I goto the new LISP (1771) and COMPLR (864)
up and running fine.  They are certainly an improvement
over the 15xx LISP I had. However here follow some bugs:
1) This one is from last time though a bit better.
What SFD a file is in is still confusing to the LISP.
When one opens a file in another SFD (or back in yours
if you set your PATH to another one) the correct file
really is opened, but part of LISP doesn't believe it.
The SFD used in the PNAME of the file object and the SFD
returned by TRUEname are WRONG! These two always
just use the value of UDIR and not reality.  However,
NAMELIST, NAMESTRING, and DEFAULTF all return the correct
value when given the file object.
2) The initial value of the variable DEFAULTF is set to
UNAME rather than UDIR. I think it should be the latter.
3) SETQ'ing T and NIL no longer completely detonate the
LISP any more, but they do cause a write into read-only
memory and and an REE does not work, only a START.
4) In building a COMPLR, CCLOAD does not work.  Things terminate
with an error that looks a lot like a setq of T or NIL.
I was able to make a complr by just loading in the appropriate
files and doing and initialize and a cdump.  However,
it would be tter if the CCLOAD really did work.  The CO(MPLR I manot had e
extensive testing done to it.



Date: 12 JAN 1979 0748-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

These days of (defun (foo macro) ...) yielding subrs like |FOO MACRO|
makes the output of BAKTRACE hard to parse.  How about effectively using
PRIN1 rather than PRINC?

Date: 12 JAN 1979 0501-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 NAMELIST
To: (BUG LISP) at MIT-MC

If namelist is given a symbol with too many characters in it, 
there will be an ilgl uuo

Date: 11 JAN 1979 1924-EST
From: JONL at MIT-MC (Jon L White)
Subject: Numeric access in NTHCDR
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

you're absolutely right, it should be JSP T,FXNV1, in order to
allow for fixnump checking.  I'll edit that in immediately.

GSB@MIT-ML 01/11/79 19:17:37
To: (BUG LISP) at MIT-ML
How about a JSP T,FXNV1 ? MOVE R,TT
instead of MOVE R,(A)
at the front of NTHCDR?
If this is deemed too much for compiled code, then compiled code
should have its own routine, since (in my opinion) it shouldn't be
doing *rset checking then.


Date: 11 JAN 1979 1902-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC


    Date: 10 JAN 1979 2107-EST
    From: KMP at MIT-MC (Kent M. Pitman)

    Jonl tells me that it is undefined what state the world will be in if
    the following piece of code is executed typing a control-G in the place
    where each READLINE is ...

    (UNWIND-PROTECT (READLINE) (NOINTERRUPT NIL) (READLINE) (SETQ SOMETHING 'FOO))

    What will happen, and if it is not clear can something be defined?
    Having to say "Well, don't do anything major in an UNWIND-PROTECT..."
    isn't really saying anything powerful for it.
    -kmp
-----
It is **PRECISLY** defined what will happen.  When the "unwind-protect" forms
are run, the UNWIND-PROTECT frame to which they belong has been popped
first.  This way an error in the unwind protect forms, for example, will
not cause a loop.  Also, how else couls THROW's out of unwind-protect handlers
work??  That is why NOINTERRUPT T is done, so that an asynchronous interrupt
can't cause the forms not to be run!!

Date: 11 JAN 1979 1856-EST
From: HIC at MIT-MC (Howard I. Cannon)
Subject: LAST versus APPEND, REVERSE, GET, etc.
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

I agree that last should terminate on any attom.  But I don't understand why you don't
want to hack the other functions in a similar fashion,  probably controlled by *RSET...

Date: 11 JAN 1979 1749-EST
From: hgb at MIT-MC (Henry G. Baker, Jr.)
Sent-by: JONL at MIT-MC
Subject: (STATUS JCL)
To: (BUG LISP) at MIT-MC

In the TOPS-10 version, this always semms to return nil.

Date: 11 JAN 1979 1740-EST
From: JONL at MIT-MC (Jon L White)
Subject: (STATUS FLUSH)
To: (BUG LISP) at MIT-MC

This feature definitely should be available to the TOPS-10/20 world.
For example, if one works a lot on a lisp subsystem, then dumps it, 
then for some reason the base LISP.SHR is lost or replaced, then you
lose.  So (SSTATUS FLUSH () )  would merely allow the TOPS-10/20
user to assure the dumping of his hiseg also.

Date: 11 JAN 1979 0208-EST
From: JONL at MIT-MC (Jon L White)
To: CWH at MIT-MC
CC: RWK at MIT-MC, HIC at MIT-MC, JONL at MIT-MC, (BUG LISP) at MIT-MC

I'D LIKE TO MAKE LAST DO THE "ATOM" TEST RATHER THAN THE "NULL" TEST,
UNLESS THRE IS A GREAT HUE AND CRY ABOUT THE **NECESSITY** FOR SPEED
IN "LAST".  PUTTING IN THE CHECKS CHANGES THE TIMING FROM  1.12 US/NODE
TO ABOUT 2.92 US/NODE, ON THE MC MACHINE.  IF THIS IS, FOR SOME REAL
REASON, UNACCEPTABLE, THEN PERHAPS WE COULD DEFINE A FAIL-SAFE FUNCTION
"LASTNODE" THAT DOES THE "ATOM" CHECK.  EITHER WAY, ALL THE OTHER
FUNCTIONS, SUCH AS APPEND, NCONC, ETC. COULD, IN *RSET MODE, MERELY
CHECK (AND (OR (ATOM ARG) (CDR (LAST ARG))) (ERROR '|NON-LIST - | ...))
BEFORE FALLING INTO THE FAST LOOP.  NOTE, HOWEVER, THAT THERE MUST
BE SOME USER-AVAILABLE FUNCTION, WHICH IS NOT AFFECTED BY *RSET, FOR
TESTING THE "NORMALITY" OF A LIST.

Date: 11 JAN 1979 0114-EST
From: JONL at MIT-MC (Jon L White)
Subject: LAST versus APPEND, REVERSE, GET, etc.
To: (BUG LISP) at MIT-MC

I propose that LAST be defined as terminating on any atom, 
whereas the other primitives be defined to terminate on the nullist -
the lack of a definition as to what these other primitives do on non-null
atoms leaves the option for maclisp to run fast in *RSET null mode, and
do error checking in *RSET non-null mode.  Possibly in LISPM and NIL, 
all primitives can be defined as terminating on any atom.

Date: 11 JAN 1979 0051-EST
From: JONL at MIT-MC (Jon L White)
Subject: LAST
To: (BUG LISP) at MIT-MC

LAST cdrs down a list, terminating when () is found - sigh!  At least the
LISPM definition of LAST is that it terminates when **any** atom is found.
The latter definitions is crucial if one wants to find out, quickly, 
whether or not a proffered list is a "standard" list (i.e., "ends" in () ).

Date: 10 JAN 1979 2138-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

FLATC and FLATSIZE seem to ignore PRINLEVEL and PRINLENGTH.

Date: 10 JAN 1979 2107-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Jonl tells me that it is undefined what state the world will be in if
the following piece of code is executed typing a control-G in the place
where each READLINE is ...

(UNWIND-PROTECT (READLINE) (NOINTERRUPT NIL) (READLINE) (SETQ SOMETHING 'FOO))

What will happen, and if it is not clear can something be defined?
Having to say "Well, don't do anything major in an UNWIND-PROTECT..."
isn't really saying anything powerful for it.
-kmp

Date: 10 JAN 1979 2012-EST
From: RLB at MIT-MC (Richard L. Bryan)
To: (BUG LISP) at MIT-MC

Boy, is a list of spaces hard to parse visually!
(| | | | | | | | | | | | | | | | | | |)
(|)

Date: 10 Jan 1979 1737-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Expanding TOPS-10 MACLISP
To:   bug-lisp @ mit-ai
Message-ID: <10Jan79 173704 SF50@CMU-10A>


Hi again,
I checked with the UCI LISP hackers here to see how they get moby
(> 128K word) low segs.  It seems that our current monitor will refuse
to LOAD a stored file with a low seg of >128K, but it is perfectly
happy to grow the low seg of a running job to whatever size is
available (i.e. not used by the high seg).  So ALLOC ought to be able to
ask for additional core in the low seg once it is fired up.  This would
be a big help to us if the change could be put in without too much
hassle.  The losing size limitation on SAVE files' low segs might
also go away someday soon, at least here at CMU -- it seems to be a basically
arbitrary problem rather than anything fundamental.

Regards,
Scott Fahlman


Date: 10 JAN 1979 1633-EST
From: MOON at MIT-MC (David A. Moon)
To: (BUG LISP) at MIT-MC

Date: 10 Jan 1979 1226-PST
From: Dick Gabriel <RPG at SU-AI>
To:   bug-lis at MIT-AI

 09-Jan-79  2038	Scott Fahlman at CMU-10A (C380SF50) 	Stretching TOPS-10 MACLISP  
To:   BUG-LISP    
Date:  9 Jan 1979 2218-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Stretching TOPS-10 MACLISP
To:   bug-lisp @ mit-ai
Message-ID: <09Jan79 221816 SF50@CMU-10A>


It appears that the low segment in TOPS-10 MACLISP is limited to 128K,
even though the high seg is only 28K or so.  Is this a fundamental
limitation or is there a way to get at some of the unused space for the
low seg?  As it is, the extra space available to UCI Lisp more than
compensates for the more compact code of MACLISP (sigh!).  Even if this
can't be changed dynamically, a static change to give more to the low seg
would be helpful.
-- Scott Fahlman @ CMUA


This seems to be a problem that many people would like to solve, including
SAIL. Earlier this fall there was a scheme afoot to get HIC and BH (Brian Harvey)
together at SAIL to solve this for SAIL (and presumably for TOPS-10 as well).
This has fallen through. Since we run 2.5 million words (2500k) of memory now,
we favor a 1 segment scheme. A simple possibility is to have the hiseg located
at <top-of-memory>-<size-of-hiseg> in a faked 2 segment system. U of Illinois does
this. Demand paging systems don't mind this either. The other tactic is to
put the hiseg below the loseg. Perhaps SAIL, CMU, MIT and other interested
parties could co-operate on a solution.
			-rpg-



Date:  9 Jan 1979 2218-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Stretching TOPS-10 MACLISP
To:   bug-lisp @ mit-ai
Message-ID: <09Jan79 221816 SF50@CMU-10A>


It appears that the low segment in TOPS-10 MACLISP is limited to 128K,
even though the high seg is only 28K or so.  Is this a fundamental
limitation or is there a way to get at some of the unused space for the
low seg?  As it is, the extra space available to UCI Lisp more than
compensates for the more compact code of MACLISP (sigh!).  Even if this
can't be changed dynamically, a static change to give more to the low seg
would be helpful.
-- Scott Fahlman @ CMUA


Date: 9 JAN 1979 2110-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: MOON at MIT-MC, RWK at MIT-MC, (BUG LISP) at MIT-MC

With RWK's permission, I deleted SYS;PURQIO 750BAD as there was nothing 
wrong with it.

Date: 9 JAN 1979 0447-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: RWK at MIT-MC, MOON at MIT-MC
CC: (BUG LISP) at MIT-MC

I just tried to load in SYS:PURQIO 750BAD and it loads in just fine. 
As disk space is nice, can one of you confirm this and delete the 
file?

Date: 9 JAN 1979 0404-EST
From: RLB at MIT-MC (Richard L. Bryan)
Subject: (FOO . #)
To: (BUG LISP) at MIT-MC

I hope JONL's fixes don't screw the hunk reader's use of stray dots.

Date: 9 JAN 1979 0400-EST
From: JONL at MIT-MC (Jon L White)
Subject: "(FOO . #)", where # is splicing macro
To: (BUG LISP) at MIT-MC
CC: alan at MIT-AI

1) The bug whereby "(FOO . )" produces "(FOO . #51)", or
   whereby "(FOO . #)" with # a splicing macro returning ()
   produces the same lossage, is fixed by inserting at RDLST4
	JUMPE T,ER2
2) The bug whereby "(FOO . #)" produces "(FOO BAR . #51)",  where # is
   a splicing macro returning "(BAR)", is fixed by replacing the two
   lines at RDLS4A+4,5 with
	HRRZ AR2A,(A)
	JUMPE AR2A,ER2
	HLRZ AR2A,(A)
	HRRM A,(TT)
	JRST RDLS4B
   This will cause the example to produce "(FOO . BAR)" in accord with
   ALAN's expectations.
***HOWEVER***, I'm not 100% sure that having splicing macros returning
lists of length longer than one can be ruled out - maybe there was a
long-lost "feature" that made "(FOO . #)"  somewhat equivalent to
"(FOO #)" in that case.  Lose, lose.  Anyway, I've edited in these
changes to the reader.

ALAN@MIT-AI 01/09/79 02:49:09 Re: Splicing macros
To: (BUG LISP) at MIT-AI
Splicing macros after a dot intended to create a cons should be checked
for better by the reader.  The LispMachine #q (read for LispMachine) and
#m (read for MacLisp) are splicing macros (since they sometimes return "nothing")
thus other usefull # features must be splicing as well, for example #/ which
reads the next character and returns its ascii value.  Forcing #/ to be splicing
causes the following bug however: (#/a . #/z) reads in as: (141 172 . #51)
(I will remind you that 51 is the ascii for ")", we have seen versions of
this bug before!) Now (#/a . #/z) is a perfectly reasonable thing to ask for,
and it seems that other splicing macros might suffer from this bug as well,
so I propose the following solution:

	After a dot a splicing macro that returns nil ("nothing") should
cause the next thing to be read in as if it wern't there (this is what the
current scheme thinks it is doing except there is no check for a ")").
	If it returns a list of exactly one thing, then that thing should
be tacked on to the end of the list and there better be a close paren next!
(or perhaps a splicing macro that returns nil first!)
	If it returns more than one thing then barf.

Is there any good reason why things can't work this way? Shouldn't splicing
macros at toplevel also work in a similar way? In any case an error should
be reported if the thing is going to continue to do what it does now.

Date: 9 JAN 1979 0105-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Presumable the line  "SKIPA R,[STTYW1&ZZ]"  just after SLINMODE:
should be "SKIPA R,[STTYW1&ZZX]"; ie. it should mask with ZZX like
all the other lines near it.

Date: 8 JAN 1979 2347-EST
From: JONL at MIT-MC (Jon L White)
Subject: Too much space on L; directory
To: (BUG LISP) at MIT-MC

Due to a gross crunch in DSK space, I deleted many of the "<" versions
of some of the LISP source, in the cases where the source hadn't been
hacked since before December, and where the SRCCOM of the deleted
file and ">" version had only a couple of lines of change.  Of course,
all deleted files had been backed up.
   ARITH 77    ERROR 116    FASLOAD 209    GCBIB 224    LCHNSP 23
   PRINT 217   SORT 10      STATUS 187     ULAP 122

Date: 8 JAN 1979 2259-EST
From: JONL at MIT-MC (Jon L White)
Subject: AUTOLOAD
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC

I verified that (TRACE $DEFRULE) in a fresh MACSYMA does not use
the built-in AUTOLOAD handler, but rather your function FIND0.

Date: 8 JAN 1979 2245-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

EVAL-WHEN should not have an ARGS property.

Date: 8 JAN 1979 2240-EST
From: JONL at MIT-MC (Jon L White)
Subject: Wrong message upon write-into-read-only-page
To: JPG at MIT-MC, DCP at MIT-MC
CC: (BUG LISP) at MIT-MC

The wrong appearance of EVAL-WHEN in the MACHINE-ERROR handler
is due to the mis-placement of the symbol EVAL-WHEN.  I'll
reassemble LISP (since there are a number of other error that
need to be corrected too), and the bug will go away.

Date: 8 JAN 1979 1539-EST
From: RWK at MIT-MC (Robert W. Kerns)
Sent-by: ___115 at MIT-MC
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC

MC:SYS;PURQIO 750BAD is a LISP pure dump that suddenly stopped working this
afternoon, presumably because the disk decided to change the page map somehow.
(It gets PURPG errors on startup now.)  I've dumped another pure dump which
seems to work OK now.

Date: 8 JAN 1979 0423-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: DCP at MIT-MC, JPG at MIT-MC

Typing to MACSYMA's LISP:
(EQTEST (GET 'MPLUS 'MSIMPIND) '((FOO)))
leads to ;EVAL-WHEN error from location 72384
	 ;program trapped while in EQTEST  .
The message is printed out by MACSYMA's MACHINE-ERROR handler 
(called MACHERRFUN).  MACSYMA is indeed trying to RPLACA pure 
structure here (MSIMPIND is a purified property), but EVAL-WHEN 
is the wrong type error.

Date: 7 JAN 1979 0304-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

Doing (TRACE $DEFRULE) in a fresh MACSYMA fails because it appears that 
LISP is using the built-in AUTOLOAD handler when it should of course 
be using the current one.