Date: 4 FEB 1980 1303-EST From: HIC at MIT-MC (Howard I. Cannon) To: KMP at MIT-MC, JIM at MIT-MC CC: (BUG LISP) at MIT-MC ^G style quits do an output reset, so your THERE is being flushed from the output buffer before it is printed.... Date: 4 FEB 1980 1112-EST From: KMP,JIM at MIT-MC Sent-by: ___135 at MIT-MC To: (BUG LISP) at MIT-MC So how come (unwind-protect nil (print 'here) (print (tyi)) (print 'there))^G prints HERE then QUIT and never prints the THERE? These last forms have to get Eval'd in NOINTERRUPT T mode. This used to work. What happened? Loses interpretted and compiled. Date: 4 FEB 1980 0431-EST From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC IF A SYMBOL, SAY FOO, HAS AN AUTOLOAD PROPERTY, AND YOU DO A SETF ON A "CALL" TO FOO, THEN THE INTERNAL SETF CODE KEEPS RELOADING THE FASL FILE FOR FOO, HOPING (I SUPPOSE) TO FIND A MACRO PROPERTY. Date: 3 FEB 1980 2044-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: #+LISPM on ITS To: (BUG LISP) at MIT-MC CC: (BUG LISPM) at MIT-MC This bothers me: On ITS, #+LISPM

causes all the symbols in to get INTERN'd even on ITS because the real reader is called. Less annoying, but an artifact of the same problem, is that #+LISPM #.(PRINT 'FOO) will print FOO even on ITS. Must I really do #. #+LISPM (PRINT 'FOO) #-LISPM () in order to win? I wonder if we shouldn't look into making the reader recognize it's in a no-op state to suppress #. and INTERN and some of these other things from really doing their thing. I don't want to do this in a hackish way so am looking for suggestions for reasonable schemes. The main intention being that I don't have to do a huge GCTWA when all done reading some conditionalized file. -kmp Date: 3 FEB 1980 0200-EST From: SGR at MIT-MC (Stephen G. Rowley) To: (BUG LISP) at MIT-MC If the last line of a file of S-exp's is a comment, and there is no CRLF at the end, the reader says: ;GOT TO TTY INSIDE S-EXP - READ ;BKPT *RSET-TRAP However, if the comment is followed by a carriage return, things work out fine. example: (defun foo () (princ '|foo was called.|)) ;comment if there's a crlf at the end, it's ok, but ending a file with a comment and no carriage return loses. is this really a bug, or am I just not understanding something? Date: 2 FEB 1980 2319-EST From: PRATT at MIT-MC (Vaughan Pratt) To: (BUG LISP) at MIT-MC (ARRAYCALL T X 0 0) complains too MANY arguments when X is a three-dimensional array. Date: 2 FEB 1980 1349-EST From: JONL at MIT-MC (Jon L White) Subject: PNPUT To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC The second arg to pnput is a flag which determines whether or not to intern the symbol - the first arg must be in list-of-packed-ascii words. It is PNGET which gives the option for converting from a symbol to either a list of packed ascii or a list of packed sixbit. Date: 2 FEB 1980 0215-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC Is the second argument to PNPUT used at all? I can only get it to assume my pnames are in acsii, isn't it supposed to support sixbit as well? Date: 1 FEB 1980 0716-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC I am still quite serious about changing the default base from base 8 to base 10 in the near future. Tentative date scheduled was April 1 (yes, april fools day but no joke) ... If anyone thinks there should be more time say so in the next day or so (and suggest how much time is needed). Otherwise, I am gonna send a system message announcing the planned change. Any package which relies on a given base/ibase without setting it is not a very reliable package anyway, so I don't think we'll break much with this much advanced notice. -kmp Date: 31 January 1980 00:49-EST From: Robert W. Kerns Sender: ___014 at MIT-MC Subject: (SSTATUS GCWHO) To: BUG-LISP at MIT-MC cc: SJK at MIT-MC WRONG! It does *NOT* only work on AI TV's. It works perfectly well on ANY ITS. Please make (STATUS FEATURE ITS) the predicate, not (STATUS FEATURE AI) Date: 30 JAN 1980 1257-EST From: ALAN at MIT-MC (Alan Bawden) Subject: backquote To: RIVEST at MIT-ML CC: (BUG LISP) at MIT-MC It is not true that there is no way to accomplish what you wish with the current backquote. What I think you want is this: (defmacro setprop (x y z) `(prog2 (putprop ,x ,y ,z) (defmacro ,z(v) `(get ,v ',',z)))) This means that a form like (setprop a b c) produces a macro named c that is defined as (defmacro c (v) `(get ,v 'c)) which I presume is what you want, right? I have inserted a quote between the two commas to prevent z from being "evaluated twice" (that is, to prevent the result of evaluating z from being reevaluated at the time the macro named ,z is invoked). There are occasions when you want such double evaluation to happen so to change backquote in the way you suggest would be breaking it. You are quite correct that there is no good explaination of this anywhere. (Probably because it is damned difficult to explain!) Probably the next LispMachine manual will contain a "double backquote cookbook" to help macro defining macro writers to stay sane. Date: 30 JAN 1980 1257-EST From: ALAN at MIT-MC (Alan Bawden) Subject: backquote To: RIVEST at MIT-ML CC: (BUG LISP) at MIT-MC It is not true that there is no way to accomplish what you wish with the current backquote. What I think you want is this: (defmacro setprop (x y z) `(prog2 (putprop ,x ,y ,z) (defmacro ,z(v) `(get ,v ',',z)))) This means that a form like (setprop a b c) produces a macro named c that is defined as (defmacro c (v) `(get ,v 'c)) which I presume is what you want, right? I have inserted a quote between the two commas to prevent z from being "evaluated twice" (that is, to prevent the result of evaluating z from being reevaluated at the time the macro named ,z is invoked). There are occasions when you want such double evaluation to happen so to change backquote in the way you suggest would be breaking it. You are quite correct that there is no good explaination of this anywhere. (Probably because it is damned difficult to explain!) Probably the next LispMachine manual will contain a "double backquote cookbook" to help macro defining macro writers to stay sane. RIVEST@MIT-ML 01/30/80 10:55:41 To: (BUG LISP) at MIT-ML This is a minor gripe and suggestion about ` First the gripe: the documentation doesn't adequately describe what happens with nested backquotes and commas, etc. Perhaps this is obvious to some (and in retrospect is pretty reasonable) but LISP NEWS might have a word here. Second the suggestion. I think backquote needs to be extended. Consider the following problem: I want to define a macro SETPROP so that (SETPROP x y z) does two things: a (PUTPROP x y z) and also it defines a macro for z so that (z foo) will extract foo's z property. My first attempt was something like: (defmacro setprop (x y z) `(prog2 (putprop ,x ,y ,z) (defmacro ,z (v) `(get ,v ',z)))) This almost works, except that the commas in the nested backquote are at different levels. The first-level expansion of the macro call (SETPROP 'a 'b 'c) tries to expand v. Nope! (Boy am I a little confused!) I just tried that and discovered that thhe problem is that Z is undefined when the defmacro for C is evaluated. So I guess the rule is that in the evaluation of a back-quoted form, only those comma-expressions are evaluated and plugged in which are not themselves inside further nested backquoted forms. (please explain this clearly somewhere in the documentation !) So how do I get what I want (elegantly, of course)? Some way of associating commas with backquotes seems a useful possibility. In the above example, we want Z to be evaluated and plugged in when the outer backquoted form is evaluated. Let me suggest the following extension: let a series of k commas associate that comma with the k-th backquote, working outwards from the occurence of the commas. Thus one comma works as before, and I get what I want with: (defmacro setprop (x y z) `(prog2 (putprop ,x ,y ,z) (defmacro ,z(v) `(get ,v ',,z)))) So the Z is evaluated with the outer backquoted form. This generalizes to ,@ etc. Comments? Ron Rivest BEN@MIT-ML 01/30/80 09:42:13 To: (BUG LISP) at MIT-ML MACLISP for the Tufts KL-10 (under TOPS-10) loses dramatically because the new KL-10 microcode no longer supports KA-10 floating point instructions. These can be simulated by the monitor at vast overhead. I am told that the KL-style floating point instructions are compatible with KI's and 20's, and so should probably be the default. Ben Kuipers Tufts University BEN @ ML 628-5000 x6650 Date: 29 JAN 1980 2154-EST From: JONL at MIT-MC (Jon L White) To: SJK at MIT-MC CC: (BUG LISP) at MIT-MC STATUS WHO problem in GCDEMN now fixed - that only works on the AI tvs, so I had it do a (STATUS FEATURE AI) first. Date: 29 January 1980 12:06-EST From: Glenn S. Burke Subject: (status ttytyp) in gcdemn To: BUG-complr at MIT-MC cc: Srisw.Scott at MIT-XX, BUG-lisp at MIT-MC It should be checking (status feature its), since non-tvs have and can use the WHO variables. (Apparently all the applications i have which use that gc-daemon have been using my own copy with this or some similar modification...) Date: 29 Jan 1980 0732-EST From: Srisw.Scott at MIT-XX Subject: Loading the compiler loses To: bug-complr at MC cc: bug-lisp at MC @l: [Keeping] LISP 1920 Alloc? n * (load '(ccload ini)) ;Loading DEFMAX 30 ;Loading MACAID 63 ;Loading BACKQ 39 (In LISP version 1920) ;Autoloading GCDEMN FASL for GC-DAEMON ;(SSTATUS WHO1 52 (QUOTE %) 166 0) ILLEGAL REQUEST ;BKPT FAIL-ACT (status ttytyp) 5 *** Code from GCDEMN.CGL *** . . . if status(ttytype,tyo)=5. % Check if we are on TV! % then (sstatus(who1,42.,"%",118.,0.); % Set up "who" line on tv's. % sstatus(gcwho,3.); who3 := "GCDEMN") . . . ------- Date: 27 JAN 1980 0206-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: GSB at MIT-MC GSB's hunk bug is now fixed. (cons 'A (hunk 'B 'C 'D)) now prints as (A . (B . C . D .)) which will be reread correctly. This patch (fixed yesterday in source and 1920) is now in effect in Lisp 1914 as well. -kmp Date: 26 JAN 1980 0632-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: GSB at MIT-MC I seem to have managed to fix the (A . (B . C . D .)) bug ... Had some problem installing it, though. Maybe later when am awake. It's fixed in XLISP tho' (patched and in source). -kmp Date: 26 JAN 1980 0535-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, RJF at MIT-MC RJF@MIT-MC 01/25/80 19:58:25 ?comexp(f(sin(x))+sin(x)); gives ;seen non-null terminatin of list - map iocerror - chnl not open Whereas what RJF is doing here in MACSYMA is not legal, it is not nice that LISP succeeds in giving the correct error message and then proceeds to clobber itself. It exits to DDT, etc. (The MAPC is in compiled code, compiled with MAPEX NIL.) Date: 25 JAN 1980 2212-EST From: JONL at MIT-MC (Jon L White) Subject: DESETQ To: RZ at MIT-MC CC: (BUG LISP) at MIT-MC Date: 24 January 1980 23:07-EST From: Richard E. Zippel (desetq (a b c) a) fails. b gets bound to (cdar a) .... There is an optimization that tries to save something between (desetq (a b c) (f a)) and (desetq (a b c) a).. In the first case a gensym gets bounnd to (f a).. If this happended in the second case thigns would win. The DESETQ generator is quite different than the LET one, and apparently it is losing on that "optimization". I've just fixed this, with new LET FASL on LISP;, version 45. If any problems, just copy LET OFASL (version 40) back. Date: 25 January 1980 01:17-EST From: Robert W. Kerns To: RZ at MIT-MC cc: BUG-LISP at MIT-MC Date: 24 January 1980 23:07-EST From: Richard E. Zippel To: BUG-LISP Also SETF seems to lose in the compiler. Try compiling (defmacro state (node) `(car ,node)) (defun foo (x y) (setf (state x) y) (bar x)) Fixed. Date: 24 JAN 1980 2307-EST From: RZ at MIT-MC (Richard E. Zippel) To: (BUG LISP) at MIT-MC (desetq (a b c) a) fails. b gets bound to (cdar a) .... There is an optimization that tries to save something between (desetq (a b c) (f a)) and (desetq (a b c) a).. In the first case a gensym gets bounnd to (f a).. If this happended in the second case thigns would win. Also SETF seems to lose in the compiler. Try compiling (defmacro state (node) `(car ,node)) (defun foo (x y) (setf (state x) y) (bar x)) GSB@MIT-ML 01/24/80 22:26:35 Re: hunk printing lossage To: (BUG LISP) at MIT-ML (cons 'a (hunk 'b 'c 'd)) prints out as (A B . C . D .) which reads in as (A . B . C . D .) which is now a hunk4. Date: 22 JAN 1980 1916-EST From: JONL at MIT-MC (Jon L White) Subject: Directory space on MC:LISP; To: (BUG LISP) at MIT-MC I've moved the LSPTTY files, and TS ASSLIS to the L; directory, due to a crunch on space. Date: 21 JAN 1980 2224-EST From: WGD at MIT-MC (William G. Dubuque) Subject: Mersenne vs. LISP To: (BUG LISP) at MIT-MC, MATHLAB at MIT-MC Consider the infamous Mersenne numbers defined by: K M = 2 - 1 K Besides being useful for generating the worlds largest known primes (k = 44497 at the present) it seems that they may also be useful for debugging numerical routines; or at least that seems so for LISP. Since GCD(M(P),M(Q)) = M(GCD(P,Q)) we see that M(K) divides M(2*K) (this may also be seen by factoring M(2*k)). However, LISP does not seem to think that this identity holds ... for all k > 105 we get (from LISP): (GCD (M K) (M 2*K))) => 1 (DIFFERENCE (M 2*K) (TIMES (M K) (QUOTIENT (M 2*K) (M K)))) => unequal 0 It also seems rather suspicious that 105 is exactly the 3-word boundary ... Date: 21 January 1980 07:14-EST From: Robert W. Kerns Subject: more info To: RLB at MIT-MC cc: BUG-DDT at MIT-MC, BUG-LISP at MIT-MC Date: 19 JAN 1980 0255-EST From: RLB at MIT-MC (Richard L. Bryan) To: (BUG DDT) Re: more info Start a Lisp without symbols in DDT. (SETQ SYMBOLS T) Load HUMBLE from LISP;. See DDT BUG DO :BUG DDT ... The Lisp is doing .BREAK 12,[..SSTB,,T] with T/ -302,,mumble at LDPUTM+6. Thereafter, at strange times, having to do with job manipulation, the bug msg reappears. I encountered occurrences of jobs doing .BREAK 12, at startup. If such jobs are reselected, the BUG DDT ... happens again. :SELF :PDUMP MC:CRASH;RLB .BREAK The :SELF is unecessary. Undesirable even. I think LISP is passing up a malformed symbol table, fucking DDT over royally. As near as I can tell from the totally inadaquate documentation on this feature, LISP should be passing a symbol table, as documented in DDT ORDER. It's not easy for DDT to protect itself from this kind of lossage. As I understand it, this is what you should be doing. It seems to work ok for me. 1) Turn on %SYGBL in the symbols. Either that or %SYLCL *MUST* be set, as documented in DDT ORDER. 2) By the way, I assume it's LISP that's clearing out the %SYHKL bit in the symbols being passed up. Please make it stop doing that, It makes the SYMBOLS T feature completely useless since it hides important symbols like A. 3) Put all the symbols in a symbol block. I'd suggest, for maximum utility, putting them into a block named after the FN1 of the FASL file. I.e. SYMS: .SQUOZE 0,TEST ;Test BLOCK -10,,1 ;10 long, including 2 for header, level 1 .SQUOZE %SYLCL,A 1 .SQUOZE %SYLCL,B 2 .SQUOZE %SYLCL,C 3 GO: .BREAK 12,[..SSTB,,[-10,,SYMS]] Date: 19 JAN 1980 1616-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC GJC;TIME > FASL loading cause NIL undefined function object. I then put in (declare (setq defmacro-for-compiling nil)) and it was O.K. DEFMACRO bug it seems. Date: 18 January 1980 02:16-EST From: Robert W. Kerns Subject: PPN vs LISP device To: RLB at MIT-MC, REES at MIT-MC cc: BUG-LISP at MIT-MC Date: 17 January 1980 09:54-EST From: RLB,REES at MIT-MC Sender: RLB at MIT-MC To: BUG-LISP Re: PPN vs LISP device It looks to REES & me like this is ignored by ITS Maclisp /1920, at least. In particular, do (DEFPROP LISP (DSK NILFAS) PPN) and try to load ((LISP) PPNTST), of which there's a heralding version on both LISP; and NILFAS;. Patched in 1914 (current) and 1920 (XL). JONL: See the code in the IFN 0, at NML6PP+n, and my comments. Date: 18 JAN 1980 0022-EST From: KMP at MIT-MC (Kent M. Pitman) To: ALAN at MIT-MC, GZ at MIT-MC, (BUG LISP) at MIT-MC It is *not* a feature that the only way to get the effect of ^S for instance is to either get a *very* old lisp and do (IOC S) or get a lisp manual and look up the function it does and write it yourself ... They ought to all be symbols so you can call them elsewhen or at least all have symbols somewhere associated with them (2. might say get back the default definition even if +INTERNAL-^B-BREAK has been redefined, but initially +INTERANL-^-BREAK ought to be defined for all symbols so that they can be examined/called by running programs that aren't sophisticated enuf or don't have enuf core to yank .INFO.;LISP NEWS and scan for the definition themselves. -kmp ps sorry to drag you in on this if you're not interested, GZ, but this has long been a gripe of mine, so thought I would get it out... GSB@MIT-ML 01/18/80 00:22:01 Re: Numeric vs symbolic tty interrupts To: gz at MIT-MC CC: (BUG lisp) at MIT-MC The primary difference is that the numeric ones may take effect even when lisp has interrupts defered or inhibited. (^X and ^G do some special case checking, but ^S, ^V, ^W, ^D, and ^C can all work even when the garbage collector is running.) The symbolic ones must be saved until it is safe to run a user function; hence ^B is symbolic (It could be a number, but then the lisp internals would have to check and do the same thing they do with user-defined interrupts anyway...) Date: 18 JAN 1980 0015-EST From: ALAN at MIT-MC (Alan Bawden) Subject: ^s & ^w To: GZ at MIT-MC CC: (BUG LISP) at MIT-MC In any case it is a feature that (status ttyint ) can be something other than a number. It enables the user to supply his own character interrupt function! Date: 18 JAN 1980 0011-EST From: KMP at MIT-MC (Kent M. Pitman) To: GZ at MIT-MC CC: (BUG LISP) at MIT-MC Yes, ^S and ^W do the same thing at interrupt level. The difference is that ^S is also a forcefeed character at readtime and when it is seen by the reader, it does (SETQ ^W NIL) again ... ^W when seen by the reader is just ignored. So ^S is less permanent than ^W. I can't answer why ^B is not a number like all others -- someone from farther back will have to try that one ... Date: 18 JAN 1980 0009-EST From: RWK at MIT-MC (Robert W. Kerns) To: GZ at MIT-MC CC: (BUG LISP) at MIT-MC At interrupt level, ^S and ^W do the same thing. (setq ^W t) ... the difference lies in what happens when they are read. ^W is ignored, and ^S SETQ's ^W back to (). Date: 18 JAN 1980 0008-EST From: GZ at MIT-MC (Gail Zacharias) Subject: (status ttyint 23) To: (BUG LISP) at MIT-MC CC: (FILE [GZ;RMAIL LISP]) at MIT-MC Doing (status ttyint 23) replies 27 - this in clean new lisp, with no init files or anything. Are ^S and ^W really the same? Also (status ttyint 2) gives a name (+internal-^B-break) rather than a number like the others. It would be easier to restore stuff if all of them were numbers. Date: 17 JAN 1980 1543-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: DEPOSIT-BYTE untested before release To: (BUG LISP) at MIT-MC In octal bases, (DEPOSIT-BYTE 1234 3 6 65) returns 1654, the correct answer. (defun depos (a b c d) (deposit-byte a b c d)) (depos 1234 3 6 65) returns 674, evidence of at least one fencepost error! deposit-byte worked before the recent incompatible change (not to complain about the change, which was necessary...) Date: 17 Jan 1980 0731-PST From: Scott at SRI-KL (Scott J. Kramer) Subject: NILAID reloads STRING To: bug-lisp at MC If STRING has been loaded, the loading of NILAID causes it to be reloaded. This doesn't seem to occur with any other packages. -sjk ------- Date: 17 JAN 1980 1020-EST From: JONL at MIT-MC (Jon L White) Subject: lisp-coded tty-scanners To: scott at SRI-KL CC: (FILE [LISP;BUG MAIL]) at MIT-MC, miller at MIT-AI, ddm at MIT-AI CC: fahlman at CMU-10A, broberts at BBN-TENEXD The current version of TOPS-10/TWENEX maclisp (version 1920) have a rudimentary CURSORPOS function assembled in - not enough to satisfy real video terminal users, but enough to get started, and enough to run the (lisp) programs which have CURSORPOS calls in them; remember that a return value of () from CURSORPOS means that the "action" didn't take place, either because the terminal can't support it, or because the code for CURSORPOS hasn't been sufficiently developed. Two examples of LISP-coded rubout processors may be found in the notes dated "MARCH 22,1976" and "MAY 27,1975". Just get the file LISP.NEWS and search for those date strings; then search for "TTYSCA" on each of those pages. Original announcement of NEWIO stuff, including the (STATUS TTYSCAN ...) facility was in the note dated "APRIL 18,1975". Date: 17 JAN 1980 0954-EST From: RLB,REES at MIT-MC Sent-by: RLB at MIT-MC Subject: PPN vs LISP device To: (BUG LISP) at MIT-MC It looks to REES & me like this is ignored by ITS Maclisp /1920, at least. In particular, do (DEFPROP LISP (DSK NILFAS) PPN) and try to load ((LISP) PPNTST), of which there's a heralding version on both LISP; and NILFAS;. Date: 16 JAN 1980 2124-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: (BUG MACSYM) at MIT-MC, DWS at MIT-MC Is it not thae case that... (ATAN 1.0E-20 1.0E20) should return 0.0 (ATAN 1.0E20 1.0E-20) should return %PI/2 or rough flonum equivalent thereof (ATAN -1.0E20 1.0E-20) should return -%PI/2 or rough flonum equivalent therof Yes, underflow/overflow conditions do occur here if you do the division but it would appear to me that there is still a well-defined meaning to that under/overflow ...? Date: 16 JAN 1980 0752-EST From: JONL at MIT-MC (Jon L White) Subject: LISP.INI's fixed, finally! To: TOURETZKY at CMU-10A CC: (FILE [LISP;BUG MAIL]) at MIT-MC, RPG at SU-AI, FAHLMAN at CMU-10A Apparently there are two bugs in either the TOPS-10 monitor, or its documentation, but finally I've gotten the sequence of kludges which makes all kinds of LISP.INIs and all kinds of relocating I/O buffers to work; the two tricks seem to be 1) always do the buffer-ring "cycling" yourself, by supplying an address to the IN uuo 2) Note that the CMU monitor (and possibly others) does not return the SN%SHR bit in the correct place, (or maybe documentation is wront), so the the fasload into the hiseg was losing. I simply added check to see if bit 4 is returned by GETTAB of the segment-number-table (.GTSGN). The documentation says that this bit is "reserved", but it is what CMU seems to return. I've tested this out at CMU, by running the standard LISP.INI, and also doing a "/NQACLSP" which is the QACLSP.MIC file altered to get LISP off [C380ML5P], so it looks like we're in good shape again. Also, I made up a complr and put it on TEMP, so when you are ready, there is a LISP.SHR and COMPLR.SHR (and .LOW's too) to be moved to SYS:. Date: 12 JAN 1980 1109-EST From: JONL at MIT-MC (Jon L White) Subject: Loading REL-type files into LISP To: touretzky at CMU-10A, fahlman at CMU-10A CC: (BUG LISP) at MIT-MC Date: 10 January 1980 1621-EST From: Dave Touretzky Does there exist a package to load TOPS-10 relocatable binary files (as produced by BLISS, FORTRAN, etc.) into MacLisp so that non-LISP subroutines can be called from LISP? The standard REL format is deficient for LISP, which is why the FASL format was invented. LISP's loader is only FASLOAD (for .FAS files). I have a user who needs to call BLISS programs from withing MacLisp. I also have a piece of LAP code that is supposed to interface BLISS routines with LISP, but I have no way of loading the program into LISP from the .REL file. Any help you could offer would be appreciated. But MIDAS can output FASL format (as well as REL); So if you could manage to translate your BLISS stuff into MIDAS . . . See the MIDAS documentation, around the section that has substring like ".FASL" and ".ATOM" etc. Date: 12 JAN 1980 0405-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Would it be possible to / would anyone object to making PROBEF be an LSUBR taking an optional second arg of T or some such thing to allow PROBEF'ing for files with a '*' in them (would set the NODEFAULT option in open)...? It would also be useful to have it be able to find things like locked open but existing files, etc (possibly returning the atom LOCKED if you selected an option saying you were expecting that possibility). Date: 12 JAN 1980 0350-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, JPG at MIT-MC GSB@MIT-ML 01/10/80 10:02:55 Re: Macsyma tags file lossage To: JPG at MIT-MC, (BUG LISP) at MIT-MC Indeed, the lossage was coming from FORMAT. However, the bug is LISP's. Lisp changes into everywhere except at the end of the file. I have changed FORMAT to explicitly call TERPRI rather than output 15 octal repeatedly; when this gets fixed in LISP (I was under the impression this got fixed long ago, because i remember complaining about it) then format can be channged back to save some space. Regardless of any lisp inconsitencies, you should use TERPRI. I have been hassled upon ocasion by several other persons about error msgs having imbedded "^M"s rather than calling TERPRI, for random-J operating system does, or needs, something different at end-of-line (where "J" varies over SAIL and some others.) Date: 10 JAN 1980 1931-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: REM at MIT-MC The ARGS property for SPRIN1 was wrong. Fixed in the source and patched. Date: 10 January 1980 1621-EST From: Dave Touretzky Subject: MacLisp loader? To: bug-lisp @ mc, Scott.Fahlman at CMU-10A Does there exist a package to load TOPS-10 relocatable binary files (as produced by BLISS, FORTRAN, etc.) into MacLisp so that non-LISP subroutines can be called from LISP? I have a user who needs to call BLISS programs from withing MacLisp. I also have a piece of LAP code that is supposed to interface BLISS routines with LISP, but I have no way of loading the program into LISP from the .REL file. Any help you could offer would be appreciated. -- Dave Touretzky GSB@MIT-ML 01/10/80 10:02:55 Re: Macsyma tags file lossage To: JPG at MIT-MC, (BUG LISP) at MIT-MC Indeed, the lossage was coming from FORMAT. However, the bug is LISP's. Lisp changes into everywhere except at the end of the file. I have changed FORMAT to explicitly call TERPRI rather than output 15 octal repeatedly; when this gets fixed in LISP (I was under the impression this got fixed long ago, because i remember complaining about it) then format can be channged back to save some space. Date: 9 JAN 1980 2155-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC, RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 7 January 1980 12:59-EST From: Kent M. Pitman . . . FASL-NAMELIST does not behave like a variable. . . But Read-Only items and items which are prone to change dynamically in non-binding ways should nt be variables. --kmp Me too. I changed this facility to be (STATUS FASLNamelist) for the time being. Date: 9 JAN 1980 2128-EST From: JONL at MIT-MC (Jon L White) To: miller at MIT-AI CC: (BUG LISP) at MIT-MC MILLER@MIT-AI 01/09/80 07:36:28 Re: SUPER-IMAGE Output There ought to be a way to OPEN a TTY file in "SUPER-IMAGE" mode, or a builtin "RAWTYO" function. These would, on ITS, prefix any special characters with a control-P. On 20X they would put the TTY in binary mode during TYO's. The way things are, it is very difficult to write terminal hacking stuff in LISP except in a very operating-system-dependent way. I have spent a lot of time changing my own code from sending control-P's to instead call appropriate JSYS's on 20X. The amount of code you'd have to put in LISP to support this is probably less than a page of MIDAS. LISP ought to provide that as a primitive, even if it only works on some systems initially. Writing code which does (TYO control-P) (TYO escape) ... at the user level is pretty obscure! Regards, Mark I believe that the idea of the CURSORPOS function was to abstract out the various "terminal hacking stuff", and refer to them as symbolic arguments (or numeric positions) to CURSORPOS. Indeed, the maclisp implementation of CURSORPOS does the appropriate "lock-out" so that control-p codes are not separated from the preceeding control-P. Shouldn't you do that too? namely, just add to the code for CURSORPOS in the midas listing? It may be that you will want to add more commands to account for the TOPS-20 or TENEX terminal capabilities. I've just edited the sources to separate out the ITS-relevant parts, and you will find in the file MC:LISP;*LISP > a page which has a part "SUBTTLCURSPOPOSFUNCTION" and that should be changed whereever there are conditionals marked by either "IT%" (meaning, "not ITS") or "IT$" (meaning, for ITS), or "IFN ITS," (also for ITS); the only things relevant there are how to read the cursorposition from the terminal, and how to move it (the "H" and "V" commands from CURSORPOS). Also, in the file MC:L;QIO > there is a page with a part "SUBTTLCONTROL-PCODES", and this will have to be scrutinized more carefully, since here it is that symbolic commands are translated into real action. This new source will be the one which you (MILLER) will receive on the tape which is being made up this week for mailing to you. As you remember, when the source is shipped out, it is "unified" into one long file. MILLER@MIT-AI 01/09/80 07:36:28 Re: SUPER-IMAGE Output To: (BUG LISP) at MIT-MC CC: MILLER at MIT-AI, gz at MIT-MC There ought to be a way to OPEN a TTY file in "SUPER-IMAGE" mode, or a builtin "RAWTYO" function. These would, on ITS, prefix any special characters with a control-P. On 20X they would put the TTY in binary mode during TYO's. The way things are, it is very difficult to write terminal hacking stuff in LISP except in a very operating-system-dependent way. I have spent a lot of time changing my own code from sending control-P's to instead call appropriate JSYS's on 20X. The amount of code you'd have to put in LISP to support this is probably less than a page of MIDAS. LISP ought to provide that as a primitive, even if it only works on some systems initially. Writing code which does (TYO control-P) (TYO escape) ... at the user level is pretty obscure! Regards, Mark Date: 8 JAN 1980 1257-EST From: REM at MIT-MC (Robert Elton Maas) Subject: pps on PURPG To: (BUG LISP) at MIT-MC See REM;BUG1 > If BAR called interpreted, ;FOO UNDEFINED FUNCTION OBJECT, but the combination of (DECLARE (ARRAY* ...)) putting a #DEAD-ARRAY around and COMPLR defaulting to Opencodearrays while not a bug sure was confusing for awhile. I guess in the future I'll compile with -O the first time just to be sure unexpected differences between interp and compiled environment don't cause PURPG -- Compiling BUG1 > with -O gives ;FOO UNDEFINED FUNCTIN OBJECT IN UUO CALL instead of PURPG. (Should default switch really be O ??? After all default is *RSET and (NOUUO T) to make debugging easier.) Date: 8 JAN 1980 1233-EST From: REM at MIT-MC (Robert Elton Maas) Subject: Final addendum I hope on DEAD-ARRAY PURPG; problem To: (BUG LISP) at MIT-MC Indeed, putting a check for #DEAD-ARRAY in that other place I check to see if the array is defined, fixes the bug. It all seems to work fine now compiled -- will give it a full test when not midday! There must be a minor bug in #DEAD-ARRAY that gives the PURPG; trap. It would be nicer if it said ;HASHTABLE ARRAY-NOT-INITIALIZED or somthing equally informative... Date: 08 Jan 1980 0846-PST From: Robert Maas To: BUG-LISP at MIT-MC Aha, another clue... I fixed NEQ to use EQUAL instead of =, and then got ;UNBOUND NONNUMERIC VALUE Running the code interpreted after running it compiled in same core image managed to evoke a brand new error message. Apparantly there's another place in my program where I do (GET 'HASHTABLE 'ARRAY) to see if the array is defined, but then don't check (ARRAYDIMS 'HASHTABLE) to be sure isn't a DUMMY-ARRAY put there by compiled code! I finally have a clue to what might really be wrong... Date: 08 Jan 1980 0822-PST From: Robert Maas Subject: Addenda on readonly-page bug reported this morning To: BUG-LISP at MIT-MC I imported most of the FASL files to here and tested it the same. I got nonumeric error trap from inside = because I had a bug that was feeding it nonnumeric values. Could it be that the nonnumeric error trap in = is broken at MC? (It occurs inside NEQ in REM;COMMON >) Date: 8 JAN 1980 1045-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC PURPG; 146537>>HRRM 1,@70767 1/ 720023 101027/ 4,,111002 Will somebody help me find out what I'm doing wrong if anything? :LISP REM;REM LISP then type (Q) and answer questions exactly "Y" "Y" and "3" (without the quotes of course). This is all compiled code, no dangerous no-checking flags turned on in compiler. Interpreted it works ok. No LAP code in vicinity of error as far as I know. If you want to compare with earlier versions, REM;HAS801 8 --> REM;HAS801 FAS8L is the most recent working version. REM;HAS801 11 --> REM;HAS801 FASL is the one that makes PURPG; happen. Date: 8 JAN 1980 0203-EST From: REES at MIT-MC (Jonathan A. Rees) Subject: FASL-NAMELIST To: (BUG LISP) at MIT-MC (By the way, all you hackers out there, in case you're curious, this issue arose in the first place because it was desired to subsume responsibility for printing the "WARNING! FOO, A USER SUBR AT 12345, IS BEING REDEFINED AS A LSUBR BY FASL FILE DSK:LOSER;LOSE FASL" that FASLOAD so courteously provides; this feature lets you get a handle on the name of the fasl file, which is otherwise (and unfairly) unavailable.) I agree with KMP, that this properly belongs as a subfunction of STATUS. Also, this idea occurs to me: why not have LOAD put the namelist in this place whether the file is being FASLOADed or not? Thus in RWK's FOOBAR example (appropriately hacked), doing (LOAD '((RWK) FOOBAR >)) would print ((DSK RWK) FOOBAR 23) [substitute correct version number], but (LOAD '((RWK) FOOBAR)) would print ((DSK RWK) FOOBAR FASL). This makes the hirsute eval-mungibles's jobs slightly less ponderous. I guess in this case the result is the same as you'd get with (TRUENAME INFILE). One gritty problem: shouldn't this guy get bound/unbound through calls to recursive calls to LOAD/FASLOAD? Suggestion for name: (STATUS LDNAM) or (STATUS LDFNA). The MIDAS symbol for this is LDFNAM. Date: 7 JAN 1980 1308-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Ooopss... To: (BUG (BUG LISP)) I didn't realize RWK was naming an XLisp when he said Lisp 1918 ... Things seem to work satisfactorily there (binding/unbindig works) although I still questin the ethics of having what ought to be a readonly thing be in a variable ... --kmp Date: 7 JAN 1980 1259-EST From: KMP at MIT-MC (Kent M. Pitman) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC I would prefer to have a (STATUS FASLNAMELIST) or something like that. FASL-NAMELIST does not behave like a variable. Doing (SETQ FASL-NAMELIST 'FOO) (FASLOAD FOOBAR) where FOOBAR is a file that just does a (PRINT FASL-NAMELIST) will print out FOO, not ((DSK KMP) FOOBAR FASL) .. which is not to say tha this isn't reasonable from the point of view of my having munged with bad things. But Read-Only items and items which are prone to change dynamically in non-binding ways should nt be variables. --kmp Date: 7 JAN 1980 0732-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: LISP 1918 To: (BUG LISP) at MIT-MC CC: REES at MIT-MC, GSB at MIT-MC I added the symbol FASL-NAMELIST to LISP, which is () at top level, and bound to the namelist of the FASL file being loaded inside FASLOAD, for eval-mungibles to ponder. This is just a symbol poining to a variable that already was in the system. Date: 6 JAN 1980 2137-EST From: hic at MIT-MC (Howard I. Cannon) Sent-by: ARCHY at MIT-MC To: (BUG LISP) at MIT-MC But I did not patch it in bianary Date: 6 JAN 1980 2137-EST From: hic at MIT-MC (Howard I. Cannon) Sent-by: ARCHY at MIT-MC To: (BUG LISP) at MIT-MC I made the fix to READER as described Date: 6 JAN 1980 2134-EST From: HIC, ALan, Archy at MIT-MC Sent-by: ARCHY at MIT-MC To: (BUG LISP) at MIT-MC Take a look at the file ALAN;READ LOSS. It is the printed representation of some HUNK structure. When read in one of the fixnums gets read in negative (same magnitude). The setting of IBASE doesn't seem to matter. HIC: The bug is that RDHNK jumps back to RDLS3Y which doesn't clear the left half bits in T. I suggest: RDLST0: MOVE B,AR2A RDHNKA: TLZA T,-1#200002 and at RDHNK+12 JRST RDHKNA instead of RDLS3Y Date: 6 January 1980 15:48-EST From: Robert W. Kerns To: CWH at MIT-MC cc: BUG-LISP at MIT-MC Date: 6 January 1980 14:45-EST From: Carl W. Hoffman To: BUG-LISP The +INTERNAL-/"-MACRO doesn't cause STRT-ification to happen. A mis-spelling, fixed. Also, I fixed INCLUDEF in the compiler. Again, a mis-spelling (forgot the F) plus forgetting to do the EVAL. Boy, the left half of my brain must have been on vacation that day. Date: 6 JAN 1980 1445-EST From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC The +INTERNAL-/"-MACRO doesn't cause STRT-ification to happen. Date: 2 JAN 1980 1248-EST From: KMP at MIT-MC (Kent M. Pitman) To: FREND at MIT-MC CC: (BUG LISP) at MIT-MC There is nothing magic about readlne. At the time it is invoked it will read a lne of characters forward until a carriage return and let you rubot as many characters as you type while yo are in the readlne. Characters that preceded its invocation cannot be rubbed out. Characters that are typed after it returns (including rubouts) cannot affect it since it will have already returned the characters to you as as string. VALRET'ing strings to DDT is a pretty KLUDGEY way to get something done anyway... -kmp Date: 31 DEC 1979 0713-EST From: JONL at MIT-MC (Jon L White) Subject: quote without comment To: (BUG LISP) at MIT-MC Date: 30 December 1979 22:58-EST From: John L. Kulp To: JONL at MIT-MC Well, I assumed that since the old spooler didn't work in the new lisp but did work in the old lisp, that it must be a bug in lisp. However, this assumption was wrong. It was instead an obscure bug associated with the change in the way CRLF was handled implicit in some command parsing code. CFFK actually tracked it down... Date: 29 DEC 1979 2020-EST From: JONL at MIT-MC (Jon L White) Subject: DEFMACRO-DISPLACE-CALL To: CWH at MIT-MC CC: (BUG LISP) at MIT-MC, JPG at MIT-MC This switch determines whether the "memoizing" code gets added to the user-supplied code for the macro; when it has been so added, then at runtime the MACRO-EXPANSION-USE switch will determine whether it is used or not, but if it hasn't even been added, then not much can be done at runtime. If such "memoizing" code was added, then the |forget-macromemos/|| call must be made upon load time (but true it shouldn't even be loaded if DEFMACRO-FOR-COMPILING is null). The MACROEXPANDED mode is so useful, that most users will probably opt for it, and will thus cause the loading of DEFMAX anyway. Date: 29 December 1979 20:12-EST From: Carl W. Hoffman Subject: Loading of DEFMAX To: BUG-LISP at MIT-MC cc: JPG at MIT-MC Date: 27 DEC 1979 0436-EST From: JPG at MIT-MC (Jeffrey P. Golden) Why does L^K (LOAD '|MACSYM;GRAMI FASL|) cause the DEFMAX stuff to be loaded in? [Ignore the error message about MDISPATCH which occurs afterwards.] After all this is a FASL file! The previous version of MACSYM;GRAMI FASL (which I can retrieve from tape if such is desired) did not require the loading in of the DEFMAX stuff while creating a new version of MACSYMA. This happens not only with MRG;GRAM, but with any file containing a DEFMACRO, even if the DEFMACRO-FOR-COMPILING switch is turned off, which is clearly wrong. The DEFMACRO-DISPLACE-CALL switch should not be the one to control whether the FORGET-MACROMEMOS form is present in the fasl file. The DEFMACRO-FOR-COMPILING switch should control this. If the macro is not present in the fasl file, then there is no need to communicate any information about it to the memoizer, so the FORGET-MACROMEMOS form shouldn't be present. Likewise, if the macro is present in the fasl file, the FORGET-MACROMEMOS form should be there, regardless of the setting of DEFMACRO-DISPLACE-CALL at compile time. Date: 27 DEC 1979 1158-EST From: JONL at MIT-MC (Jon L White) I've edited the one line necessary into MRG;GRAM >, and will leave it to you to redo the splitting and rebuilding of MACSYMA. the needed line is (declare (setq defmacro-displace-call () )). Did you really make this change? MRG;GRAM > was last updated by JPG. In any case, I put the form in LIBMAX;PRELUD >, which is the correct place for it. This way it will affect all Macsyma files which use DEFMACRO. In case you are still wondering, if you use DEFMACRO with intention of using any of the MACROMEMO features at runtime, then you need the runtime support package (which is only about 333. words); the default is to have DEFMACRO-DISPLACE-CALL non-null, but you clearly don't want to be bothered with that for the two little macros MATCH and TELL. Why don't you code FORGET-MACROMEMOS as a small subr which looks to see if MACROMEMOS is non-NIL before loading the macromemo package. Alternately, the macromemo displacer could keep track of the macro properties of symbols and check to see if they've changed. In any case, I suspect that the MACROEXPANDED scheme is used most of the time and the macromemo package shouldn't be loaded whenever DEFMACRO is used. Incidentally, why is the DEFMACRO-DISPLACE-CALL switch needed at all? Isn't the same thing accomplished by setting MACRO-EXPANSION-USE to NIL? Date: 29 DEC 1979 1903-EST From: JONL at MIT-MC (Jon L White) Subject: compilation of BOUNDP To: JOHAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 29 December 1979 18:17-EST From: Johan de Kleer I believe that MC;CBUG > compiles incorrectly. Specifically the "(BOUNDP FILE-FORK)" where FILE-FORK is an argument gets compiled into: HLRZ 1,@- 6(14) HRRZ 1,0(1) HRRZ 1,0(1) CAIN 1,QUNBOU No, this is indeed correct. But your source code, (and file-fork (boundp file-fork)) is incorrect, and should be (and (boundp file-fork) file-fork) I hope that is the only problem. Date: 29 DEC 1979 1548-PST From: DEKLEER at PARC-MAXC2 Subject: LEDIT on TOPS-20 and TENEX To: bug-lisp at MIT-AI As far as I can tell my LEDIT works on TOPS-20. It works on MIT-XX, although I cant tell how it behaves on a display terminal. The identical FASL files and :EJ files should work on TENEX and TOPS-20 (if your respecitve versions of EMACS and LISP are compatible). To run it on MIT-XX. [1] Set up your EMACS init to always load the standard LEDIT. e.g. like EMACS.INIT [2] Load LEDIT.FASL [3] Load TENEX.FASL The first time you return it will ask for LISP job name, type anything, CR. [4] Optional. Edit the LEDIT file to flush this spurious msg. You should now be winning!? The sources and auxilliary files are on [MAXC2]LEDIT.LSP/FASL [MAXC2]TENEX.LSP/FASL [MAXC2]LINIT.LSP/FASL [MAXC2]STRUC.LSP/FASL [MAXC2]LEDIT.E/:EJ Login with FTP as ANONYMOUS with password GUEST. P.S. The only problem I seem to have is that on some occasions the first character typed to EMACS gets garbled. But I cant really tell what is going since EMACS is so brain-damaged when it is talking to non-display terminal. johan ------- Date: 29 DEC 1979 1817-EST From: JOHAN at MIT-MC (Johan de Kleer) To: (BUG LISP) at MIT-MC I believe that MC;CBUG > compiles incorrectly. Specifically the "(BOUNDP FILE-FORK)" where FILE-FORK is an argument gets compiled into: HLRZ 1,@- 6(14) HRRZ 1,0(1) HRRZ 1,0(1) CAIN 1,QUNBOU There is too much indirection here for me. You get memory protection violations here depending upon whFILE-FORK contains. I meant MC:JOHAN;CBUG > johan Date: 28 DEC 1979 1925-EST From: RLB at MIT-MC (Richard L. Bryan) To: JPG at MIT-MC, (BUG LISP) at MIT-MC JPG@MIT-MC 12/27/79 05:39:41 :TAGS MACSYM;MACSYM NTAGS gives bad format error. It complains that a "^_ is not followed by a CRLF" at the end of the MACSYM NTAGS file. As you know, this file is created via (CODESIZE) of ALJABR;CODE > . (Conjecture: Are we being screwed by the change to (STATUS TERPRI)? (I didn't test this conjecture.)) I guess we blame either LISP or FORMAT. The file, written by the following code, ends with and not with as it used to (and like TAGS wants). (DO ((F (OPEN '|MACSYM;MACSYM NTAGS| '(OUT ASCII))) (FF FF (CDR FF))) ((NULL FF) (CLOSE F)) (FORMAT F '|~A~%0,~A~%^_~%| (NAMESTRING (MERGEF '|* >| (CAR FF))) (COND ((EQ (CADR (CAR FF)) 'RATLAP) 'MIDAS) ('LISP)))) Date: 28 DEC 1979 1234-EST From: JONL at MIT-MC (Jon L White) Subject: more macsyma bignumery To: JPG at MIT-MC, BMT at MIT-MC CC: (BUG LISP) at MIT-MC Date: 28 December 1979 06:13-EST From: Jeffrey P. Golden RWG@MIT-MC 12/10/79 23:29:10 loadfile(qnotex,taylor,aljabr); taylor(qnotex,q,0,0); gives QUOTIENT IS NOT EXACT. (This is a bug in the LISP bignum division routine; see the message in LISP;BUG MAIL ... wgd & bmt) This bug is still happening even though JONL claims to have fixed the bignum division bug in the current LISP on 12/13. Why is this? Well, I claim to have fixed *some* bug, not all bugs, in bignum division. Can you get a fix on the particular integers causing the problem? The "lobotomy" bug of 12/13 concerned quotients whose value is 2^n+1 for N > 35. Date: 13 December 1979 08:37-EST From: Jon L White Subject: LOBOTOMY, and the (maybe found?) BIGNUM BUG . . . Possibly only divisions where the quotient is equal to a number of the form 1+2^N for N > 36., will exercise this code, and in all cases I've inspected, the removal of the (buggy) code seems to be the right thing to do. . . . Date: 28 DEC 1979 0613-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, BMT at MIT-MC CC: JPG at MIT-MC RWG@MIT-MC 12/10/79 23:29:10 loadfile(qnotex,taylor,aljabr); taylor(qnotex,q,0,0); gives QUOTIENT IS NOT EXACT. (This is a bug in the LISP bignum division routine; see the message in LISP;BUG MAIL ... wgd & bmt) This bug is still happening even though JONL claims to have fixed the bignum division bug in the current LISP on 12/13. Why is this? Date: 27 DEC 1979 1158-EST From: JONL at MIT-MC (Jon L White) Subject: DEFMAX being autoloaded To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC, CWH at MIT-MC Date: 27 December 1979 04:50-EST From: Jeffrey P. Golden . . . MAXOUT;GRAMI > and MAXOUT;GRAMO > are generated by "splitting" MRG;GRAM > via the file MRG;SPLIT > , function SPLITFILE in the latter file. It is possible that the unfortunate loading of the DEFMAX stuff can be prevented by the resetting of some switch when splitting MRG;GRAM > . . . . ___ I've edited the one line necessary into MRG;GRAM >, and will leave it to you to redo the splitting and rebuilding of MACSYMA. the needed line is (declare (setq defmacro-displace-call () )) Date: 27 December 1979 04:36-EST From: Jeffrey P. Golden Why does L^K (LOAD '|MACSYM;GRAMI FASL|) cause the DEFMAX stuff to be loaded in? [Ignore the error message about MDISPATCH which occurs afterwards.] After all this is a FASL file! The previous version of MACSYM;GRAMI FASL (which I can retrieve from tape if such is desired) did not require the loading in of the DEFMAX stuff while creating a new version of MACSYMA. In case you are still wondering, if you use DEFMACRO with intention of using any of the MACROMEMO features at runtime, then you need the runtime support package (which is only about 333. words); the default is to have DEFMACRO-DISPLACE-CALL non-null, but you clearly don't want to be bothered with that for the two little macros MATCH and TELL. Date: 27 DEC 1979 0450-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, CWH at MIT-MC CC: JPG at MIT-MC P.S. The source for MACSYM;GRAMI FASL is MAXOUT;GRAMI > . The unfasl file is MUNFAS;GRAMI UNFASL. MAXOUT;GRAMI > and MAXOUT;GRAMO > are generated by "splitting" MRG;GRAM > via the file MRG;SPLIT > , function SPLITFILE in the latter file. It is possible that the unfortunate loading of the DEFMAX stuff can be prevented by the resetting of some switch when splitting MRG;GRAM > . If this is true, please tell me how to do this. It is obviously silly to have to have DEFMAX loaded in when loading in a FASL file. Date: 27 DEC 1979 0436-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, CWH at MIT-MC CC: JPG at MIT-MC Why does L^K (LOAD '|MACSYM;GRAMI FASL|) cause the DEFMAX stuff to be loaded in? [Ignore the error message about MDISPATCH which occurs afterwards.] After all this is a FASL file! The previous version of MACSYM;GRAMI FASL (which I can retrieve from tape if such is desired) did not require the loading in of the DEFMAX stuff while creating a new version of MACSYMA. Date: 27 December 1979 04:10-EST From: Jeffrey I. Schiller To: JEFFH at MIT-MC cc: BUG-LISP at MIT-MC The problem is probably being caused by a program named "guest2;ts l" that is being invoked instead of lisp when you type :l or l^K.... -Jeff Date: 27 DEC 1979 0353-EST From: JEFFH at MIT-MC (Jeff R. Head) To: (BUG LISP) at MIT-MC whenever i try l^k or :l i get the msg :$Use JCL$KILL but when i try lisp^k or :lisp i get the lisp. i4 appears to do this for me only as SJK and JPG tried it and could find no problems?? it has nothing to do with the init as the link was deleted and the problem still existed. why is this? Date: 26 DEC 1979 1416-EST From: LPH at MIT-MC (Leo P. Harten) To: (BUG LISP) at MIT-MC in macsyma, depends(y,x); ode(x*diff(y,x)+x^2+x*y^2-1/4=0,y,x); gives ;gleep! out of bit blocks Date: 25 DEC 1979 2309-EST From: JONL at MIT-MC (Jon L White) Subject: READLINE, and rubouts To: FREND at MIT-MC CC: (BUG LISP) at MIT-MC Date: 25 December 1979 02:44-EST From: M. Alexander Bloom In doing a valret out of LISP to : send a msg. I found that on the second line of my message, I was unable to use to erase any chars. I was using readline from within the function, and expected to be able to continue normally with my message after a carriage return. I dont know whethr this is a mistaken supposition of my own, a problem with lisp,ddt or crtsty, or an interaction problem beteen any of the three I'm afraid you'll have to be more specific - like a pointer to the file containing your function, and a specific sequence of input that loses. Date: 25 DEC 1979 0256-EST From: FREND at MIT-MC (M. Alexander Bloom) To: (BUG LISP) at MIT-MC Iretried the problem with valretting a :send from LISP that I described in my bug report a few minutes ago, and the bug did not occur Date: 25 DEC 1979 0244-EST From: FREND at MIT-MC (M. Alexander Bloom) To: (BUG LISP) at MIT-MC In doing a valret out of LISP to : send a msg. I found that on the second line of my message, I was unable to use to erase any chars. I was using readline from within the function, and expected to be able to continue normally with my message after a carriage return. I dont know whethr this is a mistaken supposition of my own, a problem with lisp,ddt or crtsty, or an interaction problem beteen any of the three Date: 24 DEC 1979 1232-EST From: KMP at MIT-MC (Kent M. Pitman) To: REM at MIT-MC CC: (BUG NEWIO) at MIT-MC (STATUS FILEMODE) always does return a dotted pair -- NIL is a valid list since its CAR and CDR are both defined (ie, (CAR NIL) => NIL and (CDR NIL) => NIL) (STATUS FILEMODE) can be used as an OPENP predicate since it returns non-NIL when the file is open and NIL otherwise. Date: 24 DEC 1979 1229-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG NEWIO) at MIT-MC .INFO.;NEWIO STUFF claims that (STATUS FILEMODE ) returns a dotted pair. That is correct if the file is open at the time, but if the is closed then (STATUS FILEMODE ) returns NIL. Is this a bug in LISP or is the document incorrect? I.e. can I depend on (STATUS FILEMODE ) being non-null if and only if the file is currently open? Date: 23 DEC 1979 0413-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (SSTATUS TERPRI...) also still loses for SFA's. Can we have that ask the SFA, too since it may be a TTY driver. Tnx. -kmp Date: 23 DEC 1979 0157-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Lisp doesn't seem to be asking the SFA-handler about LINEL info. This wreaks a lot of havoc. Could we have linel indirect thru the SFA handler? Thanks --kmp Date: 21 DEC 1979 2035-EST From: JONL at MIT-MC (Jon L White) Subject: lisp reader To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 21 December 1979 18:58-EST From: Glenn S. Burke The file MC:GSB;READ LOSS reads the atom 1-25-DIHYDROXY-VITAMIN-D-IN-SERUM-PER-PxLASMA incorrectly. It inserts a character where that lower-case "x" is. HELP!!!!!! Fixed and patched! P.S. - this bug has been around for ever (effectively speaking). The one instruction patched had been often executed, but was relevant only under verrrry arcane circumstances, which your file managed to produce; it is too complicated to describe here, but if you're really interested . . . Date: 21 DEC 1979 1858-EST From: GSB at MIT-MC (Glenn S. Burke) Sent-by: GSB0 at MIT-MC To: (BUG LISP) at MIT-MC The file MC:GSB;READ LOSS reads the atom 1-25-DIHYDROXY-VITAMIN-D-IN-SERUM-PER-PxLASMA incorrectly. It inserts a character where that lower-case "x" is. HELP!!!!!! Date: 21 DEC 1979 1703-EST From: MACRAK at MIT-MC (Stavros M. Macrakis) Subject: Hashing structures. To: PRATT at MIT-MC, (BUG LISP) at MIT-MC, MACRAK at MIT-MC I agree that the current SXHash is rather poor. But all schemes based on the recursion step R(a,x)+R(b,y) are bound to lose, since it is so often true that R(a+b,x)=R(a,x)+R(b,x), where R(a,x) is a rotated x positions. Equal rotations tend to happen through the tree. Some algebraic insight is missing here. Some sort of easily-computable finite binary operator with few identities is needed. Ideas? Date: 21 DEC 1979 1639-EST From: MACRAK at MIT-MC (Stavros M. Macrakis) Subject: Label is useful and should stay in Lisp. To: KMP at MIT-MC, (BUG LISP) at MIT-MC, BKPH at MIT-MC I was wrong about Label being the only way to write pure recursive Lisp, given Funcall, which I agree is nice, but on the other hand is not in Lisp 1.5, and is not universal Lisp. But I won't quibble about this. I stand on my statement that Label is useful and even an integral part of Lisp. Conceptually, it is different to Lambda-bind an atom to a function and to Label-bind it to one. One of the problems is the scope of the binding. How do you write a FUNCTION (as opposed to a function application) with this recursion? The ways I can think of are rather clumsy, since the outermost lambda must name the lambda-variables: (lambda (a b) ((lambda (f) (funcall f a b)) '(lambda (a b) ...(funcall f ...)...))). This seems clumsy to me compared to: (label f (lambda (a b) ...(f ...)...)), since you have to write the lambda-list twice, and repeat it to pass it along, and then use (funcall f ...) through the whole body instead of (f ...). The basic problem is that f is no longer a FUNCTION within the body, but rather a variable representing a function: a concept which is more appropriate for functional arguments, for instance. Since one of the strengths of Lisp is the concept of Function, it seems a pity to emasculate it. I agree entirely that the current implementation of Label is a crock, but then so are a lot of other things. Consider Store, for instance, or Pseudo-Funargs. I would be much happier with a better implementation, but terribly unhappy not to have Label at all. Date: 21 December 1979 16:03-EST From: Kent M. Pitman Subject: Label To: MACRAK at MIT-MC cc: BKPH at MIT-MC, BUG-LISP at MIT-MC The Y-Operator need not be primitive since it is possible to construct one from smaller primitives. There is no breach in power, pure recursive or otherwise, by having removed LABEL. Its implementation was a crock and it is not clear that it could be fixed at all given the current calling procedures. I personally would suggest you do a construct like the following when you think you need LABEL... ((LAMBDA (ANONYMOUS) ... body using (FUNCALL ANONYMOUS ...) where appropriate ...) (FUNCTION (LAMBDA (X) (SPECIAL ANONYMOUS) (COND ((ZEROP X) 1) (T (* X (FUNCALL ANONYMOUS (1- X)))))))) This will not confuse the compiler and is not utterly inelegant from a purist standpoint. The FUNCALL operator has a lot of aesthetic value in its own right. --kmp Date: 21 DEC 1979 1422-EST From: MACRAK at MIT-MC (Stavros M. Macrakis) Subject: Label To: BKPH at MIT-MC, (BUG LISP) at MIT-MC I agree with BKPH that Label is a useful--I would say an integral-- part of Lisp. It is the only way of writing pure recursive Lisp. There is, of course, nothing holy about its current syntax or implementation, but there must be SOMETHING which allows recursive functions without (visible) side-effects. The implementation where Label binds the function name atom's value to the function has always been somewhat peculiar, but even that can be made to work without requiring value application in general, if you're willing to sacrifice that name's ability to have global function cells, namely by giving it a subr property which points to a JCallF @vcell. This even works with mixed-in compiled code. Of course, this is a crock, and a better solution is desirable, but Label should stay in some form. Date: 20 DEC 1979 2020-EST From: KMP at MIT-MC (Kent M. Pitman) To: DICK at MIT-MC CC: (BUG LISP) at MIT-MC ; reads to end of line. if file ends in an EOF before it sees a for that ; you get an error. It's a known misfeature and will be corrected one day. Please just add a after the trailing comment for now. thanx. -kmp DICK@MIT-ML 12/20/79 20:18:44 To: (BUG LISP) at MIT-ML If you read in a file which has ";" as the last character in the file, LISP blows up with a strange error from the reader. It seems that this must have something to do with the way the ";" readin routine works. for example if you load a file containing only: (defun test () nil); you get the following LISP error ;GOT TO TTY INSIDE S-EXP - READ Dick Waters Date: 20 December 1979 15:42-EST From: Angela F. Kisich To: BUG-LISP at MIT-AI (mapcar 'and L M) where L,M are lists doesn't seem to work. Presumably the problem has to do with AND being an FSUBR, but I must say I was quite surprised by it not working (I thought I knew LISP pretty well, and I'm embarrassed not to know about this peculiarity). As a matter of principle I would say that this ought to be fixed somehow, but for the moment how do I program around it conveniently? Date: 20 DEC 1979 1156-EST From: JLK at MIT-MC (John L. Kulp) Subject: Lossage! To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 20 December 1979 10:35-EST From: Robert W. Kerns Sender: ___006 at MIT-MC I went to send mail, and found .MAIL.; completely full of an incredible number of messages to CARI complaining that font such-and-such was missing and that it used font 0 instead. There were about 120 of these messages, all sent within a short period. Presumably it stopped sending them because the directory filled; at any rate that's why COMSAT crashed. There's probably a bug or horrible misfeature there you want to do something about. Yes, it is a bug in the new LISP. I will let you know more when I track it down. The same fasl files loaded into OL don't exhibit this behavior. It is really not possible to write users programs which are completely robust in handling all possible lossage that LISP maintainers might put into the LISP system. Maybe the LISP maintainers should try to debug their code more thoroughly before releasing it? Date: 19 December 1979 03:14-EST From: Kent M. Pitman Subject: running lisp with other people's inits To: KEN at MIT-AI cc: BUG-LISP at MIT-AI Date: 18 December 1979 22:52-EST From: Kenneth Kahn To: BUG-LISP at MIT-AI Why is that the following loses :l direct; ... while :l direct;direct lisp works fine? ----- It is looking for the filename DIRECT;KEN LISP or DIRECT;* LISP. I know it doesn't adhere to conventions we all learned growing up but it is in adherence to the new hsname-init scheme and is reasonably maleable to what you need. Just rename DIRECT;DIRECT LISP to DIRECT;* LISP and you'll win with :L DIRECT; -kmp Date: 19 DEC 1979 0312-EST From: JONL at MIT-MC (Jon L White) Subject: " in compiler To: ken at MIT-AI CC: (BUG LISP) at MIT-MC Date: 18 December 1979 23:21-EST From: Kenneth Kahn Subject: double quotes and the complr ILOPR ing The following cannot be compiled by the complr (904) but causes an ilopr (declare (SETSYNTAX '/" 'MACRO '+INTERNAL-/"-MACRO)) (load "direct;print") A buggy COMPLR on AI was responsible for this glitch - has been repaired by FTPing from MC. Date: 18 DEC 1979 2325-EST From: JONL at MIT-MC (Jon L White) Subject: (LOAD "direct;print") To: KEN at MIT-AI CC: (BUG LISP) at MIT-MC For the time being, try (LOAD '"direct;print") - this is compatible both with current maclisp and other systems. Date: 18 December 1979 23:21-EST From: Kenneth Kahn Subject: double quotes and the complr ILOPR ing To: BUG-LISP at MIT-AI The following cannot be compiled by the complr (904) but causes an ilopr (declare (SETSYNTAX '/" 'MACRO '+INTERNAL-/"-MACRO)) (load "direct;print") Date: 18 December 1979 22:52-EST From: Kenneth Kahn Subject: running lisp with other people's inits To: BUG-LISP at MIT-AI Why is that the following loses *:l direct; DIRECT IOCERROR: - FILE NOT FOUND CHNL NOT OPEN 126372>>.IOT 1 1/ 73 while :l direct;direct lisp works fine? Date: 18 DEC 1979 1606-EST From: JONL at MIT-MC (Jon L White) Subject: SXHASH To: PRATT at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 December 1979 10:46-EST From: Vaughan Pratt Subject: SXHASH Why does permuting with sxhash have to be one or the other of car and cdr? Why can't it be both, e.g. rotate left with the car and right with the cdr? (Though frankly I'd prefer something a little more drastic than a mere rotation.) In the file JONL;RHSH >, you will find some routines which I have used to experiment with various s-expression hashing algorithms. I'f you'd like to try out some, and send me your conclusions . . . Date: 18 DEC 1979 1542-EST From: REM at MIT-MC (Robert Elton Maas) Subject: For SCHEME hackers and interested parties only To: (BUG LISP) at MIT-MC JONL suggested I pass this idea along. There are two ways to conditionally build a list (and return it). (1) MAPCAN (2) DO loop with conditional PUSH, with NREVERSE at return. We believe that MAPCAN is cleaner, because SCHEME et al could more easily co-routine it and thus avoid building structure if the only use of the list (by the calling procedure) will be to map down it once and throw it away. For example, LIBDOC;ARYFIL > is done the "wrong" way. Date: 18 DEC 1979 1238-EST From: JONL at MIT-MC (Jon L White) To: REM at MIT-MC CC: (BUG LISP) at MIT-MC Date: 17 December 1979 16:46-EST From: Robert Elton Maas Storage occupied by FIXNUM arrays doesn't show up in (STATUS SPCSIZE 'FIXNUM) nor anywhere else in (MAPCAR (FUNCTION (LAMBDA (S) (STATUS SPCSIZE S))) (STATUS SPCNAMES)) Is there some way to find out about such storage? The data part of all arrays are stored in the high end of a contiguous space, of which the low end is binary program space; in addition, each array needs two words from an "array header" space, which space name is called "ARRAY". In order to see what arrays are in use, look at the package LIBDOC;ARYFIL > (compiled code on LIBLSP;ARYFIL FASL). Date: 17 December 1979 16:30-EST From: Robert Elton Maas Gee, my goodness, "LIST STORAGE CAPACITY EXCEEDED BEYOND RECUPERATION ;MAJOR RESTART UNDERTAKEN ;GC DUE TO STARTUP" -- What does all this mean? In order to run a user-supplied break loop (or any other corrective action which can potentially call CONS), the storeage manager must allocate a few segments of more LIST space; but if this is impossible, for whatever reason, then you lose (reasons include, no more address space, no more "core" available from operating system). Date: 18 December 1979 10:46-EST From: Vaughan Pratt Subject: SXHASH To: JONL at MIT-MC cc: BUG-LISP at MIT-AI Why does permuting with sxhash have to be one or the other of car and cdr? Why can't it be both, e.g. rotate left with the car and right with the cdr? (Though frankly I'd prefer something a little more drastic than a mere rotation.) Date: 17 DEC 1979 1646-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC Storage occupied by FIXNUM arrays doesn't show up in (STATUS SPCSIZE 'FIXNUM) nor anywhere else in (MAPCAR (FUNCTION (LAMBDA (S) (STATUS SPCSIZE S))) (STATUS SPCNAMES)) Is there some way to find out about such storage? Date: 17 DEC 1979 0046-EST From: JONL at MIT-MC (Jon L White) Subject: SXHASH To: PRATT at MIT-MC CC: (BUG LISP) at MIT-MC Date: 15 December 1979 18:51-EST From: Vaughan Pratt Any chance of getting sxhash a little more random? At present it maps all permutations of a list to the same number, . . . Probably not - SXHASH is used by faslap/fasload in a "heuristic" way, but the gain to them by changeing sxhash is too small to be worth the risk of new bugs; likely in NIL, we'll define sxhash to permute in the CAR direction instead of the CDR direction, and thus satisfy most users. If you use the built-in SXHASH for atoms, it would be almost trivial to write your own version of it for non-atoms. It would also be nice if atoms were hashed a little more thoroughly - at present (A Z), (B Y), (C X) etc. all hash to the same thing. All these coincidences wreak havoc with any program using sxhash to implement its own obarray. Yea, this coincidence is unfortunate. I think if you had a version of sxhash which permuted down the car direction instead of teh cdr, you wouldn't be bothered by its peculiarities. (The reason why you "want" it to permute down one of the directions is so that the recursive definition of sxhash will be some understandable piece of code in which the sxhash of a particular node is definable in terms of the sxhash's of the car and cdr of that node.) Date: 16 DEC 1979 1555-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: (DISPLACE FOO ()) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Patched, installed on ITS, and fixed in the source. Date: 16 DEC 1979 1500-EST From: ALAN at MIT-MC (Alan Bawden) Subject: All I do is complain. To: (BUG LISP) at MIT-MC Well thanks very much for patching my displace bug in L (now OL), it would have been nice if you had patched XL (now L) at the same time as that is the one I was/am using! Date: 16 December 1979 09:58-EST From: Alan Bawden To: FREND at MIT-MC cc: BUG-LISP at MIT-MC Date: 16 DEC 1979 0800-EST From: FREND at MIT-MC (M. Alexander Bloom) Why does (equal x '||) give T when x has been assigned '|| by setq, but give nil when x gets (seemingly) the same value from readline? I tested the result from (setq x (readline t)) and got || but this failed in the (equal x '||) Is there a reason for the null string to have more than one internal value? This is not a bug. First of all there is nothing magic about symbols whose name is "". If you try (setq a (readline))foo the value of a will be a symbol named "foo". But you will find that (equal '|foo| a) returns nil. This is because there is nothing in lisp to prevent you from having two symbols with the same name. Perhaps some further explanation is in order. Symbols returned by READ are uniquized by registering them in a table called the "obarray", this process is called "interning" and gaurantees that READ will never return two different symbols with the same name. Some other functions that handle symbols also intern them, IMPLODE, for example, takes a list of characters (expressed as fixnums or symbols) and returns you an interned symbol whose name is made up of those characters. There is also a function INTERN which a takes a symbol and returns you a symbol with the same name that is registered on the obarray. The function READLINE doesn't bother to return an interned symbol, since when you call READLINE you are probably going to do string-like operations on the result and so you don't care about whether you have a unique copy of that symbol. The function EQUAL compares symbols not by looking at their names, but simply by looking to see if they are the SAME object (what the function EQ does), this is done mostly for efficiency's sake and is a small price to pay since it is usually what you want (so don't suggest that we make THAT change). I suspect that what you want is the function SAMEPNAMEP which takes two symbols and compares their names to see if they are the same and returns T if they are. This is the function to call if you are treating symbols as just plain strings. Date: 16 DEC 1979 0800-EST From: FREND at MIT-MC (M. Alexander Bloom) To: (BUG LISP) at MIT-MC Why does (equal x '||) give T when x has been assigned '|| by setq, but give nil when x gets (seemingly) the same value from readline? I tested the result from (setq x (readline t)) and got || but this failed in the (equal x '||) Is there a reason for the null string to have more than one internal value? Date: 15 DEC 1979 1851-EST From: PRATT at MIT-MC (Vaughan Pratt) To: (BUG LISP) at MIT-MC Any chance of getting sxhash a little more random? At present it maps all permutations of a list to the same number, making it entirely useless when you're dealing with such permutations. (E.g. when I'm operating on the two formulas (OR P Q) and (OR Q P) in connection with proving the theorem that they are equivalent, both hash to the same thing.) It would also be nice if atoms were hashed a little more thoroughly - at present (A Z), (B Y), (C X) etc. all hash to the same thing. All these coincidences wreak havoc with any program using sxhash to implement its own obarray. Date: 15 December 1979 02:31-EST From: Jeffrey I. Schiller To: BUG-LISP at MIT-MC In lisp 1877 on Speech-Twenex: (setq foo (open '|foo.bar| '(out ascii))) ==> #FILE-OUT|foo.bar.1|-64772 (princ '|This is a test| foo) ==> T (terpri foo) ==> NIL (force-output foo) ==> T (close foo) ==> T Foo Bar now contains: This is a test This is a test Thats right, the output is done twice, once at the force-output, and once during the close, looks like force-output isn't flushing the output-buffer. -Jeff Date: 13 DEC 1979 1122-EST From: JONL at MIT-MC (Jon L White) Subject: DEFVST To: (BUG LISP) at MIT-MC If you give a &rest component a size initialization, it still always takes the default value. e.g. (DEFVST BANK &REST VAULTS 30.) and then (CONS-A-BANK VAULTS 4) still makes a bank with 30. vaults. Date: 13 DEC 1979 1006-EST From: JONL at MIT-MC (Jon L White) Subject: MC:LISP;* OFASL To: (BUG LISP) at MIT-MC A lot of OFASL files were just deleted, since the directory is perilously close to being FULL! Date: 13 DEC 1979 0837-EST From: JONL at MIT-MC (Jon L White) Subject: LOBOTOMY, and the (maybe found?) BIGNUM BUG To: BMT at MIT-MC CC: (BUG LISP) at MIT-MC The bignum bug you reported the other day is a quotient which seems to exercise some code in the BIGNUM package at BQC1:, and I don't see why that code is there; happily, if I flush the code, there is no bug in your division. So I'm rather blindly flushing it, and have run many minutes of random bignum divisions to see that almost no other cases exercise this code. The hairy cases found by RWG and noted in the source listing don't enter in here. Possibly only divisions where the quotient is equal to a number of the form 1+2^N for N > 36., will exercise this code, and in all cases I've inspected, the removal of the (buggy) code seems to be the right thing to do. I've patched this in to lisp and xlisp. Date: 12 DEC 1979 1640-EST From: ALAN at MIT-MC (Alan Bawden) Subject: It can't be that hard to fix!!!!!!!! To: (BUG LISP) at MIT-MC This is the third time I have complained about this. (I thought it would be fixed in XL, so I tried it and it wasn't) (displace '(1 2 3) nil) (NIL) Wrong. Wrong! WRONG! The answer should be (PROGN NIL), got that? PLEASE? Date: 12 DEC 1979 1426-EST From: JONL at MIT-MC (Jon L White) Subject: (affirmed!) BIGNUM BUG To: GSB at MIT-MC, BMT at MIT-MC CC: (BUG LISP) at MIT-MC Date: 12 December 1979 13:10-EST From: Glenn S. Burke Subject: (alleged) BIGNUM BUG I, if i were into clobbering files, would take the liberty of editing the file as follows: (SETQ C 118937307725496656754857164120791261365228885. D 6296488643826193618261. Q (QUOTIENT C D) R (REMAINDER C D) C* (PLUS (TIMES Q D) R) BMTLOSES (EQUAL C C*) LISPLOSES (EQUAL R D)) and you will in fact find that LISPLOSES is T. Sigh, yes, LISPLOSES is indeed true. Will investigate shortly. Notice the representation of these numbers in base 8: C = 5252525252525252525252525252525252525252525252525 D = 1252525252525252525252525 Q = 4000000000000000000000000 R = 1252525252525252525252525 Looks like that "one chance iin 2^35."? Date: 12 December 1979 13:10-EST From: Glenn S. Burke Subject: (alleged) BIGNUM BUG To: JONL at MIT-MC, BMT at MIT-MC cc: BUG-LISP at MIT-ML I, if i were into clobbering files, would take the liberty of editing the file as follows: (SETQ C 118937307725496656754857164120791261365228885. D 6296488643826193618261. Q (QUOTIENT C D) R (REMAINDER C D) C* (PLUS (TIMES Q D) R) BMTLOSES (EQUAL C C*) LISPLOSES (EQUAL R D)) and you will in fact find that LISPLOSES is T. Date: 12 DEC 1979 1138-EST From: JONL at MIT-MC (Jon L White) Subject: (alleged) BIGNUM BUG To: BMT at MIT-MC CC: (BUG LISP) at MIT-MC Date: 11 December 1979 13:44-EST From: Barry M. Trager (remainder c d) returns incorrect result should be zero, c and d defined in bmt;bignum bug. I took the liberty of editing BMT;BIGNUMB BUG slightly as follows ;;; -*- Mode: LISP; Package: Macsyma; -*- Saved by BMT (SETQ C 118937307725496656754857164120791261365228885. D 6296488643826193618261. Q (QUOTIENT C D) R (REMAINDER C D) C* (PLUS (TIMES Q D) R) BMTLOSES (EQUAL C C*)) Both in LISP and in NLISP the remainder seems to have been calculated correctly. Date: 12 DEC 1979 1012-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC Oops, intended addendum to previous: The reason I am sending this is I don't see why any change was made in that vicinity so I may have in turn broken something. This is at SUSP3+46 or so. Date: 12 DEC 1979 1007-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: SUSPEND and (STATUS UDIR) To: (BUG LISP) at MIT-MC I found the following: SA% PUSHJ P,SUNAME .... MOVEM A,SUDIR Clearly bogus. I made it SA% IT% PUSHJ P,SUNAME IT$ .SUSET [.RSNAME,,TT] IT$ PUSHJ P,SIXATM .... MOVEM A,SUDIR Date: 12 DEC 1979 0943-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: (PROGN (SUSPEND) (STATUS UDIR)) To: (BUG LISP) at MIT-MC after a SUSPEND, (STATUS UDIR) returns the UNAME. This breaks the compiler among other things. Date: 11 DEC 1979 1344-EST From: BMT at MIT-MC (Barry M. Trager) To: (BUG LISP) at MIT-MC (remainder c d) returns incorrect result should be zero, c and d defined in bmt;bignum bug. Date: 11 DEC 1979 1031-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC Could you get a LPT-readable version of you FORMAT documentation on line somewhere? The old format was more-or-less taken directly from the LISPM, and had the documentation of capabilities on the first page, but your source code "diverts" this elsewhere and from many points in the file. The file LSB;FORMAT XGP is not suitable. GSB@MIT-ML 12/11/79 04:56:12 Re: FORMAT To: gls at MIT-AI CC: (BUG LISP) at MIT-MC, MOON at MIT-MC gls@MIT-AI (Sent by GJS@MIT-AI) 12/10/79 17:19:46 Re: FORMAT [1] Let ~:P be the same as ~P, but first do "~-1*" (which doesn't really work, I think, but it should); that is, it uses the last argument rather than the current one. 99.999% of the time I write something like (LET ((N (FROB-COUNT))) (FORMAT T "... ~D frob~P..." ... N N ...)), and it would be so much easier to write (FORMAT T "...~D frob~:P..." ... (FROB-COUNT) ...) [Sub-wish: with the @ flag, then insert "y" or "ies" depending on whether the argument (selected by the : flag) is 1 or not. Theree are weays of beiung more general, such as inventing a flag to ~[ which predicates the conditional on the 1-ness of an argument...] Comments? The colon and atsign flag suggestions sound good. By the way, "~-1*" works except that the negative number isn't recognized in the string, but can be passed in ("~v*" ... -1). ~@[ is still open for assignment... [2] Invent and as flag characters like : and @, which force the case of output for the modified command. This would be especially useful for the ~A, ~C (changes case of argument before printing, not the "Control-" etc. strings), and ~R commands. Both flags together means capitalize? Let me think on this. What i have always envisioned as the way to case switch, however, has been to have an indirection stream and some state (which it uses to decide which way it wants to switch, and whether to capitolize or not). [3] Let some command or combination of flags to ~S mean to call the grinder. The problem here is determining which pretty-printer should be used; i suppose it could funcall a special variable which defaults to SPRIN1. (I personally don't like the sprinter's heuristics; i use a different pretty-printer.) I don't think it should be on ~S, however; presumably you could always define ~\pp\ to do exactly what you want. Ie, (DEFUN (PP FORMAT-CTL-ONE-ARG) (ARG PARAMS) (AND COLON-FLAG (TERPRI STANDARD-OUTPUT)) (SPRIN1 ARG STANDARD-OUTPUT)) [4] Let some combination of flags to ~C mean use C- and M- rather than Control- and Meta-. Did you try ~@C ? ---------------- Take a look at ML:LSB;FORMAT XGP. As for case hacking etc., i guess the question is do we want FORMAT to hack this, or is what we want a better mechanism for hacking with text and still having symbolic operators? For this, take a look at ML:XLSB;%FORMA XGP (i'll make one up). GSB@MIT-ML 12/10/79 08:47:05 Re: format To: WJL at MIT-ML, RWK at MIT-MC CC: (BUG LISP) at MIT-ML The semantics of some of the parameters to the ~< operator have changed a bit, and a bug in the filling algorithm has been fixed. The modified documentation will be in ML:LSB;FORMAT XGP until such time as someone decides that that xgp file shouldn't be taking up disk space... Also, Moon has put this operator into the lispm format. GSB@MIT-ML 12/09/79 06:49:43 Re: mar hackery To: KMP at MIT-ML, (BUG LISP) at MIT-ML, RWK at MIT-MC You cannot count on the mar always aborting the instruction which does the clobberage, because that isn't supported on KA's. This means you can't get the old value when you get the mar interrupt. My guesses on what is happening are as follows: As i remember, SETQ type stuff (interpreted) has some hair for detecting setq's of pure value cells which involves it ignoring interrupts until it gets through some region of code. The mar interrupt turns itself off when it gets signaled. Thus, the frob has been bashed by the time you get the interrupt, and it doesn't loop. Rplaca apparently has no such crock, so (on a KL) you get the interrupt before the bashing has occured. There is a pc flag which gets set to cause one instruction to ignore the mar, which enables one to not have this looping. My guess is that the code which returns from a user interrupt either doesn't restore the pc flags (or they were never saved) or it causes an extra instruction to get executed after they are restored but before the aborted instruction is reached. I tend to think the latter; this would be the same type of lossage which causes one to get a return-to-ddt when single stepping at CPXDJ if there is a tty-return handler, even if it does nothing. Either this extra instruction crock should get fixed (rah! rah!) or lisp could cause the "aborted" instruction to never get aborted somehow, eg by xct-ing it if that flag in .MARPC isn't set. Date: 9 DEC 1979 0236-EST From: KMP at MIT-MC (Kent M. Pitman) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, WGD at MIT-MC, KMP at MIT-MC, JIM at MIT-MC If you get time, can you look at this: (LOAD '((DSK TURNIP) XHOOK FASL)) (MAR-TRACE 'A) ; Note that this MAR-TRACE, tho' implemented as a Macro, takes ; its args in SUBR (evaluable) fashion.... (SETQ A 3) ;A set to 3 ;** Break? n [No] (SETQ B '(A B C)) (MAR-TRACE B) ; Trace value of B (RPLACA B 'FOO) ;(A B C) has been bashed ;** Break? n [No] ;(A B C) has been bashed ;** Break? n [No] ;(A B C) has been bashed ;** Break? n [No] ... etc. [1] For SETQ's, the MAR interrupt seems to happen after the assignment. For RPLACA's it happens before. Both should happen before and some hook should be available for finding the old and new values. [2] In any case, the RPLACA seems to get in an infinite loop no matter what and refuses to ever change its value ... This is proving to be a useful debugging tool to JIM, WGD, and myself for some obscure bugs in Macsyma, but we'd like it to work correctly. Can you take a look at it? I can't make heads or tails of what's going on... Thanks. -kmp Date: 7 December 1979 19:35-EST From: Robert W. Kerns To: RIVEST at MIT-ML cc: BUG-LISP at MIT-MC Date: 12/06/79 22:38:36 From: RIVEST at MIT-ML To: (BUG LISP) at MIT-ML The way arrays are (mis-)handled in LISP is annoying. In particular, it would be nice to be able to pass arrays to functions in a simple manner. ... Comments? Ron Rivest (RIVEST@ML) Just one. LISP has been treating arrays as first class citizens since LISP 810, of April 1974! See LISP;LISP NEWS for full details, in particular ARRAYCALL. This goes beyond even out-of-dateness of documentation, this is ANCIENT documentation. ARRAYCALL didn't even make into the update to the manual of 1975! Date: 6 DEC 1979 2301-EST From: KMP at MIT-MC (Kent M. Pitman) Sent-by: ___044 at MIT-MC Subject: Oops. To: (BUG LISP) at MIT-MC apologies for long message. I meant to Un-CC bug lisp and just tell you I'd answered him, but hit ^C before I remembered. -kmp Date: 6 DEC 1979 2259-EST From: KMP at MIT-MC (Kent M. Pitman) Sent-by: ___044 at MIT-MC Subject: Un-named arrays To: RIVEST at MIT-ML CC: (BUG LISP) at MIT-MC, (FILE [AR1:KMP;NAMED ARRAYS]) at MIT-MC You should not be using the (ARRAY ...) but instead use the syntax: (SETQ MYARRAYVARIABLE (ARRAY NIL T n)) is what you want. The idea of putting things on the property list is semantically hideous anyway since it cannot be bound. Put the object only in the value cell and you will be much better off... (ARRAY () type dim1 dim2 ...) returns an array object rather than putting it on the property list. You can call this array by doing (ARRAYCALL type arrayobject subscript1 subscript2 ...) and you can store into it with (STORE (ARRAYCALL type arrayobject subscript1 ...) val) If you dislike using arraycall, define a macro to handle the calling. Eg, here is a sample piece of code using this scheme... ; Define (FOO sub1 sub2 ...) to mean (ARRAYCALL T FOO sub1 sub2 ...) (DEFUN FOO MACRO (X) `(ARRAYCALL T ,@(CDR X))) (DEFUN BAR () (LET ((FOO (ARRAY () T 10.))) ; Create a 10-length T-type array in FOO (BAZ FOO) ; Call some function BAZ with FOO array (DO ((I 0. (1+ I))) ; Loop I 0,1,... ((= I 10.)) ; thru I=9 (PRINT (LIST I (FOO I)))))) ; Printing (i foo[i]) ;;; Initialize ARRAYOBJECT to a bunch of random values (DEFUN BAZ (ARRAYOBJECT) (DO ((I 0. (1+ I))) ((= I 10.)) (STORE (ARRAYCALL T ARRAYOBJECT I) (RANDOM)))) RIVEST@MIT-ML 12/06/79 22:38:36 To: (BUG LISP) at MIT-ML The way arrays are (mis-)handled in LISP is annoying. In particular, it would be nice to be able to pass arrays to functions in a simple manner. Couldn't we do the following: -- let (ARRAY X T n) set the value of X to the same as its ARRAY property. -- this extension makes all old code work OK (as long as a symbol is not using BOTH its array and value properties, an unlikely occurence due to the confusion it engenders. -- Now, whenever a form (X a1 a2 ...) is evaluated, another special case can be added to check to see if the VALUE of X is an array-object. -- This allows arrays to be treated as full-fledged citizens, just as hunks and lists are. Comments? Ron Rivest (RIVEST@ML) Date: 6 December 1979 16:42-EST From: Robert W. Kerns To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 6 December 1979 11:53-EST From: Kent M. Pitman To: BUG-LISP I dumped something in XLISP about 3 or 4 days ago and yesterday got a LOSE - Can't find pure whatever mumble message when I tried to run it. I'm going to stop using XLISP for dumps if it doesn't stay more stable than this -- this is at least the second time in two weeks that I've gotten such a screw. What do you think the "X" in "XLISP" stands for? Certainly not Xtability! Date: 6 DEC 1979 1159-EST From: JONL at MIT-MC (Jon L White) Subject: DESETQ To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 12/05/79 20:05:02 To: (BUG LISP) at MIT-ML (desetq (nil (nil nil foo) bar) zz) doesn't work. Fixed. Date: 6 DEC 1979 1158-EST From: JONL at MIT-MC (Jon L White) Subject: SUSPENDing in XLISP To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC You shouldn't be using the (SSTATUS FLUSH 'T) option, which is why you lost as noted: Date: 6 December 1979 11:53-EST From: Kent M. Pitman I dumped something in XLISP about 3 or 4 days ago and yesterday got a LOSE - Can't find pure whatever mumble message when I tried to run it. I'm going to stop using XLISP for dumps if it doesn't stay more stable than this -- this is at least the second time in two weeks that I've gotten such a screw. You don't really save space by requiring us to keep around all those intermediate version of XLISP (probably 10 in the past month), and worse yet, there is no correspendent of the file LISP;LOCK > Date: 6 DEC 1979 1153-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC I dumped something in XLISP about 3 or 4 days ago and yesterday got a LOSE - Can't find pure whatever mumble message when I tried to run it. I'm going to stop using XLISP for dumps if it doesn't stay more stable than this -- this is at least the second time in two weeks that I've gotten such a screw. Date: 6 DEC 1979 0429-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: RWG at MIT-MC, REM at MIT-MC CC: (BUG LISP) at MIT-MC, MOON at MIT-MC RWG@MIT-MC 12/05/79 22:42:04 To: JPG at MIT-MC, MOON at MIT-MC rem's numrel pkg, which is basically iterative, seems to give pdl oflo from gc every hr or so. is the kl known to be flakey, or is this likely to be a lisp bug? Most likely a LISP bug. GSB@MIT-ML 12/05/79 20:05:02 To: (BUG LISP) at MIT-ML (desetq (nil (nil nil foo) bar) zz) doesn't work. Date: 5 DEC 1979 0353-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: TRUENAME To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC I have fixed TRUENAME and the PDL-out-of-phase problem, and installed the new XLISP on all ITSs 'cept DM. Am considering DM. TRUENAME used to make T refer to TYO, so I made it do so again. However, this seems like nonsense to me...why not TYI? But I suppose it's compensatory nonsense for the nonsense of "T" as a file ... why treat it as an error? GSB@MIT-ML 12/05/79 01:52:29 To: (BUG LISP) at MIT-ML The "NOT FILE" wrng-type-arg error from TRUENAME will return the file returned from the break loop, and then the pdls will be out of phase. Date: 4 December 1979 10:16-EST From: "Guy L. Steele, Jr." Subject: [1] LIST* [2] LOAD-BYTE To: MOON at MIT-AI, JONL at MIT-MC cc: GLS at MIT-AI, BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI [1] LIST* of zero arguments ought to be an error, as has already been pointed out. I originally wanted (LIST* a) => a, but forget whether that was done originally or not. [2] [a] Regarding byte pointers, the LISP Machine syntax still has the two severe disadvantages that (i) you can't parse it unless it is in octal notation, and (ii) the byte size is limited to 63 decimal. I have in the past suggested that a function BPTR be introduced such that (BPTR p s) takes two non-negative fixnums p and s and produces a byte pointer. The nature of this pointer is machine- dependent, but may be given to the LOAD-BYTE etc. functions and be expected to work. Probably also there would have to be functions BPTR-SIZE and BPTR-OFFSET to extract the s and p numbers from a byte pointer. The advantages of this are several. (i) Neither p nor s is limited in value by these definitions. (ii) The precise representation of a byte pointer can be machine-dependent for greater efficiency. For example, the LISP Machine byte pointer format is not suitable for the VAX. (iii) When writing (BPTR p s) one can write p and s in whatever radix one pleases. [b] Regarding left-to-right versus right-to-left, I would suggest that bits always come out in right-to-left order *when converted to fixnums* for the reasons expounded by Moon. Thus (LOAD-BYTE #B"0101100" (BPTR 2 3)) produces the fixnum 6. (Are not bits naturally numbered this way anyway in the VAX?) For machine-@dependent crocks, a machine-dependent set of primitives may also extract byte in whatever way is convenient for the machine. The S-1 will store bits in left-to-right order (bag-biters they), but the compiler will gladly output bit-reverse instructions to keep this compatible interpretation (eliding them when possible). Date: 4 DEC 1979 0935-EST From: JONL at MIT-MC (Jon L White) Subject: LOAD-BYTE etc, and order of bit numbering To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC, NIL-IMPLEMENTATION at MIT-MC Date: 3 December 1979 22:46-EST From: David A. Moon Subject: LOAD-BYTE and DEPOSIT-BYTE . . . dependency is that the arithmetic value of a fixnum containing a certain pattern of bits depends on the word length; if the bits were numbered from right to left it would not depend, provided only that the number of bits was small enough to fit in a word. Yea, this is the critical point as to why one has to have LDB as well as LOAD-BYTE, namely that for READ/PRINT purposes one would like to have a word-size-independent means of representing "bytes" (if there is no I/O, using integers, why would one care what the numerical value of a "byte" is?) In NIL, we have the BITS data type, which is the preferred means for I/O of bytes; only when converting from fixnums to BITS is there the ambiguity of "scaling" and "ordering" (right-to-left, or left-to-right). Likely this means that LOAD-BYTE will be used only in explicitly machine-dependent code; there are no usages of it in the NIL system now (only in the maclisp virtual-machine support), but rather we depend on the conversions from BITS to integers and vice-versa. By the bye, code is not made machine-independent merely by using only machine-independent primitives - your whole machine may be Godel'd into a bunch of numbers, to which you apply only standard arithmetic primitives. Date: 3 DEC 1979 2246-EST From: MOON at MIT-MC (David A. Moon) Subject: LOAD-BYTE and DEPOSIT-BYTE To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC The machine dependency I referred to is not that you are limited by the length of the word (assuming they only support fixnums). The machine dependency is that the arithmetic value of a fixnum containing a certain pattern of bits depends on the word length; if the bits were numbered from right to left it would not depend, provided only that the number of bits was small enough to fit in a word. This is particularly important when you have constants, and is one of the reasons why I feel bits should be numbered from right to left whenever possible. In fact, we changed the Lisp machine from left-to-right to right-to-left several years ago for this reason among others. Date: 3 December 1979 20:15-EST From: Robert W. Kerns Subject: The Animal game uncovers more bugs... To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, EJS at MIT-MC Date: 3 December 1979 20:05-EST From: Kent M. Pitman To: BUG-LISP cc: EJS, RWK Re: The Animal game uncovers more bugs... Lisp seems to be quitting with a .LOGOUT 0, rather than a .LOGOUT 1, -- can this be changed? It's confusing the game program which thinks it is getting a .VALUE of sorts instead of a quit. Thanks. -kmp No, it IS getting an ILLOPR ... I changed it. I didn't patch it, but can do so if you want.... Date: 3 DEC 1979 2005-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: The Animal game uncovers more bugs... To: (BUG LISP) at MIT-MC CC: EJS at MIT-MC, RWK at MIT-MC Lisp seems to be quitting with a .LOGOUT 0, rather than a .LOGOUT 1, -- can this be changed? It's confusing the game program which thinks it is getting a .VALUE of sorts instead of a quit. Thanks. -kmp Date: 3 DEC 1979 0736-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC Cancel that, I was confused, prinlevel actually was so very terse that I saw normal output afterward and thought it was part of the prinlevel output. It must be getting bedtime... Date: 3 DEC 1979 0732-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC Hmmm, PRINLEVEL or whatever used by the STEP package prints forever when given a list of the form (10 (12 (13 (x ...) ...) ...) ...) if x is the (12 ...) object. I.e. it fails to detect CADADR loops. Date: 3 DEC 1979 0424-EST From: KRAMER at MIT-MC (Scott J. Kramer) Subject: Twenex GRIND - lose lose To: (BUG LISP) at MIT-MC The GRIND function on Twenex is losing badly, the following output was produced on XX: This was the file prior to running GRIND (mashed intentionally to demo bug): (defun y-n () (clear-input tyi) (princ '|(Y or N)? |) ((lambda (char) (cond ((or (= char 89.) (= char 121.)) (princ '|es| tyo)) ((or (= char 78.) (= char 110.)) (princ '/o tyo) nil) (t (y-n)))) (tyi))) This was the resulting output: (DEFUN Y-N NIL (CLEAR-INPUT TYI) (PRINC '|(Y or N)? |) (( LAMBDA (CHAR) (COND ((OR (= CHAR 89.) (= CHAR 121.)) (PRINC '|es| TYO))((OR ( = CHAR 78.) (= CHAR 110.)) (PRINC '/o TYO) NIL)(T (Y-N))))(TYI))) I think the bug is in GRINDEF, but I am not sure where to look as I am not familiar with the workings of that program. Running GRINDEF on the function within Lisp works fine. Scott Date: 1 December 1979 23:53-EST From: Robert W. Kerns To: JONL at MIT-MC cc: GSB at MIT-MC, BUG-LISP at MIT-MC Date: 1 December 1979 12:15-EST From: Jon L White To: RWK, GSB cc: BUG-LISP I was under the impression from talking with Glenn last spring (or was it summer?) that he would polish up his FORMAT package, and we'd replace the one on LISP: with it. Done. We didn't put it on XX yet though. The previous FORMAT package is in OFORMAT FASL. Date: 1 December 1979 23:39-EST From: Robert W. Kerns To: EB at MIT-ML cc: BUG-LISP at MIT-MC Date: 12/01/79 15:20:21 From: EB at MIT-ML To: (BUG LISP) at MIT-ML Are the following supposed to work differently in the interpreter and compiler, as they do? (defun f macro (m) (cond ((eq (cadr m) '+) 'plus) ((eq (cadr m) '-) 'difference) (t (error)))) (defun foo+ (x y) ((f +) x y)) (defun foo- (x y) ((f -) x y)) In the Interpreter, PLUS or DIFFERENCE is an unbound variable. In the compiler, the function PLUS or DIFFERENCE is JCALLed, or so the LAP claims. This is indeed not supported in the interpreter. No plans to change it exist. NIL will probably support it, but I'm not convinced it's a win. EB@MIT-ML 12/01/79 15:20:21 To: (BUG LISP) at MIT-ML Are the following supposed to work differently in the interpreter and compiler, as they do? (defun f macro (m) (cond ((eq (cadr m) '+) 'plus) ((eq (cadr m) '-) 'difference) (t (error)))) (defun foo+ (x y) ((f +) x y)) (defun foo- (x y) ((f -) x y)) In the Interpreter, PLUS or DIFFERENCE is an unbound variable. In the compiler, the function PLUS or DIFFERENCE is JCALLed, or so the LAP claims. Date: 1 DEC 1979 1335-EST From: JONL at MIT-MC (Jon L White) Subject: STORE To: RG at MIT-MC CC: (BUG LISP) at MIT-MC Date: 21 November 1979 16:26-EST From: Richard Greenblatt Subject: Change to STORE MOBY FOO!!! This will break lots of old code. Furthermore, there is no reason for doing it, since STORE is obsolete anyway. I STRONGLY object. Let sleeping crocks lie. You're quite right. The main intent was for SETF to work fully correctly in the left-to-right evaluation order, and we can do this without changing STORE. (So far, only the interpreter had been changed, but correct compilation *is* feasible, by hassling the compiler to push and pop "LISAR" when compiling STORE, but . . .). We'll have an XLISP out pronto with STORE re-STOREd to its full crockish glory. Likely, we will have to introduce some new construct for SETF which would be equivalent to the AREF/ASET of LISPM, so that one gets the advantage of compatible order of compilation without having to specify the array type as required by ARRAYCALL. But that's not been done yet. Sorry for delay in replying - was on mini vacation visiting parents just after Thanksgiving. Date: 1 DEC 1979 1323-EST From: JONL at MIT-MC (Jon L White) To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC Re: Date: 21 November 1979 17:54-EST From: David A. Moon Subject: lisp; new recent To: BUG-LISP at MIT-MC cc: MOON at MIT-MC . . . LOAD-BYTE and DEPOSIT-BYTE do not work exactly as documented. The documentation needs to make clear that the bit position is the number of the high-order bit counting from LEFT TO RIGHT, i.e. the number of bits to the left of the byte IN A FIXNUM. Better than this crockish machine-dependency would be to number the bits from right to left in the standard way, as LDB and DPB do, avoiding dependency on machine word-length. Consider what LOAD-BYTE and DEPOSIT-BYTE would do in NIL. I've inserted the following into the documentation for LOAD-BYTE As in standard PDP10 terminology, bits are numbered from high-order to low-order ("left-to-right") with the high-order bit being 0. The idea here is that a fixnum is being used as a mini bit string. In NIL, the correspondent, BITS's, would definitely be numbered from left to right, and there may still be the need to have some "mini bit string" capability for FIXNUMs (no consing, etc). However, you may be looking at the question in the wrong light - there is no more of a machine-dependency in the scheme which "counts" from the left than in one which "counts" from the right. Both are equally limited by the wordsize of the machine. Date: 1 DEC 1979 1215-EST From: JONL at MIT-MC (Jon L White) To: RWK at MIT-MC, GSB at MIT-MC CC: (BUG LISP) at MIT-MC I was under the impression from talking with Glenn last spring (or was it summer?) that he would polish up his FORMAT package, and we'd replace the one on LISP: with it. Date: 1 DEC 1979 1202-EST From: JONL at MIT-MC (Jon L White) Subject: TOPS-20 version of Johan's LEDIT To: miller at MIT-AI CC: (BUG LISP) at MIT-MC I fiddled a bit with the source for this, to get it to work "a little bit" on TOPS-20, but it's not completely working yet. I don't have time to look at it again (for a while), but the fiddled source is on MC:JONL;TNXLED > Date: 1 DEC 1979 1137-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC Right! Date: 1 DEC 1979 1136-EST From: JONL at MIT-MC (Jon L White) To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC Date: 1 December 1979 11:33-EST From: Jeffrey P. Golden To: BUG-LISP at MIT-MC Date: 1 DEC 1979 1116-EST From: JONL at MIT-MC (Jon L White) To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC . . . ------------------------------------------- Sorry to belabor this issue, but for the record some MACSYMA save files contain exactly such symbols. That's how quoted-strings are implemented in MACSYMA. That's one of the reasons I've been raising a ruckus about this issue and requesting some sort of transitional period. To cut down on lossage. So if I understand you, there still is no problem, since these "symbols" are pseudo-strings used for commentary, and won't be affected by an ocasion insertion of a CR. Date: 1 DEC 1979 1133-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC Date: 1 DEC 1979 1116-EST From: JONL at MIT-MC (Jon L White) To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC The Old-files problem (re the change to CR) is indeed completely solved this way, except for the overly-long symbol which was PRINTed out with vertical-bars. Frankly, I don't believe there are any such symbols in existing files. ------------------------------------------- Sorry to belabor this issue, but for the record some MACSYMA save files contain exactly such symbols. That's how quoted-strings are implemented in MACSYMA. That's one of the reasons I've been raising a ruckus about this issue and requesting some sort of transitional period. To cut down on lossage. Date: 1 DEC 1979 1116-EST From: JONL at MIT-MC (Jon L White) To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC Date: 26 November 1979 13:42-EST From: Robert W. Kerns Subject: LISP;NEW RECENT To: JPG at MIT-MC cc: BUG-LISP at MIT-MC Your charges of ignoring Macsyma are unfounded. You yourself point out the proper way to deal with the problem of old files with CR's in them. If you do (STATUS SYNTAX / ) in 1861, and set CR to that syntax, you will get the old behaviour. The Old-files problem (re the change to CR) is indeed completely solved this way, except for the overly-long symbol which was PRINTed out with vertical-bars. Frankly, I don't believe there are any such symbols in existing files. Date: 1 DEC 1979 1106-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 27 November 1979 12:14-EST From: Kent M. Pitman Sender: KMP at MIT-MC Subject: # and " ==> /# and /" ...? To: BUG-LISP at MIT-MC I propose that the syntax bits for " and # be changed so that they PRIN1/PRINT with /'s in front of them. This will help get files converted over to compatibility with # and " without any ill effects. Done. Date: 1 DEC 1979 0838-EST From: JONL at MIT-MC (Jon L White) Subject: Perfect Floating-point PRINT in MACLISP To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG I) at MIT-MC yea, I suppose we stopped at the 99.99999% complete point. Unlikely that either QUUX or I will look at it, even though the 1977 MUC-I paper anticipated the completion - I can show you in the code where to hac it, if you are interested. Date: 30 NOV 1979 0415-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC In mail MOON sent you on 11/21 he questions whether the change to the order of evaluation of the args to STORE can work. I am not sure myself what the implications of this change are, nor what MOON is worried about here, but I sure hope this change, which seems somewhat gratuitous even if possibly aesthetic, won't break a lot of code. Date: 29 NOV 1979 1759-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: LIST* To: MOON at MIT-MC, RWK at MIT-MC, HENRY at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC MacLISP doesn't support (LIST*) [the zero-arg case]. While it is ``obvious'' that the 1-arg case has meaning, it is not so obvious the 0-arg case does. (LIST* () () ()) => (() ()) (LIST* () () ) => (() ) (LIST* () ) => ( ) (LIST* ) => ??? ; I see nothing really logical to go here. () may be a nice thing for LIST* of 0 args to return, just so it isn't an error, but it hardly 'follows' from the others. It is indistinguishable then from what (LIST* ()) does. I'm not altogether convinced that the zero-arg case should be supported. Is the existance of (LIST* ,@X) with worries that X might be NIL sufficient reason? Maybe so. I think I still need to be convinced, tho'. -kmp MOON@MIT-MC 11/29/79 06:49:12 Re: LIST* with 0 or 1 argument To: Henry at MIT-AI, (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI I have rectified this oversight on the Lisp machine (in the source only). I haven't tested it since there don't seem to be any Lisp machines in the immediate vicinity out here. I also rewrote the code to make it readable and to remove a bug. Bob, the reason the 0- and 1-argument cases work out naturally in Maclisp and not in the Lisp machine is that Maclisp lacks cdr-coding, allowing LIST* to be written as iterated calling of CONS. Date: 29 November 1979 04:51-EST From: Jeffrey I. Schiller To: ALAN at MIT-AI cc: BUG-LISP at MIT-AI I agree with ALAN that base i-1 would be an infinite win. I would also like to propose that the change be put in tomorrow so that we can begin to win immediately. 24 hours seems like a reasonable amount of time for everybody to recompile (rewrite) their programs. In all seriousness I think that have true file properties would be a real win. However I strongly believe that base 8. is preferable to base 10. In general I am disturbed by the number of people who are in favor of installing newer and hairier on-by-default features in MacLISP (like the hints of # becoming a magic macro character) before long it will be near impossible to grock MacLISP without having to know about all of the obscure "features" of it. I prefer a very simple default environment and let the world load or otherwise turn on the hairier features. -Jeff P.S. I am not good at flaming over the mail system. Anyone who is interested in knowing my exact reasons for the position I take is invited to ask... Date: 29 November 1979 02:48-EST From: Alan Bawden Subject: Base-10? To: RWK at MIT-MC, KMP at MIT-MC, GSB at MIT-ML cc: BUG-LISP at MIT-MC Perhaps instead of changing the base lisp PRINTS numbers we should consider changing the base lisp STORES numbers. I propose base i-1 (that's i=sqrt(-1)). This has the interesting property that you can represent all complex integers uniquely using just the digits 0 and 1. Thus you could use a 36 bit word to store a complex number. Examples: 1100 = (i-1)^3+(i-1)^2 = (2+2i)+(-2i) = 2 11100 = (i-1)^4+(i-1)^3+(i-1)^2 = -2 11 = i 111011101 = 7 11000001 = -7 1000111 = 7i 11101000011 = -7i Note that there is no kludgy "two's complement" representation for negative numbers, they have nice finite representations just like all the rest of the numbers. Wouldn't it be nice to have complex integers in lisp? Of course there are bugs: The portion of the complex plane covered by a 36 bit word is a rather odd shape (it IS connected). The representation is not easily groked by the user (if we were all taught in grade school ....). The algorithms for addition and subtraction and multiplication, although not difficult, are not supported by any hardware that I know of. I have been unable to devise a satisfactory division algorithm. We would still have to decide how to PRINT the damn things! Of course we would have to recompile all the FASL files in the world (since the compiler could no longer output instructions such as ADD or IMUL), but that is a small price to pay for such a winning extension to the language (right?). Date: 29 November 1979 02:16-EST From: Robert W. Kerns To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 28 November 1979 21:04-EST From: Kent M. Pitman To: BUG-LISP In my working dir, Q^K! n (DEFPROP FOO (TEST TEST) AUTOLOAD) FOO DEFAULTF ((DSK KMP) * >) (FOO 3) ;(LOAD ((DSK LISP) TEST TEST)) FILE NOT FOUND why is it looking on LISP? The file lives on *my* dir. It does an explicit MERGEF with '((DSK LISP)) rather than just letting it use DEFAULTF. It would be much more reasonable for it to look on the DEFAULTF directory first....a search-list would be even more winning! Date: 29 November 1979 01:56-EST From: Robert W. Kerns To: Henry at MIT-AI cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI Date: 29 November 1979 00:41-EST From: Henry Lieberman To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI Since the trivial case for LIST is (LIST 'ONE-THING) is (ONE-THING) I think the trivial case for LIST* should be (LIST* '(ONE-THING)) is (ONE-THING) rather than complaining when given less than two args. Perhaps also (LIST*) is NIL These cases would make (APPLY 'LIST* ...) work out more nicely. Consider: (LIST* () () () ) => ( () () ) (LIST* () () ) => ( () ) (LIST* () ) => () i.e. from right to left, each of the arguments before the last is NCONSd onto the rightmost argument. This is what MacLisp does. I'm supprised the LISP Machine doesn't also do this; it makes life easier for BackQuote.... Date: 29 NOV 1979 0154-EST From: KMP at MIT-MC (Kent M. Pitman) To: HENRY at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC MacLISP does allow (LIST* ) as an identity operator. Your suggestions are what has been implemented for a long time... Date: 29 November 1979 00:41-EST From: Henry Lieberman To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI Since the trivial case for LIST is (LIST 'ONE-THING) is (ONE-THING) I think the trivial case for LIST* should be (LIST* '(ONE-THING)) is (ONE-THING) rather than complaining when given less than two args. Perhaps also (LIST*) is NIL These cases would make (APPLY 'LIST* ...) work out more nicely. Date: 29 November 1979 01:13-EST From: Robert W. Kerns Subject: CAR and CDR To: Dave.Touretzky at CMU-10A cc: KMP at MIT-MC, HIC at MIT-MC, BUG-LISP at MIT-MC My first sentence in my last note on rereading (and HIC flaming) is bullshit. There ARE indeed cases where the SEVENTH element is EXACTLY what you want to say. I do contradict myself at the end, even. And certainly FIRST and REST are very often exactly the right thing. I apologize for the flame and smoke. However, as KMP points out, it's often better to use destructuring to pick out the components than doing (FOURTH X) ... (FIFTH X) .... and more efficent besides. With a destructuring LET or a DESETQ you give NAMES for these components; they usually have meaning beyond merely being the 7th element. You also give a graphic representation of the the item is to look like. Besides, the only unmnemonic part about CAR and CDR is the A and D, which are nothing more than arbitrary names...I can't quite think of how you're going to explain LISP without their being able to understand "Contents"; Register is easy to explain...a place to store something! So your explanation can dwell on CAR being an operation to extract one of the contents of a CONS. You can tell how the A and D got in there as an amusing and educational story of how names in CS, once chosen, tend to stick. And how they should choose well the names they use for making sense, as if the names they choose might outlast them! That's enough for them to remember CAR and CDR. By all means, they should use FIRST, REST, (and when aprpriate, SECOND, etc.) in their code when that's what they mean. But I think you should also teach them that such things are constructed out of these low level primitives, and that this building of high-level operations out of low-level is one of the more important aspects of LISP (and indeed, all good programming). Date: 29 November 1979 00:38-EST From: Robert W. Kerns Subject: FIRST SECOND THIRD ... (don't forget REST) To: Dave.Touretzky at CMU-10A cc: BUG-LISP at MIT-MC, KMP at MIT-MC, HIC at MIT-MC I always try to avoid situations where I'd want to write obscenities like SEVENTH ... why should it be the SEVENTH thing? Better make it a macro so that I can change it later! And then (SETF (FROB X) BAR) wins totally, while (SETF (SEVENTH X) BAR) and (SETF (CADDDR (CDDDR X)) BAR) still don't say why you think 7 is such a magic number. FIRST and REST are fine, they say you are dealing with a homogenous list of items. But even then, it's better to write (POP X Y) rather than (SETQ Y (FIRST X)) (SETQ X (REST X)). The point is that CAR/CDR are the low-level primitives of the language, and concepts like FIRST, REST, SECOND, THIRD, etc. are all semantic overlays on these basic concept, assuming left-right non-recursive character to your data structure. But these don't even deal well with such simple structures as the ALIST. Do you really want to write (FIRST (FIRST X)) to get the top tag on the ALIST, and (REST (FIRST X)) for the CDR of the top CONS, which might be, say, a FIXNUM? REST is hardly apropriate there. Even the outer FIRST in the first one isn't quite right, since it's hardly the first element of a sequence. So sure, use FIRST, SECOND, THIRD, etc. when they're apropriate. But don't mistake them for being the underlying primitives of the language. Date: 28 NOV 1979 2301-EST From: MACRAK at MIT-MC (Stavros M. Macrakis) To: KMP at MIT-MC CC: GLS at MIT-MC, JONL at MIT-MC, (BUG LISP) at MIT-MC CC: (BUG FORTRAN) at MIT-MC The problem with floating output then input is known. I'm not sure if current Lisp solves it even in the non-extreme cases. It usually does. If you're interested, I have some papers on the subject I can copy for you. Date: 28 NOV 1979 2241-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Claims in MUC-I proceedings... To: GLS at MIT-MC CC: JONL at MIT-MC, (BUG LISP) at MIT-MC, (BUG FORTRAN) at MIT-MC JONL claims in ``LISP: Program is Data'' that you have perfect output for flonums in MacLISP -- this isn't so. Are you aware? eg, 1.70141182E+38 prints as 1.70141183E+38 which if you try to reread it will give ;ARITHMETIC OVERFLOW error ... *Really* losing since my Fortran translator generates this quantity for Fortran numbers that overflow the precision of our machine (figures a maximally large number is a good substitution) but I am screwed because I can't read those text files back into a Lisp to get them compiled. Re-reading as another number is one thing, but not reading at all is a real screw. -kmp Date: 28 November 1979 21:25-EST From: Edward Barton Subject: Interlisp To: BUG-LISP at MIT-AI [MESSAGE FROM KMP at MIT-MC 9:07pm] Interlisp is a total loss. False. Interlisp has a lot of nice features in addition to a lot of lossage. I think that simplistic thinking like the above is rather silly, especially for a place that likes to think it has some substance to its pursuits like MIT. What you want to do is to copy or adapt the good ideas and leave the bad ones, preferably after understanding what is right about the idea and what exactly went wrong in trying to reduce it to practice. I am reminded of a talk given by IBM research people at GM Research Labs about their spiffy new editor/debugger thing which they were developing for Lisp/370. At several points members of the audience asked questions about how one could do various things, and naturally it had never even occurred to the IBM people that one would ever want to do such things, even though the operations in question were clearly well-defined and useful, and documented (although badly) in the Interlisp manual as well as probably in other editors. Of course the IBM people admitted never even having read the Interlisp manual to see what its editor could do, even though they were setting out on a major project with some overlap. It was beneath them, I guess; better reinvent the whole world without the benefit of looking at what people had tried before, and why, and how. I don't want to get into a big argument about Interlisp, but I will of course continue to point out things that I personally have found useful in working with large Interlisp systems. I haven't suggested that the Lisp community here should just adopt Interlisp, nor am I about to; but neither am I likely to believe (or pay much attention to) blanket knee-jerks like "Interlisp is a total loss." Nothing personal intended to anyone, of course, just a disagreement. I might have a similar disagreement with people that won't even listen to, say, CLU people. And while I'm on it, why don't I point out another Interlisp winnage, namely its iteration statements. To me, at least, they are an order of magnitude better than the idiotic Maclisp DO or the conceptually clear (unless there are free variables) but (in my opinion) clumsy and ugly MAPCAR, or MAPCONC, or MAPCADDADDRNCONC, or MAPCABBAGE, or whatever someone wants to come up with next. Of course that one's not much of an issue, since PSZ has implemented similar Maclisp macros. Date: 28 November 1979 21:03-EST From: Edward Barton Subject: First, Second, Third To: BUG-LISP at MIT-AI Of course that still isn't as nice as Interlisp's CLISP forms x:1, x:3, x::1 (CDR), etc. for accessing things you haven't defined as structures. I wouldn't want to argue for a big crock like the way Clisp is implemented in Interlisp, but still things like x:1, point:xCoord, x:1_'Foo are nice on one way of thinking. Date: 28 NOV 1979 2104-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC In my working dir, Q^K! n (DEFPROP FOO (TEST TEST) AUTOLOAD) FOO DEFAULTF ((DSK KMP) * >) (FOO 3) ;(LOAD ((DSK LISP) TEST TEST)) FILE NOT FOUND why is it looking on LISP? The file lives on *my* dir. Date: 28 NOV 1979 2018-EST From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, KMP at MIT-MC, Dave.Touretzky at CMU-10A The Lisp Machine has for a very long time had the macros FIRST, SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH which I personnaly use anytime I want the "nth" element of a list -- I find that it makes the code substantially clearer. I also use (SETF (FIRST foo) bar) (as opposed to (RPLACA foo bar)) when I'm useing the FIRST .. SEVENTH convention. I find this also makes code more self-documenting. I think MacLisp should institutionalize this convention, and that perhaps people keep it in mind as a useful tool. --Howard Date: 28 November 1979 1940-EST From: Dave Touretzky Subject: Re: CAR and CDR To: kmp @ mc CC: bug-lisp @ mc In-Reply-To: Kent M. Pitman's message of 27 Nov 79 13:46-EST I was not kidding about CAR and CDR. While I agree wholeheartedly that FIRST and REST, HEAD and TAIL, etc., are awkard, and that short names for the most basic primitives are essential for "natural" languages, I also believe that these names should have some mnemonic properties. I am planning to teach LISP to some novice programmers next fall. These are people who have probably never seen a computer before. I think it is going to be fairly embarassing to explain to them why they have to say "CAR" and "CDR" instead of something more intuitive. "Contents of Address portion of Register" is not very mnemonic for someone who does not know what an address or a register is. These relics of the 7090 are amusing bits of trivia for us hackers, but they aren't so amusing to frustrated non-Lispers trying to develop an intuitive understanding of a very foreign language. With regard to composition of these nasty selectors into more obscure forms, I have the following observation. We either use composition to select some top-level element further down the list, e.g. CADR, CADDR, CADDDR, or we use it to select some internal element, e.g. CDDAADDAR. Quick, tell me what CDDAADDAR means! (I'm sure you can pronounce it, but what does it mean???) I suggest that top-level selection can be replaced with more intuitively named primitives like 1ST, 2ND, 3RD, 4TH, 5TH, etc. Note that these all contain 3 letters, while the current scheme would use CADDDR (six letters) for 4TH, and CAR of CDDDDR (7 letters plus an extra function nesting) for 5TH. In the case of internal elements, we already know that it is better to define macros for selecting named elements than to use obscure composite selectors like CDDAADDAR. The existence of a structure package for MacLisp using named elements makes it reasonable to suggest that the convention be used universally. This leaves perhaps one or two special cases, like CDAR or CAADR, that occur often enough to have built-in names. I'm sure people can think up something suitable. We Lispers keep talking about the wonderfulness of an interpretive program-development environment, and the non-Lispers are beginning to listen. Now I think it's time that we listen to some of what they've been saying about fighting obscurity in languages and programs. Date: 28 November 1979 15:19-EST From: Edward Barton Subject: File property lists To: BUG-LISP at MIT-AI It would be nice if they were general, as I mentioned. For example, IBASE is not the only per-file reader parameter one can imagine; macro characters of any desired complexity are also of exactly the same flavor. Of course since Maclisp doesn't have a RESETFORM or other mechanism for undoing arbitrary things (not known when the scope is entered) when the scope is exited, generality seems impossible. (Of course, for all I know the capability does exist and ungeneral crocks can after all be avoided.) The capability of making changes temporarily also applies to compilation, of course, and to prettyprinting, and to loading a compiled file. Interlisp users who have had the patience to wade through the manual and discover the way of associating things with exactly the right doing and undoing times know. Of course there are always hack ways of accomplishing such things in small systems; they become important when dealing with large, organized, possibly multi-authored systems. Date: 28 November 1979 14:50-EST From: Robert W. Kerns Subject: ;;; -*- Mode:Lisp; IBase:10. -*- To: EB at MIT-AI cc: BUG-LISP at MIT-AI This is called a "File property list", and is a general mechanism for storing facts about the file that are needed by various programs. For example, the Mode:LISP; is understood by various editors (EMACS, ZWEI, at least) to mean that this file should be edited in LISP mode. The IBase:10. is understood by the LOAD function in the LISP Machine currently, to mean that IBASE should be bound to 10. while loading the file. Other things can also appear there, such as Package:. Obviously, to implement this there would also have to be a FILE-SETQ function to SETQ variables in such a way that they would be unbound when the file is finished loading (or the loading is aborted....) Date: 28 NOV 1979 1227-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC in an XL try this: (sprin1 '((x . 5))) it works now. I fixed this bug in grindef where it did (get '(x . 5) ...) and went into an infinite loop inside get. Date: 28 November 1979 11:57-EST From: Edward Barton Subject: ;;; -*- Mode:Lisp; IBase:10. -*- To: BUG-LISP at MIT-AI What exactly is being proposed here for this "working"? Is the construction to be understood by Lisp or Emacs, and what would Emacs do with it?? If it is to be understood by Lisp, we seem to be starting vaguely along the direction of the Interlisp file package, which allows precise control of how everything in a file is printed, read, compiled, etc. (up to its limitations), only doing it in some crock non-general way. Date: 28 November 1979 11:51-EST From: Edward Barton Subject: Yet another BASE/IBASE opinion To: BUG-LISP at MIT-AI I vote for decimal. Date: 28 NOV 1979 1147-EST From: RWK at MIT-MC (Robert W. Kerns) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, HIC at MIT-MC In LISP 1901, CLEAR-INPUT and CLEAR-OUTPUT will work on SFA's. Also, the system ^W interrupt will no longer try to do an output reset on the SFA's non-existant channel if TYO is SETQ'd to a SFA. It won't do a CLEAR-OUTPUT operation either. If you want that, you can redefine ^W. The ^W(PRINT FOO T) problem is a real mess. GSB@MIT-ML 11/28/79 06:42:54 Re: in xlisp To: (BUG LISP) at MIT-ML (princ 'foo t) is still not the same as (princ 'bar '(t)) with respect to ^W. CLEAR-INPUT and CLEAR-OUTPUT still don't work on SFAs. GSB@MIT-ML 11/28/79 06:22:23 Re: # and " ==> /# and /" ...? To: (BUG LISP) at MIT-MC Changing the syntax bits such that those chars come out slashified sounds winning. I feel that # should eventually go into the default lisp environment, but i'm not so sure about "... Date: 28 November 1979 01:17-EST From: Robert W. Kerns Subject: Base-10 To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC I haven't decided that we can or can't or should or shouldn't, but I felt like flaming anyway, so I'll respond to a few of your points. Date: 27 November 1979 16:24-EST From: Alan Bawden To: KMP cc: BUG-LISP Re: Base-10 3) I find that I am more often concerned with the bit pattern of a number than with the pure magnitude. That depends on who you are, of course. 4) Octal is a more rational base than decimal anyway. So let's convert to Octric (base 8 units of measurement). That's really the right thing, you know. The number of fingers we have is really a stupid way to choose your default base. And besides, if you ignore your thumbs, you've got something to use to point to your base-8 digits! What I'd really like to see is the flushing of two of the 3 bases in common use. 5) I have never seen any new users screwed by octal, or even seriously confused. You need to watch more beginning users. Even I get screwed by it regularly. (more often they can't understand the difference between CONS and APPEND or similar). Definitely true! But irrelevant. There is nothing really obscure about octal, we are all introduced to alternate bases fairly early in our education these days (or should be). A fast poll of those in the room with me indicates that most people were so educated in grade school if not sooner. True. It's the "unexpected" aspect that gets people. I haven't had to explain what base 8 was to more than a couple people. 6) This seems to be a fairly late date to change something so fundamental to the basic user. I'm sorry, none of the recent changes really change the default environment (I'm against turning # and " on by default.) Better late than never? Certainly I agree that we should not change # and " at this time. However, with clear repeated warning that it will eventually change, and the print syntax changing soon, the syntax could eventually be changed moderatly painlessly. No predictions on how long it would take. I do think the world would be better for it. What do you think about LISP supporting ;-*- BASE:10 -*- ? Date: 27 NOV 1979 1624-EST From: ALAN at MIT-MC (Alan Bawden) Subject: Base-10 To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC KMP@MIT-MC (Sent by ___113@MIT-MC) 11/27/79 10:39:33 Re: Base-10 Your note made it hard to tell if you were upset by Base-10 or what you were afraid was my scoffing at it ... do you favor the change and if no, why not? -kmp I do not favor the change because: 1) It breaks more files than carrage returns in atoms ever will. 2) I like being able to type both octal and decimal with ease (no I don't think #O is acceptable). 3) I find that I am more often concerned with the bit pattern of a number than with the pure magnitude. 4) Octal is a more rational base than decimal anyway. 5) I have never seen any new users screwed by octal, or even seriously confused. (more often they can't understand the difference between CONS and APPEND or similar). There is nothing really obscure about octal, we are all introduced to alternate bases fairly early in our education these days (or should be). A fast poll of those in the room with me indicates that most people were so educated in grade school if not sooner. 6) This seems to be a fairly late date to change something so fundamental to the basic user. I'm sorry, none of the recent changes really change the default environment (I'm against turning # and " on by default.) Date: 27 November 1979 1333-EST From: Dave Touretzky Subject: first base To: bug-lisp @ mc MacLisp's first (default) base should be decimal. I agree with KMP and the others here: let's try to make LISP a modern general purpose programming language; it's not just a toy for assembly hackers and AI types anymore. Now if we could only flush CAR and CDR... Date: 27 NOV 1979 1214-EST From: KMP at MIT-MC (Kent M. Pitman) Sent-by: KMP at MIT-MC Subject: # and " ==> /# and /" ...? To: (BUG LISP) at MIT-MC I propose that the syntax bits for " and # be changed so that they PRIN1/PRINT with /'s in front of them. This will help get files converted over to compatibility with # and " without any ill effects. Note: I am *not* suggesting that " or # do anything unusual by default, merely that they print as if they did to guard against being re-read later in an environment where # and/or " have funny syntax since this is happening so often lately. If anyone knows of any reason why syntax bits 400 and 100 octal should not be turned on for these characters in the very near future, please let me know. Thanx. -kmp Date: 27 NOV 1979 1133-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: SETF/PUSH/POP and LISP;NEW RECENT To: (BUG LISP) at MIT-MC OK, I've fixed SETF/PUSH/POP WRT order of evaluation. Works like a charm. I've also update muchly LISP;NEW RECENT. You should have a look at it. I probably say too much about PUSH/POP/SETF, but I couldn't think of any way to concisely specify the properties that these are guarenteed to have, without also being obscure. I also documented PROG1, since I made XC understand it. Date: 27 November 1979 06:13-EST From: Robert W. Kerns To: JPG at MIT-MC cc: BUG-LISP at MIT-MC, GSB at MIT-MC Date: 27 November 1979 05:54-EST From: Jeffrey P. Golden To: BUG-LISP RWK says he would rather screw people who are already using LISP in the default way than screw people who want to use a new feature. It seems to me that this attitude is preposterous. People who are waiting anyway can more easily be asked to wait some more than can people who will be screwed by this change to MACLISP, especially here where the transition can be made less painful so easily by first changing the default for TERPRI to T (which I have already done in the current MACSYMA) and waiting some on the CR change. I would dispute your use of the word "default". You mean "old". The rest of the world has passed us by. Consider TWENEX, TENEX, TOPS-10, SAIL, CMU, and Multics versions of MacLisp all have long (or always) had this mode. So does the LISP machine. NIL, INTERLISP, every damned one except ITS. I would rather force 1 user to change the 1 program significantly affected (MACSYMA) than force all the rest of the world to mark time. There really aren't that many programs which depend on CR being invisible in old files with atoms longer than LINEL! Not many print atoms longer than LINEL! Date: 27 NOV 1979 0554-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC RWK says he would rather screw people who are already using LISP in the default way than screw people who want to use a new feature. It seems to me that this attitude is preposterous. People who are waiting anyway can more easily be asked to wait some more than can people who will be screwed by this change to MACLISP, especially here where the transition can be made less painful so easily by first changing the default for TERPRI to T (which I have already done in the current MACSYMA) and waiting some on the CR change. Date: 27 NOV 1979 0543-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Who goes first? To: JPG at MIT-MC, GSB at MIT-MC CC: (BUG LISP) at MIT-MC I don't think the two situations (# and CR) are quite analogous. There's a hell of a lot more to be broken by # than by autoterpri. There does have to be a period of transition, yes. The question becomes: Who do you screw? I'd say there's fewer people with programs that have to watch out for old autoterpri lossages than there are people who want to use the new CR syntax in their files. So on whom should the burden of the transion fall? It's my view that it is more of a loss to make everyone temporarily put some lossage like (EVAL-WHEN (EVAL COMPILE) (SSTATUS SYNTAX / (STATUS SYNTAX / ))) in all their files. And their LISP inits, and any LISP environment they get into that they want to type at, etc. etc. etc. Waiting to make the change will only make it harder for people to tranport code to the Lisp Machines and Multics (don't forget Multics Macsyma, Jeff!). GSB@MIT-ML (Sent by GSB0@MIT-ML) 11/27/79 05:32:56 Re: Syntax changes To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC JPG is right, there should be a reasonable transition period for proposed reader-syntax changes, even if it is possible to backwards-compatibilize stuff (eg by munging the syntax back). For example, protosystem has database files which include the "#" character; currently it is slashified in none of them. This is easier to hack than , however; i can just make "#" get slashified in output even if it isn't a reader macro. (Fortunately PS1 doesn't suffer from auto-terpri problems; stuff is either pretty-printed (which binds TERPRI to T and hence never breaks atoms) or the stuff is in fasl format.) Date: 27 NOV 1979 0515-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC Date: 26 November 1979 13:42-EST From: Robert W. Kerns Subject: LISP;NEW RECENT To: JPG at MIT-MC cc: BUG-LISP at MIT-MC Your charges of ignoring Macsyma are unfounded. You yourself point out the proper way to deal with the problem of old files with CR's in them. If you do (STATUS SYNTAX / ) in 1861, and set CR to that syntax, you will get the old behaviour. The new LISP RECENT should mention this. Because of the stand the LISP system hackers are taking on this issue, I am not responsible if someone tries to LOADFILE in a file to the new MACSYMA in which the non-invisibility of CR is assumed. Date: 27 NOV 1979 0428-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC I don't think anybody noticed it before, but STATUS SYSTEM was buggy. It is possible to have user symbols between TRUTH, QUNBOUND, and the rest of the system symbols. SYALC is immediately after QUNBOUND! I fixed it. Date: 27 NOV 1979 0006-EST From: KMP at MIT-MC (Kent M. Pitman) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Yes, despite the silly date chosen (we thought it was somehow appropriate), I am quite serious about changing Lisp's base. If anyone has a reasonable objection, let him voice it now but I have advocated for a long time that Base-10 is what the world runs on and people sophisticated enuf to know what base-8 is also know enuf to make init files and set defaults explicitly. -kmp Date: 26 NOV 1979 1758-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: More on BASE/IBASE To: (BUG LISP) at MIT-MC CC: DHD at MIT-MC, KMP at MIT-MC, GSB at MIT-MC, EJS at MIT-MC Why don't we convert people to use base 10 (eight)? It's really a much more logical base, being a power of two, and then we only have to convert people, not programs! Date: 26 NOV 1979 1745-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC I propose that on April Fool's Day of 1980 (approx 6 months hence) the default I/O base of MacLISP be changed to 10. and *NOPOINT default to NIL. This will have the following good effects: (1) Output from a default environ to be readable back into any environ. (2) New users will not be confused and scared off by funny default base. There already exist read macros #O and #X in MacLISP for specifying a number is to be read in Base-8 or Base-16 or whatever and I suggest we start using these. This amount of time should be enough time for the files that depend on base to be ammended. Those of you who are really worried about contingencies should write an SFA scheme that binds IBASE to 8 while reading files created before some threshold date ... NOTE: Ammending files should NOT mean changing the numbers to rely on base 10, but rather to use the "." to force base 10 or use #O or #/ or whatever so that you don't rely on a default. There should also be an effort organized to get at least a FILE-SETQ and maybe a general FILE-EVAL working for people who just want to set IBASE in a given file. I would also like to see ;;; -*- Mode:LISP; IBase:10. -*- work correctly. -kmp Date: 26 November 1979 13:42-EST From: Robert W. Kerns Subject: LISP;NEW RECENT To: JPG at MIT-MC cc: BUG-LISP at MIT-MC Your charges of ignoring Macsyma are unfounded. You yourself point out the proper way to deal with the problem of old files with CR's in them. If you do (STATUS MACRO / ) in 1861, and set CR to that syntax, you will get the old behaviour. Date: 26 November 1979 09:21-EST From: Mark L. Miller Subject: Base/ibase To: DHD at MIT-AI, BUG-LISP at MIT-AI I know this is an old issue and gripes have been overruled in the past, but I have to side with DHD on this one. The defaults in a programming system should make it POSSIBLE for experts to do expert things, but EASY for beginners to do beginning things. Surely most "experts" regard it as foolhardy for a file to assume ANYTHING about the ibase without wrapping it in specific declarations. In any case, it makes more sense to require experts to set up init files to override base 10., than to require beginners to set them up to override base 8! This sort of thing just lends support to the outside world's belief that "Lisp is just some strange assembly-level language for esoteric string processing applications, with lots of stupid parentheses" (a more common view than we may care to admit). Regards, Mark Date: 26 November 1979 09:00-EST From: Mark L. Miller Subject: Twenex MacLisp Additions To: MILLER at MIT-AI, DEKLEER at PARC-MAXC2 cc: BUG-Lisp at MIT-MC In Reply To: Date: 24 NOV 1979 2034-PST From: DEKLEER at PARC-MAXC2 subsys, and a bunch of other things can be found in those files I sent you long ago. Apparently my LEDIT doesnt quite work on TOPS-20, and I missed getting it to work when I was at MIT I know, thanks, I just haven't had a chnce to work on it yet -- soon! Things like cursorpos would be very useful. Agreed. BTW things like cursorpos should really be in the MIDAS source, not as a piece of LAP, or is that what you are doing. Well, we KNEW you could do it in MIDAS, and it looked like you could also do it in LAP, and we were unclear which would be preferred, or why. Why? Thanks, Mark Date: 26 NOV 1979 0506-EST From: JPG at MIT-MC (Jeffrey P. Golden) Subject: LISP;NEW RECENT To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC Concerning the change to , how do you specify its syntax in the new LISP to make it invisible so as to be able to read in TERPRI NIL files with long atoms in them? Obviously this is necessary if such MACSYMA SAVE files created in the current MACSYMA are to be loaded into the new LISP. I am unhappy that after all the discussion we had on the issue that the new scheme was installed without a transition period in which TERPRI T was the default LISP mode. It would be unfortunate if this means as it may that MACSYMA may have to stay in LISP 1861 for several months. I think that would set us back quite a bit. However, RWK had sent a system msg asking who this change would hurt, and I explained how it would hurt MACSYMA, yet this change was made with apparently no consideration for softening the blow. Date: 25 November 1979 02:05-EST From: Robert W. Kerns To: CFFK at MIT-MC cc: BUG-LISP at MIT-MC Date: 24 November 1979 16:48-EST From: Charles F. F. Karney To: BUG-LISP After setting up the # char, #X12 and #O12 both say that X (or O) is an unknown dispatch char. Documentation says I should get hex/octal read. Fixed, except #X doesn't work in MACLISP unless you follow the X with a +. I.e. #XA will give an error, but #X+A will give 16. Date: 24 NOV 1979 2146-EST From: KMP at MIT-MC (Kent M. Pitman) To: CFFK at MIT-MC CC: (BUG LISP) at MIT-MC The # characters /!, /", /(, /=, /B, /I, /L, /O, /T, /X, /[, /{ Seem to be defined only for the NIL environ ... I agree that #O and #X would be useful to MACLISP as well -- will see about putting that in. Date: 24 NOV 1979 1648-EST From: CFFK at MIT-MC (Charles F. F. Karney) To: (BUG LISP) at MIT-MC After setting up the # char, #X12 and #O12 both say that X (or O) is an unknown dispatch char. Documentation says I should get hex/octal read. DHD@MIT-AI 11/24/79 11:28:15 Re: Base/ibase To: (BUG LISP) at MIT-AI Is there any real reason the initial IBASE is 8. rather then 10. like it is in the rest of the world? I realize that the LISP machine is still under development, so I suppose they have to have it 8. to interact better with the hardware, but why is such an anacronisim still in MACLISP? The obvious answer is compatibility with the LISP machine and other lisp programs, but NIL (or the simulator anyway) is base 10, so we have (or will have when NIL is up) compatibility problems anyway. In any case, you can always do (SETQ BASE ...). I don't see any reason not to do this, and it would cause a lot less confusion for beginners. In any case, I don't see why it would be too hard to put the (SETQ BASE ...) into a LET for incompatible code; the change is so trivial I don't think anyone would be inconvenienced very much. So why not consider it? This base 8 bit is at least as ridiculous as the old carriage return syntax! Date: 24 November 1979 11:03-EST From: Robert W. Kerns Sender: RWK0 at MIT-MC Subject: Losing Format/Winning Format To: BUG-LISP at MIT-MC cc: GSB at MIT-MC The current Format is a loss, as we all know. It doesn't even KNOW about ~T, and ~& doesn't work right, etc... GSB has a FORMAT that's as fully LISPM compatible as can be done, works well, comes complete with excellent documentation (due to LSB) It takes only about 300 words more BPS than the current MacLisp default, etc. unless ~R, ~<, or ~C are used, which autoloads another 700 words or so. I haven't done any speed comparisons yet, but I'd expect GSB's to be at least comparable, if not superior. Do we want to make GSB's format autoload instead of the current one? (Macsyma doesn't use FORMAT, so the space is less critical than it might be) The disadvantages include the fact that it's written with LSB, which hurts its exportability. On the other hand, it's so far superior to the current one that I've always used it instead of the default one even in it's much earlier and more primitive versions. Date: 24 NOV 1979 0238-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: New atom constructor in STRUCT To: (BUG LISP) at MIT-MC I have added the macro MSAT, which just takes a PNAME and creates the symbol with no properties or labels, for the sake of preallocating symbols that will be used in autoloaded packages, and want to be unbound, etc. SHARPM, for example, has mungibles which do (OR (BOUNDP mumble) (SETQ mumble ...)) Date: 24 NOV 1979 0121-EST From: RWK at MIT-MC (Robert W. Kerns) To: EB at MIT-MC CC: (BUG LISP) at MIT-MC There was also a bug causing the result of a USERATOMS hook to get EVAL'ed one too many times. Curiously, all my test cases were such that an extra evaluation was harmless. Date: 24 November 1979 00:11-EST From: Robert W. Kerns Subject: USERATOMS-HOOKS To: EB at MIT-MC cc: BUG-LISP at MIT-MC Date: 23 November 1979 15:03-EST From: Edward Barton To: BUG-LISP Re: USERATOMS-HOOKS In fact what happens is that I get "OB$Z unbound variable" on loading the FASL file. (If I were to put an additional QUOTE in the NCONS or if I were to set OB$Z to something, I would get file not in fasload format at load time.) I suspect you loaded the resulting FASL file into LISP rather than XLISP. LISP had a bug where it would give "File not in FASL format" errors at load time. Date: 23 NOV 1979 1503-EST From: EB at MIT-MC (Edward Barton) Subject: USERATOMS-HOOKS To: (BUG LISP) at MIT-MC Consider the following file as compiled on MC with XC: (eval-when (compile) (defun :-hook (x) (let ((temp)) (cond ((not (atom x)) nil) ((eq (car (setq temp (explode x))) ':) (ncons `(quote ,(implode (append '(o b $) (cdr temp)))))) (t nil)))) (push ':-hook useratoms-hooks)) (defun foo (x) 1) (defun foo1 (x) :z) (setq ob$z 'win) (defun :foo (x) 2) It seems to me that the FASL file should achieve the same effect, in this case, as (defun foo (x) 1) ; no problem here, of course (defun foo1 (x) ob$z) (defun ob$foo (x) 2) In fact what happens is that I get "OB$Z unbound variable" on loading the FASL file. (If I were to put an additional QUOTE in the NCONS or if I were to set OB$Z to something, I would get file not in fasload format at load time.) If I omit the FOO1 defun, I get "OB$FOO unbound variable" on loading. In that case, if I set OB$FOO to, say, WRONG, the effect is as if I had said (defun wrong (x) 2) instead of the :foo defun. Is all this really the way it's supposed to work? Date: 23 NOV 1979 1204-EST From: JONL at MIT-MC (Jon L White) Subject: " on TTYSCAN-STRINGERS/| To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC ALAN@MIT-AI 11/21/79 08:11:57 Re: XLISP variable TTYSCAN-STRINGERS/| To: (BUG LISP) at MIT-AI has the pair (#/" . #/") by default. This would seem to be wrong if (status macro #/") is nil by default. No, the list held by TTYSCAN-STRINGERS/| is only for read-macro chars - the crucial line of the documentation is "tty prescan function can know about which (read macro) characters are" but indeed if you would like to make """ a non-stringer macro char, you would have to remove it from TTYSCAN-STRINGERS/|. Date: 23 November 1979 04:11-EST From: RWK,KMP at MIT-MC Sender: RWK at MIT-MC Subject: SETF, PUSH, POP To: EB at MIT-ML cc: BUG-LISP at MIT-MC Date: 11/22/79 18:54:32 From: EB at MIT-ML To: (BUG LISP) at MIT-ML Re: SETF, PUSH, POP Why not have a general, uniform mechanism for operations thatt first access, compute with, and then reset (SETF) some component? This is done in Interlisp with the so-called "changeword" mechanism, of which Interlisp "push", "pop", "pushnew", "add", and "pushlist" are instances. It seems better to have a general CHANGEF primitive than to special-case everything. For example, in Interlisp a form (change ) has such an effect. ("DATUM" within stands for the old value.) is only evaluated once. This is a crockashit ... you can't nest CHANGEs inside CHANGEs, since there's no way to distinguish the DATUM referering to outside or inside CHANGE. But the idea is useful. How about instead of being a form, it being a Lambda- expression? Thus INCREMENT becomes nothing more than a convenient way to write (CHANGE (mumble) (lambda (x) (1+ x))) or maybe (CHANGE x (1+ x) (mumble)) How about a DEFCHANGE macro which defines a macro to define things like INCREMENT ... (DEFCHANGE (INCREMENT x) (1+ x)). (DEFCHANGE (ADDTO X N) (+ X N)) ;Structure always comes first [KMP doesn't like the names CHANGE and DEFCHANGE ... thinks they're ugly] Anyway, the way the SETF stuff works it's easy for you to do any of this, avoiding multiple-evaluations of the structure-access, and other such goblins. I don't know how many of these are useful enough to go into the system! Date: 23 November 1979 02:17-EST From: Robert W. Kerns To: EB at MIT-AI cc: BUG-LISP at MIT-MC Date: 11/21/79 13:48:27 From: EB at MIT-AI To: (BUG LISP) at MIT-AI THE FOLLOWING FILE: (EVAL-WHEN (COMPILE) (DEFUN FOO-HOOK (X) (COND ((EQ X 'FOO) (NCONS 'FOO-SYM)) (T NIL))) (TRACE FOO-HOOK) (PUSH 'FOO-HOOK USERATOMS-HOOKS)) (DEFUN FOO (X) 'FOO) PRODUCES THE FOLLOWING ERROR IN LISP COMPILER 900: (COMMENT **ERROR** FOO Atomindex screw in function FOO) ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% ;BKPT BARF THE TEST ABOVE WAS PLAYING AROUND WITH USERATOMS-HOOKS, INTENDING TO EVENTUALLY WRITE A USERATOMS-HOOK THAT PUTS SYMBOLS ON A CHOICE OF OBARRAYS DEPENDING ON THE FORM OF THE SYMBOL, AND USEABLE EVEN AT PLACES THAT ARE NOT GETTING EVALUATED (E.G. IN (DEFUN atom (atom1) ...). Fixed in the source, and in XCOMPLR on MC. By the way, I suspect that you don't mean what you actually wrote. More likely: (DEFUN FOO-HOOK (X) (COND ((EQ X 'FOO) '('FOO-SYM)))) Note that the form you return the NCONS of is EVAL'd at load time to get the final atom. EB@MIT-ML 11/22/79 18:54:32 Re: SETF, PUSH, POP To: (BUG LISP) at MIT-ML Why not have a general, uniform mechanism for operations thatt first access, compute with, and then reset (SETF) some component? This is done in Interlisp with the so-called "changeword" mechanism, of which Interlisp "push", "pop", "pushnew", "add", and "pushlist" are instances. It seems better to have a general CHANGEF primitive than to special-case everything. For example, in Interlisp a form (change ) has such an effect. ("DATUM" within stands for the old value.) is only evaluated once. GSB@MIT-ML 11/22/79 09:50:47 Re: lisp; new recent To: MOON at MIT-MC, (BUG LISP) at MIT-MC, RWK at MIT-MC CC: HIC at MIT-MC I think the current (maclisp) SETF is a step in the right direction with respect to handling correct order of evaluation. If it is incompatible with the Lisp machine SETF, then yes, some resolution is in order, but i feel very strongly about having implied order of evaluation obeyed. You guys SAY that you only don't want to break atoms across lines, but if TERPRI has to be T for the output to be "correct" then what point is there in the switch? You are now saying that i can have either correct output or readable output but not both. The problem is that TERPRI is being used for two quite different purposes; one to control a minimal amount of "formatting", the other to control breaking of atoms. What is needed is to have TERPRI continue to affect PRIN1 (and PRINC?) the way it does now, and to have a per-file EOL-HOOK, which gets called when the "end-of-the-line" is reached. It will have the responsibility of outputting (or not) anything necessary at that point. The default case, where there is none, would do nothing, thus never breaking atoms across lines. This should probably be something handled like an ENDPAGEFN - it needs to be per-file because the action that will be taken is dependent not only on the type of device but the interpretation which will be placed on the output. Date: 22 November 1979 04:03-EST From: Robert W. Kerns Subject: lisp; new recent To: MOON at MIT-MC cc: BUG-LISP at MIT-MC Date: 21 November 1979 17:54-EST From: David A. Moon To: BUG-LISP cc: MOON Re: lisp; new recent ## is no longer used and should be flushed. #\FORM should be defined; this is what is written on the key on Knight and LM keyboards, and therefore should be the preferred name of the key. #\BACK-NEXT is missing. Done. STATUS FILESYSTEM-TYPE, OPSYSTEM-TYPE, SITE(?) (STATUS SITE) should probably return something like CADR-11. Date: 22 November 1979 01:20-EST From: Robert W. Kerns To: RMS at MIT-AI cc: BUG-LISP at MIT-MC Date: 11/21/79 22:58:09 From: RMS at MIT-AI To: (BUG LISP) at MIT-AI Why does SETF in Maclisp look for a SETF-X property instead of a SETF property like the one on the Lisp machine? It seems there is a gratuitous incompatibility born every minute. Because the SETF-X property is not the same as the SETF property on the LISP machine. MacLisp's has additional stuff in it to allow PUSH and POP (and similar things) to avoid multiple evaluation of the structure reference. Usual user interface is kept simple through the DEFSETF macro. Date: 22 November 1979 00:28-EST From: Robert W. Kerns Subject: lisp; new recent To: MOON at MIT-MC cc: BUG-LISP at MIT-MC Some things I leave to JONL to answer, but... Date: 21 November 1979 17:54-EST From: David A. Moon To: BUG-LISP cc: MOON Re: lisp; new recent SETF has to be a macro, not an FSUBR. Or else MACROEXPAND has to know about it specially. I assume you hold the same view of PUSH and POP? I sort of feel the same way, but don't have good arguments. Perhaps you can supply same. In particular, why is it important that MACROEXPAND expand SETF/PUSH/POP ? I'd really feel much better if you could convince us. The property which controls SETF should be called SETF, not SETF-X. This is for Lisp machine compatibility and because it is useless to introduce another name when the name of the property can reflect the function which it controls. The main reason for it being a different name is because it operates differently. It's rather complicated, so I'll write it up elsewhere, but what it's all about is avoiding multiple evaluations of arguments to PUSH and POP. DEFSETF hides this hair from the user. LDB and DPB in the Lisp machine work on bignums. Much of our software that runs in Maclisp (where they are sometimes called LOGLDB and LOGDPB) depends heavily on this. Evidently yours only accept fixnums? The pp field in a byte-pointer should not be limited to 2 octal digits, but should simply be (// ppss 64.); this is important when dealing with bignums. Should we make + work on bignums too, like the Lisp Machine? Admitedly, this isn't quite as clear as that, but I'm not sure we want to give up the efficiency... Maybe optimizing the case where the arguments are declared fixnums is enough though. Why do useratoms-hooks NCONS their return values, since the value, being a form evaluated for some kind of side-effects, will surely be non-NIL? I don't know why you think the value will be a form evaluated for some kind of side-effects!! The change to eliminate automatic insertion of CR's seems wrong. Isn't what you want to retain automatic insertion of CR's, but NEVER within an atom? Thus formerly extra-long atoms would be broken with a CR in the middle, but now they would result in extra-long lines, but normal output will not contain extra-long lines. Yes, I thought this was what JONL and I agreed was the right thing. EOF-COMPILE-QUEUE (This supersedes EOC-EVAL, doesn't it?) I dunno. I never did figure out what EOC-EVAL was for, so I don't know if it superscedes it. It might be kind of awkward to use EOF-COMPILE-QUEUE for EOC-EVAL's. &WHOLE in DEFMACRO but not in DEFUN (we probably already have this). I think &WHOLE in DEFUN was a documentation bug. I'll change it. Date: 21 November 1979 23:28-EST From: Robert W. Kerns Subject: ASSOQ and ASSQ and atoms To: RMS at MIT-AI cc: BUG-LISP at MIT-MC, NIL-I at MIT-MC, TLP at MIT-AI, BUG-LISPM at MIT-AI When is it useful to allow non-null atoms in an ASSQ list? RMS@MIT-AI 11/21/79 22:58:09 To: (BUG LISP) at MIT-AI Why does SETF in Maclisp look for a SETF-X property instead of a SETF property like the one on the Lisp machine? It seems there is a gratuitous incompatibility born every minute. Date: 21 November 1979 22:41-EST From: Robert W. Kerns Subject: Mailing-lists To: Scott at SRI-KL cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC The problem is that everybody in the world (almost) knows to send to BUG-LISP for their MacLisp complaints. While your idea is valid and good, it is completely incompatible with the programs everybody has in their heads.... Date: 21 November 1979 22:39-EST From: Robert W. Kerns Subject: GC-DAEMON and nointerrupt mode? To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 November 1979 12:49-EST From: Jon L White To: RWK cc: BUG-LISP Re: GC-DAEMON and nointerrupt mode? Upon reconsideration, I'm thinking that the current status is ok, namely that the so-called "synchronous" interrupts should not fiddle with, nor care about, the state of nointerrupt. these are: AUTOLOAD, ERRSET, *RSET-TRAP, GC-DAEMON, GC-OVERFLOW, and PDL-OVERFLOW. Thus it would be ok to write some code which first sets "nointerrupt" and then calls the GC - the "nointerrupt" would delay neither the GC-OVERFLOW nor the GC-DAEMON functions; but GC-LOSSAGE is deferred until nointerrupt is null. I agree that they should not care, i.e. should be run immediately. However, GC-DAEMON *MUST* be able to look at the world before ANYBODY ELSE does ANY consing. The only way to do that is to inhibit interrupts when it is invoked. As near as I can figure, however, GC-DAEMON is unique in this requirement. Date: 21 NOV 1979 1754-EST From: MOON at MIT-MC (David A. Moon) Subject: lisp; new recent To: (BUG LISP) at MIT-MC CC: MOON at MIT-MC ## is no longer used and should be flushed. #\FORM should be defined; this is what is written on the key on Knight and LM keyboards, and therefore should be the preferred name of the key. #\BACK-NEXT is missing. I don't see how the change to the order of evaluation of STORE can work, particularly in compiled code. Has this really been tested? Does (STORE (APPLY ...) ...), which Macsyma uses, still work? SETF has to be a macro, not an FSUBR. Or else MACROEXPAND has to know about it specially. The property which controls SETF should be called SETF, not SETF-X. This is for Lisp machine compatibility and because it is useless to introduce another name when the name of the property can reflect the function which it controls. LDB and DPB in the Lisp machine work on bignums. Much of our software that runs in Maclisp (where they are sometimes called LOGLDB and LOGDPB) depends heavily on this. Evidently yours only accept fixnums? The pp field in a byte-pointer should not be limited to 2 octal digits, but should simply be (// ppss 64.); this is important when dealing with bignums. LOAD-BYTE and DEPOSIT-BYTE do not work exactly as documented. The documentation needs to make clear that the bit position is the number of the high-order bit counting from LEFT TO RIGHT, i.e. the number of bits to the left of the byte IN A FIXNUM. Better than this crockish machine-dependency would be to number the bits from right to left in the standard way, as LDB and DPB do, avoiding dependency on machine word-length. Consider what LOAD-BYTE and DEPOSIT-BYTE would do in NIL. I fail to understand this example; &WHOLE is meaningless in anything other than DEFMACRO. (DEFUN FOOM (&WHOLE X) ) would bind X just like (MACRO FOOM (X) ) Why do useratoms-hooks NCONS their return values, since the value, being a form evaluated for some kind of side-effects, will surely be non-NIL? The change to eliminate automatic insertion of CR's seems wrong. Isn't what you want to retain automatic insertion of CR's, but NEVER within an atom? Thus formerly extra-long atoms would be broken with a CR in the middle, but now they would result in extra-long lines, but normal output will not contain extra-long lines. The following features seem reasonable to adopt in the Lisp machine. I'll put them in when I return to the east coast. SPRIN1 EOF-COMPILE-QUEUE (This supersedes EOC-EVAL, doesn't it?) STATUS FILESYSTEM-TYPE, OPSYSTEM-TYPE, SITE(?) Hacking of + in read-eval-print loop. &WHOLE in DEFMACRO but not in DEFUN (we probably already have this). EB@MIT-AI 11/21/79 13:48:27 To: (BUG LISP) at MIT-AI THE FOLLOWING FILE: (EVAL-WHEN (COMPILE) (DEFUN FOO-HOOK (X) (COND ((EQ X 'FOO) (NCONS 'FOO-SYM)) (T NIL))) (TRACE FOO-HOOK) (PUSH 'FOO-HOOK USERATOMS-HOOKS)) (DEFUN FOO (X) 'FOO) PRODUCES THE FOLLOWING ERROR IN LISP COMPILER 900: (COMMENT **ERROR** FOO Atomindex screw in function FOO) ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% ;BKPT BARF THE TEST ABOVE WAS PLAYING AROUND WITH USERATOMS-HOOKS, INTENDING TO EVENTUALLY WRITE A USERATOMS-HOOK THAT PUTS SYMBOLS ON A CHOICE OF OBARRAYS DEPENDING ON THE FORM OF THE SYMBOL, AND USEABLE EVEN AT PLACES THAT ARE NOT GETTING EVALUATED (E.G. IN (DEFUN atom (atom1) ...). ALAN@MIT-AI 11/21/79 08:11:57 Re: XLISP variable TTYSCAN-STRINGERS/| To: (BUG LISP) at MIT-AI has the pair (#/" . #/") by default. This would seem to be wrong if (status macro #/") is nil by default. I agree that this does mean that when you do a setsyntax for #/" you have to remember to do a push onto ttyscan-stringers/| as well, but thats just the way things are. Date: 20 NOV 1979 1654-EST From: JONL at MIT-MC (Jon L White) Subject: IBASE = ROMAN To: (BUG LISP) at MIT-MC CC: MTM at MIT-AI MTM@MIT-AI 11/15/79 13:17:06 With BASE and IBASE set to ROMAN, the form (setq n1 CCXIII n2 XXIII) returns XXIV. Fixed - edited in source and patched in current LISP. Date: 20 NOV 1979 1402-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 16 November 1979 00:51-EST From: Glenn S. Burke *LISP 891 has some constants at FLSPA3 which get fallen into by the code at SHAREP+n when the .CALL SYSFIL succeeds... It is supposed to fall into SHARP1, but this random cruft has been put in the middle. Fixed. but beware, these higher-number versions are still XLISP, and not yet stabalized w.r.t. adding code. Date: 20 NOV 1979 1249-EST From: JONL at MIT-MC (Jon L White) Subject: GC-DAEMON and nointerrupt mode? To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Upon reconsideration, I'm thinking that the current status is ok, namely that the so-called "synchronous" interrupts should not fiddle with, nor care about, the state of nointerrupt. these are: AUTOLOAD, ERRSET, *RSET-TRAP, GC-DAEMON, GC-OVERFLOW, and PDL-OVERFLOW. Thus it would be ok to write some code which first sets "nointerrupt" and then calls the GC - the "nointerrupt" would delay neither the GC-OVERFLOW nor the GC-DAEMON functions; but GC-LOSSAGE is deferred until nointerrupt is null. Date: 20 Nov 1979 0809-PST From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: ASSOC and ASSQ on lists with atomic entries To: JONL at MIT-MC, TLP at MIT-MC, ALAN at MIT-MC, RWK at MIT-MC, RMS at MIT-MC Cc: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC In-reply-to: Your message of 20-Nov-79 0651-PST In response to multiple mailing lists: if implemented, they should be named BUG-MACLISP, BUG-LISPM, BUG-NIL and BUG-LISP with the last being bug mail pertaining to all LISPs. Sounds reasonable? (sorry for the multiple copies on this) Scott ------- Date: 20 NOV 1979 0951-EST From: JONL at MIT-MC (Jon L White) Subject: ASSOC and ASSQ on lists with atomic entries To: TLP at MIT-MC, ALAN at MIT-MC, RWK at MIT-MC, RMS at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC 1) as for maclisp, it appears to be a bug in the manual that this isn't documented - the manual seems to imply that "association lists" must contain only dotted pairs. The "feature" of maclisp's ASSQ under which it really takes car of each item in the association list must be considered a speed kludge in the same cattegory as that of converting ATOM check for end of list in the various MAPs into a NULL check in compiled code; one could construct pathological cases which exploited/demonstrated this difference, but in fact in the 5+ years that it has been installed, there has never been a naturally-occurring complaing agains ASSQ/ASSOC. (on the other hand, there have been a few complaints that compiled MAPs do not do the same endtest check as the interpreted version, i.e. that NULL has been substituted for ATOM). 2) the utility of being able to delete entries from an "association list" by means of RPLACAing them to (), rather than having to re-invent and/or open-code the mechanisms of DELETE, is supremely useful; likely we should ensure that all of MACLISP/LISPM/NIL permit it. 3) some of us will receive multiple copies of this note, due to the mail-forwarding process - should we perhaps define a new mailing list which reaches BUG-LISP, BUG-LISPM, and NIL mailing lists? MILLER@MIT-AI 11/19/79 10:47:31 Re: Grief with T and NIL as Filespecs To: (BUG Lisp) at MIT-MC, KMP at MIT-MC I agree with KMP wholeheartedly -- down with T and NIL as filespecs! Moreover it ought to be easier to write an LSUBR which has the same arg passing conventions as PRIN1, TYO, etc. If you become paranoid about it, as I have, you end up writing cruft like this "image mode" tyo for Tops-20 version (based on assuming NO second arg to TYO etc. may NOT be identical to NIL as a second arg): (Defun RawTyo Nargs (cond ((> Nargs 1) (Unwind-Protect (prog2 (Binary-Mode T (arg 2)) (tyo (arg 1) (arg 2))) (Binary-Mode Nil (arg 2)))) (T (Unwind-Protect (prog2 (Binary-Mode T) (Tyo (arg 1))) (Binary-Mode Nil))))) and simlarly for the subprocedure Binary-Mode, and for RawPrinc, etc. What is more, one HAS to assume that passing NIL as a second arg is unwise, since the specs are difficult to remember, reasonably likely to get changed, and so on. Knowing when T or NIL will work versus when it won't is more trouble than it is worth. Regards, Mark Date: 19 NOV 1979 0918-EST From: KMP at MIT-MC (Kent M. Pitman) To: GSB at MIT-MC, (BUG LISP) at MIT-MC CC: RWK at MIT-MC, REES at MIT-MC GSB@MIT-ML 11/19/79 00:03:58 Date: 18 NOV 1979 0736-EST From: KMP at MIT-MC (Kent M. Pitman) (SETQ ^R T ^W T OUTFILES '(NIL)) according to the lisp manual will make the output go to the terminal. It doesn't -- it does a .VAL 0; EROR5A+22>>PUSHJ P,UINT instead. The lisp manual quite 'clearly' states that if ^W is on, that the default output destinations do not include the tty unless ^R is on and NIL is a member of the OUTFILES list... -kmp Obviously the lisp manual should be fixed, since this 'clearly' contradicts newio conventions. (Sigh. My personal opinion is that T and NIL should be flushed as filespecs. Too much greif.) ----- Well, step one could be to change the losing default error handlers so they don't try to print to '(T) ... This caused REES and me no end of hassles this weekend. The number of cases of file objects and lists thereof that a printer must handle to be compatible as a value of PRIN1 is ridiculous. -kmp Date: 19 November 1979 01:06-EST From: Richard M. Stallman Subject: ASSOQ and ASSQ and atoms To: TLP at MIT-AI, BUG-LISPM at MIT-AI, RWK at MIT-MC, BUG-LISP at MIT-MC Why in the world shouldn't ASSOC and ASSQ ignore atoms in the alist? It's clearly useful, much more useful than getting an error, because it makes those functions usable in situations where they would now be worthless. In fact people have functions called ASSQ-CAREFULLY, etc., on the Lisp machine which do precisely this. Who would be screwed by extending the functionality of ASSOC and ASSQ in this way? Date: 18 November 1979 09:51-EST From: Robert W. Kerns To: ALAN at MIT-MC, TLP at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-AI Date: 14 November 1979 03:45-EST From: Alan Bawden To: BUG-LISPM at MIT-AI cc: BUG-LISP Date: 13 NOV 1979 0925-EST From: TLP at MIT-AI (Tomas Lozano-Perez) Why doesn't ASSOC in LISPM LISP just ignore atoms in the list argument (like MacLisp does) instead of barfing by trying to take CAAR of them? Is this really a feature of MacLisp? I can't seem to find this in the moonual or in LISP NEWS or in the new MacLisp manual. It does behave this way on both ITS and Multics, but I would have reported it as a bug if I had found out about it on my own. It really is a shame that the LispMachine is forced to continue such lossages. Another example is the MacLisp definition of new-style DO in the case where the second "argument" is nil, it executes the body just once! This one is documented at least, but it sure is random! The DO feature is at least useful ... Anyway, ASSOC happens to behave this way, because it lets you use '((A . B) NIL (C . D)) and have the NIL entry ignored. This ends up carrying over to symbols because it uses (ATOM X) instead of (NULL X). Lose, lose. I think MacLisp should be changed... even the feature of ignoring null entries is kind of marginal. It should just do a null-check, like ASSQ does. TLP: If you're using ASSQ in MacLisp, it will LOOK like it's working, but will merely be taking the CAR of the symbol, which is unlikely to match your argument. It is merely randomness that this isn't also true of ASSOC. I.e. your code is bugous. Date: 18 NOV 1979 0736-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (SETQ ^R T ^W T OUTFILES '(NIL)) according to the lisp manual will make the output go to the terminal. It doesn't -- it does a .VAL 0; EROR5A+22>>PUSHJ P,UINT instead. The lisp manual quite 'clearly' states that if ^W is on, that the default output destinations do not include the tty unless ^R is on and NIL is a member of the OUTFILES list... -kmp JONL@MIT-ML 11/17/79 15:05:49 Re: GC-DAEMON To: (BUG LISP) at MIT-ML should be run in nointerrupt=T mode JONL@MIT-ML 11/17/79 14:57:24 Re: putddtsym To: (BUG LISP) at MIT-ML seems to have the wrong idea about whether GETDDI skips on success or failure (i.e., is-symbol-a-globalsym). Date: 16 NOV 1979 0051-EST From: GSB at MIT-MC (Glenn S. Burke) To: (BUG LISP) at MIT-MC *LISP 891 has some constants at FLSPA3 which get fallen into by the code at SHAREP+n when the .CALL SYSFIL succeeds... It is supposed to fall into SHARP1, but this random cruft has been put in the middle. MTM@MIT-AI 11/15/79 13:17:06 To: (BUG LISP) at MIT-AI With BASE and IBASE set to ROMAN, the form (setq n1 CCXIII n2 XXIII) returns XXIV. Date: 15 NOV 1979 1256-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC, KMP at MIT-MC, REES at MIT-MC One of us should fix GFN so that it pretty-prints LAMBDA's and LET's right. The comment by the grind functions for LAMBDA and LET is right -- it does want to avoid FORM3, but the code doesn't do the job... sigh. I haven't time now -- maybe later if someone else doesn't do it first (hint, hint) ... -kmp Date: 14 NOV 1979 1946-EST From: JONL at MIT-MC (Jon L White) Subject: Header Protocols for LISP source files To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, REES at MIT-MC, JPG at MIT-MC, CWH at MIT-MC Date: 14 November 1979 09:53-EST From: Kent M. Pitman To: BUG-LISP at MIT-MC LET and DEFMAX both don't care any more about (STATUS FEATURE NOLDMSG) -- the culprit is a buggy version of HERALD in NILCOM;MACAID > I've just fixed this, and will probably distribute the fasl's to other sites tonite. There is a new header protocol for files that want the # stuff activated - look at the first page of NILCOM;MACAID > The point is that the header no longer forces the fasloading of SHARPM, but hinges its request onto the symbol +INTERNAL-/#-MACRO The most recent versions of LISP will have an initial autoload property for +INTERNAL-/#-MACRO, but since most of this code will want to work properly in LISP 1861 etc, he extra care shown in this header is needed. The compiler will now have a SHARPM already loaded, with the macro initially activated in the compiler-enviroment, but not so in the user-enviroment. Date: 14 November 1979 18:46-EST From: Glenn S. Burke To: JPG at MIT-MC, BUG-LISP at MIT-MC Date: 13 NOV 1979 2036-EST From: JPG at MIT-MC (Jeffrey P. Golden) The UNFASL file should contain a semi-colon line giving the (STATUS USERID) of the person compiling the file. It probably would be a good idea for it to also note that (STATUS UNAME), since (STATUS USERID) may be 'ed to something random. Date: 14 NOV 1979 0953-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC LET and DEFMAX both don't care any more about (STATUS FEATURE NOLDMSG) -- the culprit is a buggy version of HERALD in NILCOM;MACAID > Date: 14 November 1979 03:45-EST From: Alan Bawden To: BUG-LISPM at MIT-AI cc: BUG-LISP at MIT-MC Date: 13 NOV 1979 0925-EST From: TLP at MIT-AI (Tomas Lozano-Perez) Why doesn't ASSOC in LISPM LISP just ignore atoms in the list argument (like MacLisp does) instead of barfing by trying to take CAAR of them? Is this really a feature of MacLisp? I can't seem to find this in the moonual or in LISP NEWS or in the new MacLisp manual. It does behave this way on both ITS and Multics, but I would have reported it as a bug if I had found out about it on my own. It really is a shame that the LispMachine is forced to continue such lossages. Another example is the MacLisp definition of new-style DO in the case where the second "argument" is nil, it executes the body just once! This one is documented at least, but it sure is random! Date: 13 NOV 1979 2036-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC The UNFASL file should contain a semi-colon line giving the (STATUS USERID) of the person compiling the file. Date: 13 NOV 1979 1608-EST From: JONL at MIT-MC (Jon L White) Subject: Ordering of Initial symbols To: (BUG LISP) at MIT-MC RWK and I have discovered the need to enforce a certain order in the symbol-headers of all carcdr properties; since there are about 7 such groupings of symbols with multiple ordering constraints, I've added commentary beginning with a line ;;; NOTE WELL! the symbol headers for which tries, for each grouping, to explain the required ordering, the other dependencies, and the reasons therefor. This is in the source file L;STRUCT > (and of course, in the unified source). JLS@MIT-AI 11/13/79 09:12:34 To: (BUG LISP) at MIT-AI Apologies, My mail about a supposed bug in EXP occured because I forgot that (EXP -88) is almost equal to the smallest number available on ITS. Date: 12 NOV 1979 0259-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: LET errors To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC (LET ((FOO (BAR) (BAR))) FOO) prints far too much in the error message --- everything after the LET! Clearly it would be much more helpful to print just the part that was found to be bad. Also, if you look at the EVALFRAME just below the ERRFRAME, the frame of the ERROR, you find this random #7171 pointer where you'd expect to see the rest of the arguments to ERROR. Date: 10 NOV 1979 1334-EST From: JONL at MIT-MC (Jon L White) Subject: PAGELENGTH with GRIND To: finin at MIT-AI CC: (BUG LISP) at MIT-MC The various grind things don't worry about page lengths - that would mostly be an operating-system concern. but lisp does keep a page-length variable for each open output file, and I believe it is initialized to nearly-infinity. you can reset it with (PAGEL ) Date: 10 Nov 1979 (Saturday) 1323-EST Id: Tim Finin (finin@mit-ai) From: DEWOLF at WPAFB-AFAL Subject: telling Grind about page length To: bug-lisp at MIT-AI reply to: finin@mit-ai Is there any way to tell Grind how many lines are on a page. My version of Grind seems to assume 60 lines/page. Tim Date: 10 NOV 1979 0132-EST From: KMP at MIT-MC (Kent M. Pitman) Sent-by: ___036 at MIT-MC Subject: LAMBDA* To: ALAN at MIT-MC CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, NIL at MIT-MC No, FEXPR's lose utterly -- you couldn't compile (LAMBDA ("E X Y Z) &AUX A) ; You left this var out, I'll assume it was implied (SETQ A (EVAL X) A (EVAL Y) A (EVAL Z)) (1+ A)) correctly (or at all) unless your compiler is CONSIDERABLY smarter than I think it is ... There's no hint of what's getting EVAL'd! ((LAMBDA* (A A A) ) ) would be the same as ... ((LAMBDA (A) ((LAMBDA (A) ((LAMBDA (A) ) )) )) ) Then LET* could just turn into a LAMBDA* ... I'm not sure if I'm serious or not. I'm also not sure if it matters. I thought I would throw it out for laughs, comments, or consideration and see if someone could help me make up my mind ... If anyone gives this any serious consideration, they'll have to also address what ((LAMBDA* (A A &OPTIONAL (B 1)) A) (* 0. B)) means ... or even worse ((LAMBDA* (A &OPTIONAL (A A))...) ...) and/or ((LAMBDA* (A &OPTIONAL (A A) &AUX (A A)) ...)...) mean ... I guess I'm probably not serious ... -kmp Date: 10 November 1979 01:09-EST From: Alan Bawden Subject: PROG* and related forms To: KMP at MIT-MC cc: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI, NIL at MIT-MC Date: 10 NOV 1979 0048-EST From: KMP at MIT-MC (Kent M. Pitman) Could we introduce a LAMBDA* operator which did bindings sequentially? Consider the following form, which returns the value 4. ((LAMBDA* (A A A) (1+ A)) 1 (1+ A) (1+ A)) Are you serious? You must be kidding. You can't really mean this. Consider: what does (LAMBDA* (A A A) (1+ A)) mean under your scheme? It would have to be the equivalent to: (LAMBDA ("E X Y Z) (SETQ A (EVAL X)) (SETQ A (EVAL Y)) (SETQ A (EVAL Z)) (1+ A)) Surely this ugly thing cannot be considered usefull. Clearly what you have in mind is that LAMBDA* only be used in places like the one you gave as an example: "((LAMBDA*", in which case What you want is LET*. Date: 10 NOV 1979 0048-EST From: KMP at MIT-MC (Kent M. Pitman) Sent-by: ___005 at MIT-MC Subject: PROG* and related forms To: (BUG LISPM) at MIT-MC CC: (BUG LISP) at MIT-MC, NIL at MIT-MC Could we introduce a LAMBDA* operator which did bindings sequentially? Consider the following form, which returns the value 4. ((LAMBDA* (A A A) (1+ A)) 1 (1+ A) (1+ A)) -kmp Date: 9 NOV 1979 2209-EST From: EJS at MIT-MC (Eric J. Swenson) To: (BUG LISP) at MIT-MC I'm not sure if sprinter is supposed to be used this way, but it sure generates an interesting error. Do this in a fresh lisp: (setq prin1 'sprinter) foo It will print out many, many, ";"'s and then the lisp will die with a .val 0 error. (.val 0; 63351>>push 16, 11) JLS@MIT-AI 11/09/79 18:32:37 To: (BUG LISP) at MIT-AI EXP SEEMS TO HAVE A BUG. (exp -50) = x..E-22 (exp -60) = x..E-27 (exp -70) = x..E-31 (exp -80) = x..E-35 BUT.. for anything less than -88 it gives zero when the exponent of the result should simply be decreasing linearly with the argument. - jim stansfield - Date: 9 NOV 1979 1421-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (SPRINTER '((5 . 7))) never returns. Date: 9 NOV 1979 1210-EST From: JONL at MIT-MC (Jon L White) To: RIVEST at MIT-MC CC: (BUG LISP) at MIT-MC RIVEST@MIT-ML 11/09/79 09:31:54 To: (BUG LISP) at MIT-ML Is ^Q broken? It doesn't seem to work today. Value of ^Q was looking funny, and ocasional odd terpri was missing, but is now patched (and source edited again). RIVEST@MIT-ML 11/09/79 09:31:54 To: (BUG LISP) at MIT-ML Is ^Q broken? It doesn't seem to work today. Ron Date: 9 NOV 1979 0039-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 11/07/79 09:24:38 To: (BUG LISP) at MIT-ML Why is copysymbol a no-op on NIL? . . . Patched, and edited in the source.