Date: 5 JAN 1979 1557-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-10 grinding
To: (BUG GRIND) at MIT-MC

Due to the incompattibliity of RENAME in the TOPS-10 version,
you can't rename to an existing file (wont delete the existing file)
so have to use some intermediate strategy, as in FASLAP.

Date: 5 JAN 1979 1549-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-10 version
To: (BUG LISP) at MIT-MC

JCL reader doesn't understand aboutt PPN specifications in the
lisp init file.  

Date: 5 JAN 1979 0359-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC


    Date: 5 JAN 1979 0252-EST
    From: JPG at MIT-MC (Jeffrey P. Golden)

    I just noticed that both MAXIMA's dumped out on MACSYM; are 
    n blocks + 8 words big.  Why the 8 words?

The 8 words are the indirect symbol table pointer.

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

I just noticed that both MAXIMA's dumped out on MACSYM; are 
n blocks + 8 words big.  Why the 8 words?

Date: 5 JAN 1979 0231-EST
From: Quux at MIT-AI (Quux)
Sent-by: GLS at MIT-AI
Subject: {[foo]<bar>[bletch] =>)
To: rpg at SU-AI
CC: (BUG lisp) at MIT-MC

You have just been aided by the new MacLISP DEBDWYCPHM (deb-dwick-phum)
feature: Don't Even Bother Doing What You Couldn't Possibly Have Meant.
MacLISP saves on machine cycles when it comes across something so
ridiculous that even PAM wouldn't have written it.
Instead it just does something even moore ridiculous so you'll give
up and stop wasting your time.  It will probably work fine if you get rid
oof all those silly brackets.


Date: 4 Jan 1979 1354-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: SAIL-NEWIO    
To:   bug-lisp at MIT-MC    

	I've come across a strange diskio bug in SAIL-NEWIO.

Namely, suppose that { is a read macro that basically does TYI's.
However, assume that [ and < cause a READ to occur and ] and >
are splicing macros al la (lambda () ()) and that you are scanning something
like:

	{[foo] <bar> [abcd] => ...}

The program does a tyi and sees the [, flushes it, and the does (READ file),
getting "foo" (and removing the ] from consideration). Now it does a TYI and
gets > (!!!), then a space, then the < (!!!). Here it does the correct (READ file).
It flushes the > but then the next TYI gets a > again!!!

This sounds suspicious to me.
			-rpg-



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

The IO-LOSSAGE break point when a file is not found, often has
the file-specification before any MERGEFing was done, so it is
hard to figure out just why the file was not found; e.g.
;(OPEN ((* *) FOO BAR) FILE NOT FOUND
maybe we could display both what the user supplied, and what OPEN
really was looking for (in this case, the value of (* *) was 
supplied by DEFAULTF, but not always so.)

Date: 4 JAN 1979 1052-EST
From: JONL at MIT-MC (Jon L White)
Subject: Active files
To: (BUG LISP) at MIT-MC, KMP at MIT-MC, HIC at MIT-MC, RICH at MIT-MC

Some time ago, we talked about having a function which would return
the "active" arrays, which could be selected out for active files.
I have put such a function on LIBDOC;ARY? JONL1, and LIBLSP;ARY? FASL
which can be used exactly the same way as ACTIVEFILES could be used;
if there is some discrepancy, we should get to know it.

Date: 4 JAN 1979 1007-EST
From: JONL at MIT-MC (Jon L White)
Subject: Random Device names
To: (BUG LISP) at MIT-MC

I hacked some code for the IDND (Insufferable Device Name Distinguisher!)
in ITS mode, to make it recognize things like AR1 as devices.   Basically,
there was a bug in the stripping off of right-end digits - but also I put
in a binary sort of the device-name table.

Date: 4 JAN 1979 1004-EST
From: JONL at MIT-MC (Jon L White)
Subject: DEFNS 
To: (BUG LISP) at MIT-MC

I added some symbols to the XTRSYMS feature in DEFNS:
  READ6C, TYIMAN, CHNTB, DEDSAR, GCMKL
The first three were requested by the SAIL hackers some time ago,
and the latter three may be useful in the ACTIVEFILES hack.
Also, I moved READ0A out from under the QIO conditional (why was 
it conditionalized?).  Why also is there an entry for Q..MIS, since
this can always be referenced by (QUOTE **MISSING-ARG**) ??

Date: 3 JAN 1979 2052-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: JONL at MIT-MC, RICH at MIT-AI

Take a look at MC:HIC;ACFILE >


Date: 3 JAN 1979 1925-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: JONL at MIT-MC, RICH at MIT-AI

It is fairly trivial to get all of the open file objects.
I think that perhaps a STATUS frob is quite reasonable for this, but
since you need to install a new LISP for a status thing perhaps a simple
function could be written (ACTIVEFILES).  As far as heuristics are concerned,
I won't put any in, but you are welcome to remove the UREAD file (et al.) from
the list of things that ACTIVEFILES returns.  I will mail you a pointer to the function.

Date: 3 JAN 1979 1802-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: RICH at MIT-MC, (BUG LISP) at MIT-MC, JONL at MIT-MC

Sorry for the funny state of last message - a control-c doubled on me.
Anyway, aside from fact it thought I was gonna list two things, which I
was about to change to one, I was about done... -kmp

Date: 3 JAN 1979 1759-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC, JONL at MIT-MC, RICH at MIT-AI


    RICH@MIT-AI 01/02/79 21:53:21
    Re: Useful Macro for doing I/O in MacLISP under New-i/o
    this brings to mind an earlier discussion with JONL about the
    need to have  LISP keep some global list of open files.

A Two suggestions for discussion. Could I have some comments about why they
are not the 'right' thing or what tradeoffs are involved, etc.

[1] (STATUS ACTIVEFILES) => might return a list of all open new-i/o file
    objects. Shouldn't mention anything being UREAD since that's handled
    in other ways.

    This would let people know if files were open and optionally map down
    them closing them.


Date: 3 JAN 1979 0616-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 version 
To: (BUG LISP) at MIT-MC

(STATUS GCTIME) seems to give random numbers.

Date: 2 JAN 1979 2121-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG ITS) at MIT-MC
CC: (BUG LISP) at MIT-MC, KMP at MIT-MC

Since ITS doesn't recognize the device MCARn when on the MC machine,
this must be an ITS deficiency.

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

(QUIT 0) returns to DDT with a normal prompt. P re-enters and immediately
valrets :VK to DDT. P again returns 0 at lisp level. RWK asks 'what is this
spurious :VK doing in there?' (i'll second the motion).
-kmp

Date: 30 DEC 1978 1937-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Could you make MCAR1: be recognized as a device by lisp...? Makes for nice
transportability between ITS's when source lives only on one site. tnx- kmp

Date: 28 DEC 1978 2002-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 file-io
To: (BUG LISP) at MIT-MC

MERGEF loses.  If you use MACSYMA while **not** connected to
the <macsym> directory you will lose.  The following scenario
should describe the bug perfectly (prefix char of line indicates
who is typing at whom):
@CD <MACLISP>
@RUN LISP
%ALLOC ?
*N
%
%*
*(MERGEF '|FOO| '((DSK MACSYM) * FASL))
%((PS MACLISP) FOO FASL /0)

So the problem seems to be in the buggy code of FIL6BT that 
attempts to play around with GTJFN.

Date: 28 DEC 1978 1920-EST
From: JONL at MIT-MC (Jon L White)
Subject: Device names
To: (BUG LISP) at MIT-MC

The ITS-specific code that tries to figure out if things like PKnn
and ARnn are device names is losing.  I think it is a lossage near
IDND1, it should be testing B for zero in addition to checking for
values '0 thru '9.

Date: 28 DEC 1978 1827-EST
From: JONL at MIT-MC (Jon L White)
Subject: Floating-point printout
To: (BUG LISP) at MIT-MC

1) an unnormalized floating zero (i.e., SETZ) kills the printer
   with an infinite output of 0's
2) largest magnitude flonums  printout in too few digits. (just a
   reminder on this one!).  E.g.  1.70141183E38 really should be
   1.701411825E38.

Date: 28 DEC 1978 1822-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

(LOAD '((AR4) A B)) gives the error message 
;(LOAD ((DSK AR4) A B)) NON-EXISTENT DIRECTORY 
when LISP claims to make an attempt to recognize that AR4 is a device-name. 
(It has "AR" in its table.)

Date: 27 DEC 1978 0118-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: TOPS-20 Interrupts
To: (BUG lisp) at MIT-MC
CC: dang at MIT-XX

^S is weird in thhat it is BOTH an inteerrupt character and a macro
character.  I forget whether this is difficult or impossible to
do on a -20.  In any case, it is like ^W as an interrupt character
and like ^V and then a TERPRI as a macro character.  It should not
affect ^Q -- a primary use of it is to "turn off output until
my UREAD file is loaded" after seeing the first few bits of output.
JONL is of course correct in seying that ^Q should not be an interrupt
character.  (There is some question in my mind as to whether ^R and
^T should be interrupt characters as well!  But soomeone else can
argue thhat -- I don't care too much.)


Date: 26 DEC 1978 1710-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 interrupts
To: (BUG LISP) at MIT-MC
CC: dang at MIT-XX

MACLISP is advertised to have interrupt meaning for the following
control characters:
  ^A, ^B, ^C, ^D, ^G, ^R, ^T, ^V, ^W, ^X, and ^Z
I believe that ^Q, ^S, are macro characters, and ^K and ^L are specially
recognized by the read-scanner.  Apparently there are two bugs here?
1) on ITS systems, ^S fails to set ^Q to (), and
2) on TOPS-20, ^Q seems to be set up as an interrupt character.
3) on neither system does ^A set the value of ^A as it should.
Having interrupt capacity for at least
  ^B, ^G, ^V, ^W, ^X and ^Z
would be fairly important for TOPS-20 maclisps.

Now there seems also to be a bug in (SSTATUS LINMO T) on the TOPS-20
systems - it affects TLPRIN, but seems not to effect the ruubout scanner.
It woudl be possible to use the standard TOPS-20 JSYS for input, thereby
taking adavantage of all the twenex terminal niceities, if the LINEMODE
worked ok; but when not in linemode, lisp must inspect each character in
order to decide if enough has been buffered up.

Date: 26 DEC 1978 1014-EST
From: JONL at MIT-MC (Jon L White)
Subject: LIMIT-CONS for arrays and hunks
To: REM at MIT-MC
CC: (BUG LISP) at MIT-MC, jmc at SU-AI, rww at SU-AI, wilber at SRI-KL
CC: gsb at MIT-ML

The informations provided by
 1) (ALLOC 'T)
 2) (GETSP (1+ (GETSP 0)))
 3) input to GC-DAEMON
are sufficient to write the consers you want, namely "take-new-cell if
enough space already, otherwise return ()".  One problem is that the
array space will dynamically increase and decrease (but if NORET is 
non-null, it will not decrease).
  The current action by maclisp, upon running out of any allocatable
space, was deemed satisfactory for most usages; this action is described
in the various places that the function ALLOC and the feature GC-DAEMON
is discussed.  Henry Baker's package on  AI:LIBDOC;GCDEMN BAKER1 provides
one interesting usage of these features in a way to override the system
defaults. I really don't see how programming the storage management in
machine language is less work than accepting the limitations of a LISP
system and working around that (providing of course that the limitations
are not prohibitory).

Date: 24 DEC 1978 1556-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Allocating arrays and hunks
To: rem at MIT-MC
CC: jmc at SU-AI, rww at SU-AI, wilber at SRI-KL, gsb at MIT-ML
CC: (BUG lisp) at MIT-MC

Well, if you try to allocate something and it won't fit, you
most certainly do get some kind of error -- in the case of a hunk
it is a GC-OVERFLOW error, and in the case of an array I think
you get a FAIL-ACT of soome sort.  While it is admittedly not
convenient (because various errors are grouped into these
categories), this ought to be enough of a hook to let you
write ALLOCATE-RETURNING-NIL-ON-FAILURE.


Date: 23 DEC 1978 2247-EST
From: REM at MIT-MC (Robert Elton Maas)
To: (BUG LISP) at MIT-MC
CC: WILCOX%SUMEX at MIT-MC, JMC at SU-AI, RWW at SU-AI
CC: WILBER at SRI-KL, GSB at MIT-ML

I understand that MacLisp has no way for the user-level program to
request "try to allocate such and such an array or hunk, if you can
do it without increasing that space beyond its MAX parameter then
go ahead and return a pointer, otherwise don't allocate anything
just return NIL to indicate it lost (or throw an ERROR to be
caught by ERRSET)".  That pretty welll makes it impossible for
the user-level program to adapt itself to a given memory size,
unless it is willing to do all allocation itself.  I can do everything
myself by using assembly language.  Is anyone willing to install
such a capability, or shall I give up on MacLisp for really serious
totally-dynamic-allocation processing such as my data-compression work?
I have already given up on Mainsail (Temporarily, they seem likely
to install the feature soon, maybe maybe), SAIL, Forth, Pascal, etc.
for same reason.

Date: 23 DEC 1978 1410-EST
From: JONL at MIT-MC (Jon L White)
Subject: XTRSYMS
To: (BUG LISP) at MIT-MC

The SAIL hackers need some more XTRSYMS added in DEFNS:
  READ6C TYIMAN CHNTB
probably the first two should just be added, and the third put 
under a sail conditional.

Date: 19 DEC 1978 1338-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: BAK at MIT-MC, (BUG LISP) at MIT-MC


    Date: 18 DEC 1978 2056-EST
    From: BAK at MIT-MC (William A. Kornfeld)

    In general, when you evaluate (memq <atom> <atom>) you get nil.  However
    evaluating (memq 4 2) seems to cause an infinite loop!
-----
Right!!  This is the canonical "Use NIL check, not atom check for end of lists".
What happens is that normally it ends up doing CDR's to randomness and
since 0 is so common eventually gets NIL.  BUT, probably AC 2 contains a value
that MEMQ sets up, and so it CDR's back to 2, which might point to itself, etc...

Basically, don't pass it atoms!

--howard

Date: 19 DEC 1978 1330-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: FRAWLE at MIT-MC
CC: (BUG LISP) at MIT-MC

THere is apparently some wierd bug in GRIND whereby you need
to specify the device.  So say (GRIND (dsk bud) t t) and
it will work.

JOHAN@MIT-AI 12/19/78 11:37:27
To: (BUG LISP) at MIT-AI
ARRAYCALL with too few args, gets too many args msg.


Date: 18 DEC 1978 2056-EST
From: BAK at MIT-MC (William A. Kornfeld)
To: (BUG LISP) at MIT-MC

In general, when you evaluate (memq <atom> <atom>) you get nil.  However
evaluating (memq 4 2) seems to cause an infinite loop!

Date: 17 DEC 1978 2153-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

P% doesn't work right when TYO is an SFA.  It looks like it's pulling the
channel to write to out of the SFA-array and gets an IOC error.  Why doesn't
it just call PRIN1?  It would be much more useful to me that way.

Date: 17 DEC 1978 1933-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(STATUS TTYSIZE) does not work on SFA's.

Date: 17 DEC 1978 1646-EST
From: rwk at MIT-MC (Robert W. Kerns)
Sent-by: NEAL at MIT-MC
To: (BUG LISP) at MIT-MC

The TTYCONS operation on SFA's is not documented.

Date: 17 DEC 1978 0454-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

TYIPEEK with args is not documented, and doesn't seem to work right.
In particular, the argument always seems to be this frob of type RANDOM.

Date: 17 DEC 1978 0436-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

Another operation which transmits gibberish as data is LINEL
(LINEL CONSOLE-OUTPUT)
 => argument was #SFA-|CONSOLE-OUTOUT|-70706

It should be nil.

Also, LINEL is not documented in .INFO.;LISP SFA

GSB@MIT-ML 12/17/78 03:06:54 Re: (Status Terpri)
To: RWK at MIT-MC, (BUG LISP) at MIT-MC
CC: GSB at MIT-ML
Should be something which can be set on a per-file basis.  It's meaning
is that lisp will not auto-terpri on hitting the end of the line.  As far
as i can tell, there is no reason for it to be restricted to tty files.
It is a loss to set the linel to 0, because that will severely confuse
pretty-printers;  binding TERPRI isn't all that hot, especially when
debugging, because then one doesn't get the hairy prin1 auto-terpri
stuff.
How about AUTOTERPRI (lsubr, 1 or 2 args) and flush (status terpri)?
This could be trivially extended to sfa's, too.
Sprinter probably should be binding TERPRI anyway, i suppose that
it means it for everything, not just the tty.


Date: 17 DEC 1978 0254-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC

(SETQ TYO CONSOLE-OUTPUT)
(STATUS TERPRI)
; #SFA-|CONSOLE-OUTPUT|-@#$%@^$ NOT TTY OUTPUT FILE

(SSTATUS TERPRI)
; #SFA-|CONSOLE-OUTPUT|-@#$%@^$ NOT TTY OUTPUT FILE

Bletch.  Moby bletch.  What does it need to do with a TTY output file
to perform this function?  Why isn't it something that an SFA can handle?
This makes SPRINTER useless in this environment.

RWK@MIT-ML 12/16/78 22:25:00 Re: Magic File Array
To: (BUG LISP) at MIT-ML
To clarify, the problem is not that it barfed at FOO, but that it did
it's own printing of FOO in the error message without going through
CONSOLE-OUTPUT.

It also seems to ignore the value of MSGFILES.  I put CONSOLE-OUTPUT
on MSGFILES and it didn't get that either.


Date: 16 DEC 1978 2212-EST
From: RWK at MIT-MC (Robert W. Kerns)
Subject: Magic File Array
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC

Alright, where do you hide it.
MSGFILES is '(T), TYO is CONSOLE-OUTPUT, I do
(TYO 5 FOO)
and it does
;<mumble> LOSING OUTPUT FILE

OK, so where is the output file that it writes the <mumble> to?
It's certainly not going through TYO, unless it's on a character-by-character
basis!

Date: 16 DEC 1978 2143-EST
From: CWH at MIT-MC (Carl W. Hoffman)
To: (BUG LISP) at MIT-MC

In the MacLisp manual, ATAN is advertised as a function of one
or two arguments, however it is in reality only a function of two.
(Actually, the manual is correct -- it is DOCLISP which is incorrect)

Date: 16 DEC 1978 2032-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

Also, CHARPOS is not documented in .INFO.;LISP SFA

Date: 16 DEC 1978 2023-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

CLEAR-INPUT and CLEAR-OUTPUT don't seem to allow SFA's.  This is definately
a loss.

Date: 16 DEC 1978 2017-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(CNAMEF <sfa> 'FOOBAR) asks <sfa> for it's name and then barfs about
the namelist not being a file array.  It should just send the CNAMEF
to the SFA, there's no default handling that can be done.

Date: 16 DEC 1978 1944-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RWK at MIT-MC, (BUG LISP) at MIT-MC


    From: RWK at MIT-MC (Robert W. Kerns)

    The RENAMEF operation on SFA's doesn't seem to work properly.  I've noticed
    several things which are not as I'd expect:

    1)  It's not documented.
-----
Hm...ok
-----
    2)  (RENAMEF FOO-SFA 'MUMBLE) does a NAME operation, expecting this to
        return a namestring.
-----
This is what it should do if the SFA can't handle RENAMEF.  That this isn't
documented is my oversight.
-----
    4)  The NAME operation is invoked without checking the WHICH-OPERATIONS mask.
-----
That's right!  Not every operation has a bit in the WHICH-OPERATIOSN mask.
If you invoke RENAMEF on an SFA that can't handle it, then it better be able
to handle name.  The SFA is responsible for error-checking it's operation.
-----
    6)  It seems that it insists on trying to do a NAME operation even if there
        is a RENAMEF operation (and the RENAMEF bit is on in the mask)
-----
This is the blatent bug, and I'll see what I can do to fix it.

Date: 16 DEC 1978 1940-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

The RENAMEF operation on SFA's doesn't seem to work properly.  I've noticed
several things which are not as I'd expect:

1)  It's not documented.
2)  (RENAMEF FOO-SFA 'MUMBLE) does a NAME operation, expecting this to
    return a namestring.
3)  The NAME operation is not documented.
4)  The NAME operation is invoked without checking the WHICH-OPERATIONS mask.
5)  There's no bit in the WHICH-OPERATIONS mask for the NAME operation.
6)  It seems that it insists on trying to do a NAME operation even if there
    is a RENAMEF operation (and the RENAMEF bit is on in the mask)
7)  It seems that no matter what, I can't get it to ever call the SFA with the
    RENAMEF operation.  It insists on trying to do a RENAME, the intent is to
    pass a RENMWO onto the file the SFA is outputing to.


Date: 16 DEC 1978 1857-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(DEFUN FOO-SFA (SELF OP DATA)
  (CASEQ OP (WHICH-OPERATIONS '(CHARPOS TYO))
	 (T (FORMAT T '|~&Operation = ~S, Data = ~S~&| OP DATA)
	    0)))		   ;need to return a fixnum

(CHARPOS FOO)
Operation = CHARPOS, DATA = #SFA-|FOO|-234153

Barf.  It should probably pass in NIL as the third argument if there's no
second argument to the CHARPOS.

Also, if you don't return a fixnum, it complains about "Wrong type argument".
This is clearly the wrong error message from the user's point of view.
Probably something like "Illegal return value" would make more sense.

Date: 16 DEC 1978 1646-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(format t '|~:[false~;true~]| T)false
T

According to the LISP machine documentation it should say "true"

Date: 14 Dec 1978 2246-PST
From: Beverly Kedzierski <BIK at SU-AI>
Subject: No init file  
To:   bug-lisp at MIT-MC    

	We in "TOPS-10"-land need to be able to say "no ini (init)
file please". 
			-rpg-



Date: 14 DEC 1978 2054-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

The initial readtable should have "," defined as a macro, with function
+INTERNAL-COMMA-FUN
which in turn should have an autoload property the same as the function
+INTERNAL-BACKQUOTE-MACRO
The failure to have comma defined as a macro in the initial LISP environment
causes the complr (which has several readtables) much pain, and would
amount to an inconsisten screw for anyone who tried to use non-standard
commas without "turning off" the macro anyway.

PRATT@MIT-AI 12/14/78 18:35:43
To: (BUG LISP) at MIT-AI
Ok, replace my last message by
:L<space><crlf> needs to be documented in LISP NEWS.


PRATT@MIT-AI 12/14/78 18:08:52
To: (BUG LISP) at MIT-AI
It would be nice to be able to say in the JCL for LISP not to use
any init file - i.e. over-ride the default of reading FOO LISP etc.


Date: 14 DEC 1978 1410-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

I SUPPOSE LSP IS OK...RANDOM, BUT OK...PERHAPS MACLISP
IS MORE CORECT THAN LISP, BUT IF WE CAN'T GET IT TOGETHER ENOUGH
TO EAISILY PRODUCE TAPES WITH FILES WITH DIFFERENT 2ND FN'S, THEN WE
ARE LOSING BADLY

Date: 14 DEC 1978 1228-EST
From: JONL at MIT-MC (Jon L White)
Subject: "default second file name"
To: (BUG LISP) at MIT-MC

    There appears to be  no reason to make the default second file 
name different on TOPS-20 than on TOPS-10.  This is a separate issue
from what the variable DEFAULTF is initialized to.  Please read the 
considerations in the file LISP;DEFAUL NOTE and reply fairly soon if 
you have any comments.

Date: 14 DEC 1978 0931-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC

The default second file name for TOPS-20
should be LISP, not LSP.

Date: 13 DEC 1978 2147-EST
From: JONL at MIT-MC (Jon L White)
Subject: Use of COMMON
To: (BUG LISP) at MIT-MC

there is a list which the +INTERNAL-AUTOLOAD function uses in a 
call to MERGEF - "(DSK COMMON)".   This should probably be  "(DSK LISP)"
for ITS systems, and "(DSK MACLISP)" for TOPS-20 systems.
Also, the default second file name for TOPS-20 systems should be "LSP"
instead of "MACLISP".

Date: 13 DEC 1978 1320-EST
From: JONL at MIT-MC (Jon L White)
Subject: DIFFERENCE vs MINUS
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC

Yes, I saw your mail of some time ago that said "dont change DIFFERENCE"
but failed to read from it the suuggestion about MINUUS.  I dont see any
reason why not to change MINUS, but there are two minor problems:
1) its likely to be some time before another MACLISP debugging/update 
   assembly is done
2) could we get the change extended to the other maclisp-like lisps?
   namely, MULTICS maclisp and LISPM lisp.

PRATT@MIT-AI 12/12/78 17:51:35
To: (BUG LISP) at MIT-AI
I forget - did I mail a suggestion re DIFFERENCE and MINUS?  (I don't
recall getting a reply.)  The suggestion was to have MINUS be the
generic analogue of - and -$ , on the ground that too many MACLISP
users wanted DIFFERENCE preserved, and that MINUS was presently
simply undefined at the argument counts where extension to MINUS
was called for, so that the change would be upward compatible.
(Also it had the neat feature of making MINUS the "mate" of PLUS,
which seems reasonable both on familiarity grounds - PLUS-MINUS
sounds better than PLUS-DIFFERENCE - and on length grounds -
MINUS is 4 characters shorter than DIFFERENCE.)


Date: 11 DEC 1978 1123-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 renamef
To: (BUG LISP) at MIT-MC

1) RENAMEF apparently fails to do the corresponding CNAMEF as is
   done on the ITS version
2) RENAMEF fails to accept namelist, but barfs about illegal 
   source/destination designator
3) If one does a RENAMEF while the file is open, then subsequent calls
   to TRUENAME on the open file-object re4sult is illegal op code execution.

Date: 10 DEC 1978 0328-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 9 DEC 1978 1327-EST
    From: JONL at MIT-MC (Jon L White)

    Why doesn't the LISP system do the DELETEF necessary before
    doing a RENAMEF on the DEC10 implementations?  I.e., if
    a file FOO.BAR already exists, then it is necessary to delete it
    before (RENAMEF '(FOO.NEW) '(FOO.BAR))  will win.
-----
On Tops-10 people do not expect to be able to superceed a file by renaming it.
Therefore, to have LISP do the DELETEF stands a chance of causing lossage.  Not
having it do the rename can never cause loss of information.
I don't think it should be changed.

Date: 10 DEC 1978 0258-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Is there a way in lisp that I can distinguish between file not found
and file locked. Particularly in the case of an archive being locked,
it hardly seems fair for (PROBEF '((AR1 FOO) BAR >)) to return NIL just
because the silly archive is off running on its own... I understand
why it does this, but can someone suggest a simple way that I can
tell the difference between file not found and file found but locked?

Date: 9 Dec 1978 2241-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: Awright you losers!
To:   bug-lisp at MIT-MC    

;Edit  
_ (CR (DEFUN FOO (A) (WHILE T DO (SETQ A (CONS A A))))))))

_ O
FOO 
_ (FOO NIL)

;GC DUE TO LIST SPACE
; 70.[0%] LIST, 708.[69%] FIXNUM, 511.[99%] FLONUM, 
; 507.[99%] BIGNUM, 744.[36%] SYMBOL, 470.[91%] ARRAY WORDS FREE
;ADDING 5 NEW LIST SEGMENTS
; BUT DIDN'T SUCCEED -- LIST SPACE NOW 10752 WORDS

...INCREASING LIST GCMAX TO 11384. WORDS...

;GC DUE TO LIST SPACE
; 37.[0%] LIST, 708.[69%] FIXNUM, 511.[99%] FLONUM, 
; 507.[99%] BIGNUM, 744.[36%] SYMBOL, 470.[91%] ARRAY WORDS FREE
;ADDING 6 NEW LIST SEGMENTS
; BUT DIDN'T SUCCEED -- LIST SPACE NOW 11776 WORDS

...INCREASING LIST GCMAX TO 12400. WORDS...

;GC DUE TO LIST SPACE
;PDL OVERFLOW WHILE IN GC!
;MAJOR RESTART UNDERTAKEN

;GC DUE TO STARTUP
; 5628.[47%] LIST, 708.[69%] FIXNUM, 511.[99%] FLONUM, 
; 507.[99%] BIGNUM, 744.[36%] SYMBOL, 470.[91%] ARRAY WORDS FREE

_ ^C
^C

.R PPSAV
			-rpg-



Date: 9 Dec 1978 1446-PST
From: Dick Gabriel <RPG at SU-AI>
To:   bug-lisp at MIT-MC    

 09-Dec-78  1026	JONL at MIT-MC (Jon L White)  
Date: 9 DEC 1978 1327-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Why doesn't the LISP system do the DELETEF necessary before
doing a RENAMEF on the DEC10 implementations?  I.e., if
a file FOO.BAR already exists, then it is necessary to delete it
before (RENAMEF '(FOO.NEW) '(FOO.BAR))  will win.

It is problematic whether semantically a RENAMEF should 
imply a DELETEF, or whether it should simply reflect UUO semantics,
whatever they are on your favorite DEC10-like machine.
			-rpg-



Date: 9 DEC 1978 1327-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Why doesn't the LISP system do the DELETEF necessary before
doing a RENAMEF on the DEC10 implementations?  I.e., if
a file FOO.BAR already exists, then it is necessary to delete it
before (RENAMEF '(FOO.NEW) '(FOO.BAR))  will win.

Date: 6 DEC 1978 1527-EST
From: JONL at MIT-MC (Jon L White)
Subject: NAMELIST components on DEC10
To: (BUG LISP) at MIT-MC

It would help a lot if  ((* *) ...)  would mean the same to
namelist processors as  ((* (* *)) ...)

Date: 5 DEC 1978 1701-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 5 DEC 1978 0954-EST
    From: JONL at MIT-MC (Jon L White)

    Quite regularly, I can make LISP bomb out to ddt with
    ILOPR; INTPDL+10>> . . .
    It seems to be a timing bug of some sort, since it occurs aafter typing
    ^B at a running expr complr, but not all the time.
-----
I REALLY NEED MORE INFO TO EVEN START LOOKING FOR THE BUG.

ANYTHING MOREO OYU CAN TELL ME??

--HOWARD

Date: 5 DEC 1978 1128-EST
From: JONL at MIT-MC (Jon L White)
Subject: (TYIPEEK <frob> <file> -3)
To: (BUG LISP) at MIT-MC

will return -1 regardless of the setting of -3.
Probably no one is shafted by this, but it is inconsistent with
the documentation.

Date: 5 DEC 1978 0954-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Quite regularly, I can make LISP bomb out to ddt with
ILOPR; INTPDL+10>> . . .
It seems to be a timing bug of some sort, since it occurs aafter typing
^B at a running expr complr, but not all the time.

PRATT@MIT-AI 12/02/78 12:11:48 Re: Making (DIFFERENCE 3) be -3
To: (BUG LISP) at MIT-AI
Although those who want this seem to outnumber those who don't, I'm inclined
to side with the latter.  KMP speculated that there probably existed
programs and macros that depended on DIFFERENCE having its present
behavior.  While this is unclear, I think the general principle of not
messing around with the language this way is sound.

It would however be nice to have a generic operator that corresponded to
the fixnum and flonum operators in their behavior at one argument.
One possibility is to take MINUS to be that function.  This would be
an upward compatible change since on one argument MINUS would behave as
before.  Furthermore, MINUS seems a much better name for the opposite
of PLUS than DIFFERENCE, both in terms of length and the fact that one
always thinks of PLUS and MINUS.

If MINUS is not the way to go, some unused name should be brought into
play, perhaps DIFF or somesuch.  But I like the MINUS solution much better.


PRATT@MIT-AI 12/02/78 12:02:21 Re: GCDEMN
To: (BUG LISP) at MIT-AI
The feedback on GCDEMN overall seems to be "OK, provided I can turn it
off easily."


Date: 2 DEC 1978 0037-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC, (FILE [HIC;LISP THINGS]) at MIT-MC


I guess I'm pretty well convinced, so that on my next LISP hacking 
session I'll fix NCONC, APPEND, etc to listen to *RSET and do the "right"
thing if the list isn't a real "list".  I don't guarantee when this'll
happen, but.....

Date: 1 DEC 1978 2245-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

(SETPLIST 'FOO '(SOME THING))
(NCONC '(A . FOO) '(B . FOO) '(C . FOO))
will never return. Apparently (even with *RSET set!!) it traces down the
CDR of the atom. Creating an invisible circularity. The CDR of FOO becomes
first (SOME THING) then (SOME THING B . FOO) then it seems to CDR forever
looking for the end of the list! This shouldn't happen. It is gross to debug
and I would be willing to spend the time every NCONC to have it make this
check. I would like this to be an error.

Date: 30 NOV 1978 2316-EST
From: JONL at MIT-MC (Jon L White)
Subject: Generation numbers on TWENEX
To: (BUG LISP) at MIT-MC

1) ">" should be acceptable as a generation number, meaning roughly
   the same thing as when used a a second file name for ITS
2) default generation number for UWRITE and OPEN (with open option OUT)
   seems random - possibly defaulting the same as device or directory
   to the last one mentioned specifically in a UREAD or input OPEN
3) UFILE returns a list which consists of the temporary name instead of
   the final renamed name
4) (UREAD FOO BAR /8) should recognize the /8 as a generation number
   rather than a device name

Date: 30 NOV 1978 0043-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RPG at MIT-MC
CC: (BUG LISP) at MIT-MC

I believe that I have made all the changes in the source that you
have requested me to make.  This includes incorproating
SAILQIO, SAILDEFNS, as well as the latest version of NEWGC.

Your changes looked mostly reasonable, and were put in verbatim 
except for some minor tweaks here and there (mostly cosmetic!).
Perhaps it is time to try to build a new SAIL NEWIO from the
sources.

--howard

PRATT@MIT-AI 11/29/78 12:08:21
To: (BUG LISP) at MIT-AI
While I appreciate the (LET (((A . B) C) ...) ...) form, it is a pity that
the parameter binding mechanisms available in LISP are growing like Topsy.
Wouldn't it be better to make "structured binding" part of the whole binding
philosophy rather than of one of the many binding constructs?
While we're on the subject, it seems to me that something like what Carl
uses in Plasma gives a more usable method of "structured binding."  Carl
combines structured binding with pattern matching, a combination that is hard
to beat.  Perhaps you might consider CASES to be a pattern-matching + binding
variant of COND, permitting code like:

(defun append (a b)
  (cases a
	 (NIL  b)
	 ((x . y) (cons x (append y b)))))



Date: 29 NOV 1978 0023-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG COMPLR) at MIT-MC
CC: PRATT at MIT-MC, (BUG LISP) at MIT-MC

Pratts note of 11/25/78 about AI:PRATT;JUNK LAP  should have been directed
as a complr bug.  I has been patched.

Date: 28 NOV 1978 1306-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

I see no need to change from whatever the current TOPS-10 filename is
to LIS (isn't it LSP?).  The change is simply gratuitous.  It may have
some advantages for programs that runon all systems and snoop around,
but then we have the problem of SAIL and ITS being different anyway.

Date: 28 NOV 1978 0252-EST
From: JONL at MIT-MC (Jon L White)
Subject: On-line MACLISP manual
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC, ELLEN at MIT-MC

For some weeks now, ELLEN has been intending to fetch the current
version of the MACLISP manual off backup tape, and put it back on the
LSPMAN directory.  It apparently was backed up sometime after the
publishing of the new manual (parts 1,2,and3) last summer.  The
thing on LSPMAN that appears to be a manual is a false lead, dating
to sometime in 1973;  the thing from the backup tape is the ting
from which the current published version is printed.

Date: 27 Nov 1978 2037-PST
From: Dick Gabriel <RPG at SU-AI>
To:   bug-lisp at MIT-MC    

 27-Nov-78  1917	JONL at MIT-MC (Jon L White)  
Date: 27 NOV 1978 2216-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

How about the following for conventional names of "second" filenames
on various systems:
ITS 	- 	>
SAIL	-	||
TOPS-10 - 	LIS
TOPS-20 - 	LISP
This has the property that a descriptive second name may be used, and for
the system without enough characters in the second name the descriptive
name is merely truncated.  If this approach were followed in general, we
would ahve to be careful that the distinctiveness were evident from the
firs few characters of the "second" filename, so that losing systems could
be accomodated.

I agree, with the modulo above.
			-rpg@SAIL-



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

How about the following for conventional names of "second" filenames
on various systems:
ITS 	- 	>
TOPS-10 - 	LIS
TOPS-20 - 	LISP
This has the property that a descriptive second name may be used, and for
the system without enough characters in the second name the descriptive
name is merely truncated.  If this approach were followed in general, we
would ahve to be careful that the distinctiveness were evident from the
firs few characters of the "second" filename, so that losing systems could
be accomodated.

PRATT@MIT-AI 11/25/78 22:40:48
To: (BUG LISP) at MIT-AI
AI:PRATT;JUNK LAP does not seem an adequate translation of JUNK >.
When (NEWNUM) is called for the first time, 1 is returned when one
would expect 0.


Date: 25 NOV 1978 1532-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

TYIPEEK seems to ignore its third arg. Doing

(OPEN <file> '(IN ASCII))
(FILEPOS <file-obj> T)
(TYIPEEK NIL <file-obj> -2.)

returns -1 for the last form - same as if I just typed
(TYIPEEK NIL <file-obj>)

Shudn't this be consistent with TYI? -1 seems like an ok default if
no 3rd arg is given, but I think making the 3rd arg be the return value
at an EOF is only fair.

PRATT@MIT-AI 11/25/78 10:53:04
To: (BUG LISP) at MIT-AI
How about having the LISP manual more readily online, say in one of the
info directories?


Date: 24 NOV 1978 2333-EST
From: JONL at MIT-MC (Jon L White)
Subject: TWENEX version
To: (BUG LISP) at MIT-MC

(UFILE FOO BAR) returns ((dev usr) MACLISP OUTPUT ||)
shouldn't it return ((dev usr) FOO BAR /n)  ?

Date: 21 Nov 1978 (Tuesday) 1706-EST
From: DEWOLF at WPAFB-AFAL
Subject: ilgl go or return - not inside prog
To:   bug-lisp at MIT-AI

The following seems strange to me.  The interpreter evals
the return-value portion of a DO in a control environment 
which is neither inside the DO nor in the enclosing PROG.
Never-never land?

	.r com:lisp
	LISP 1137
	ALLOC? n
	* 
	(defun foo () (prog ()(do ()(t (return t)))))
	FOO 
	(foo)
	(GO RETURN) ILGL GO OR RETURN - NOT INSIDE A PROG
	;BKPT FAIL-ACT
	^Z

I would not be surprised if the compiler got confused, but
I am surprised at the interpreters confusion.

Tim Finin, FININ@MIT-AI





Date: 24 NOV 1978 2044-EST
From: RWK, KMP at MIT-MC
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC

(STATUS FILEMODE) seems never to invoke the SFA to ask it to describe
itself.  It always returns the ((SFA) {results of a WHICH-OPERATIONS call})
list, in the test we tried.

Date: 24 NOV 1978 2038-EST
From: RWK,KMP at MIT-MC
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC

For the sake of compatibility with existing programs, and consistancy,
+TYO should *NOT* barf "not ascii output file" when you give it an SFA, but
should simply do an implicit (SFA-CALL <file> '+TYO <arg>).

Date: 24 NOV 1978 1936-EST
From: KMP,RWK at MIT-MC
Sent-by: KMP at MIT-MC
To: (BUG LISP) at MIT-MC

We have updated .INFO.;LISP SFA to include doc on the use of CURSORPOS by
SFA's. Lisp seems to handle this, but there was no documentation on it.

Date: 24 NOV 1978 1906-EST
From: JONL at MIT-MC (Jon L White)
Subject: FORMAT
To: (BUG LISP) at MIT-MC

1) (format () <ctl> ...) fails to return the answer as a cons'ed up
   string (symbol in maclisp)
2) floating point "~f" doesn't work
3) many placees call (PRING ARG STANDARD-OUTPUT) rather than uusing
   INVOKE-STREAM
I've attempted to fix these.

Date: 24 NOV 1978 1851-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC


    MSG: DIFF   1     
    PRATT@MIT-AI 11/24/78 16:10:25 Re: What difference does one argument make?
    ...  However, for the case of one argument (- 3) yields -3
    and (-$ 3.0) yields -3.0 as one might expect, whereas (DIFFERENCE 3)
    yields 3.  Does anyone own a program that would not work if DIFFERENCE were
    brought into line?  Does anyone care either way?

(MINUS 3.0) returns -3.0 - the problem is that the two generic operators
map into the single fixnum operator. I would rather see there created fixnum
and flonum analogs of both MINUS and DIFFERENCE rather than have DIFFERENCE
altered. A distinction should be made between the use of the unary minus
and the use of an N-ary minus which just happens to have only one term.
Both can be useful at times. Since there are probably existing programs 
(especially macros) which generate code relying on DIFFERENCE to work a certain
way it seems like these would get messed up by your proposed change. I would
not want to have to search all of my files changing such a thing.

--kmp

Date: 24 NOV 1978 1833-EST
From: JONL at MIT-MC (Jon L White)
Subject: Point for Clarification
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC

The mere giving of information about the existence of FFORMA
should not be construed as "maintaining an all or nothing approach".

Date: 24 NOV 1978 1828-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC, ES at MIT-MC

Apparently JONL wishes to maintain this all or nothing approach. 
Either use a floating point formatting package or be stuck with what 
LISP gives.  It seems to me that as long as this parameter is an 
assembly parameter, it could conceivably be made a switch.  But, 
I personally don't care.  ES can press the point if he likes.

Date: 24 NOV 1978 1821-EST
From: JONL at MIT-MC (Jon L White)
Subject: XXXXXX.FF versus X.XXXXXFFE<exp>
To: ES at MIT-MC
CC: JPG at MIT-MC, (BUG LISP) at MIT-MC

I think it is a parameter in the assembly of LISP as to how
many digits it tolerates to the left of the decimal point, currently
set to 8.  Probably the reason for that is that all 8-digit (decimal)
integers are representable exactly as a floating-point number.
There is a package to to fortran-style formating - see LIBDOC:FFORMA >

Date: 24 NOV 1978 1813-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: ES at MIT-MC

Forwarded to BUG-LISP for ES:
ES@MIT-MC 11/23/78 22:37:23
Floating point numbers would be easier to read if the output routine
switched into "E format" whenever there would otherwise be more than
6 digits to the left of the decimal point.

BAKER@MIT-AI 11/24/78 17:00:19 Re: difference vs. -
To: PRATT$CBAKER at MIT-AI
CC: (BUG LISP) at MIT-AI
Yes, please bring these into consistency w/ one another.

BAKER@MIT-AI 11/24/78 16:59:15 Re: DIFFEREN
To: PRATT at MIT-AI
CC: BAKER at MIT-AI, (BUG LISP) at MIT-AI


Date: 24 NOV 1978 1550-EST
From: JONL at MIT-MC (Jon L White)
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC

(- 3) ==> -3  was a feature that wasn't retrofitted to DIFFERENCE.
So who will offer their neck in sacrifice to bring DIFFERENCE and
QUOTIENT into line?  While we're at it, we might as well mention the
lack of consistent ordering of the floating point operations in
(+ A B C) and (- A B C):  compiled code performs the operations
left-to-right, whereas the interpreter does it right-to-left.  All 
would be fine except for the non-associativity of floating-point.
Has anyone actually been bugged by this difference? (and who else
has been bugged by this DIFFERENCE?)

PRATT@MIT-AI 11/24/78 15:42:24
To: (BUG LISP) at MIT-AI
(I mean a bug in the definition of LISP, not in the implementation.)


PRATT@MIT-AI 11/24/78 15:40:44
To: (BUG LISP) at MIT-AI
(Further to JONL's remark that (//$ 3.0) yields 0.33333333 when (quotient 3)
yields 3.)  (- 3) yields -3 and (-$ 3.0) yields -3.0, even though
(difference 3) yields 3.  That's no feature, that's an out-and-out bug,
which I can see driving people nuts.


Date: 24 NOV 1978 1524-EST
From: JONL at MIT-MC (Jon L White)
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC

Not too long ago we had a series of discussions with some loser
about the reason why
  (//$ 3.0)  ==>  .333333332
instead of 3.0 [note that (QUOTIENT 3.0) ==> 3.0]
So there are two conventions at work here - one is to return the one
argument, and the other is to operate upon it as second arg with the
operation identity as first arg.  The latter convention thus allows
(- 3) ==> -3,  (//$ 3.0) ==>  .333333332 etc.
Now if you (Pratt) are willing to put your neck on the line for making
non-upward-compatible changes to DIFFERENCE and QUOTIENT . . .
well, I wouldn't stand in the way.  But I don't want my neck on 
the line again, especially in view of the fact that not too long ago
someone wrote a flaming message on the system about system programmers
pulling the rug out from underneath old programs;  I think his first
name started with the initial letter "V".

PRATT@MIT-AI 11/24/78 15:12:16
To: (BUG LISP) at MIT-AI
How about making (DIFFERENCE A) have the effect of (MINUS A)?  This would be
more in line with ordinary usage, where one writes the same symbol for a-b
and for -a.


Date: 24 NOV 1978 1244-EST
From: JONL at MIT-MC (Jon L White)
Subject: why GCDEMN is not part of initial LISP
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC

Well, how many people want it there?  I'm unaware of a 
widespread such desire, but if so, maybe we could at least
start it out as an initial AUTOLOAD on some function that starts 
it up.

Date: 24 NOV 1978 1220-EST
From: JONL at MIT-MC (Jon L White)
Subject: Bit-position of rightmost 1
To: PRATT at MIT-MC
CC: (BUG LISP) at MIT-MC

For a 2's complement machine, the following expression will
give the index, 0-origin, of the rightmost 1, which is the same
as the exponent for the highest power of 2 that evenly divides
the number:
   (1- (HAULONG (BOOLE 1 N -N)))      for 0 < N < bignum
Where the base of the arithmetic is suspect, one may build-in the
feature of 2's complement that makes this work:
  (1- (HAULONG (BOOLE 1 N (BOOLE 6 (1- N) 77777777777)
                                      for 0 < N < 77777777777

PRATT@MIT-AI 11/24/78 10:58:06
To: (BUG LISP) at MIT-AI
What's a time-efficient way in LISP to compute the position of the
rightmost 1 bit of a fixnum?


rich,johan@MIT-AI (Sent by JOHAN@MIT-AI) 11/24/78 09:49:05 Re: READ
To: (BUG LISP) at MIT-AI
In the current lisp (READ 'FOO) and (READ 'FOO 'FOO) both read
from the TTY instead of giving a losing filespec error.  Isn't
this a bug?


Date: 23 NOV 1978 1537-EST
From: PRATT at MIT-MC (Vaughan Pratt)
To: (BUG LISP) at MIT-MC

How come GCDEMN isn't a standard feature of LISP?

Date: 23 NOV 1978 0903-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

I'm about to add a macro DESETQ to the LET file - it produces
essentially the same sort of "disassembly" of a frob into a 
group of variables (specified through a data "pattern") as does
LET, but it is a "set"ting, rather than a lambda-binding.  For
NIL operation, it will permit a vector in place of a list.  E.g.
(DESETQ ((A B) #(C D E) . F)  (MUMBLE))
would be acceptable.   Any comments?

Date: 22 NOV 1978 2038-EST
From: JONL at MIT-MC (Jon L White)
Subject: TOPS-20 alloc prompt
To: (BUG LISP) at MIT-MC

Doug Blewett suggests using RDTTY instead of PBIN in alloc to
gobble down the "Y" or "N", and that should fix the superfluous
<cr> problem.

Date: 22 NOV 1978 1622-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC


    Date: 22 NOV 1978 0711-EST
    From: JONL at MIT-MC (Jon L White)

    TOPS-20 version cant accept a "y" (or a "Y") at alloc without
    requireing a following <cr> or <space>, which then fouls up
    the next allocation line.
----
Yes, that's right, so just type the allocation like
Y1234<sp> and you'll win

Date: 22 Nov 1978 1436-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: MACLISP on CMUA
To:   HIC @ mit-mc
CC:   bug-lisp @ mit-mc
Message-ID: <22Nov78 143625 SF50@CMU-10A>


Howard,
        A month after we asked for it to be installed (slow systems
people around here) MACLSP and COMPLR are on SYS: at CMUA, and they
have been announced to a hungry world.  Since we still lack sections 4-n
of the new manual (is it being worked on?) I am encouraging people with
small problems of short duration to use the old UCI lisp and telling
people starting major projects to go with MACLISP.
        Dave Touretzky and Dave McDonald have done some interesting things
to overcome the lossages of using the system here.  Look at MACLSP.DIR,
EXAMPL.INI, and SLURP.MCL on [c380ml5p] if you are interested.  The INIT
file fixes useful autoloads to point to the right things, and the slurp
package is an I/O front end that does useful decoding of local PPNs.
We have a bit of a problem with autoloads in the COMPLR, since it doesn't
get set up by an INIT file, but we kludge around it.  The UCI-lisp editor
has been converted, though it is far inferior to using LEDIT and EMACS.
It saves top-level comments, but only wins with ; comments within functions
if they occur where a random NIL is OK.  And the comments live in core,
at present at least.  We may try to write a package that merges code from
the core image and comments from the old file, but this will be hairy.
        NETL runs fine here, and McDonald has converted the SRI Diamond
parser to run in MACLISP (converted from interlisp).  Anyway, thanks again
for your help, and let us know when and if the CDR of the manual appears.
                                Regards,
                                Scott Fahlman

Date: 22 NOV 1978 0726-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

TOPS-20 version gives (STATUS UDIR) = (STATUS HOMEDIR), but if one is
"connected" to a directory other than the login name, then these two should
be different?

Date: 22 NOV 1978 0714-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

In TOPS-20 version, <control>-Q doesn't seem to do anyting.

Date: 22 NOV 1978 0711-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

TOPS-20 version cant accept a "y" (or a "Y") at alloc without
requireing a following <cr> or <space>, which then fouls up
the next allocation line.

Date: 22 NOV 1978 0449-EST
From: JONL at MIT-MC (Jon L White)
Subject: tops-20 filename lossages
To: (BUG LISP) at MIT-MC

Most of the autoload properties are lists with long symbols as names,
but we have depended upon these being truncated (in the file system)
to 6 characters.  BOTTOMS-20 does not truncate.

Date: 22 NOV 1978 0341-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(SSTATUS LINMO T)
has only part of the desired effect - it affects the toplevel
printer, but seems not to affect the rubout-processor.

Date: 20 NOV 1978 1535-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

(GETMIDASOP 'LERE)  ==> 0
should be ().

Date: 20 Nov 1978 0047-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: backq lossage
To:   bug-lisp @ mit-mc
CC:   Fahlman at CMU-10A, McDonald at CMU-10A, Touretzky at CMU-10A,
      vanRoggen at CMU-10A
Message-ID: <20Nov78 004726 SF50@CMU-10A>


Comments of the form (comment foo, bar, bletch) run afoul of the BACKQ macro
if they appear after a ` in a file being read in.  Comments of this form are
useful for the @ (AT) listing package, and commas occur naturally in this
context.  I'm not sure this should be fixed, but it should be advertised.

Scott Fahlman (FAHLMAN @ CMUA)

GSB@MIT-ML 11/19/78 08:06:42
To: (BUG LISP) at MIT-ML
(GETDDTSYM IOJRST) CAN'T GET DDT SYMBOL - FASLOAD
Can't this go in GETMIDASOP?  CALL and friends do...


Date: 17 NOV 1978 1400-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC
CC: KMP at MIT-MC

LISP doesn't seem to recognize EOF-in-READ errors while inside backquote.

Date: 15 NOV 1978 1118-EST
From: JONL at MIT-MC (Jon L White)
Subject: *READ
To: (BUG LISP) at MIT-MC, RPG at SU-AI


    Date: 14 Nov 1978 1031-PST
    From: Dick Gabriel <RPG at SU-AI>

     14-Nov-78  0455	JONL at MIT-MC (Jon L White) 	*READ
    Date: 14 NOV 1978 0325-EST
    From: JONL at MIT-MC (Jon L White)
    Subject: *READ
    To: (BUG LISP) at MIT-MC

    READ$:	movei t,0
    	jrst read

    Would anyone confess to having put in the 
    	SKIPE VOREAD
    	JCALLF 15,@VOREAD
    or to any other such brain-damages?

    Is this a change I should patch in?
    			-rpg-

You should "patch in" this if you like having brain damage.
*READ is supposed to be only a 0-arg entry into READ.  Only the
toplevel reader is supposed to check for the value of the symbol READ.


Date: 15 NOV 1978 1116-EST
From: JONL at MIT-MC (Jon L White)
Subject: *READ
To: (BUG LISP) at MIT-MC, RPG at SU-AI, jonl at SU-AI


    Date: 14 Nov 1978 1031-PST
    From: Dick Gabriel <RPG at SU-AI>

     14-Nov-78  0455	JONL at MIT-MC (Jon L White) 	*READ
    Date: 14 NOV 1978 0325-EST
    From: JONL at MIT-MC (Jon L White)
    Subject: *READ
    To: (BUG LISP) at MIT-MC

    READ$:	movei t,0
    	jrst read

    Would anyone confess to having put in the 
    	SKIPE VOREAD
    	JCALLF 15,@VOREAD
    or to any other such brain-damages?

    Is this a change I should patch in?
    			-rpg-



Date: 14 NOV 1978 0325-EST
From: JONL at MIT-MC (Jon L White)
Subject: *READ
To: (BUG LISP) at MIT-MC

READ$:	movei t,0
	jrst read

Would anyone confess to having put in the 
	SKIPE VOREAD
	JCALLF 15,@VOREAD
or to any other such brain-damages?

Date: 14 NOV 1978 0249-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

READ$:	MOVEI T,0

Date: 14 NOV 1978 0029-EST
From: JONL at MIT-MC (Jon L White)
To: CFFK at MIT-MC, JLS at MIT-AI
CC: (BUG LISP) at MIT-MC

I have changed the name of the fortran-style formatter file to
LIBLSP;FFORMA FASL     (source =   LIBDOC;FFORMA >)
but kept a link from LIBLSP;FORMAT FASL  (and from LIBDOC;FORMAT >).
These links will be kept around for some indefinite period, not
less than two weeks.  Notice also that  the files CHOMP FASL etc
have disappeared with the inclusion of the CHOMP function into the
regular COMPLR.

GSB@MIT-ML 11/13/78 23:37:11
To: (BUG LISP) at MIT-ML
purcopying an array appears to set the i-am-a-flonum-array-bit (100 octal)
in the asar of the array.  It neither references the bit nor the asar
symbolically.  It is i presume supposed to set the tts.cn bit in the
ttsar.


Date: 13 NOV 1978 2132-EST
From: JONL at MIT-MC (Jon L White)
Subject: SHOWIT uuo for COMPLR's current file
To: (BUG LISP) at MIT-MC
CC: RPG at MIT-MC

I'm not sure that there is any decent way for a lisp program
to get at the channel number assigned to a file-array?  is the
SHOWIT function in sail MACLISP and not in the others?

Date: 13 NOV 1978 1736-EST
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

EVAL-WHEN is not documented!

GSB@MIT-ML 11/13/78 06:02:45
To: SJOBRG at MIT-ML
CC: (BUG LISP) at MIT-ML, GSB at MIT-ML
Output of sail characters is controled by a bit in one of the words
which can be hacked with (status tty).
What you want to do is
((lambda (s) (sstatus tty (car s) (cadr s) (boole 7 (caddr s) 4_27.) t)
 (status tty t))
If you had done a :tctype sail before starting up the lisp, then this
would not be necessary.  (The rest of this message is primarily directed 
to bug-lisp.) 
There appears to be a problem in lisp which may make doing this cause
incorrect rubout processing and/or charpos setting:  lisp sets the SAIL
option (which is a tty capability bit, rather than an option) from
%TOSA1;  this is the wrong thing to do!  As a 'capability' it should come
from %TOSAI;  as an option (which lisp does not support), it should come
from the ttysts word, %TSSAI.  Initializing it only from %TOSA1 makes it
impossible to dynamically change whether or not one wants to use the
sail character set and have lisp behave correctly.  It looks to me as
if SAIL should appear if the CDR of a status-filemode list iff the tty
supports sail characters (from %TOSAI), and in the car (as an
open-option) from %TSSAI;  only the latter should be used by the rubout
function, tyo, etc.


Date: 12 NOV 1978 0228-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: NIL at MIT-MC, GLS at MIT-MC
CC: (BUG LISP) at MIT-MC

As I understood it, the purpose of having a constant was not just 
initialization, but almost macrofication. Thus 
(DECLARE (CONSTANT (A 5)))
would meant that 5's got inserted in the code every time an A was seen,
and that the compiler would output no code involving A's. Thus,
(DECLARE (CONSTANT (A 5)))
(DEFUN F (X) (+ X A))
would expand into (DEFUN F (X) (+ X 5)) is not a runtime controllable
entity in theory. One can't setq A and expect it to run differently, whereas
if it expanded to
(DECLARE (SPECIAL A))
(SETQ A 5)
...
(DEFUN F (X) (+ X A))
then this wouldn't be the same.

By the way, is it possible to make constants live in a different space
than ordinary variables so that SETQ's to them even during interpreted
run of the code could be trapped easily as an error?

GLS@MIT-AI 11/12/78 02:13:09 Re: CSETQ/CONSTANT
To: nil at MIT-MC
CC: (BUG lisp) at MIT-MC
I do not understand why, in the given example:
  ((LAMBDA (A B N)
           (DECLARE (SPECIAL A) (FIXNUM N) (CSETQ PI 3.14159))
           (TIMES B (//$ (*$ 2.0 pi) 13.0) N))
    'T (MUMBLIFY) 4)
it is said that PI would get "evaluated" but N would not be folded out.
If N is foldable (and here it manifestly is), then there is no
obvious reasoon why the compiler cannot do this.  And indeed,
	(LET ((PI 3.14159)) ... PI ...)
seems to be erfectly natural.  There is something to be said for
being able to say at the time of binding (and by the way, if the
local case is intended to be local in the sense of textually
scoped, then having SETQ in the name is perhaps noot wise -- I
appreciate the similarity to the historical usage of CSETQ, but
CSETQ had drastically different scoping, taking precedence even
over local bindings!) that the variable is "constant" in the
sense that it is neverr SETQ'd within its scope.  You could just
have this be an alternative DECLARE syntax:
	((LAMBDA (A B N) (DECLARE (CONSTANT N)) ...) ... 4)
This is of course redundant, but the compiler could perhaps
check it.  A convention I have used in some SCHEME macros (and yes,
you can shoot me for the syntax) is to define the "value" part of
a LET-like clause not to be the CADR, but the (CAR (LAST .)).
This allows one to insert a comment gritch:
	(LET ((A = 4)	;a constant
	      (B := 5)	;I might decide to SETQ this later
	      (C = '(A B C)))	;'nother constant
	     ...)
Now LET using local variables woorks fine local constants,
but there is still the problem of global constants.  In this situation,
a global CONSTANT declaration essentially serves notice to the
compiler that it may "integrate" the global value of suchh a variable
into code if it thinks that will improve the code generated
(for example, (CONSTANT FROB = 5) .... (AREF THE-ARRAY FROB)).
Viewed in this way, evidently the CONSTANT problem for variables
and the so-locally-called "DEFUN-ILE" problem for functions
arre the same problem.  It would be nice to have a uniform declaration
that coverrs both.


SJOBRG@MIT-AI 11/11/78 16:42:12
To: (BUG LISP) at MIT-AI
CC: SJOBRG at MIT-AI
Uh, about using the SAIL option when opening a tty file ....
that option doesn't seem to exist, at least

	(open 'tty/: '(tty sail out))

causes a wrong-type arg error and a no such option message.
To get SAIL characters output, could I use some sort of 
image mode?  The trouble with that, is that the positioning
of characters seems to get screwed up (meaning every time
I try to write a line, it overwrites the previous one).
Any suggestions??

Thanks, Bob.


Date: 11 NOV 1978 1519-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: JIS at MIT-MC, (BUG LISP) at MIT-MC


    Date: 11 NOV 1978 1259-EST
    From: JIS at MIT-MC (Jeffrey I. Schiller)

    (append '(1 . -1) '1)
    MPV; 15162>>HLRZ 1,(5)   1/   115636   777777/   ??

    need I say more?

    The interpreter should at least catch this sort of thing.
------
Since atom checks are soo much more expensive than NIL checks, things such
as APPEND do not check for them.  This is "well documented" and
has been flamed about before.  There are no plans to change it.

Date: 11 NOV 1978 1321-EST
From: JONL at MIT-MC (Jon L White)
Subject: CONSTANT declarations
To: NIL at MIT-MC
CC: (BUG LISP) at MIT-MC, HIC at MIT-MC

One thing I would like for symbolic constants is the same flexibility
that one now has with SPECIAL declarations - namely, if done at top-level
of a "file", the declarations is in effect for all functions, but
if done within a LAMBDA or PROG (as a local declare) it has only
local effect.  I would like to propose  "CSETQ"  instead of "CONSTANT"
and let CSETQ merely turn into SETQ in the interpreter; but the compiler
would notice top-level CSETQ's, and in addition to doing the SETting, 
would put a CONSTANT (or CSETQ) property on the propterty list of the
symbol.  But for local declarations, e.g.
  ((LAMBDA (A B N) 
	   (DECLARE (SPECIAL A) (FIXNUM N) (CSETQ PI 3.14159))
	   (TIMES B (//$ (*$ 2.0 PI) 13.0) N))
    'T (MUMBLIFY) 4)
then the PI would get "evalualted" out of the "//$", but N would
not be "folded" out.   If the name "CSETQ" has bad connotations,
then how about other suggestions?  Of course, the compiler would
signal as erroneous an attempt to lambda-bind a symbolic-constant.

Date: 11 NOV 1978 1259-EST
From: JIS at MIT-MC (Jeffrey I. Schiller)
To: (BUG LISP) at MIT-MC

(append '(1 . -1) '1)
MPV; 15162>>HLRZ 1,(5)   1/   115636   777777/   ??

need I say more?

The interpreter should at least catch this sort of thing.

Date: 11 NOV 1978 0419-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RIVEST at MIT-MC, (BUG LISP) at MIT-MC

The best way to get around reading the
control-C's at the end of the file is to ignore cintrol-C's!  The bug is that
teco uses block mode I/O to dump the file, and therefore a character count is
not available.  If you have meaningful control-C's in the file, then I don't
know what to say.  The control-L is probably relly in the file, so if you
don't want it you should get rid of it with teco.

RIVEST@MIT-ML 11/10/78 21:21:35
To: (BUG LISP) at MIT-ML
WHY IS IT THAT WHEN I DO AN
	INPUSH OPEN "SAMPLE >"; ?^Q := T
(I'M USING CGOL NOTATION HERE, ALTHOUGH THE PROBLEM IS IN LISP, I BELIEVE),
THAT I AM ABLE TO READ THE ENTIRE FILE OK USING READCH, BUT I GET
A ^L  AND SOME NUMBER OF ^C 'S BEFORE REACHING THE END OF THE FILE?
OBVIOUSLY A WORD COUNT AND NOT A CHARACTER COUNT IS BEING USED.  HOW DO
I GET AROUND THIS?
	RON RIVEST


Date: 10 NOV 1978 0645-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


    GSB@MIT-ML 11/06/78 17:10:57
    SFA-STORE doesn't pdlnmk the thing it is storing.

-----
Fixed and patched

Date: 10 NOV 1978 0152-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: MATSON at MIT-MC, (BUG LISP) at MIT-MC

TOPS-10 MacLISP is not a particularly viable entity as far as we are
concerned and therefore we don't really plan on doing any major development
on it.  This includes things such as SFD's.  WE wish, though, to have
a working software tool, and therefore are interested in the outright bugs.
LISP does an INBUF/OUTBUF to set up the appropriate number of buffers.

JONL mentioned that you might be interested in having me come out to DEC
and debug MacLISP on your machine.  I'd be willing to do that, if we can
work out appropriate arrangments.

--howard

Date: 9 NOV 1978 0051-EST
From: MATSON at MIT-MC (Wayne E. Matson)
To: (BUG LISP) at MIT-MC

In trying to use the TOPS-10 version of LISP out here at Marlboro
I have encountered the following difficulties.

Not all fasl files will load.  some get "file not in fasl format".
This is similar to a problem I had with LISP 1 1/2 years ago where
it used dump mode i/o to read the fasl file, but if the last IOWD
failed.  (last block not full) it assumed that it didn't get
anything where as it really did.  jonl said that he fixed this
particular problem, so my guess is probably wrong.

doing i/o in general occasionally gets one of many varied
ill uuo ... type messages from the monitor, or
write into read only memory from lisp.  This tends to bring to
mind another old lisp bug where you played around with .jbff
and/or .jbrel before doing the initial "in" or "out" uuo's that
set up the buffer rings.  the code that did this assumed that
the monitor would alwasy build a ring of 2 buffers.  This is
NOT the case.  The number of buffers is related to the cluster
size of the disk.  again,  Im not sure that this has anything to
do with the problem at hand.  I haven't spent enough time
to figure out exactly what's going on.

minor things are
you set up the default ppn from the users ppn, not his path

lisp doesn't understand SFD's.   (this is really 2 problems)
You could run lisp out of an sfd if it would put "0" in
the 4th word of the lookup/enter block if a ppn wasn't specified.
since lisp does specify the 4th arg every time, it is impossible
to read a file form an sfd.
full sfd stuff would be nice, and probably wouldn't be very hard...

Ill send more once I get some more time to play with it again.
schedules are getting pretty tight...

Date: 7 NOV 1978 0455-EST
From: JPG at MIT-MC (Jeffrey P. Golden)
Subject: The "* <pgm>" convention
To: (BUG ITS) at MIT-MC, (BUG DDT) at MIT-MC, (BUG EMACS) at MIT-MC
To: (BUG LISP) at MIT-MC

Because of problems such as the one GLS mentioned with "* <pgm>", 
MACSYMA opted for ".ALL. <pgm>" instead.  I think that using "*" 
here is much more trouble than it is worth.  (Witness some of the 
problems LISP has had with it e.g. wrt OPEN.)  I think that the 
semantics of "*" and "all" are really different, they are really 
different kinds of wildcards and two different conventions should 
be used.

Date: 6 NOV 1978 2240-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: The "* <pgm>" convention
To: (BUG ITS) at MIT-AI, (BUG DDT) at MIT-AI, (BUG EMACS) at MIT-AI
To: (BUG LISP) at MIT-AI

While it is intuitively appealing to use the name "* <pgm>"
to mean an init file that applies to all users (because of
the semantics of "*" meaning "all" when replacing a single
user name in "<user> <pgm>"), there is a highly unfortunate
interaction of this idea with the use of "*" in otherr contexts.
In particular, I have recently run into the problem that you
cannot use a translation either to or from such a name.
This bug arose in the context of trying to set
up a translation to circumvent a naming incompatibility during
the current transition period:
	 EMACS;.EMACS EMACS,* EMACS
does not work.


GSB@MIT-ML 11/06/78 17:10:57
To: (BUG LISP) at MIT-ML
SFA-STORE doesn't pdlnmk the thing it is storing.


Date: 6 NOV 1978 0039-EST
From: RWK at MIT-MC (Robert W. Kerns)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC

I don't think KMP can claim that the code generated is GOOD code!

Date: 4 NOV 1978 1948-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: DANG at MIT-MC, JPG at MIT-MC, (BUG LISP) at MIT-MC

There is now a new version of macsyma (either the latest macsyma or one
version ago) and a new version of LISP up (the latest) on the -20.

Date: 4 NOV 1978 0310-EST
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC

One way to do this is to get the time, the date, the dow, and then
the time again, in that order, and see if the second time is less
than the first.  If so, you wrapped around midnight, and must
fetch the date and dow again.  It's a kludge, and assumes
that the whole operation takes less than 24 hours, which I think
is a resonable assumption, but shoould work.

Date: 3 NOV 1978 2013-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

I am concerned by the following:

((LAMBDA (TIME DOW DATE) ...) (STATUS DAYTIME) (STATUS DOW) (STATUS DATE))

Is there a way in which I can get all three of those with some degree of
simultaneity? Eg,  return 

(STATUS TIMES)  =>  (<dow> <yr> <mo> <day> <hr> <min> <sec>)

where <dow> was a number from 0 to 6, all others were like (STATUS DATE)
nconc'd to (STATUS DAYTIME) - This way you wouldn't get the screw of:

DOW => FRIDAY
TIME => (23. 59. 58.)
DATE => <the next date - Saturday>

if you got swapped out. If this ever happened, it could be very confusing.
--kmp

gsb@MIT-ML (Sent by KWC@MIT-ML) 11/03/78 15:55:59
To: (BUG LISP) at MIT-ML
(load '(moby file))
..... <grind grind grind>
^B
;bkpt ^b
(gc)
$P
MPV; RDCHAR+1>>MOVE B,@RSXTB   B/   HLL F,R   276157/   ??
RSXTB/    A,,276117
rdinch/ rdin
Someone not restoring or clobbering or gcing RSXTB?
(A had 40 in it)


Date: 2 NOV 1978 2215-EST
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Why does
'(||())
return
(||( NIL)
in Lisp? That's not even a balanced set of "()"'s !!
Even
'(||)
comes back as
(||()
the CAR of which is || and cdr is NIL ... the extra "(" seems to just get
printed. It is evidentally not really there.

GSB@MIT-ML 11/02/78 21:03:45 Re: (sstatus ttycons <sfa> nil)
To: (BUG LISP) at MIT-ML
appears to get arguments identical to
(status ttycons <sfa>)
So how can it tell whether you are reading or clearing it?


Date:  1 Nov 1978 1329-EST
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: MACLISP installed on SYS: at CMUA
To:   bug-lisp @ mit-ai
CC:   Fahlman at CMU-10A, McDonald at CMU-10A, Touretzky at CMU-10A,
      vanRoggen at CMU-10A
Message-ID: <01Nov78 132901 SF50@CMU-10A>


MACLISP is now running well enough here that we feel reasonably secure
in making it available to everyone on CMUA.  We have asked that the
current SHR and LOW files be installed as SYS:MACLSP and SYS:COMPLR.
Once we are sure these are running properly, we will announce the
existence of the program and point people to the documantation, such
as it is.

As new versions of the program arrive from MIT, we should play with them
for awhile on C380ML5P before moving them to SYS:.

Scott Fahlman


Date: 1 NOV 1978 1315-EST
From: JONL at MIT-MC (Jon L White)
Subject: Loading messages
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

I just recompiled GRINDEF etc, LAP, and GETMIDASOP so that they
print onto MSGFILES instead of OUTFILES.   Still, they pay attention
to the setting of (STATUS FEATURE NOLDMSG)

Date: 1 NOV 1978 1257-EST
From: JONL at MIT-MC (Jon L White)
To: gsb at MIT-ML
CC: (BUG LISP) at MIT-MC

Gleep! looks like a bug in GC-OVERFLOW.  since all the rest
of the code is the same as BKCOM, we'll have to kludge it somehow.
tnx for note.

GSB@MIT-ML 11/01/78 12:54:01 Re: GC-OVERFLOW
To: (BUG LISP) at MIT-MC
CC: GSB at MIT-MC
 GCOB goes through BKCOM which calls ERRPRINT.
But there is no error frame, so if one is already in a break loop, you get
the previous error message.


Date: 1 NOV 1978 1214-EST
From: JONL at MIT-MC (Jon L White)
Subject: Finding out what file (and array) objects exist
To: (BUG LISP) at MIT-MC, rms at MIT-AI, rich at MIT-AI

The tag "GCMKL" in LISP holds a list of arrays in the system;
problem is that this tag is not accessible without loading
the symbol table, so probably there should be some status call,
or some primitive function, which copies the top level of this
list, deleting the "dead-array" markers.  If Howard doesn't want
to do it, then I will for the next lisp.

Date: 1 NOV 1978 1200-EST
From: JONL at MIT-MC (Jon L White)
Subject: GC-OVERFLOW, GC-LOSSAGE
To: GSB at MIT-MC
CC: (BUG LISP) at MIT-MC

GC-OVERFLOW  isn't really supposed to be an error, which is why there is
no errframe.  GC-LOSSAGE is supposed to be an error, with an errframe,
but sometimes facilities are so cramped that the only thing possible
is to print out a message and punt back to toplevel.  What kind of
message was being printed out by GC-OVERFLOW that made you think it
was a standard error message?

Date: 1 NOV 1978 1156-EST
From: JONL at MIT-MC (Jon L White)
Subject: bindings of ECHOFILES in LISP
To: johan at MIT-AI, jls at MIT-AI
CC: (BUG LISP) at MIT-MC

Neither the break loop nor the interrupt handler rebinds ECHOFILES
to anything.  Apparently the probelm, for you, is that the system-
supplied ttyscanner is rebinding echofiles to nil (which is a good
idea), and when you interrupt out of the scanner, you find yourself
in a state where echofiles is ().  This doesn't happen, for example
if you interrupt out of some random computation.  You can supply your
own scanner, perhaps modeled after the system-supplied one, by
(SSTATUS TTYSCAN 'RANDOM-FUN)  {or (SSTATUS TTYSCAN 'RANDOM-FUN file)}

GSB@MIT-ML 10/30/78 14:23:03 Re: List storage capacity exceeded
To: (BUG LISP) at MIT-ML
CC: GRR at MIT-ML
This is somewhat reasonable, but i am skeptical that it should
get it again, this time 'beyond recuperation', before the lisp has
gotten into a break loop.  Even a *rset-trap would be somewhat useful.
We have no error handlers, no gc-daemon, no breaklevel, only a gc-overflow
handler which does NOT try to take things into its own hands.
It makes it difficult to see if maybe there really was something
wrong in the code, as opposed to 'simply' running out of space...


jls@MIT-AI (Sent by JOHAN@MIT-AI) 10/30/78 10:48:15
To: (BUG LISP) at MIT-AI
I think it is a bug that LISP rebinds ECHOFILES to NIL
in a breakpoint.  It does not rebind MSGFILES or OUTFILES,
why should it rebind ECHOFILES?  (It does rebind ^R to NIL,
which is "ok").  This becomes a problem when dribbling
(e.g. using LIBLSP;DRIBBL).  If ECHOFILES were treated the
same as MSGFILES and OUTFILES, then I could win by simply
typing control-R at the breakpoint, but now i have to 
fool around with (SETQ ECHOFILES OUTFILES) or some such.


Date: 30 OCT 1978 0228-EST
From: MOON5 at MIT-MC (David A. Moon)
Subject: BUG IN ASSLIS
To: (BUG LISP) at MIT-MC

AT CFDEL+1, THERE IS A RANDOM .FDELE WHICH IS PRESUMABLY
TRYING TO DO A DELETE.  ACTUALLY, IT DOES A RENAME DUE TO
A MISSING 0 IN ITS ARGUMENT BLOCK.  UP UNTIL JUST NOW, THIS
WAS A LOSS SINCE RENAME ON THE CLU DEVICE CRASHED THE SYSTEM
(WHICH I HAVE FIXED).

Date: 29 OCT 1978 1659-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, DAVET at MIT-ML

Though GRINDEF is meant to be given a symbol, it is true that hanging
when given a number is the wrong thing.  We will look into it, but in
the mean time just don't give GRINDEF a number.

DAVET@MIT-ML 10/29/78 11:46:12
To: (BUG LISP) at MIT-ML
CC: DAVET at MIT-ML
	grindef becomes confused on numeric arguments:
it gives, e.g.,  (SETQ 1 '1)  and then hangs somewhere
from whence it must be control-G'ed, and after that
things in general seem to work strangely.
	-davet


Date: 29 OCT 1978 0430-EST
From: HIC at MIT-MC (Howard I. Cannon)
To: RJF at MIT-MC
CC: (BUG LISP) at MIT-MC

PDLOV:	MOVE F,INTPDL		;INTERRUPT ROUTINES MUST LOAD INTPDL INTO F
	MOVE R,IPSWD1(F)	;GET OLD INTERRUPT MASK
IFE SAIL,[
	TRZ R,AP.CLK		;LEAVE ON ALL EXCEPT CLOCK INTS
	MOVEM R,IMASK		;REMEMBER, ALLOW PDL OV IN PDL OV HANDLER
	APRENB R,
]	;END IFE SAIL
IFN SAIL,[
	TLZ R,4			;TURN OFF <ESC>I INTERRUPTS
	MOVEM R,IMASK
	INTMSK R		;LEAVE ON ALL BUT ESC<I> AND CLOCK INTS
]	;END IFN SAIL

Bug in the running code:  The code is currently what appears in the IFE SAIL
conditional and should be changed to what is now in the IFN SAIL conditional.
If not, PSLOV's will get an interrupt system error message.

--howard
(BTW, I have an apparently working but VERY UNTESTED oneseg LISP
on [1,HIC]...it is called TSTLSP.  Perhaps some people would be interested
in trying it out...

--howard

Date: 28 Oct 1978 2151-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Lossages in CMUA MACLISP
To:   bug-lisp @ mit-ai
CC:   fahlman at CMU-10A, touretzky at CMU-10A
Message-ID: <28Oct78 215125 SF50@CMU-10A>


We are using an internal LISP editor here until such time as we can get an
EMACS/LEDIT system running.  In such a system it is inconvenient to have
displace do its thing, since it puts out the expanded form into the edited
source.  I can think of other situations in which DISPLACE wants to be 
inhibited as well.  How about having DISPLACE be a no-op unless the variable
displace is NON-NIL.  Most of the old hand-written displace functions had this
feature.

A number of errors punt the user out of LISP and back to the TOPS-10 system.
Two examples are typing alt-P to the PDL-OVERFLOW error handler, which
causes an IRREPARABLE-PDL-OVERFLOW (I know it's stupid, but it's easy to do
by accident) and setting T or NIL, which causes an attempt to write into
read-only memory error, and exits to the system with no intervening break.
When this happens, it should be easy to get back to the top-level of the
existing LISP.  It turns out that START does this, but REE or CONTIN flame
out destructively.  Is this easy to correct?  It is particularly tragic to
flame out a LISP when editing internally, since fuction definitions
representing a lot of work may be lost.

Aside from such minor lossages, we are winning.  The active MACLISP
community now stands at four members, Dave McDonald has adapted the
UCI-Lisp editor for MACLISP, and Dave Touretzky has created an init
file and some IO functions which move around nicely through the 
cretinous CMU directory structure.

Scott Fahlman


ACW@MIT-AI 10/28/78 15:39:58
To: (BUG LISP) at MIT-AI
I apologize.  The bug is not reproducible.  I couldn't get those close parens
again.  I don't think that it is a lisp bug.  Probably net screwage.


ACW@MIT-AI 10/28/78 15:37:24
To: (BUG LISP) at MIT-AI
Boy!

The following sequence:
(setq foo (get 'car 'subr))
(subrcall foo '(a b c))
was typed while I was trying to see if subrs were really second-class citizens
of the lisp world.
I got back:
;(A B C) NOT SUBR POINTER

;BKPT WRNG-TYPE-ARG
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))....
At this point I hit control-G and Lisp stopped printing out close parens.
What does it all mean?  Those close-parens must be wrong...


Date: 28 Oct 1978 1440-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: Revision, MACLISP in C
To:   rjf @ mit-mc, ward @ mit-ml, jonl @ mit-mc, bug-lisp @ mit-mc
Message-ID: <28Oct78 144018 SF50@CMU-10A>


Please send information about maclisp implementations in C to FAHLMAN @ CMUA
only.  KELLER @ CMUA, mentioned in previous messages, gets to the wrong person.
Thanks,
Scott Fahlman

GLS@MIT-AI 10/28/78 01:49:15 Re: rich@ai
To: (BUG lisp) at MIT-MC
I think RICH actually just wanted a list of outstanding I/O objects;
but if the more general thing of getting every array in the world
would help, that sounds fine.


Date: 27 OCT 1978 1905-EDT
From: JONL at MIT-MC (Jon L White)
Subject: rich@ai
To: (BUG LISP) at MIT-MC

A couple of weeks ago, I think RICH suggested some function which
would, in effect, tell the loser whats on the GCMKL.  Not a bad
idea, what are we waiting for?  Often I too would like to
know if there are some extra obarrays justt lying around, or if
there are some files opened that I dont remember where their 
names are.

MOON@MIT-AI (Sent by MOON0@MIT-AI) 10/25/78 11:52:23
To: (BUG LISP) at MIT-AI
  I GOT A MPV FROM $DEV1+3 WHILE TRYING TO LOAD UCODE SYMBOLS INTO A
LISP.  IT HAD READ THRU 97% OF THE INPUT FILE, AND THERE WAS NOTHING
APPARENTLY STRANGE ABOUT THE INPUT NEAR THAT REGION.  THE LOSSAGE WAS
REPRODUCABLE, BUT UNFORTUNATELY, IN THE COURSE OF FURTHER HACKING I
WILL PROBABLY ALTER FILES, ETC, NEEDED TO REPRODUCE IT EXACTLY.
IT WOULD GREATLY HELP TRACK THESE THINGS DOWN IF THERE WERE A SOURCE
OF LISP ON THE MACHINE (IN EMACS-ABLE FORM) AND A TAGS FILE.


Date:    24 Oct 1978 2326-EDT
From:    DAVE.TOURETZKY(C410DT50) at CMU-10A 
Subject: bug in TOPS-10 version of COMPLR 838
To:      SCOTT.FAHLMAN, DAVE.TOURETZKY, bug-list at MIT-AI

In a compiled function, when the compiler generates in-line
code for nth, if it knows that the first argument is 0 it
takes the entire list instead of the car.  Try this function
interpreted, and then compiled, to see what I mean:

	(defun loser (x)
	  (princ (nth 0 x))
	  (terpri))

-- Dave Touretzky, TOURETZKY @ CMU-A


GSB@MIT-ML 10/24/78 19:32:24
To: (BUG LISP) at MIT-ML
gc-overflow does an errprint but sets up no error frame.
This is fucking confusing if you are already inside of an error break
loop.


Date: 24 Oct 1978 1041-EDT
From: Scott Fahlman at CMU-10A (C380SF50)
Subject: LISP implementation in C.
To:   bug-lisp @ mit-mc
Message-ID: <24Oct78 104149 SF50@CMU-10A>


Hi, gang,

An undergrad here, Ken Keller by name, has decided the world needs a good 
portable LISP, probably written in C for use on Unices and other such machines.
I think he's good enough to pull it off.  He wants to make the thing look as
much like MACLISP as possible, perhaps even with a compiler someday.  It
would have BIBOP and NEWIO.  Comments?  Are there existing systems around
that he ought to know about, written in C or something else that is suitably
high-level?

Replies to KELLER @ CMUA, FAHLMAN @ CMUA

Thanks,
Scott

Date: 24 OCT 1978 0147-EDT
From: GSB at MIT-MC (Glenn S. Burke)
To: (BUG LISP) at MIT-MC

Iloprs which get trapped through UUOGLEEP when there is a machine-error
handler loop infinitly, re-trying the losing instruction.  It appears
that what is happening is that the bit saying that the error is a machine-error
is not being set in D right before calling UINT in UUOGL2.
(If i single-step through this and set the bit in D, then everything works.)

Date: 21 OCT 1978 1332-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC

SATYA@MIT-MC 10/20/78 20:33:03
a:2.0$ b:1000.0$  romberg(exp(-2.*b*sin(t/2)**2*(1.+a*a*sin(t/2)**2)
/(1.+a*a))/(2.*%pi),t,a,b);
gives the message "mpv(atty;)63366>>POPJ 14,"
(I get "failed to converge" when I do not ^Z ^P the MACSYMA, but
BADPI or some other LISP error when the job is ^Z^Ped. - JPG)

Date: 20 OCT 1978 0930-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


    GSB@MIT-ML 10/19/78 22:15:44
    Doing (sstatus ttycons file nil)
    when file is already not ttyconsed clobbers the file badly.
    eg, 
    (setq f (open 'tty: '(out ascii tty single)))
    => #file-out-|tty:* *|-70776
    (sstatus ttycons f nil)
    => T
    f
    => #NIL-0-70776
------
Patched.

GSB@MIT-ML 10/19/78 22:15:44
To: (BUG LISP) at MIT-ML
Doing (sstatus ttycons file nil)
when file is already not ttyconsed clobbers the file badly.
eg, 
(setq f (open 'tty: '(out ascii tty single)))
=> #file-out-|tty:* *|-70776
(sstatus ttycons f nil)
=> T
f
=> #NIL-0-70776


Date: 19 OCT 1978 2023-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC
CC: gpb at MIT-ML

There seems to be no way to defeat the DEFAULTFing action of LOAD,
and this makes it tricky to snarf down complr init files beginning
with *.  If the file is a link to some other file with a more standard
name, the it should win now.

GPB@MIT-ML 10/19/78 19:50:26
To: (BUG LISP) at MIT-ML, (BUG COMPLR) at MIT-ML
ok. re my protest. I did get the thing to work. But it's still a time
sink.

GPB@MIT-ML 10/19/78 19:31:02
To: (BUG LISP) at MIT-ML, (BUG COMPLR) at MIT-ML
I'm really pissed about the INIT handling changes.  I've been
trying to get my blinking complr init to load now for several
days without having to do an extra alt-control S each time,
without success.  As far as I can tell, I'm doing the right
things with links except that it complains that it can't find
((DSK GPB) @ COMPLR) which ain't one of mine.

This whole change was fantasically sloppy. Us poor souls shouldn't
have to second-guess you guys.  If you're going to make changes
like that, and if they must be incompatible then PLEASE give
us folks lots of nice packages or detailed instructions on wjat
to do to make things work.  I've been only a sporadic user for
the past 3 weeks or so and it's alarming to get back to programming
and find the world has changed. It's a big time-waster.

I haven't been so mad since they changed the reading room policy.
Cheers. Gretchen

Date: 18 OCT 1978 0903-EDT
From: JLK at MIT-MC (John L. Kulp)
Sent-by: BROM at MIT-MC
To: (BUG LISP) at MIT-MC, (BUG BUG-MACSYMA) at MIT-MC

BROM HAS A LONG CALCULATION WHICH ALWAYS ENDS WITH A PURPG ERROR
AT MEMERR+5 WITH THE FXP POINTING AT PURE MEMORY.  ANY IDEAS
WHAT TO DO ABOUT THIS?  BROM WILL SEND A MESSAGE SUBSEQUENTLY
ON HOW TO REPRODUCE THIS.

Date: 16 OCT 1978 2205-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: lisp bug at Illinois
To: (BUG LISP) at MIT-MC, DEWOLF at WPAFB-AFAL


Thanks very much for this bug report!!  This bug has already been found and
fixed in the current LISP version (though only a few days ago!).  If you
wish to get a more recent copy of LISP, please let us know and we can arrange
it.


Date: 16 Oct 1978 (Monday) 2158-EST
From: DEWOLF at WPAFB-AFAL
Subject: lisp bug at Illinois
To:   bug-lisp at MIT-AI

Someone here found a GC bug in our current LISP (1137!).  I'm
forwarding you his message.

From Tze-Wah Wong[702,207] on October 14, 1978 at 4:16 PM
I found a bug under the following circumstance:
	(1) A compiled function passes a number to either (a) an interpreted
		function, or (b) a function with a SPECIAL argument.
	(2) The argument passing mechanism makes sure that the argument is
		a true number by number-consing
	(3) If this number-cons causes GC, the GC destroyes certain save
		locations and causes an error.

in ONR:LISP.EXE
742114/	push 14,7	;save funct,,lambda-form on p
742116/ movem 6,462	;c(462)=-ve number of arguments
735105/ skipn 1,174	;get a flonum, succeed ?
735106/ jsp 1,752362	;no more flonum, go to gc
735107/			;return from gc, c(462) destroyed !!!!!!!!!!!!
742125/ move 6,462	;restore 6=-ve ac
751136/ move 3,6	;reg 3=-ve number of arg
751137/ addi 3,0(14)	;reg 3 points to funct,,lambda-form
751140/ hrrz 1,0(3)	;reg 1=lambda-form
			;At this point we get garbage as lambda-form

[Forwarded from Tim Finin]


Tim Finin (FININ@MIT-AI)




rms,rich@MIT-AI (Sent by RICH@MIT-AI) 10/16/78 17:32:17
To: (BUG LISP) at MIT-AI
It is so often a problem that people forget about files
which are open in their Lisps, that something should be done about it.
Even people who know that they must put CLOSEs in their code
do this if their functions have bugs and don't reach the CLOSE.
It is just not good enough to rely on people to know that they
should do (GC) in such cases, because inevitably someone will not
have got the word yet and will tie up the system.
Also, they may have put some of their file objects on global vars
so that even (GC) won't close them, and may not be able to remember
what the vars are called or even that they exist.

Clearly Lisp must offer some way for the user to find out what the
status of his disk files is, so that he can close them.
There should be a function which prints out a description of
which channels have which files open, and another which allows
the user to close specific channel numbers.  Or maybe the first
one should, after printing the list, ask about each file whether
to close it.  A simpler alternative might be to return a list of
the open file-objects (dug up from a non-GC'd variable inside Lisp)
but that has the problem of making lost objects be pointed to again,
so you might not like it.  Also, the former is more likely to be
used, actually, by not-so-experienced people, so I prefer it.

It is important to do something.


Date: 16 OCT 1978 1603-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

Cant TRACE 1+

Date: 16 OCT 1978 1112-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JLK at MIT-MC, GSB at MIT-MC, (BUG LISP) at MIT-MC, BEE at MIT-MC

Change to the IOCINS format:
Instead of IOCINS being the instruction to XCT, it should be the address to
PUSHJ FLP, to.

**NOTE THIS IS FLP (YES, FLP)!!!**

RWK@MIT-ML 10/14/78 19:12:45
To: (BUG LISP) at MIT-ML
Previous message only applies to MC and ML, which have the new DDT needed
to make this move.  I'll do the same for AI tomorrow when I install the new
DDT there.


Date: 14 OCT 1978 1906-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

I've moved the FOO .LISP. files off of (INIT) to their new homes in
<hsname>;<xuname> LISP

GLS@MIT-AI 10/14/78 18:15:12 Re: .SXEVAL (SETQ FOO 5)
To: jlk at MIT-MC
CC: (BUG lisp) at MIT-MC
Any S-expression mentioned in a FASL file has a weird syntax with
respect to numbers.  One must use a special prefix character to
indicate that a number follows.  Just writing "5" means the symbol
whose print name  is "5".


Date: 14 OCT 1978 1120-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

Is it a bug that
.SXEVAL (SETQ FOO 5)
in a .FASL file, causes an error, /5 unbound variable, when loaded?

Date: 13 OCT 1978 2257-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GLR at MIT-AI


    GLR@MIT-AI 10/13/78 22:53:37
    why doesn't (equal 1 1.0) return t ???
------
Well, in order for equal to match things they must be of the same type. 
You should probably use (zerop (difference 1 1.0)) to test them.

GLR@MIT-AI 10/13/78 22:53:37
To: (BUG LISP) at MIT-AI
why doesn't (equal 1 1.0) return t ???

(difference 1 1.0) --> 0.0 so the
math thinks its equal.


Date: 12 OCT 1978 2310-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, JPG at MIT-MC


    Date: 11 OCT 1978 0633-EDT
    From: jpg and hic at MIT-MC
    Sent-by: HIC at MIT-MC
    
    JPG and I think that due to the trouble with * with the init file, and
    the fact that * is a losing name, the first filename for the everyone
    init file should be [ALL].  What think you...(MACSYMA and LISP may
    change to this scheme regardless of what DDT does).

I don't think * is at all a losing name!  I think that it's use to mean "match
anything" is widespread and generally accepted, and that [ALL] is rather
foolish.  * has the additional advantage of quieting the cretins that like
having init files at the beginning of the directory.  I definately think it
should stay as it is, particularly given that things have changed so much
recently.

Date: 12 OCT 1978 1829-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

LISP 1753 bombs out trying to fasload the complr at CMU
I ftp'd  LISP;RELRLQ 1753, and suitably lost.  Furthermore, the
autoload properties are automatically being set to the SYS device - 
I thought there would be a way to rearrange that?

Date: 12 OCT 1978 1827-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: ACW at MIT-AI
CC: (BUG LISP) at MIT-MC

    I think that // of one argument should be that argument, not zero
    as it presently is. ...
Your argument is well-taken, and is similar to the approach taken
in APL with respect to the reduction operator.  MacLISP, however,
purposely uses the "unary" forms of the noncommutative arithmetic
operators so that (- n) can mean what it "obviously" means,
i.e. negation.  By analogy with this, (// n) denotes the reciprocal
of n.  For fixnums this trivially produces zero, but for consistency
with flonums we must do this.

Date: 12 OCT 1978 1822-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: JLK at MIT-MC, (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC
CC: BEE at MIT-MC

    Why does this crock persist that (when using .FASL)
    .ENTRY FOO SUBR 0001
    means a subr of no arguments (i.e. it is always one more than what it
    should be)?  Is there a reason for this?
The answer is that the number 0001 is the "internal format"
value of the ARGS property.  Niceness might have dictated
a better interface, but it suffices.  People write 0001
instead of 1 to remind themselves that a crock is happening.

Date: 12 OCT 1978 1634-EDT
From: JONL at MIT-MC (Jon L White)
Subject: .FASL format ".ENTRY FOO SUBR 0001"
To: JLK at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC

I think that occurs due to the ease of modifying MIDAS, when RG first
put in the .FASL option.

Date: 12 OCT 1978 1632-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC
CC: BEE at MIT-MC

Why does this crock persist that (when using .FASL)
.ENTRY FOO SUBR 0001
means a subr of no arguments (i.e. it is always one more than what it
should be)?  Is there a reason for this?

Date: 12 OCT 1978 1120-EDT
From: JONL at MIT-MC (Jon L White)
Subject: LISP ARCHIV
To: (BUG LISP) at MIT-MC

Perhaps we could make a file LISP OARCHI  which would be the current
LISP ARCHIV from beginning to about March 1978 (which is more or less
where the current published manual is up to date).  Then LISP NEWS
and LISP RECENT could proceed as if begun in March 1978.  
   Comments?

ACW@MIT-AI 10/12/78 03:25:57
To: (BUG LISP) at MIT-AI
I think that // of one argument should be that argument, not zero
as it presently is. I realize that this is an incompatible change,
but I wonder how many people's code depends on (// foo) returning 
0!  My argument runs this way: (// 100. 5 5) --> 4. (// 100. 2 2 5) --> 5.
In other words, (apply '// (cons foo list-of-other-args)) mostly seems to
evaluate to the same thing as (// foo (apply '* list-of-other-args)).
So when // gets one argument, the imagined * gets no arguments and thus should
return a 1.  The numerator of course does not change when divided by this 1.

In keeping with the philosophy of consistency in boundary cases, I think this
change should be made.


Date: 12 OCT 1978 0246-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: CTH at MIT-MC, (BUG LISP) at MIT-MC

Your init file should be called
GUEST1;CTH LISP

Read .INFO.;LISP RECENT for complete information on the new init file scheme.
(INIT); is now obsolete.

Date: 12 OCT 1978 0103-EDT
From: CTH at MIT-MC (Chris T. Hibbert)
To: (BUG LISP) at MIT-MC

I have an init file on (init); like I'm supposed to but when I respond
<ctrl>-Q to alloc? it looks on guest1;   If this isn't specific enough 
for you to help me just send me mail.

Date: 11 OCT 1978 1857-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: EJS at MIT-MC, (BUG LISP) at MIT-MC


    Date: 11 OCT 1978 1653-EDT
    From: EJS at MIT-MC (Eric J. Swenson)

    since when is CLI an illegal device to open on in lisp?
-----
This is sort of a poor bug report.  Could you tell me the exact OPEN that
was failing please.

Date: 11 OCT 1978 1855-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: Weird error message
To: (BUG LISP) at MIT-MC, PSZ at MIT-ML
CC: LH at MIT-ML


    PSZ@MIT-ML 10/11/78 18:27:06 Re: Weird error message
    Would anyone like to tell me why I got the message
    SYMBOL BLOCKSTORAGE CAPACITY EXCEEDED BEYOND RECUPERATION
    ;MAJOR RESTART UNDERTAKEN
-----
You ran out of room when trying to create a new symbol, and the LISP couldn't
get any more core.

PSZ@MIT-ML 10/11/78 18:27:06 Re: Weird error message
To: (BUG LISP) at MIT-ML
CC: LH at MIT-ML, PSZ at MIT-ML
Would anyone like to tell me why I got the message
SYMBOL BLOCKSTORAGE CAPACITY EXCEEDED BEYOND RECUPERATION
;MAJOR RESTART UNDERTAKEN
?


Date: 11 OCT 1978 1653-EDT
From: EJS at MIT-MC (Eric J. Swenson)
To: (BUG LISP) at MIT-MC

since when is CLI an illegal device to open on in lisp?

Date: 11 OCT 1978 0633-EDT
From: jpg and hic at MIT-MC
Sent-by: HIC at MIT-MC
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, JPG at MIT-MC

JPG and I think that due to the trouble with * with the init file, and the fact
that * is a losing name, the first filename for the everyone init file should
be [ALL].  What think you...(MACSYMA and LISP may change to this scheme 
regardless of what DDT does).

Date: 10 OCT 1978 0535-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: GSB at MIT-MC, (BUG LISP) at MIT-MC

GSB recreated the unwind-protect bug and it has been fixed.

Date: 10 OCT 1978 0524-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC, RPG at SU-AI

I am planning on help BH out when he gets here.  I have as
yet to see him this week, though I guess he'll be showing up
tomorrow.

Date: 9 OCT 1978 2332-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: GSB at MIT-MC, (BUG LISP) at MIT-MC

GSB deleted the dump that had the unwind-protect problem in it, and I cannot
make it fail with a simple case.  Therefore, until someone comes up with
another failing situation, I'll have to sit on this bug.

Date: 9 OCT 1978 2310-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: PSZ at MIT-MC
CC: LH at MIT-MC, WAM at MIT-MC, (BUG LISP) at MIT-MC

[If you send your notes to BUG-LISP, btw, you'll probably get better response]
I noticed your note in JONL's mail.  What happens is that if you use
(SSTATUS FLUSH T), then you **MUST PUT AN ENTRY INTO LISP;LOCK > TO LET
US KNOW**.  This was documented when I installed the FLUSH feature.  The file
SYS;PURQIO nnnn that your POWL was dumped from got flushed because there was
noone using it (according to the LOCK > file).  SImply reload your system and
save it again in the current LISP.

Date: 9 OCT 1978 2249-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC, RPG at SU-AI

All I ask, RPG, is that you let me know what you are doing and the same
code gets generated for ITS and TOPS-10 and TOPS-20 as does now (meaning
you should be careful about conditionalizing).  Also, please leave the
old sources around so that I may FILCOM as I am currently primarily responsible
for the source and like to be able to know what is going on.  Also, if I am
logged in, please be sure I am not hzcking the files, and I will do the same.

DDM@MIT-AI 10/09/78 19:48:49
To: (BUG LISP) at MIT-AI
Why is it that:
  (hunkp (makhunk (list 'foo nil))) = NIL  ????
I.e. why are two item hunks (or perhaps its 2 item hunks where item2= nil)
not hunks as far as hunkp is concerned ????


GSB@MIT-ML 10/09/78 19:37:31
To: (BUG LISP) at MIT-ML
In newio, LAP should NOT bind ^W and ^R to nil when it prints its loading
message, it should print it to MSGFILES.


GSB@MIT-ML 10/09/78 12:06:25 Re: unwind-protect losing
To: (BUG LISP) at MIT-ML
I can also get an MPV at UBD+2 pretty reliably:
load amber;.hack 11
and say 'printfile("file-not-found");'
and after the error it will die.
The error about the return address happens when the unwind-protect is
being exited by a THROW, and it appears to work ok if it is being exited
normally.


GSB@MIT-ML 10/09/78 11:46:46
To: (BUG LISP) at MIT-ML
;UNWIND-PROTECT LEFT DUMMY RETURN ADR ON STACK
;BKPT *RSET-TRAP

The interesting thing about this, of course, is that it ran the
system *RSET-TRAP handler rather than my own;  mine were lambda-bound
rather than setq'ed, which implies that someone over-did their unbinding...


Date: 7 OCT 1978 2157-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC
CC: JPG at MIT-MC

The problem with the complr getting the floating point array index
was that CCLOAD used a variable that complr used to loop over an array
to initialize it!!!!!  I change thevariable CNT in CCLOAD to CCLOAD-CNT and
it works fine...arghh!!  I should have checked something like this first.

Oh well, live and learn.

I have installed CCLOAD 9 on all systems and rebuilt chomplers.

Date: 7 OCT 1978 2102-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, RG at MIT-AI

There was a bug in the defaulting of stuff in OPEN.  It has been fixed
and the LISP reinstalled on all machines.

RG@MIT-AI 10/07/78 19:56:55
To: (BUG LISP) at MIT-AI
(OPEN ((LMCONS) CADREG >) IS TRYING TO REF THE
LMCONS DEVICE INSTEAD OF DEFAULTING PROPERLY WHICH THE OLD THING USED TO DO.


Date: 7 OCT 1978 1748-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, PRATT at MIT-AI

When a person
without a directory logs in, his HSNAME is set to be the directory that
his files are on.  For example. on MC we have the GUEST1; GUEST2; GUEST3;
(et al.) directories.  DDT has all the smarts about where an init file is
kept.  Therefore, to get FOO's init file one would type:
FOO$^S
which would set the HSNAME correctly when you start up the next program
(for example, L^K)

If you mean by public init files init files to be used by many people, then
you should put the init file somewhere and specifiy it in the JCL line:
:L foo;bar
which will look for foo;bar > (notice the change to use >).  If you wish to
have an init file on a certain directory to be used by everyone, then you
would use a small "kludge" (the foo; construct as the JCL) and put
foo;* LISP to be the init file that you wanted.  Therefore, if you had an ABC;
directory with an init file to build program ABC, then one would name
the init file ABC;* LISP and for an arbitrary person to use it they would
type:
:L ABC;
note that this is not really a feature of the general init file scheme, but
is a minor kludge put in for this purpose.

PRATT@MIT-AI 10/07/78 17:38:23
To: (BUG LISP) at MIT-AI
Guess I don't understand the new INIT philosophy.  Is the (INIT) dir
going to continue to exist?  If so, how does one conveniently name it
in the JCL to LISP (i.e. without having to spell it out as (INIT);)?
If not, where are public init files to be kept?


KEN@MIT-AI 10/07/78 11:43:10
To: (BUG LISP) at MIT-AI
(open '((ken) foo bar) 'out)
used to work and now says NO SUCH DEVICE
however
(open '((dsk ken) foo bar) 'out) 
seems to work fine
this is the latest lisp 1750

GSB@MIT-ML 10/06/78 22:04:48
To: (BUG LISP) at MIT-ML
(setq foo (array nil t 10.))
#T-12-70776
(arraycall nil foo 2 3)
;((NIL . 2) (NIL . 777776)) TOO MANY ARGUMENTS SUPPLIED - APPLY

Where is all the error info disappearing to???


Date: 6 OCT 1978 2152-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

Unfourtunatly, I do not have time to revamp the default handling scheme.
(JONL, didn't we decide not to do significant stuff to MacLISP?).

Same with TOPS-10.

If you wish to do it, be my guest.

Date: 6 OCT 1978 1958-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, SJOBRG at MIT-AI

Did you read .INFO.;LISP RECENT?  Init file names have changed.

Date: 6 OCT 1978 1953-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: CRD at MIT-MC, (BUG LISP) at MIT-MC


    Date: 6 OCT 1978 1233-EDT
    From: CRD at MIT-MC (Charles R. Davis)

    After creating an init file under the new naming scheme, any attempt to
    start up a lisp job results in

    GC CALLED FROM ALLOC - LOSE, LISP IS DEAD

    and a .VALUE at 123444.
------
Did you remmeber to include an ALLOC comment at the beginning of a file?

If not, when LISP READ's the first form, it could be a large one, thereby
causing a GC (etc...).  You must have a (COMMENT) as the first thing in
an init file even when you don't wish to do any allocations.

Date: 6 OCT 1978 1951-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: INIT file searching
To: RLB at MIT-MC, (BUG LISP) at MIT-MC

To get FOO's init file, say:
FOO$^S
This does the "right" thing.

Date: 6 OCT 1978 1946-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JLK at MIT-MC, (BUG LISP) at MIT-MC
CC: JPG at MIT-MC


    Date: 6 OCT 1978 1632-EDT
    From: jlk at MIT-MC (John L. Kulp)
    Sent-by: MEV at MIT-MC

    Why does (EXP (*$ x x)) give a missing args error when x is too big.
    This is very confusing to MACSYMA users...
------
This was a bug that is fixed in the new LISP...when MACSYMA comes up
in the new LISP, it will get the benefit of this fix.

Date: 6 OCT 1978 1632-EDT
From: jlk at MIT-MC (John L. Kulp)
Sent-by: MEV at MIT-MC
To: (BUG LISP) at MIT-MC

Why does (EXP (*$ x x)) give a missing args error when x is too big.
This is very confusing to MACSYMA users...

DICK@MIT-AI 10/06/78 15:39:15
To: (BUG LISP) at MIT-AI
	I have teh tty open in 12 bit mode, (wich worked just fine in the past)
however now if I do a (read tyi) lisp blows up with an infinite sequence of 
;#FILE-IN-|TTY:* *|-70012 NOT ASCII FILE
messages.  if you do a (read) or (read t) things seem to get past teh error
checkers and work alright, but I would rather not have to run around and change all my
code.
						Dick


Date: 6 OCT 1978 1512-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: INIT file searching
To: (BUG LISP) at MIT-MC

According to the description in LISP RECENT, if I want to start a Lisp
with FOO's init file, I need to type :LISP FOO;FOO LISP (i.e., nodefault).
Suppose the search went like:

	B) JCL of the form:
		foo;	look for foo;<xuname> LISP, if not found try
				 foo;* LISP, if not found try
				 foo;foo LISP
		fn1	look for <sname>;fn1 >
		fn1 fn2 look for <sname>;fn1 fn2
		foo;fn1 look for foo;fn1 >

Date: 6 OCT 1978 1233-EDT
From: CRD at MIT-MC (Charles R. Davis)
To: (BUG LISP) at MIT-MC

After creating an init file under the new naming scheme, any attempt to
start up a lisp job results in

GC CALLED FROM ALLOC - LOSE, LISP IS DEAD

and a .VALUE at 123444.

Date: 6 OCT 1978 1042-EDT
From: MILLER at MIT-AI (Mark L. Miller)
Subject: New Init Scheme
To: (BUG COMPLR) at MIT-AI, (BUG LISP) at MIT-AI
CC: MILLER at MIT-AI


I have switched my init files over to the new scheme
as per the lisp recent instructions.  But consider the
following:

I have an init file miller;miller lisp, and
a different one     spade; spade  lisp, and
one for complr,     spade; spade complr.

Now if I do L^K, I get miller;miller lisp loaded.  Great.
If I do, spade$^s
         spade$$^s
and then
         L^K, I get spade;spade lisp loaded.  Super.
But then when I tried:
         complr^K
I expected to get spade;spade complr loaded.
NO.  I got miller;miller lisp!
I hope this is a bug.  If it is a "feature" I must admit I
find the "winning new init file scheme" to be a loss.
Mark


SJOBRG@MIT-AI 10/06/78 10:19:06
To: (BUG LISP) at MIT-AI
What's with the "Alloc?" message I'm now getting
with my Lisp?  Why doesn't it just read my .LISP. (INIT) file,
like it used to?


Date: 6 OCT 1978 1016-EDT
From: JONL at MIT-MC (Jon L White)
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

I just made up new compiler dumps in the current lisp 1747.
by deleting the complr entries in lisp;lock >,  it is noted that
PURQIO 1578 may go away, and that no complrs need lisps prior to 1747.

Date: 6 OCT 1978 0825-EDT
From: BROM at MIT-MC (Leslie Bromberg)
To: (BUG LISP) at MIT-MC, (BUG ARC) at MIT-MC

When the Gould spooler reads AR2:BROM;RESUME XGP, an end of file condition is reached
well before the real end.  Copying it to disk and trying again, wins however.
(I.e. (TYI CHANNEL) where CHANNEL is open in ascii mode to an ARC device seems to return
-1 before it should).

Date: 6 OCT 1978 0732-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

1) Why not extend the new INIT scheme to TOPS-10 world?
2) The kludginess of NODEFAULT is apparent in the fact that
   all of PROBEF, LOAD, FASLOAD, FASLP, and DELETEF would like
   to specify that also (in addition to OPEN).  But for the nonce,
   why do they take a perfectly good open'd file array and run
   the DMRGF algorithm?  Why not take the file literally, and thus
   extend (indirectly albeit) the benefit of NODEFAULT?

Date: 5 OCT 1978 2058-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, RWK at MIT-MC

OK, the new flag NODEFAULT has been added to OPEN.  Thus, the init
file can be called "* LISP".  Thanks to JONL for this suggestion.

Date: 5 OCT 1978 1945-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC
CC: JFK at MIT-MC, MRG at MIT-MC, ELLEN at MIT-MC


    Date: 5 OCT 1978 0754-EDT
    GRIND is apparently ignoring its args and using the value of defaultf.
    Perhaps a MERGEEF is in the wrong order?
-----
My initial analysis was correct in practice, but incorrect in cause.  I
have fixed the bug in GRIND and have reinstalled it on all systems.

Date: 5 OCT 1978 0915-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

LISP NEWS of May 25, 1978, has a spelling error
LAP-A-LISP  ==>  LAP-A-LIST

Date: 5 OCT 1978 0754-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC
CC: JFK at MIT-MC, MRG at MIT-MC, ELLEN at MIT-MC

GRIND is apparently ignoring its args and using the value of defaultf.
Perhaps a MERGEEF is in the wrong order?

Date: 5 OCT 1978 0618-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


    GSB@MIT-ML 10/05/78 05:28:42
    (EXP 100.)
    ;**MISSING-ARG** ARG TOO BIG - EXP
    Come come now...

-------
Has been fixed for the next LISP.

GSB@MIT-ML 10/05/78 05:28:42
To: (BUG LISP) at MIT-ML
(EXP 100.)
;**MISSING-ARG** ARG TOO BIG - EXP
Come come now...


Date: 5 OCT 1978 0324-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: SATAN at MIT-MC, RLB at MIT-MC, (BUG LISP) at MIT-MC


    Date: 4 OCT 1978 1727-EDT
    From: SATAN,RLB at MIT-MC
    UNBND3 and PNMK1 seem to be the same place.
-----
yeah, since alot of this stuff has to be saved on interrupts, we try
to be stingy...I have seperated UNBND3 and PNMK1

PRATT@MIT-AI 10/04/78 18:08:12
To: (BUG LISP) at MIT-AI
It used to be that (declare (setq special t)) at the beginning of a lisp
file to be compiled would special all variables.  This no longer works,
but I can't find any reference to this fact in LISP;LISP NEWS.  What's
the story?


Date: 4 OCT 1978 1727-EDT
From: SATAN,RLB at MIT-MC
Sent-by: SATAN at MIT-MC
To: (BUG LISP) at MIT-MC

Goddammit!!
You guys are so stingy with temporary locations!
UNBND3 and PNMK1 seem to be the same place.
Consider what happens if a PDLNMK saves TT in PNMK1 at NMK1, then goes to
FLCONS, which calls AGC4, which runs some GC daemon, which specbinds
something, runs code, calls UNBIND, which clobbers UNBND3 (i.e. PNMK1),
ultimately returning to PNMK2, restoring TT from the (clobbered) PNMK1.

DDM@MIT-AI 10/03/78 23:56:23
To: (BUG LISP) at MIT-AI
I believe I've located a bug in mapcan  - the circumstances are a bit
invovled to duplicate... I'll have to demonstrate -   the symptoms
are never returning from the 1st run through the lambda body (I was
TRACE'ing it) and taking the value of that lambda body and scrunching
it into a circular list:  (cdr foo) = foo
   I'll be around tomorrow (Wed) afternoon until 6 and randomly through
the rest of the week.


ALAN@MIT-AI 10/03/78 22:27:01 Re: `
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-AI
	Well MY backquote turns `(a ,@ b) into (cons a b).
You can use `(a . ,b) to get (cons a b) however.
The maclisp backquote can use a lot of improvement
in this direction.

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

Why does TYO observe the rule that PRINC does about terpri'ing in certain
places. The last thing in the world I can imagine anyone wanting if they
are using TYO to output specific chars is for lisp to randomly output
spurious <CR>'s and <LF>'s to a file!

Date: 3 OCT 1978 1701-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: ALAN at MIT-MC

It would be nice for the purposes of constructing A-Lists to have the 
backquote macro expand

	`(FROB1 ,@ FROB2) go to (CONS 'FROB1 FROB2)

instead of (APPEND (NCONS FROB1) FROB2) which will die. Indeed maybe 
`(FROB1 FROB2 ... FROBN-1 ,@ FROBN) should expand into cons's since they
are well defined in meaning even for atoms.

				--kmp

Date: 3 OCT 1978 0427-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Time (extra) to produce LAP files
To: (BUG LISP) at MIT-MC

Just for the record, if one opts for producing a LAP file instead of
the FASL file as the output of the COMPLR, the the runtime of the
compiler seems to be increased about 40%.  This must undoubtably be 
due to the inncreased overhead of character handling in TYO, as
opposed to the word-at-a-time buffering (and simple semantics) of
OUT.

DDM@MIT-AI 10/01/78 23:42:23 Re: "not-ascii-char bug"
To: (BUG LISP) at MIT-AI
Turns out not to be lisp bug - since it was happening
during read-in I didn't notice that it was actually happening
in a processing routine of mine - bad char to maknam
  Sorry for the wallpaper,   -ddm


DDM@MIT-AI 10/01/78 23:18:25 Re: addittion to earlier msg.
To: (BUG LISP) at MIT-AI, RMS at MIT-AI
Foo!! - there are 3 of those "#724126" non-ascii-characters in
the file now --- but it read in perfectly yesterday (uh, no- just
about midnight I got one of these same errors and patched it out
of the file.
   ?? Why doesn't emacs notice ??


DDM@MIT-AI 10/01/78 23:11:05
To: (BUG LISP) at MIT-AI, RMS at MIT-AI
Hi,  I've just gotten the second "char. not acsii" bug from
lisp while reading a file that read in perfectly well moments
before.  I snipped out the offending section of the file
and stored it as:  DDM;.NOT ASCII     Attempting to load that
file will recreate the error.   The exact msg was
  ";#724126 NOT ASCII CHARACTER"

Happy hunting,  ddm


Date: 1 OCT 1978 1420-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML

Sorry about the installation, I must have blown it..oh well..

Date: 1 OCT 1978 1416-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: ..RPUR .BREAK 12 to DDT
To: MOON at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

As RWK said, what I need is a way to copy and depurify a page.

Date: 1 OCT 1978 1410-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: SUSPEND for case of :PDUMPI
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

I probably dumped out the lisp with PURIFY instead of XPURIFY.  I have
now XPURIFI'ed it...if it still fails, let me know.

GSB@MIT-ML 09/30/78 23:55:49
To: (BUG LISP) at MIT-ML
-1_-1  =>  ;ILLEGAL OBJEXT SOMEWHERE OR OTHER - READ
rather than either /-1_-1 or 377777777777


Date: 30 SEP 1978 1408-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC
CC: BKERNS at MIT-MC, NIL at MIT-MC


    Date: 30 SEP 1978 0209-EDT
    From: KMP at MIT-MC (Kent M. Pitman)

    I thought we agreed that "," would not generate an error outside of 
    backquote! At the very worst it should be an ordinary character
    when not in backquote. After all, "@" doesn't get similarly wedged.
    We are losing characters fast and sacrificing them for a new feature is
    one thing but making them altogether illegal in certain contexts is
    very restricting I think.

If you allow "," to mean anything useful outside of a back-quoted
expression, then you cannot use it to mean that useful thing
within a back-quoted expression.  Ergo it is a loss so to use it.
QED

Date: 30 SEP 1978 0209-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC
CC: BKERNS at MIT-MC, NIL at MIT-MC

I thought we agreed that "," would not generate an error outside of 
backquote! At the very worst it should be an ordinary character
when not in backquote. After all, "@" doesn't get similarly wedged.
We are losing characters fast and sacrificing them for a new feature is
one thing but making them altogether illegal in certain contexts is
very restricting I think.

Date: 29 SEP 1978 1748-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: ..RPUR .BREAK 12 to DDT
To: MOON at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC


    Date: 28 SEP 1978 2133-EDT
    From: MOON at MIT-MC (David A. Moon)
    Subject: ..RPUR .BREAK 12 to DDT
    To: (BUG LISP) at MIT-MC
    CC: RWK at MIT-MC

    This is grotesque.  Tell me what Lisp wants and I'll put it into the
    CORBLK system call (or else a new system call).

Hurrah!  How about just making %CBCPY do the right thing?
(We all knew it was grotesque, but so was the option of using some pure
page and mapping it back in from the file.)

Date: 29 SEP 1978 0624-EDT
From: JONL at MIT-MC (Jon L White)
Subject: SUSPEND for case of :PDUMPI
To: (BUG LISP) at MIT-MC

If I use TS XL instead of TS L, the dumped file fails to
be reloadable, complaining about not finding SYS;PURQIO nnnn
but it should be looking for LISP;PURQIX nnn

Date: 28 SEP 1978 2133-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: ..RPUR .BREAK 12 to DDT
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

This is grotesque.  Tell me what Lisp wants and I'll put it into the
CORBLK system call (or else a new system call).

GSB@MIT-ML 09/28/78 00:24:19
To: (BUG LISP) at MIT-ML
Apparently the installation of a patched purqio 1742 to fix the interrupts
backing up to makunbound was incomplete, the behavior was manifesting 
itself, and upon inspection i discovered that there was a purqio 1742
on ML:LISP; with the same credate as the one on MC:SYS; but more
recent than the one on ML:SYS; .  I moved the one from ML:SYS; to
ML:LISP;PURQIO LOSS, and the one from ML:LISP;PURQIO 1742 to
ML:SYS;PURQIO 1742.
.........


JHT@MIT-ML 09/28/78 00:20:13
To: (BUG LISP) at MIT-ML
Control-B'ed LISP goes to makunb for some strange reason.
(GSB and i had this error a while a go - i thought it was fixed)

GSB@MIT-ML 09/27/78 21:42:54
To: (BUG LISP) at MIT-ML
hey, i thought the lossage of having somethin like P.X to a lisp
waiting for input had been fixed?  Upon P'ing it i get a .value
at uintpu...
(note the presence of a tty-return interrupt which does next to nothing)


KEN@MIT-AI 09/27/78 01:49:02
To: (BUG LISP) at MIT-AI
the following loses:

(putprop 'foo f1 'expr)
(putprop 'foo f2 'subr)
(putprop 'foo f3 'expr)

The last putprop does not move the expr in front of the plist of foo
so that f2 is the definition of the Foo rather than f3
At least people should be warned to remprop first or else use defprop
I managed to waste a fair amount of time until it became apparent what was
wrong.

GSB@MIT-ML 09/26/78 07:08:39
To: (BUG LISP) at MIT-ML
(TYIPEEK) when done such that it inputs from a SFA doesn't move the lisp
number into TT, but goes through FIX1, so returns some garble;  readmacros
lose badly with this.


Date: 26 SEP 1978 0427-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: BUG COMPLR at MIT-MC

REMEMBER TO USE (STATUS HSNAME) FOR COMPLR (INIT) FILES.

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

(quit 't) 
fails to be "noiseless", and per documentation in LISP NEWS

Date: 25 SEP 1978 2252-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

1746 doesn't have the GLOBALSYMs  "PTNTRY" and "PTEXIT" as promised.

Date: 25 SEP 1978 2250-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

LAPSETUP is putting GLOBALSYM properties instead of the desired SYM
properties.  I changed L;ULAP >  to reflect a proper fix.

Date: 25 SEP 1978 0857-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RWK at MIT-MC, JPG at MIT-MC, (BUG LISP) at MIT-MC

RWK and I talked out what LISP needs to do.  Before I release the next
LISP (which unfourtunatly might have to wait until I get back this
weekend), I will implement whatever new functions are needed, and DOCUMENT
exactly what is going on!!

Date: 25 SEP 1978 0437-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
Subject: <HSNAME>;<XUNAME> <FOO> for LISP
To: (BUG LISP) at MIT-MC, RWK at MIT-MC

In response to GLS's and RWK's responses to my note on this, 
as far as the STATUS function is concerned, I think LISP should 
provide (STATUS HSNAME) and (STATUS XUNAME) when the time comes.
This will make things more uniform and simpler as that is what 
these frobs appear to be called.  If this should make any of the 
existing STATUS args obsolete, then they can eventually be phased 
out.  But during the transition period, e.g. (STATUS USERID) and 
(STATUS UDIR) and whatever other related STATUS args there are 
should continue to be computed as they are now.

Date: 24 SEP 1978 0639-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC

Thank you for your suggestion re the FASLOAD messsages, but we have no plans
to change them at this time.

Date: 24 SEP 1978 0638-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

Could you please create a way that the messages 
;MUMBLDEEFROTZ A USER SUBR AT <SOMEPLACE> IS BEING REDEFINED BY ...
could be compressed into somethings more concise like:
;The following functions are being redefined by <filename>
;Frob, Frob, ...
It's a nice message but I so rarely care about the locations etc that an
abbreviated version which didn't cause so many more-breaks would be much
appreciated. I know many people who also think this would be a win.
-kmp

Date: 23 SEP 1978 0742-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(QUIT 100000)
MC. (my DDT prompt)
$P
:VK  (What is this doing here, I didn't ask for that!)
$P
100000


MOON@MIT-AI 09/23/78 05:31:33
To: (BUG LISP) at MIT-AI
When it erases the ##MORE##, it should position the cursor at the front of
the ##MORE## rather than the front of the line.  For instance, when the gc
prints a ";adding a new list segment..." message on the bottom line of the
screen, the ##MORE## comes out at the end of that line since interrupts
are cretinously deferred during the printing of this message, and when the
more is proceeded, the gc message gets erased.

Date: 23 SEP 1978 0138-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: <HSNAME>;<XUNAME> <FOO>
To: JPG at MIT-MC, (BUG LISP) at MIT-MC, RWK at MIT-MC

    Date: 22 SEP 1978 1514-EDT
    From: GLS at MIT-MC (Guy L. Steele, Jr.)
    Subject: <HSNAME>;<XUNAME> <FOO>
    To: JPG at MIT-MC, (BUG LISP) at MIT-MC, RWK at MIT-MC

    I AM UNCLEAR ON THE EXACT SEMANTICS OF HSNAME, BUT
    PERHAPS IT IS THE CORRECT THING TO MAKE (STATUS UDIR) USE IT??

No, (STATUS UDIR) should continue to return the SNAME on startup.
(STATUS HOMEDIR) should probably return the same as (STATUS USERID) on
TOPS-10, and I assume on other non-ITS's as well.  On ITS, it should
just return the result of a .SUSET [.RHSNAME,,R] converted to an atom.

LISP should get it's init file from <HSNAME>;<XUNAME> LISP

Note that this is simpler than what is now, which checks on (INIT) as well.
However, an additional feature would be to also check for a file
<HSNAME>;* LISP which would be a way for all users of a directory to
share a LISP init.  DDT will have this feature, and LISP might as well too.

Also, I'm putting in a .BREAK 12, to ask DDT to lookup the HSNAME of another
user.  How about having (STATUS HOMEDIR <xuname>) get this info from DDT
and return it?  This would be useful for running other people's init as a
JCL option.

RMS@MIT-AI 09/22/78 23:27:16
To: (BUG LISP) at MIT-AI
(COND ((= (TYIPEEK) 40))
      (T (SETQ X (READ))))
(READCH)

doesn't work, because the rubout processor doesn't look at the char gobbled
by the TYIPEEK, making it impossible to type a 1-character atom at the READ.


Date: 22 SEP 1978 1514-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: <HSNAME>;<XUNAME> <FOO>
To: JPG at MIT-MC, (BUG LISP) at MIT-MC, RWK at MIT-MC


    Date: 22 SEP 1978 0420-EDT
    From: JPG at MIT-MC (Jeffrey P. Golden)
    Subject: <HSNAME>;<XUNAME> <FOO>
    To: (BUG LISP) at MIT-MC, RWK at MIT-MC

    I guess it is obvious that shortly after the new DDT is released, that 
    LISP will have a (STATUS HSNAME) and (STATUS XUNAME) and that 
    e.g. JPG;.LISP. (INIT) will become JPG;JPG LISP .  ("LISP" instead of 
    ".LISP." I hope - there is a slight problem of interference with some 
    FOOBAR's LISP expressions file named "FOOBAR LISP", but I think the risk 
    here is worth the change.)  Anyway, after the STATUS frobs are available, 
    I look forward to using them for MACSYM INIT files.

(STATUS XUNAME) ALREADY EXISTS IN THE GUISE OF (STATUS USERID).
I AM UNCLEAR ON THE EXACT SEMANTICS OF HSNAME, BUT
PERHAPS IT IS THE CORRECT THING TO MAKE (STATUS UDIR) USE IT??

Date: 22 SEP 1978 1055-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, SJOBRG at MIT-MC, RICH at MIT-MC

The EVALHOOK bug has been fixed, and I am in the process of installing
the fixes on all system now.
I'm sorry if this caused any inconvenience.

Date: 22 SEP 1978 0420-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
Subject: <HSNAME>;<XUNAME> <FOO>
To: (BUG LISP) at MIT-MC, RWK at MIT-MC

I guess it is obvious that shortly after the new DDT is released, that 
LISP will have a (STATUS HSNAME) and (STATUS XUNAME) and that 
e.g. JPG;.LISP. (INIT) will become JPG;JPG LISP .  ("LISP" instead of 
".LISP." I hope - there is a slight problem of interference with some 
FOOBAR's LISP expressions file named "FOOBAR LISP", but I think the risk 
here is worth the change.)  Anyway, after the STATUS frobs are available, 
I look forward to using them for MACSYM INIT files.

GSB@MIT-ML 09/21/78 23:20:09 Re: interrupt lossage in new lisp
To: (BUG LISP) at MIT-ML
It appears that if i interrupt out of an interpreted DO at a time
when BAKTRACE shows nothing on the stack except the DO itself,
upon exiting the stack has been clobbered or otherwise handled incorrectly,
as someone jumps to MAKUNBOUND, and there is something random in A.
(I traced this back by looking at the jpc and setting breakpoints.)
At MAKUNBOUND, the jpc is CPXDJ, so i didn't bother going back further...


Date: 21 SEP 1978 2212-EDT
From: JONL at MIT-MC (Jon L White)
Subject: CTCALL
To: (BUG LISP) at MIT-MC

First instruction in CTCALL  {compiled code's setup for CATCHALL}
should be PUSH P,T  rather than PUSH P,B

Date: 21 SEP 1978 1906-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Apology on NCDR/NTHCDR timings
To: (BUG LISP) at MIT-MC

Thinking about the NCDR timings reported yesterday, I realized some
gross anomaly:  HRRZ-SOJG is two instructions per cdr, and the compiled
lisp version takes about three instructions per cdr (due to the overhead
of getting in and out of a subroutinized CDDDDR).  Trying it again, 
I must confess, sad to say, I was comparing apples and oranges - the 
compiler (with NCDR in it) has *RSET off, and the new lisp had it initially
on, so the NTHCDR loop being executed was the slow path with checking for 
list-type at each cdr.  The correct figures (in so far as the KL10 timing 
clock can be considered "correct") with *RSET off are as follows, with 
F5NCDR being an unrolling to a loop-length of 5, and F16NCDR an unrolling 
to 16.   Timings: 
   (NCDR l n)	 12.us + 1.41*<n-1>us	|compiled loop on (CDR (CDDDDR x))
   (NTHCDR n l)	  4.us + 0.93*<n-1>us	|HRRZ-SOJG
   (F5NCDR l n)	  4.us + 0.68*<n-1>us	|5 HRRZs + looping
   (F16NCDR l n)  4.us + 0.52*<n-1>us	|16 HRRZs + looping
Trial functions F5NCDR and F16NCDR can be found in MC:JONL;FNCDR LAP

Date: 21 Sep 1978 1217-PDT
From: RPG at SU-AI (Dick Gabriel)
Subject: Addition to Tops-10 Mailing list  
To:   bug-lisp at MIT-MC    

Please send a MacLisp kit to:
	Prof. Marco Somalvico
	Politecnico Di Milano
	Milano, Italy

They run a 603 monitor. Thanks.
			-rpg-



Date: 21 SEP 1978 1420-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Unrolling NTHCDR
To: GLS at MIT-MC
CC: (BUG LISP) at MIT-MC

Yes, the winnitude of the compiled version, which merely unrolls
4 cdrs at a time by doing JSP T, %CDDDDR  seems to say that
the more complicated unrollings aren't worth it.  Most likely this
is due to the relatively small loop overhead, and the fact
that the cache misses are most certainly concentrated in the data
rather than the program (well, how fast can one randomly cdr down
a list anyway?)

Date: 21 SEP 1978 0135-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
Subject: NTHCDR
To: (BUG LISP) at MIT-MC

If you want to unroll the loop, there are yet trickier ways to do it:
	MOVN TT,(B)		;the negation is important!
	ASHC TT,-LOGN
	ASH D,LOGN-43
	AOJGE TT,BARF(D)	;the G in GE is needed if arg 2 was zeroIt is cerrtainly true that the SOJG in the tight loop would screw up
a pipelined machine; this certainly holds for the S1.  Unfortunately
for the S1, though, the tight sequence of HRRZ A,(A) or the equivalent
also bottles up in the pipeline because it is hard to index off something
you wrote into the the previous instruction.  Sigh...

LOOP:	JUMPE A,CPOPJ		;optional, and may be placed later if desired
REPEAT 1_LOGN, HRRZ A,(A)
	AOJN TT,LOOP
	JRST BARF(D)

REPEAT 1_LOGN, HRRZ A,(A)
BARF:	POPJ P,
If the JUMPE test is included for early cutoff, I suggest that LOGN==3;
otherwise probably LOGN==2 will suffice.
By the way, it is astonishing that the compiled NCDR won, when
you consider that is was calling %CDDDDR out-of-line!

MOON@MIT-AI 09/20/78 23:36:21
To: (BUG LISP) at MIT-AI
Lisp 1742 seems not to print fasload warnings when
the same file is loaded twice.  The value of fasload was (SUBR FSUBR LSUBR).
Is this a bug?

Date: 20 SEP 1978 1959-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: ||
To: (BUG LISP) at MIT-MC, Jason at MIT-ML

This bug has been fixed and will be installed shortly.

Jason@MIT-ML 09/20/78 18:03:52 Re: ||
To: (BUG LISP) at MIT-ML
How come (print '(||)) prints it as:
||()
?

WELG@MIT-AI 09/20/78 16:17:22
To: (BUG LISP) at MIT-AI
On attempting to fasload a fasl file into a lisp I obtained the following
error message:
   ILOPR; 427735>>UNREAL   0/   0   UNREAL/   0
     Any suggestions as to what is causing it?
				- Eric

Date: 20 SEP 1978 1212-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Timings for NTHCDR
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

I obtained them using the TIMIT (and NTIMIT) functions in the
BS package (on LIBDOC and LIBLSP).  Times for NTHCDR are probably
bad due to the SOJG.  Certainly on a pipelined machine, the
SOJG would really slow things down.

Date: 20 SEP 1978 1201-EDT
From: JONL at MIT-MC (Jon L White)
Subject: NTHCDR
To: (BUG LISP) at MIT-MC

1) In *RSET mode, NTHCDR fails to check the first arg for FIXNUMness.
   Should probably also check that it is less than about 2^18 or so.
2) I would like to replace my own function NCDR with NTHCDR, but the 
   latter is too slow (even though the former is compiled LISP!)
   Timings:  (NCDR l n)		12.us + 1.80*<n-1>us
	     (NTHCDR n l)	 8.us + 3.86*<n-1>us
   How about trying the loop-unfolding trick, and inserting just before
   the label "NTHCD1" this code
   NTHCD0:	CAIGE R,4
		  JRST NTHCD2
   REPEAT 4,	HRRZ A,(A)
		SUBI R,4
		JRST NTHCD0
   NTHCD2:	JUMPLE R,CPOPJ
   NTHCD0: 	. . .

Date: 20 SEP 1978 0840-EDT
From: JONL at MIT-MC (Jon L White)
Subject: ARRAY management in MACLISP
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC

    Yea, "NORET" rather than "*NORET", cheers to "*NOPOINT".
But I'm aghast at your comment that fiddling NORET and GETSP slowed
things down (or at least left an unacceptable solution) - it can't do 
anything but reduce the number of GCs and array-relocations both.  
One theory of HUNKs was that the overhead, both in terms of header-space 
consumed and in time spent on memory-management (creation, relocation and 
gc'ing) was much less than for arrays.  Certainly, setting ^D cant cause 
any significant time loss.  Most likely, you should try setting the 
interval (- BPEND BPORG) as large as possible, in order to reduce the 
array-relocation incidence; this would be similar to allocating as much 
FLONUM space as possible when you have a fastly-flonum-consing problem.  
    But also, you may merely be victim of the gross time-overhead for 
ARRAY creation.  In NIL, the VECTOR will most likely solve this problem 
since their management will be essentially the same as cons cells (please,
no "black" humor).  Could you try your application with HUNKs?  How did 
you estimate the likely time the problem should take (since you said the 
array solution seemed to take 3 times longer)?

Date: 20 SEP 1978 0252-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: ARRAY relocations in MACLISP
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

    Date: 18 SEP 1978 1927-EDT
    From: JONL at MIT-MC (Jon L White)
    Subject: ARRAY relocations in MACLISP
    To: MOON at MIT-MC
    CC: (BUG LISP) at MIT-MC
    
    BPORG and BPEND delineate the free binary program space, with programs
    eating up from below, and arrays from above.  There should be no need for
    a user to try to control the array relocations, since the space between
    BPORG and the top of arrays is treated like a general heap - when there 
    isn't enuf space between bporg and bpend, the first arrays are shuffled
    upwards to close out any already-dead space; then if there still isn't
    enough room, a GC is done to see if any more arrays died; finally, if 
    there still isn't enough room, more address space is eaten from the 
    time-sharing system allocator (ocasionally leading to "NO CORE? - mumble"
    messages).
       However, if you are building up a set of mumbles - arrays and programs - 
    and know in advance that about, say, 32K is needed to hold them, then do
    two things first
      1)   setq *NORET to non-null, to prevent returning address space,
      2)   (GETSP 33000.) or some such suitable number.
    I think this is what you want.  Probably after building up the system,
    you should reset *NORET to null.

Presumably by *NORET you mean NORET?

In fact, the observed symptom is that if I don't do the GETSP in advance,
it eventually gets into a loop doing nothing but GC: ARRAY RELOCATION
(if ^D is turned on).  So I did some GETSP's and NORET's.  Now it seems
that the program is taking about 3 times as long to run as it should,
the theory being that it is spending all of its time shuffling arrays,
although it might be that turning on ^D slows things down a lot.  I was
using sstatus gcwho and most of the time there was no gc message in the
who-line but I suspect that is not on for array relocation blt'ing that
does not involve a wholine.

It seems to me that it would be as reasonable for the user to control
allocation of array space as for any of the other spaces.

Anyway, I plan to stop using arrays for this application since they
obviously aren't suitable, so I don't have any particularly loud complaint.
However, it does seem that array support could be a lot better.

Date: 19 SEP 1978 0630-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

1) THRALL:  SETZB B,(P)
   saves a lot of compiler output
2) CTCALL:  HRLI A,CATSPC\CATALL\CATCOM
	    PUSH P,B
	    JRST CATPS1+1
   this has been a bug.  would someone pls patch it
   the code for CATBAR and UNWINC could also join with CATPS1+1
     (call it, say, CATPS2) if UNWINC is fixed as
   UNWINC:  MOVEI A,1(T)
	    HRLI A,CATSPC\CATUWP\CATCOM
	    JRST CTCALL+1
3) There may be a bug related to UNWINE, but I'll have to check
   this out when I'm more fully awake.

Date: 18 SEP 1978 1927-EDT
From: JONL at MIT-MC (Jon L White)
Subject: ARRAY relocations in MACLISP
To: MOON at MIT-MC
CC: (BUG LISP) at MIT-MC

BPORG and BPEND delineate the free binary program space, with programs
eating up from below, and arrays from above.  There should be no need for
a user to try to control the array relocations, since the space between
BPORG and the top of arrays is treated like a general heap - when there 
isn't enuf space between bporg and bpend, the first arrays are shuffled
upwards to close out any already-dead space; then if there still isn't
enough room, a GC is done to see if any more arrays died; finally, if 
there still isn't enough room, more address space is eaten from the 
time-sharing system allocator (ocasionally leading to "NO CORE? - mumble"
messages).
   However, if you are building up a set of mumbles - arrays and programs - 
and know in advance that about, say, 32K is needed to hold them, then do
two things first
  1)   setq *NORET to non-null, to prevent returning address space,
  2)   (GETSP 33000.) or some such suitable number.
I think this is what you want.  Probably after building up the system,
you should reset *NORET to null.

Date: 18 SEP 1978 1909-EDT
From: JONL at MIT-MC (Jon L White)
Subject: initial switch settings in COMPLR
To: DLW at MIT-MC
CC: (BUG LISP) at MIT-MC

These initial settings were described in the May 25 LISP RECENT,
but it certainly would be useful to have them restated in the
context of this one.  Will do asap.

Date: 18 SEP 1978 1403-EDT
From: BEE at MIT-MC (Bruce E. Edwards)
To: (BUG LISP) at MIT-MC

By the way. Seems that almost everyone (except LH/| (whoever he is, never saw
anyone with a vertical bar in his name before)) wants to cons an array, and
get an array pointer to it. maybe there should be a function that given a number
of words, allocates a fixnum array, but in random space, so that the GC doesn't
move it around. This is also the right thing for the vision hackers and the
people who hack AI tv's. It is approximately what GLS does in the TVLISP package
also. This seems to be a reasonable feature. (Maybe an extension to LH| so that
its args are:
(LH/| <type of space> <type of array to cons> dim1 dim2 ..... dimn)

Date: 18 SEP 1978 1403-EDT
From: BEE at MIT-MC (Bruce E. Edwards)
To: (BUG LISP) at MIT-MC

By the way. Seems that almost everyone (except LH/| (whoever he is, never saw
anyone with a vertical bar in his name before)) wants to cons an array, and
get an array pointer to it. maybe there should be a function that given a number
of words, allocates a fixnum array, but in random space, so that the GC doesn't
move it around. This is also the right thing for the vision hackers and the
people who hack AI tv's. It is approximately what GLS does in the TVLISP package
also. This seems to be a reasonable feature. (Maybe an extension to LH| so that
its args are:
(LH/| <type of space> <type of array to cons> dim1 dim2 ..... dimn)

Date: 18 SEP 1978 1056-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC

TRACE has been modified on all machines to autoload the function first
if there is an autoload property and the function has not been previously
defined.

Date: 18 SEP 1978 0912-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC

A change that I requested some time ago: One should be able to TRACE a 
function, e.g. SORT which is not currently in core, but which has an 
AUTOLOAD property, and have the TRACE succeed by its loading in the 
appropriate file for you.  (MACSYMA's TRACE package has done this for 
some time now.)

HIC@MIT-AI (Sent by HIC0@MIT-AI) 09/17/78 16:52:30
To: KENT at MIT-AI, (BUG LISP) at MIT-AI
CC: TLP at MIT-AI
The problem that you experienced with the new LISP has been fixed.
The reason that KENT;G (INIT) was losing was that one of the files
on the TLp directory (DRAWL) was written incorrectly.  It was susing
the OLDIO channel number conventions which, due to a change in
the most recent LISP, caused the tty input channel to get opened as
a tty output channel!  Due to the seriousness of this matter, I fixed the
appropriate functions in TLP;DRAWL > and recompiled the source.
KENT, your init file now uns to completion.

--howard


KENT@MIT-AI 09/17/78 15:05:38
To: (BUG LISP) at MIT-AI
the new lisp with kent;g as the init file loses with spewing control at signs!!!

DLW@MIT-AI 09/17/78 15:05:28
To: (BUG LISP) at MIT-AI
The list of COMPLR options in the new LISP RECENT is very useful,
but it would be even more useful if it told you what the default
value was for each option.  Maybe you can just edit this into
the existing LISP RECENT.


Date: 16 SEP 1978 1952-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, MOON at MIT-MC, RWK at MIT-MC

In the next LISP, || will print as such !  The LISP should
be out tommorrow.  GRINDEF has been changed to return *.

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

As I've often suggested before, the obvious way for things like GRINDEF and
the like to return "nothing" is for them to either return some token which
the top-level loop recognizes and doesn't print at all, or *.  It is a complete
and total screw for || to not print when you explicitly ask it to print.

How about making the top-level read-eval-print loop not print the returned
value if it is EQ to the value of TOP-LEVEL-NO-PRINT or somesuch?  This
allows people who actually might want to see || at top level (like if it
were the value of some variable) to set it to (NCONS NIL), and things
like GRINDEF should be changed to return this "magical" value.  Initially,
it would be initialized to ||, but after a time it could be changed to
be ANYTHING so long as it isn't interned.  Maybe an uninterned atom "NOPRINT"
would be a good choice.

GLS@MIT-MC 09/16/78 15:57:18
To: MOON at MIT-AI, (BUG LISP) at MIT-AI


    MOON@MIT-AI 09/16/78 03:57:16
    To: (BUG LISP) at MIT-AI
    The null pname doesn't print as ||.  This is screwing me to the wall,
    since I have a data file which somestimes contains null pnames.  Please fix!
Sigh, sigh, sigh.  Maybe in NIL the pname printing convention should
be consistent.  On the other hand, can we provide some other neat
way to cause GRINDEF and like utilities to be able to return "nothing"?
Maybe some kind of system-supplied CATCH in the top-level loop
could be provided to throw to in order to avoid the print (this facility
to be used only by top-level utilities of that kind, by convention)?




MOON@MIT-AI 09/16/78 04:14:15
To: (BUG LISP) at MIT-AI
In Bolio I am hacking large numbers of small
arrays and have some slight problems.  The manual doesn't mention any way to find out
how much array space is occupied.  Presumably this is the difference between bpend and
some variable that I don't know about.  Is there a way to find this out?  I suspect I
want to do a getsp of some number similar to this to cut down the amount of array relocation
gc's.

MOON@MIT-AI 09/16/78 03:57:16
To: (BUG LISP) at MIT-AI
The null pname doesn't print as ||.  This is screwing me to the wall,
since I have a data file which somestimes contains null pnames.  Please fix!

Date: 15 SEP 1978 1435-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Movement of LISP related files from COMMON;
To: HIC at MIT-MC, JPG at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

There should be no new LISP-related files on this directory since our
discussion of the problem (of where to put LISP-auxilliary files) last
February.  In addition, there should never have been source files there.
So regarding HIC's proposed changes, I would caution
1) Get all FASL files for autoload stuff on LISP directory
2) Dont move all sources to COMLAP, since some are written in MIDAS and
   have been on the L directory.  
3) Leave the dozen or so links on COMMON that we agreed upon last Feb.
4) Continue to encourage user-supplied packages to be put on LIBDOC and
   LIBLSP, and dont hassle users who do so.  Any such files we deem 
   important enough to have initial autoload properties can either be
   linked from the LISP directory, or moved over as with the other
   system-supplied files.

Date: 15 SEP 1978 0850-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC, (BUG LISP) at MIT-MC
CC: RWK at MIT-MC

I plan to do the following:
A) Move all LISP related files from COMMON; to LISP; and the sources
   will be on COMLAP;.

B) Leave links to all these files on COMMON; for the
   currently running LISPs.

C) Change the next LISP (not the one being released today, though)
   to look on LISP;, not on COMMON;.

D) Tell people about the change, and after a few weeks phase
   out the links completely.

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

Links for LISP files on COMMON; seem to be proliferating. 
Since the COMMON; directory is often full and directories such as 
LIBLSP; exist, isn't it time to cut out this nonsense?  It is clear 
who is being hurt by this, but who is being helped?

Date: 14 SEP 1978 0937-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject:  TERPRI vs. STATUS TERPRI
To: JPG at MIT-MC, (BUG LISP) at MIT-MC

STATUS TERPRI affects one particular file-object only, whereas TERPRI
variable affects all file-objects.  They are not otherwise related.

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

As far as I remember (SSTATUS TERPRI foo) is supposed to be the same 
as (SETQ TERPRI (NOT foo)).  (Unfortunately, there is no clear note to 
this effect in .INFO.;LISP ARCHIV .)  I was considering finally phasing 
out the former from MACSYMA files in favor of the latter as JONL long 
ago recommended.  However, it would be reasonable and reassuring 
(if my assumption above is true) if doing a (SSTATUS TERPRI foo) 
had some effect on the value of TERPRI, which it doesn't.  (Expecting 
resetting TERPRI to have some effect on (STATUS TERPRI) I would think 
is not to be expected.)  Can someone clarify just what the story here is?
Thanks.

Date: 13 SEP 1978 0428-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
Subject: _FASL_ and _UNFA_ 
To: JONL at MIT-MC, MOON at MIT-MC, RWK at MIT-MC, (BUG LISP) at MIT-MC
CC: (BUG TECO) at MIT-MC

Since MOON mentions the reapers in people's heads, for people names 
like .FASL. OUTPUT and .UNFA. OUTPUT would be better than _FASL_ OUTPUT 
and _UNFA_ OUTPUT as every now and then people list their directories 
from the top, and they are perhaps more likely to flush these files 
when they see them.  In fact, I have long wished TECO used 
.TECO. OUTPUT rather than _TECO_ OUTPUT for this reason.  (Does anyone 
out there still generate such files besides me?)

Date: 12 SEP 1978 1306-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: _FASL_ and _UNFA_
To: JONL at MIT-MC, MOON at MIT-MC, JPG at MIT-MC
CC: (BUG LISP) at MIT-MC, RWK at MIT-MC


The automatic reapers, including those in people's heads, could be made
to know about these FN2's, but what does it buy?  Nothing as far as I can see;
the only way to manipulate the temporary output file names is by using translations
and it seems clear to me that anyone doing that and needing the name of the
file being compiled in there is wedged.  In any case this would be better done
by giving JCL to the compiler.

It seems to me the real problem was that the name of the UNFASL file used to be the
same as its final name so that your UNFASL file could get clobbered by an aborted
computation.  But calling it _UNFA_ OUTPUT should be a reasonable fix for that.

Could you ask whoever it was who wanted this feature to tell me what it does for them?

Date: 12 SEP 1978 1232-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: Local type info for compilation
To: JONL at MIT-MC, KMP at MIT-MC
CC: (BUG LISP) at MIT-MC, LISPM at MIT-MC


    Date: 12 SEP 1978 0523-EDT
    From: JONL at MIT-MC (Jon L White)
    Subject: Local type info for compilation
    To: KMP at MIT-MC
    CC: (BUG LISP) at MIT-MC, LISPM at MIT-MC

    (+ <frob>)  is preferable to (+ <frob> 0) for announcing that <frob>
    will be of type FIXNUM (similarly for +$ and FLONUM), and most likely
    that will do whereever you wanted a local type specification.
       If there is going to be some other key word, I would suggest something
    without the word "force" in it, since the action here is not a type
    coercion to one type or other, but rather merely the "telling" of 
    information to some processor (compiler, data checker, interpreter).

(LOCAL-DECLARE (FIXNUM) <frob>), as I think someone mentioned, would be 
ok with me. I object strongly to saying (+ <frob>) because that relies on
you telling me that the compiler will make a certain assumption at
that point. Since you maintain the compiler this is reasonable, but is
not what I think of as classically 'clean' - or even close. This type of
thing wants a builtin primitive in MacLISP that could be a compiler macro
for all I care doing exactly that - Just that I object highly to handling
its definition at the user-level. 

--kmp

Date: 12 SEP 1978 0720-EDT
From: JONL at MIT-MC (Jon L White)
Subject: _FASL_ and _UNFA_
To: MOON at MIT-MC, JPG at MIT-MC
CC: (BUG LISP) at MIT-MC, RWK at MIT-MC

Actually, it was a collection of several other randoms who insisted
on having the temporary name for the fasl and unfasl files incorporate
some part of the name of the file being compiled, and JPG entered the
picture by noting that the temporary name (before CLOSEing) and the
final name should not be the same.  Comment still stands as to why
the automatic reapers (and logout protocols) can know about files with
.FNAM2 of _FASL_ and _UNFA_

Date: 12 SEP 1978 0714-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, RWK at MIT-MC


Yes, there was some special reason why these are used instead on merely
.LISP. OUTPUT  or .FASL. OUTPUT    Mostly, JPG complained about the
problems with the automatic generation programs for the various macsyma
directories.  Why cant the automatic reaping programs know about any
file whose .FNAM2  is among _FASL_ or _UNFA_ ?  These kinds of file
can only occur if there is an abortion during compilation.

Date: 12 SEP 1978 0523-EDT
From: JONL at MIT-MC (Jon L White)
Subject: Local type info for compilation
To: KMP at MIT-MC
CC: (BUG LISP) at MIT-MC, LISPM at MIT-MC

(+ <frob>)  is preferable to (+ <frob> 0) for announcing that <frob>
will be of type FIXNUM (similarly for +$ and FLONUM), and most likely
that will do whereever you wanted a local type specification.
   If there is going to be some other key word, I would suggest something
without the word "force" in it, since the action here is not a type
coercion to one type or other, but rather merely the "telling" of information
to some processor (compiler, data checker, interpreter).

DLW@MIT-AI 09/10/78 15:54:22
To: (BUG LISP) at MIT-AI
The previous message was supposed to go to BUG LISPM, but it looks
like I didn't manage to type the trailing "M".  Sorry, please ignore.


DLW@MIT-AI 09/10/78 15:50:53
To: (BUG LISP) at MIT-AI
I have gone through all of the files in the LMDOC; LISPM tags table
and changed the uses of (= 0 1_24.) to uses of (STATUS FEATURE LISPM).
Since the reader will be changed relatively soon to do the right thing
for 1_24., no new programs should depend on the equality of 0 and 1_24.
(not that I mean to suggest that it was a wonderful thing for old
programs, either...)  The official way to tell whether you are executing
on the Lisp Machine is (STATUS FEATURE LISPM).

Date: 9 SEP 1978 2328-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

1.0E reads as 1.0E+10
1.E  reads as 10.0
1.1E reads as 1.1E+11
1.2E reads as 1.2E+12

If these would generate errors I would be happy. In any case, it doesn't
seem consistent enuf to me unless I am missing something. Bugp?

--kmp

Date: 9 SEP 1978 0232-EDT
From: Kle at MIT-MC (Edward Jay Kleban)
Sent-by: JIS at MIT-MC
To: (BUG LISP) at MIT-MC

base roman doesnt hack bignums.  foo.  --54

Date: 8 SEP 1978 2137-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: Pooooor reader!
To: (BUG LISP) at MIT-MC

(sstatus + t) (setq ibase 16.)
'-eof- 
gives ";ILLEGAL OBJECT SOMEWHERE OR OTHER - READ"
instead of /-EOF- .  By the way, '/-EOF- prints without slashifying the
leading -.

Date: 6 SEP 1978 0300-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: LAST
To: HIC at MIT-MC, RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, CWH at MIT-MC


    Date: 5 SEP 1978 2340-EDT
    From: HIC at MIT-MC (Howard I. Cannon)
    Subject: LAST
    To: RWK at MIT-MC
    CC: (BUG LISP) at MIT-MC, CWH at MIT-MC

        From: RWK at MIT-MC (Robert W. Kerns)
        Subject: LAST
        Your comment would be almost valid, except that LAST obviously isn't
        just CDR'ing down the list checking for NIL.  It is doing a LIST-P
        on the CDR instead.
    ------
    You are wrong.  It is doing a NIL check (look at the damn code before
    flaming, please).
    ------
Twas faked out by it's coincidentally working since the CDR of an atom is
its (usually null) plist.  Another example of randomness that this can cause!

      After all, this isn't very expensive, a MOVEI, a LSH,
        and a SKIPL will do it.  I would muchly appreciate it if APPEND would
        be changed to do likewise.
    ------
    Compared to a JUMPN, a MOVEI, LSH, and SKIPL are quite expensive.
    ------
Aw c'mon.  Yes, it doubles the loop size.  It still probably all runs in the
cache (on KL's).  I still wouldn't call it expensive for an interpreter
      (There should also be a TYPEP before the loop,
        so (LAST 3.3) wouldn't die).
    ------
    I had this idea also, and I might implement it.
    ------
      After all, the interpreter isn't supposed to
        be fast, it's supposed to be suportive and not die on easy mistakes.
    ------
    This is true...on the other hand, one does not want to make it unbearably slow.
    Perhaps a *RSET check is in order...more thought is necessary.
I would go along with this....*RSET is for things like that.
    --howard

Date: 5 SEP 1978 2340-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: LAST
To: RWK at MIT-MC
CC: (BUG LISP) at MIT-MC, CWH at MIT-MC

    From: RWK at MIT-MC (Robert W. Kerns)
    Subject: LAST
    Your comment would be almost valid, except that LAST obviously isn't
    just CDR'ing down the list checking for NIL.  It is doing a LIST-P
    on the CDR instead.
------
You are wrong.  It is doing a NIL check (look at the damn code before
flaming, please).
------
  After all, this isn't very expensive, a MOVEI, a LSH,
    and a SKIPL will do it.  I would muchly appreciate it if APPEND would
    be changed to do likewise.
------
Compared to a JUMPN, a MOVEI, LSH, and SKIPL are quite expensive.
------
  (There should also be a TYPEP before the loop,
    so (LAST 3.3) wouldn't die).
------
I had this idea also, and I might implement it.
------
  After all, the interpreter isn't supposed to
    be fast, it's supposed to be suportive and not die on easy mistakes.
------
This is true...on the other hand, one does not want to make it unbearably slow.
Perhaps a *RSET check is in order...more thought is necessary.

--howard

Date: 5 SEP 1978 1010-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: Errors, yet again
To: (BUG LISP) at MIT-MC
CC: NIL at MIT-MC

The system should not limit the classes of errors possible to the ones that
the system generates (I.e. Wrong-type-argument, wrong-number-args,
unbound-variable, undefined-function, etc.).  There should be a way for the
user to signal and provide handlers for errors in exactly the same manner as
the system does.

For example right now in MACLISP, the ERROR function's third argument
could be a symbol which is considered to be the error-class, and it's value
to be the handler, and the value returned to be the value returned from the
handler, etc.  I think that this would be a useful and compatible change
(if the arg was a fixnum it would be as before).  I don't think this is the
final word on how to win though....

GSB@MIT-ML 09/05/78 06:20:07 Re: xl & (load nil)
To: (BUG LISP) at MIT-ML
WHat the hell is NIL meaning defaultf for if i can't use it?


Date: 5 SEP 1978 0420-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: LAST
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC, CWH at MIT-MC

Your comment would be almost valid, except that LAST obviously isn't
just CDR'ing down the list checking for NIL.  It is doing a LIST-P
on the CDR instead.  After all, this isn't very expensive, a MOVEI, a LSH,
and a SKIPL will do it.  I would muchly appreciate it if APPEND would
be changed to do likewise.  (There should also be a TYPEP before the loop,
so (LAST 3.3) wouldn't die).  After all, the interpreter isn't supposed to
be fast, it's supposed to be suportive and not die on easy mistakes.

Date: 4 SEP 1978 1326-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

; BUT DIDN'T SUCCEED - SYMBOL SPACE NOW 7680 WORDSSYMBOL BLOCKSTORAGE CAPACITY EXCEEDED BEYOND RECUPERATION

Shouldn't there be a (CURSORPOS 'A) or something before the 'SYMBOL BLOCKST...'
message? 10Q
-kmp

Date: 3 SEP 1978 0836-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, CWH at MIT-AI


    CWH@MIT-AI (Sent by GJS@MIT-AI) 09/02/78 17:04:52
    The behavior of LAST seems rather obscure for arguments it is not used to
    getting:
------
It isn't obscure, it is quite understandable.
------
    (LAST '(A B . C)) --> C

    which is essentially useless.  I think it should return the last cons in the
    structure.
------
This is an old suggestion, but the problem is that it is much easier to CDR down
the list and look for NIL then it is to check at each step whether you have
a CONS, etc....perhaps an initial arg check is in order (at least you better
have handed the thing a CONS).  But as for checking every step along the way,
my suggestion is that you write LISP code to do it the way you want to.

--howard

CWH@MIT-AI (Sent by GJS@MIT-AI) 09/02/78 17:04:52
To: (BUG LISP) at MIT-AI
CC: CWH at MIT-MC
The behavior of LAST seems rather obscure for arguments it is not used to
getting:

(LAST '(A B . C)) --> C

which is essentially useless.  I think it should return the last cons in the
structure.

(LAST 'A) --> A
(LAST 3) --> ***MISSING-ARG***   (meaningless error message)
(LAST 3.3) --> breaks lisp
(LAST <bignum>) --> <list of fixnums>

I think the right thing to do is to have the last four cases be errors and
to print the fact that LAST was called with a ridiculous argument and print
the argument.


Date: 31 Aug 1978 2315-PDT
From: GLS at SU-AI (Guy Steele)
Subject: SAIL NEWIO and SHOWIT   
To:   BUG-LISP at MIT-MC    

The SHOWIT uuo should be applied to the UREAD channel
whenever UREAD is done.  It should be applied to
the UWRITE channel by UWRITE iff no UREAD channel
is active.



Date: 1 SEP 1978 0136-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GJS at MIT-AI


    GJS@MIT-AI 08/21/78 15:23:33
    To: (BUG LISP) at MIT-AI
    A) Setup UREAD file
    B) Cause GC-OVERFLOW
    C) Cause Read macro context error
    D) Watch infile go away
------
The bug was apparently related to overrubout, and not directly to the
read macro context error.  What would happen is that overrubout on the tty
acted like an eof, and so lisp decided to "pop" the input stack to try to
read from the previous input source.  Well, this is fine, except this should
only happen when ^Q is T (namely, we are reading from the input source
that INFILE/INSTACK control).  I have made this change in the source,
but have not patched it in as I hope to have a new LISP out shortly.

Date: 31 AUG 1978 0706-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: GLS at MIT-MC, RWK at MIT-MC, KGK at MIT-MC, (BUG LISP) at MIT-MC


    Date: 31 AUG 1978 0549-EDT
    From: GLS at MIT-MC (Guy L. Steele, Jr.)
    To: RWK at MIT-MC, KGK at MIT-MC, (BUG LISP) at MIT-MC


        Date: 29 AUG 1978 2034-EDT
        From: RWK,KGK at MIT-MC
        Sent-by: RWK at MIT-MC
        To: (BUG LISP) at MIT-MC
        CC: RWK at MIT-MC, KGK at MIT-MC

        (SETQ POLY-1 '(NIL NIL 5 . 6))
        (SETQ POLY-2 '(nil nil nil nil))
        (APPEND POLY-1 POLY-2)
        MPV;APP1>>HLRZ A,(AR2A)

        Please fix to either work or give an error.
    PDP-10 MacLISP simply does not pretend to check for atoms other than
    NIL (sorry, ()) at the end of a list, because the atom test
    is too expensive in important inner loops like APPEND.
Mumble.  I would agree with that philosophy in compiled code.  However, it
makes it VERY difficult to do tutoring as to what a bug was, when the
entire LISP dies due to the user bug.  The normal mode of operation is that
the interpreter is used for interactive trials and debugging and similar
things.  For those purposes, you want to detect errors.  Otherwise the
code would be compiled!

Date: 31 AUG 1978 0549-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: RWK at MIT-MC, KGK at MIT-MC, (BUG LISP) at MIT-MC


    Date: 29 AUG 1978 2034-EDT
    From: RWK,KGK at MIT-MC
    Sent-by: RWK at MIT-MC
    To: (BUG LISP) at MIT-MC
    CC: RWK at MIT-MC, KGK at MIT-MC

    (SETQ POLY-1 '(NIL NIL 5 . 6))
    (SETQ POLY-2 '(nil nil nil nil))
    (APPEND POLY-1 POLY-2)
    MPV;APP1>>HLRZ A,(AR2A)

    Please fix to either work or give an error.
PDP-10 MacLISP simply does not pretend to check for atoms other than
NIL (sorry, ()) at the end of a list, because the atom test
is too expensive in important inner loops like APPEND.

Date: 31 AUG 1978 0342-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JONL at MIT-MC, (BUG LISP) at MIT-MC

Fasload was checking for redefinitions in correctly.  This has
been fixed in thr source.

Date: 31 AUG 1978 0324-EDT
From: HIC at MIT-MC (Howard I. Cannon)
Subject: PROGV
To: JONL at MIT-MC
CC: (BUG LISP) at MIT-MC

I'm not completely convinced as to the advisability of making
(PROGV '(FOO BAR) '(A) ...)
bind FOO to A and BAR to UNBOUND, but it has been done...

Date: 31 AUG 1978 0310-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: GLS at MIT-MC, JONL at MIT-MC, MOON at MIT-MC, GLS at SU-AI
CC: (BUG LISP) at MIT-MC

MOON has asked me to make OPEN barf if there is an illegal keyword
in the list of keywords.  The comments in the code (I also believe
that I have discussed this with GLS before) indicate that the reason
an illegal keyword does not hurt is that it might be "unimplemented in this
version of LISP".  Well, furthur thought on the matter indicates to me that
if the option you request is not implemented in this version of LISP, there
is a good chance that YOU REALLY WANT TO KNOW ABOUT IT!  It seems to me that
having the error check will save more heartache then it will cause, and
I teherfore am going to install it.

--howard

Date: 31 AUG 1978 0305-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, MOON at MIT-AI
CC: RLB at MIT-MC, MOON at MIT-MC

LIBLSP;APROPOS > has been completely rewritten and reinstalled.

MOON@MIT-AI 08/30/78 04:16:52
To: (BUG LISP) at MIT-AI
CC: rlb at MIT-MC, moon at MIT-MC
I tried to use LIBLSP;APROPO for the first time today, and eventually
discovered that it had a gross bug in it.  My offering of an improved
version is in AI:LIBDOC;APROPO MOON, fasl file on my directory.
Someone should check it over and install it.


Date: 29 AUG 1978 2034-EDT
From: RWK,KGK at MIT-MC
Sent-by: RWK at MIT-MC
To: (BUG LISP) at MIT-MC
CC: RWK at MIT-MC, KGK at MIT-MC

(SETQ POLY-1 '(NIL NIL 5 . 6))
(SETQ POLY-2 '(nil nil nil nil))
(APPEND POLY-1 POLY-2)
MPV;APP1>>HLRZ A,(AR2A)

Please fix to either work or give an error.

Date: 29 AUG 1978 0918-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: (BUG LISP) at MIT-MC, GSB at MIT-ML


    GSB@MIT-ML 08/22/78 19:23:25
    To: (BUG LISP) at MIT-ML
    Attempting to purcopy a hunk4 (others maybe?) gets an mpv in current lisp,
    and a purpg in xl.
------
PURCOPY'ing of hunks was **soooooooo** completely broken....

It is fixed in the source, and will be fixed in XL the next time I release
one.

Date: 29 AUG 1978 0832-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RWK at MIT-MC, (BUG LISP) at MIT-MC


    Date: 24 AUG 1978 0700-EDT
    From: RWK at MIT-MC (Robert W. Kerns)
    To: (BUG LISP) at MIT-MC

    (STATUS TTY TYO) certainly ought to work OK.  There is no reason to restrict
    it to input files, since ITS doesn't care.  If you're hacking the CADDR,
    many of those bits effect OUTPUT as well, and it's stupid and wrong to have
    to hack the TTYCONS of the file to read them.
------
This has been fixed in the source and patched on MC.

Date: 28 Aug 1978 2204-PDT
From: GLS at SU-AI (Guy Steele)
Subject: SAIL NLISP characters   
To:   BUG-LISP at MIT-MC    

SAIL NLISP seems to read and-sign (^D) as beta (^C),
and not-sign (^E) as and-sign, at least from files.



GLS@MIT-MC 08/26/78 19:02:29
To: SJOBRG at MIT-AI, (BUG LISP) at MIT-AI

Congratulations!  You are the 500th person to be screwed by this bug.
The problem occurs only when reading from the TTY as opposed to a file.
The problem is that while TYIPEEK does not gobble the character
from the "main read stream", it does swallow it in such a way
that it foils the heuristic end-of-S-expression guesser that is used
by the rubout processor to decide when an S-expression has finished.

Suggestion to HIC: maybe the rubout processir should be changed so that
*leading* spaces (as opposed to embedded ones) cause a force-feed?



GSB@MIT-ML 08/26/78 00:08:11 Re: length
To: (BUG LISP) at MIT-ML
I am impressed!  LENGTH detects circular lists, and errors out saying
'NON-LIST - LENGTH'.  Unfortunately, errprint first tries to print the
offending datum...


Date: 25 AUG 1978 1615-EDT
From: KMP at MIT-MC (Kent M. Pitman)
Subject: PRIN1 value not having anything to do with PRINT'ing
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, RLB at MIT-MC, RWK at MIT-MC

I do not consider this an acceptable reply:

    Date: 25 AUG 1978 0932-EDT
    From: HIC at MIT-MC (Howard I. Cannon)
    To: KMP at MIT-MC, (BUG LISP) at MIT-MC
    
    
    I guess the feeling is that if you are doing an explicit PRINT,
    then you could just as well do an explicit MY-OWN-PRINT.
    What you really want to use are SFA's...
    
    
[1] SFA's are not yet available.
[2] I should not have to write my own printer. This is
    exactly what the PRIN1 handle is for. The idea is that I
    have whole slews of stuff written already. I want to
    patch your PRIN1 so it does what I want. I will not go
    and edit all the code changing all PRINT's to MY-OWN-PRINT.


Please re-install PRIN1 to work on PRINT'd stuff. Thanx --kmp

Date: 25 AUG 1978 0932-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: KMP at MIT-MC, (BUG LISP) at MIT-MC


I guess the feeling is that if you are doing an explicit PRINT,
then you could just as well do an explicit MY-OWN-PRINT.
What you really want to use are SFA's...


SJOBRG@MIT-AI 08/25/78 09:08:55
To: (BUG LISP) at MIT-AI, SJOBRG at MIT-AI
Consider the following simple program:

        (defun tyitest nil
	       (print (tyipeek))
	       (print (read))
	       (tyi))

Now, (tyipeek) followed by the character sequence "777 " for example,
prints
	67
	777
	40
as it should.  Also, (tyipeek) followed by " 777 " prints
	40
	777
	40
as it should.  However, (tyipeek) followd by "7 " prints only
	40
and waits for more input.  If one types "7 " at this point, then
the remainder 
	7
	40
is printed.

Question:  Am I wrong in assuming that tyipeek does not gobble the
next character when reading?  Why doesn't it work with a single
character input?

What I want is to write a function which, after a prompt, waits either
for a space (to indicate use default), or an arbitrary fixnum followed
by a space (to use that fixnum).  Things work fine for all but single
digit fixnums, in which case I get the above problem.  It happens the
same in compiled and interpreted code.


Date: 25 AUG 1978 0627-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

I've explained to TEF about NREVERSE

TEF@MIT-AI 08/25/78 04:36:23
To: (BUG LISP) at MIT-AI
There is a bug in NREVERSE  (Maybe you already knew this?)

(SETQ FOO '(A B C D))
(a b c d)
(NREVERSE FOO)		;THIS WORKS OK
(d c b a)
FOO			;...BUT SIDE EFFECT IS BAD
(a)


Date: 24 AUG 1978 2137-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

The feature of SETQ'ing PRIN1 to a function name to be used in place of
PRIN1 in PRINT is losing utterly. The new function (I call it PRIN2) is
getting called only when the system tries to print something.
So that you get...

(SETQ PRIN1 'PRIN2)
PRIN2
(TRACE PRIN2)
(1. ENTER PRIN2 ((PRIN2))) (PRIN2)
(1. EXIT PRIN2 T)
(PRINT '(FOO))
(FOO)
(1. ENTER PRIN2 (T)) T
(1. EXIT PRIN2 T)

etc... Note that PRIN2 was called in printing the "T" message returned by
PRINT, but not in getting the (FOO) onto the tty. (My PRIN2 will print
|| as || instead of as   (nothing)...
(PRIN2 '||) prints ||
but (PRINT '(A || B)) prints (A   B) while PRIN1 is bound to PRIN2 ...?
--kmp

Date: 24 AUG 1978 0837-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC

I notice that (CHARPOS T) does not return the "real" position if ^W is T (i.e.
suppose you typed ^W at the left margin.  (CHARPOS) says, correctly, that
your hpos is 2.  Then type a RETURN, whose echoing puts you at hpos=0.
(CHARPOS T) still thinks it is 2).  Is this a feature or a bug?

Date: 24 AUG 1978 0700-EDT
From: RWK at MIT-MC (Robert W. Kerns)
To: (BUG LISP) at MIT-MC

(STATUS TTY TYO) certainly ought to work OK.  There is no reason to restrict
it to input files, since ITS doesn't care.  If you're hacking the CADDR,
many of those bits effect OUTPUT as well, and it's stupid and wrong to have
to hack the TTYCONS of the file to read them.

Date: 24 AUG 1978 0457-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: GSB at MIT-MC, (BUG LISP) at MIT-MC


    Date: 24 AUG 1978 0448-EDT
    From: GSB at MIT-MC (Glenn S. Burke)
    To: (BUG LISP) at MIT-MC

    GTNPS3 shouldn't bash TT, it isn't nice.
---
FIXED in the source, I'll patch it if you like.

Date: 24 AUG 1978 0448-EDT
From: GSB at MIT-MC (Glenn S. Burke)
To: (BUG LISP) at MIT-MC

GTNPS3 shouldn't bash TT, it isn't nice.

Date: 24 AUG 1978 0054-EDT
From: KMP at MIT-MC (Kent M. Pitman)
To: (BUG LISP) at MIT-MC

TEACH's save feature loses badly. Here is an example of text from it:

(SETQ  ')

Remember lisp doesn't print || as ||. We all know PRINC should print 
ascii 0 as nothing and PRIN1 it as || but that's not how it is. Hence,
(PRINT '(SETQ || '||)) loses utterly!
Please special-case this part. Every time someone does an UNSAVE i have to
edit the SAVE file
thanx --kmp

Date: 23 AUG 1978 2231-EDT
From: JONL at MIT-MC (Jon L White)
To: (BUG LISP) at MIT-MC

FASLOAD gives a spurious error msg about "CDR" or whatver being
redefined as a FOO-SUBR  when you fasload in the FASL file for
(DEFUN (CDR FOO-EXPR FOO-SUBR) (X) (MUMBLE X))
There is no redefinition involved since a FOO-SUBR property is being
put.

Date: 23 AUG 1978 1823-EDT
From: JONL at MIT-MC (Jon L White)
Subject: PROGV
To: NIL at MIT-MC
CC: (BUG LISP) at MIT-MC

Suggest: Let "(PROGV <list-of-vars> <list-of-vals> . <body>)"  be
acceptable when <list-of-vars> is longer than <list-of-vals>, and the
non-paired variables would be "bound" to the internal unbound marker.
In NIL, we no doubt want to copy the LISPM idea that puts a "NOVAL" 
kind of marker which the interpreter will trap as error, and which some
microcoded machines may trap in compiled code also.
  This change to PROGV will facilitate writing the NIL interpreter,
especially w.r.t. the sequential nature of initialization code for
non-supplied &optional arguments.

Date: 23 AUG 1978 1741-EDT
From: JONL at MIT-MC (Jon L White)
To: HIC at MIT-MC
CC: (BUG LISP) at MIT-MC

Isn't it true that at one time we decided to put *THROW and *CATCH into
MACLISP, which would be as on the LISPM, and then someday, phase out the
old definitions of CATCH and THROW, to be turned into the same as the * 
versions?  I still dont see any * version in the latest XL.

GSB@MIT-ML 08/22/78 19:23:25
To: (BUG LISP) at MIT-ML
Attempting to purcopy a hunk4 (others maybe?) gets an mpv in current lisp,
and a purpg in xl.


JONL@MIT-AI 08/22/78 14:16:18 Re: DEFUN&
To: ALAN at MIT-AI
CC: NIL at MIT-AI, (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI

I like the DEFUN& stuff I saw on your direectory - would you like to make
it available to the MACLISP community by installing it on LIBLSP and
LIBDOC?  I have three suggestions that you might want to consider
seriously first, however.

1.) Use a gensymmed symbol for the LEXPR lambda variable;  it won't make 
    any difference when compiling, since this variable should be purely 
    local, but you will avoid two pitfalls:
      1a) Inadvertent capturing of a binding by a free variable in
	  interpretive code - interpretive bindings in MACLISP do not shield
	  the local variables from other, non-lexically-apparent functions.
      1b) Inadvertent SPECIALization of the lambda variable during
	  compilation.

2.) The meaning of a DECLARE, in a DEFUN immediately following the dummy 
    argument list, cannot be retained correctly unless it is placed either 
    before the internal lambda-bindings for the optional variables, or 
    immediately after any such lambda-variable-list that has some affected 
    variables.  Thus, the form
	(DEFUN& FOO (A &optional B) 
		(DECLARE (SPECIAL A) (FIXNUM B)) 
		(PRINT (LIST A B)))
    must expand into something like
	(DEFUN FOO G0025
	       (DECLARE (SPECIAL A) (FIXNUM B))
	       (AND (OR (< G0025 1) (> G0025 2)) 
		    (ERROR 'WNA (LIST 'FOO G0025 '(1 . 2))))
	       ((LAMBDA (A) 
			((LAMBDA (B)
				 (PROGN (PRINT (LIST A B))))
			    (ARG 2)))
		    (ARG 1)))
    rather than
	(DEFUN FOO G0025
	       (AND (OR (< G0025 1) (> G0025 2)) 
		    (ERROR 'WNA (LIST 'FOO G0025 '(1 . 2))))
	       ((LAMBDA (A) 
			((LAMBDA (B)
				 (PROGN (DECLARE (SPECIAL A) (FIXNUM B))
					(PRINT (LIST A B))))
			    (ARG 2)))
		    (ARG 1)))


3.) Also, I THINK the "flattening" of contours, where there is no need
    for the sequentialization of optional arg computations, would be a 
    very easy step which could make the code more readable to the human
    eye, and less likely to produce multiple SPECBINDings in the compileed
    code.   Thus the example above could turn into
	(DEFUN FOO G0025
	       (DECLARE (SPECIAL A))
	       (AND (OR (< G0025 1) (> G0025 2)) 
		    (ERROR 'WNA (LIST 'FOO G0025 '(1 . 2))))
	       ((LAMBDA (A B) 
			(PROGN (PRINT (LIST A B))))
		    (ARG 1) (ARG 2)))
Some function, perhaps like the one in my file AI:JONL;CNVD >
    (DEFUN CERTIFY-NO-VAR-DEPENDENCY (FORM BAD-VARS BOUND-VARS) . . . 
could be pressed into service, applying it to the various initialization
forms with BAD-VARS starting out as alist of all required and optional
arguments, and BOUND-VARS starting out () .


Date: 22 AUG 1978 0350-EDT
From: JPG at MIT-MC (Jeffrey P. Golden)
To: (BUG LISP) at MIT-MC
CC: JPG at MIT-MC, CHAR at MIT-MC, ELLEN at MIT-MC

It would be nice if something were done about the cute 
"gleep! out of bit blocks" message.  This message is unintelligible 
to us all wrt the state it is trying to convey and its seriousness. 
E.g., can a MACSYMA be reasonably continued after the user receives 
this message?  Can it happen when (STATUS MEMFREE) is not 0?
And exactly what does it mean as far as the functioning of the GC 
or whatever?

GJS@MIT-AI 08/21/78 15:23:33
To: (BUG LISP) at MIT-AI
A) Setup UREAD file
B) Cause GC-OVERFLOW
C) Cause Read macro context error
D) Watch infile go away


Date: 21 AUG 1978 0114-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: RWK at MIT-MC, (BUG LISP) at MIT-MC


    Date: 12 AUG 1978 0805-EDT
    From: RWK at MIT-MC (Robert W. Kerns)
    :L
    Alloc? N
    (SETQ FOO (OPEN 'TTY: '(SINGLE FIXNUM)))
    (IN FOO)^G
    MPV; TTYIC1+2>>HLR R,(TT)  R/   SETZ C  116003/ ??
--------
I believe I have finally fixed a long-standing "misfeature" of LISP.
I have changed the channel allocation algorithm so that lower channel
numbers are allocated first (how does this win, you may ask).  Well,
since ITS interrupts on the lowest TTY channel, the canonical TTY channel
will now initially be the lowest!!  Therefore, this bug (which occured because
the ^G interrupt occured in the new channel) and probablky
many other oddities will now have been corrected.  On the other hand, I have
probably just screwed N people who relied on this manic behaviour....

--howard

Date: 21 AUG 1978 0111-EDT
From: HIC at MIT-MC (Howard I. Cannon)
To: JPG at MIT-MC
CC: (BUG LISP) at MIT-MC

In the next LISP, if a TTY-RETURN interrupt happens
with the PC at one of the canonical input-waits, the
TTY-RETURN function will be invoked with an argument of 'IN rather than
NIL.

GSB@MIT-ML 08/19/78 11:37:07 Re: mldev/mlslv lossage
To: (BUG ITS) at MIT-ML
CC: (BUG LISP) at MIT-ML, AOK at MIT-ML
.call (access) over the net loses grossly on output files, producing
similar (though not necessarily identical) results with either unit
ascii (siot) or block ascii output;
a small test case, which prints 2 (short) lines of text, accesses
to 0, and prints 2 more (slightly longer), will give a reasonably sized
file (about 835 words).  The text output after the access is
(correctly!) at the end of the file, but the beginning is usually all
nulls, sometimes with the original text at the beginning and maybe at
other places...


AOK@MIT-ML 08/19/78 05:36:36
To: (BUG LISP) at MIT-ML
RE: PREVIOUSLY REPORTED BUG IN APPENDING. AFTYER EVEN MORE GRIEF I CAN GET IT TO
WORK FINE ON ML WRITING TO ML, BUT IT WONT WORK RUNNING ON AI AND GOING OVER TO 
WRITE ON ML. HOPE THIS HELPS SOME MORE. TO FIND LATEST CODE BEING RUN LOOK AT
ML:AOK;IORTN >, AND LOOK AT FWRITE FREAD FCLOSE FWRITE-OPEN FREAD-OPEN IN THE 
AFOREMENTIONED FILER. GOOD LUCK!!!!!!!

AOK@MIT-AI 08/19/78 03:23:23
To: (BUG LISP) at MIT-AI
HOW DOES WINNING NEW I/O HANDLE APPENDS?
A VERY GOOD QUESTION!

CODE:

(DEFUN FWRITE (S)
       (COND ((NULL OUTFILES)
              (SETQ OUTFILES (LIST (OPEN '((ML AOK) POSITN >) 'APPEND)))))
       (PRINT S (CAR OUTFILES)))

RESULTS: 

1. GARBAGE AT THE BEGINNING OF FILE - ABOUT 2 1/2 SCREENFULS OF  ETC... FOLLOWED BY

2. MY NEW INPUT (INTENDED TO BE APPENDED)

3. ALL OLD DATA IN THE FILE IS GONE

4. AFTER THIS UGLY FILE IS CLOSED AND READ BACK IN I HAVE NO TROUBLE GETTING MY NEW
INPUT (APPARENTLY THE I/O SYSTEM KNOWS TO SKIP (SLOWLY) OVER THE 'S), BUT ALL MY OLD DATA
IS GONE.

5. PROGNOSIS - TERMINAL !!!!!




Date: 18 AUG 1978 1941-EDT
From: RLB at MIT-MC (Richard L. Bryan)
Subject: Losing reader (sigh) ...
To: (BUG LISP) at MIT-MC

/2^N-P requires a slash to read in but doesn't get one on output.