Date: 26 October 1981 03:17-EST From: William G. Dubuque Sender: BIL at MIT-MC Subject: back to normal ... To: BUG-LISP at MIT-MC Loading VECTOR into a XCOMPLR loses when a putprop is attempted on a fixnum while loading the new winning EXTEND. I renamed LISP;EXTEND FASL to LISP;EXTEND LOSER and the linked LISP;EXTEND FASL to OFASL.  Date: 25 October 1981 15:33-EDT From: Kent M. Pitman Subject: Questionable "modifications" to LIBDOC;6BIT To: JONL at MIT-MC cc: BUG-MACLISP at MIT-MC (1) I have never had an application for doing 6bit->ascii or vice versa in real time. Almost invariably, this is done in reader macros where the translation occurs once only and at compile time. There is no reason to make it twice as fast. It was not significantly slow. Worrying about someone using BOOLE or LOGAND instead of LOAD-BYTE or whatever is like worrying about someone using (PROG1 ...) instead of LET or PROG instead of DO. There may be a one or two instruction difference but who really cares? At this point in the evolution of Maclisp, code readability is worth its weight in gold. (2) My code was readable and compact. The cruft you wrote is long and unintelligible. (3) My code uses advertised functions, not crufty internal things with /| hanging off the end of them. If the advertised functions are too slow, we should make and advertise new functions with nice names. If you want to write your own package in such a form and propose it as an alternative that's fine, but I don't think that the LIBDOC;6BIT KMP2 which you wrote qualifies as something simply "added to" LIBDOC;6BIT KMP1. I will let you take the trouble of de-installing the `mods' ... I've spent as much time on this as I care to.  Date: 25 October 1981 13:48-EDT From: George J. Carrette Subject: Joke of the century. To: BUG-LISP at MIT-MC The implementation of strings and bitvectors in Maclisp is a joke. I brought up the NIL READer in maclisp to use as a Macro32 parser, and the damn thing runs 138 times slower than it does in real VAX NIL. If it were only 2 times slower it would be usable, but 138 times, that is absurd. For a 297 calls to +TYI there were 1297 calls to SI:CHECK-TYPER, 936 calls to PTR-TYPEP, 936 calls to BITSP, 828 calls to STR:CHARACTER-VALUEP, 828 calls to *:FIXNUM-TO-CHARACTER, 714 calls to CHAR-CODE, 645 calls to +INTERNAL-CHAR-N, 469 calls to MEMQ on the arguments [BITS,(STRING VECTOR BITS LIST EXTEND)]. 468 calls to SI:CHECK-SUBSEQUENCER, 468 to BITS-LENGTH, 468 to BIT, 360 to +INTERNAL-RPLACHAR-N, all for only 60 calls to READ-TOKEN. There are just three functions that need to be fast, which make up the inner loop of the finite state machine, I wonder if there is a good way to get at the primitives to hand code them? #+Maclisp (defun si:inch-by-mask-into-string (stream bits string offset) ;; Maclisp conditionalized for using +TYI. (do ((n (string-length string)) (c)) ((= offset n) offset) (setq c (+tyi stream)) (rplachar string offset (code-char c)) (if (bit1p bits c) (return offset) (setq offset (1+ offset))))) #+MACLISP (defun si:inch-by-not-mask (stream bits) (do ((c)) (()) (setq c (+tyi stream)) (cond ((= c -1) (*throw 'si:read-eof ())) ((not (bit1p bits c)) (return (code-char c)))))) (defun si:translate-string-subseq (translations string offset length) (do ((j 0 (1+ j))) ((= j length) string) (rplachar string (+ j offset) (char translations (char-code (char string (+ j offset))))))) -gjc  Date: 24 October 1981 13:18-EDT From: Edward Barton Subject: DESCRIBE To: BUG-LISP at MIT-MC (describe (si:extend foo-class)) The object at #717777 of class FOO, and is 2 Q's long. ; The grammar could be better here.... (describe 4) 4 is a FIXNUM ; great, it knows something to say about fixnums (describe tyi) ; yes, it knows something to say about a file, too (describe 'foo) * ; but alas remains silent about symbols  Date: 24 Oct 1981 1043-EDT From: JONL at MIT-EECS Subject: Not MacLISP's fault To: ls.bowbeer at MIT-EECS, gjs at MIT-AI cc: jonl at MIT-EECS, gjc at MIT-EECS, bug-maclisp at MIT-MC, scott at SRI-KL, jsol at RUTGERS, csd.jock at SU-SCORE, zubkoff at CMU-20C, BRoberts at BBNG The various problems related with using COMPLR, SCHEME, etc while supduping into MIT-EECS turn out not to be MacLISP's fault; I've spent many hours tracking this down, and finally have some proof that the EE version of VTS support is buggy. Eric Ostrom has just told me that there are other known bugs in it, and it will probably be de-installed in a week or so. Anticipating the loss of VTS, I'll have a lisp-written version of the cursorpos function which will work for several common terminals (VT52, VT100, HEATH, C100, and maybe a few others), and also a generalized "rubout" processor such has become common recently. Relevant files on MIT-MC are JONL;LCURSO >, LIBDOC;TERMTY DAT, NILCOM;THREAD >, and NILCOM;RUBOUT >. This stuff is currently under hacking/development so isn't yet ready for use. -------  Date: 24 October 1981 10:33-EDT From: Jon L White Subject: Redefining existing CLASSes To: eb at MIT-ML cc: BUG-LISP at MIT-MC EB@MIT-ML 10/24/81 03:49:26 To: (BUG LISP) at MIT-ML ;Re-defining class FOO (previously from file DSK:EB;FOO 1) (in file DSK:EB;FOO 3) ;Overwrite the existing class? (Y or N) y (Yes) now load in the new FOO file again, and it says ;Re-defining class FOO (previously from file DSK:EB;FOO 1) (in file DSK:EB;FOO 3) ; etc. Fixed now in EXTEND 287 and EXTSTR 91. (Installed on MC and ML, but not install yet on AI since its network program seems broken). What a long-dormant bug! Not only was the parity of the answer from the (Y or N) question being inverted, but even if you had typed "N" (which would have been mis-understood to mean yes), it still didn't redefine things right.  EB@MIT-ML 10/24/81 03:49:26 To: (BUG LISP) at MIT-ML ;Re-defining class FOO (previously from file DSK:EB;FOO 1) (in file DSK:EB;FOO 3) ;Overwrite the existing class? (Y or N) y (Yes) now load in the new FOO file again, and it says ;Re-defining class FOO (previously from file DSK:EB;FOO 1) (in file DSK:EB;FOO 3) ; etc. That is, either it doesn't do the redefinition or it forgets to use the correct source file information. The second time around, after a supposed redefinition, it still says the class was previously from the original source.  Date: 23 October 1981 09:26-EDT From: Jon L White Subject: 6BIT To: KMP at MIT-MC cc: MACRAK at MIT-MC, BUG-MACLISP at MIT-MC AI's network is still down, so I've not been able to install anything. There is this internal function in LAP called 1WD/| which does sort of what you want, but a little more generally. I extended 6BIT to allow for this additional functionality by adding the interface functions SYMBOL-TO-SIXBIT and SYMBOL-TO-ASCII which admit &optional second arguments specifying which 'word' of the converted pname is desired. For symmetry, I also added SIXBIT-TO-SYMBOL and ASCII-TO-SYMBOL. I might mention that the conversion from sixbit to ascii for the purpose of symbolification is an ideal application of LOAD-BYTE and DEPOSIT-BYTE, and by recoding that inner loop to use them instead of consing up for implode, the thing runs 75% faster (and does virtually no consing).  Date: 22 October 1981 22:36-EDT From: Kent M. Pitman To: JONL at MIT-MC cc: MACRAK at MIT-MC, BUG-MACLISP at MIT-MC I created the library LIBLSP;6BIT FASL (with associated doc/source LIBDOC;6BIT >) which I cannot install because AI is down. If you could take care of doing this later, I'd appreciate it. The ^DOC^ TJABLE, ^DOC^ MEMO, and ^DOC^ XGP need to be :INSTAL'd as well.  Date: 22 October 1981 21:51-EDT From: Stavros M. Macrakis To: BUG-LISP at MIT-MC Isn't there a Sixbit-to-Ascii and vice versa function somewhere in Lisp? I can't seem to find it in Lisp News, Lisp Oarchi, or the Obarray under anything obvious.  Date: 22 October 1981 12:13-EDT From: Jon L White Subject: SUSPEND/GC bug: OPSYFT To: JAR at MIT-MC cc: BUG-LISP at MIT-MC Date: 15 October 1981 22:31-EDT From: Jonathan A. Rees To: BUG-LISP at MIT-MC The location OPSYFT in list space is clobberred by the startup code that gets run after a suspend happens. However, that list cell is subject to garbage collection; if it can get on the freelist (it can; don't ask me how ...), the cell can get allocated for another use before the SUSPEND, and clobberred after. What you probably did to get that cell gc'd was something like (SSTATUS NOFEATURE TOPS20) -- that's about the only way to cause that cell to be cut out of the features list. At any rate, the correct thing to do (which I've just done by editing the sources) is to have the three critical status options (namely OPSYSTEM-TYPE, SITE, and FILESYSTEM-TYPE) be in a non-reclaimable part of list space.  Date: 21 October 1981 15:00-EDT From: Jon L White Subject: SETVST, in DEFVSX file To: BUG-MACLISP at MIT-MC For some reason, something has changed in the EXTHUK, EXTBAS, or EXT files since about midsummer, and caused that read-time-expansion of an SI:XREF to lose again. I've implemented the crock in a different way so as not to depend on these continuing vagaries, and recompiled DEFVSX (now version 105). Sigh! Can anyone think of why the read-time expansion suddenly changed from going into a RPLACX into a (LAMBDA ... (RPLACX ...)) ?  Date: 20 Oct 1981 0748-EDT From: JONL at MIT-EECS Subject: GRINDEF losage on EECS To: LS.PAE at MIT-EECS cc: bug-maclisp at MIT-MC In-Reply-To: Your message of 17-Oct-81 2228-EDT May have been an CFTP transmission error -- I've just re-transmitted the GRINDEF.FASL.462 file, and things seem to work again. After verifying that the previous one lost the way you said it did, I deleted it. -------  Date: 17 October 1981 13:10-EDT From: Jon L White Subject: EXPLODE, EXPLODEC, EXPLODEN reveal bug in PRINT To: MOHAMMED at SRI-KL cc: RWK at MIT-MC, BUG-LISP at MIT-MC Date: 7 Oct 1981 1806-PDT From: MOHAMMED at SRI-KL (explode '("abc")) generates the following error message: *** MISSING ARGS *** LOSING OUTPUT FILE SPEC It seems that the explode functions can't handle strings within lists. John Mohammed I see the trouble here -- the PRINT function is not properly faking out the sub-recursive call to EXPLODE/EXPLODEC/EXPLODEN. There will have to be the same kind of development in PRINT for the EXPLODE series which was done for FLATSIZE. RWK: I believe you put in the code around FLTHNK, do you wanna try a hand at this one?  Date: 17 October 1981 12:04-EDT From: Jon L White Subject: additional &AUX capability To: WGD at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 3 October 1981 18:03-EDT From: William G. Dubuque (defun f (a &aux b &aux c) ...) complains about the arglist; this works on the Lispm. Allowing this format makes it much easier for programs to append additional &aux vars. I forgot to mention that this now works in DEFMAC 166 (currently installed version which you get if DEFUN& is autoloaded). Also, the same thing should be true for DEFMACRO, right? Currently, the COMPLR isn't yet reloading DEFMAC, but there should be a new COMPLR soon anyway. Incidentally, some time ago, someone complained about the COMMENT which DEFUN&/DEFMACRO outputs that it shouldn't tell you about the &AUX vars; I believe removing that information is a mistake, and have re-installed it now, so that the comment contains pretty much the whole lambda-list. I see that some persons avoid &AUX for esthetic reasons, so presumably these ones wouldn't complain about the COMMENT.  Date: 17 October 1981 08:22-EDT From: Jon L White Subject: Updating MacLISP on SPEECH machine To: JIS at MIT-SPEECH cc: nlg.ja at MIT-SPEECH, GSB at MIT-ML, KWC at MIT-ML, ZUE at MIT-ML, BUG-MACLISP at MIT-ML Perhaps it would be wise to make the full MacLISP update to SPEECH, with the current LISP.EXE kept around for a while in case anyone notices difficulties. There used to be a bootstrap OMACLISP.EXE which would get the lower version number of LISP.EXE. In general, all the .FASL files have been tested out to work in the older lisps, although it's possible that some differences could be detected if one tried hard enough.  Date: 17 October 1981 08:12-EDT From: Jon L White Subject: (STATUS HSNAME) on Twenex To: KMP at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 11 October 1981 15:52-EDT From: Kent M. Pitman (STATUS HSNAME) on EE seems to return (STATUS UDIR) and not (STATUS USERID). This is a long-standing bug which has probably been reported before. It deserves to be fixed since it's probably trivial and would be very useful to a lot of people if it worked right. Actually, it happens that (STATUS HOMEDIR) was returning (STATUS UDIR) rather than (STATUS USERID), and in all reasonable cases, (STATUS HSNAME) turns into (STATUS HOMEDIR). So I've just edited in the source to have (STATUS HOMEDIR) return (STATUS USERID) -- hopefully this will keep people happy who write transportable code, since the concept of HSNAME is an ITS term that only weakly transports to Twenex.  Date: 17 October 1981 07:51-EDT From: Jon L White Subject: &AUX list backwards in MacLISP To: BIL at MIT-MC cc: BUG-LISP at MIT-MC, KMP at MIT-MC, GJC at MIT-MC Date: 16 October 1981 00:09-EDT From: William G. Dubuque (defun car&cdr (list &aux (car (car list)) (list (cdr list))) (values car list)) (car&cdr '(a b)) ==> (values 'b '(b)) It appears that defun& is totally losing here, switching the order of the &aux's and performing a boundp check on list. This works on the Lispm and in NIL. Both Lispm and a real NIL have "native" modes for binding the &optional and &aux variables, so only MacLISP has to try to "patch it" into a LET or LET* and kludge around. But indeed, the MacLISP only version of DEFUN& was returning a reversed list, and this is now fixed in DEFMAC 166. Date: 16 October 1981 00:58-EDT From: Kent M. Pitman . . . I thought it was agreed that &AUX had the semantics of a LET* -- why doesn't it just turn into one and be done with it. . . . Am I confused or is someone just trying to save a few cons's at the expense of correct code? Some time back, there was a flurry of mail talking about the semantics of binding for these & frobs -- originally the LISPM did a bind of all variables to their former values, and then a sequential assignment; subsequently it was changed to do incremental binding. For a variety of reasons, the incremental binding is a loss for MacLISP (more details if you are *really* interested), so the MacLISP-only version of DEFUN& tries to emulate the original Lispm behaviour. This "incompatibility" is rather a moot point, since the differences in semantics can only be detected when there is SETQ'ing of free variables in the &aux or &optional computations; the reversal of the &aux list, was, however a real bug and has been fixed. Date: 16 October 1981 15:06-EDT From: George J. Carrette If you load "VAXMAX;DEFUN&" you will win. . . However, we don't claim to support the stuff for any strange maclisp-only purposes you may have, but of course, if the price is right, maybe. The NILCOM file DEFMAC had two completely different versions of DEFUN& -- one for use under NIL, and one for use under MacLISP having the properties mentioned in the reply to KMP above. That you chose to rewrite as much of this software as you could, in your own way, is a mark of your personality, but it hardly helps the person like BIL who wants to write code that will run both in MacLISP and NIL. As mentioned above, I've fixed the MacLISP-only bug. [yes, I know, you had to "do it right" -- don't you always? -- but you've introduced yet a third set of alternatives with minor semantic differences which *** are not moot points *** as the one difference with Lispm noted above.]  Date: 16 October 1981 15:06-EDT From: George J. Carrette Subject: &AUX lossage. To: BIL at MIT-MC cc: BUG-LISP at MIT-MC If you load "VAXMAX;DEFUN&" you will win. This is amoung the code presently in use by NIL people when using Maclisp, as it became "inconvenient" to use the "NILCOM" macro support for DEFUN&, LET, DEFMACRO, BACKQ, SETF, DEFVST, etc. Since we hope to use the message-passing system you are working on, we might as well tell you about the goods. However, we don't claim to support the stuff for any strange maclisp-only purposes you may have, but of course, if the price is right, maybe. -gjc  Date: 16 October 1981 00:58-EDT From: Kent M. Pitman Subject: BIL's bug simplified: To: BUG-LISP at MIT-MC cc: BIL at MIT-MC (DEFUN F (&AUX (A (PRINT 'FOO)) (B (PRINT 'BAR))) (LIST A B)) (F) BAR FOO (T T) The bug in both cases seems to be that the list of setups which the &AUX expands into is backwards. I thought it was agreed that &AUX had the semantics of a LET* -- why doesn't it just turn into one and be done with it. Wouldn't (DEFUN F (...anything... &AUX ...more-stuff...) ...body...) work fine if it were just (DEFUN F (...anything...) (LET* (...more-stuff...) ...body...)) Am I confused or is someone just trying to save a few cons's at the expense of correct code?  Date: 16 October 1981 00:09-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-MACLISP at MIT-MC (defun car&cdr (list &aux (car (car list)) (list (cdr list))) (values car list)) (car&cdr '(a b)) ==> (values 'b '(b)) It appears that defun& is totally losing here, switching the order of the &aux's and performing a boundp check on list. This works on the Lispm and in NIL.  Date: 15 October 1981 22:31-EDT From: Jonathan A. Rees Subject: SUSPEND/GC bug: OPSYFT To: BUG-LISP at MIT-MC The location OPSYFT in list space is clobberred by the startup code that gets run after a suspend happens. However, that list cell is subject to garbage collection; if it can get on the freelist (it can; don't ask me how - all I know is that in Lisp 2088, on a Tops-20 at Yale, it has happened), the cell can get allocated for another use before the SUSPEND, and clobberred after. In our case it was the value word for a SUBR property in a PLIST; the symptom was UNBOUND PC WITH ILLEGAL OPCODE or something of that nature. Look at the code near TNXSET and the comments before and after TNXSET.  Date: 11 October 1981 16:09-EDT From: George J. Carrette To: BUG-LISP at MIT-MC do :L? you get BADPI;(IOCH1;) 126046>>,IOT 1,1 1/ 101  Date: 11 October 1981 15:52-EDT From: Kent M. Pitman To: BUG-MACLISP at MIT-MC (STATUS HSNAME) on EE seems to return (STATUS UDIR) and not (STATUS USERID). This is a long-standing bug which has probably been reported before. It deserves to be fixed since it's probably trivial and would be very useful to a lot of people if it worked right.  Date: Sunday, 11 October 1981 14:51-EDT From: GJC at MIT-EECS To: BUG-MACLISP at MIT-MC SUPDUP from a Lispmachine to MIT-EE. Then do XCOMPLR Then try typing various control characters such as ^L and ^C  Date: 10 October 1981 09:59-EDT From: Ken Church Sender: KWC0 at MIT-ML Subject: Re: maclisp To: "JIS@MIT-SPEECH" at MIT-AI cc: GSB at MIT-ML, KWC at MIT-ML, ZUE at MIT-ML, BUG-MACLISP at MIT-ML, nlg.ja at MIT-SPEECH Date: 9 Oct 1981 2209-EDT From: JIS at MIT-SPEECH at MIT-AI In-Reply-To: Your message of 9-Oct-81 1728-EDT Hi, you guys should not be screwing around with maclisp on Speech. Maclisp is installed on speech in cooperation with the VLSI and speech group. It would be a bad thing if a new maclisp went in without warning and broke their stuff, they happen to own the machine... -Jeff ------- It is very important that the MACLISP on Speech be kept up to date (more or less) so that it is possible to transport code from the ITSes to Speech. I have not been able to install LSB on speech because DEFMAX (in particular) is out of data and missing some important features. I am willing to help out in the updating process, but I will need to know some passwords. - ken  Date: 7 Oct 1981 1806-PDT From: MOHAMMED at SRI-KL Subject: EXPLODE, EXPLODEC, EXPLODEN To: bug-lisp at MIT-MC To whom it concerns: (explode '("abc")) generates the following error message: *** MISSING ARGS *** LOSING OUTPUT FILE SPEC It seems that the explode functions can't handle strings within lists. John Mohammed -------  Date: 3 October 1981 18:03-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-MACLISP at MIT-MC (defun f (a &aux b &aux c) ...) complains about the arglist; this works on the Lispm. Allowing this format makes it much easier for programs to append additional &aux vars.  Date: 28 September 1981 01:59-EDT From: Glenn S. Burke To: WGD at MIT-MC cc: BUG-MACLISP at MIT-MC Date: 27 September 1981 16:33-EDT From: William G. Dubuque Sender: BIL at MIT-MC How come a recursive wrng-no-args break calls the system supplied handler even when a user handler exists as the value of wrng-no-args? Errors which are going to immediately bomb out to errsets don't even call the handler; they just do (essentially) (ERRPRINT NIL), which is what all the default handlers do anyway. This is presumably what is happening to you? If in fact you make them stack by doing something like (setq errset 'car) then the correct handler gets called.  Date: 27 September 1981 16:33-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-MACLISP at MIT-MC How come a recursive wrng-no-args break calls the system supplied handler even when a user handler exists as the value of wrng-no-args?  Date: 24 September 1981 16:38-EDT From: Richard L. Bryan To: BUG-LISP at MIT-MC Date: 24 September 1981 03:15-EDT From: Richard L. Bryan The lsubr definition for SI:EXTEND in LSPSRC;EXTBAS seems to have si:extend-q-overhead added into the ARG ref rather than the I ref. Thus (SI:EXTEND VECTOR-CLASS 'X) returns #(X NIL). This Watergate plumber was discovered only because some code was compiled in an environment without the whitewash SI:EXTEND macro in EXTHUK. I fixed this.  Date: 24 September 1981 1315-EDT (Thursday) From: Guy.Steele at CMU-10A To: Alan Bawden Subject: Re: I wouldn't have believed it... CC: bug-lisp at MIT-MC In-Reply-To: Alan Bawden's message of 23 Sep 81 23:50-EST Message-Id: <24Sep81 131542 GS70@CMU-10A> It's simple. LOAD uses READ. DRIBBLE sets up ECHOFILES. Anything that gets read goes to ECHOFILES. Q.E.D. Now maybe we want to crock around this, but it's perfectly consistent with the current MacLISP I/O model. --Guy  Date: 24 September 1981 03:15-EDT From: Richard L. Bryan To: BUG-LISP at MIT-MC The lsubr definition for SI:EXTEND in LSPSRC;EXTBAS seems to have si:extend-q-overhead added into the ARG ref rather than the I ref. Thus (SI:EXTEND VECTOR-CLASS 'X) returns #(X NIL). This Watergate plumber was discovered only because some code was compiled in an environment without the whitewash SI:EXTEND macro in EXTHUK.  Date: 24 September 1981 00:50-EDT From: Alan Bawden Subject: I wouldn't have believed it... To: BUG-LISP at MIT-MC in a fresh maclisp: (fasload (liblsp) dribble) (dribble) (load '|dsk:luser;code >|) (dribble nil) Now LOOK at the dribble file. It contains the entire contents of luser;code!!! Can I really be seeing this? It doesn't fit in any of my models of MacLisp braindamage IO... (Presumably the author of dribble should be binding ^J to T or perhaps load should be swapping two magic bits in FREEAC or something...) Things like this just shouldn't happen in the real world. Perhaps P. K. Dick has been mucking around with MacLisp recently?  Date: 23 September 1981 17:40-EDT From: Jon L White Subject: And you thought you could trace ALPHALESSP while sorting... To: DCP at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 September 1981 15:34-EDT From: David C. Plummer . . . (trace alphalessp) (sort '(this is a test) 'alphalessp) (1 ENTER (ALPHALESSP (IS THIS)) (1 EXIT ALPHALESSP T) PURPG; 126744>>HRRM 5,(11) 5/ 740607 27076/ PUSH 16,6 SORT is hand-coded and thought that it *knew* that the ALPHALESSP function doesn't damage certain accumulators. But phooey on that if one re-defines, or traces, ALPHALESSP; so I've repaired that hole in the accumulator defences, and it works now in SORT version 13.  Date: 23 September 1981 16:49-EDT From: Jon L White Subject: 'count' argument for BITS-POSQ To: WGD at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 September 1981 18:42-EDT From: William G. Dubuque In NILAID: (setq b #B"000000001") (bits-posq 1 b 7 8) The 'count' value 8 is out of range for ... Yes, this is right -- starting at index 7, you can only have a maximum cont of 2. that last argument is a 'count' of number of positins to try -- not a maximum index.  Date: 22 September 1981 15:46-EDT From: Jeffrey P. Golden To: BUG-LISP at MIT-MC cc: ASB at MIT-MC, JPG at MIT-MC In a fresh MACSYMA, type e.g. LIMIT(X); . After it prints "LIMIT ... being loaded" but before it prints "Loading done" hit any interrupt character, e.g. ^G . The effect of the ^G will never happen. It is supposed to be postponed til after the loading process is completed because of a (NOINTERRUPT 'TTY) setup in the function LOADFILE of JPG;SUPRV , but of course the interrupt is supposed to happen when they are turned back on. This used to work, but stopped working at least in the last two releases of LISP.  Date: 22 September 1981 00:14-EDT From: George J. Carrette To: BUG-LISP at MIT-MC :L LISP 2122 Alloc? n * ''''')^L When you type ^L the quotes go away, are not redisplayed, cannot be rubbed-out. Nice trick.  Date: 21 September 1981 23:16-EDT From: George J. Carrette Subject: An easy way to not load DEFVSX To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Is to use DEFSTRUCT instead, I swear by it, and even use a video structure editor and EXHIBITOR running in Maclisp for it, almost like the one I showed you running in NIL. I've never been screwed by incompetent changes either, as I have with DEFVST. -gjc  Date: 21 September 1981 19:28-EDT From: Robert W. Kerns Subject: DEBUG To: KMP at MIT-MC cc: GJC at MIT-MC, BUG-LISP at MIT-MC BUG-LISP seems like a pretty silly place to complain about problems with a personal package belonging to me. Or are you implying that you think it should be standard? Anyway, in response to complaints from my users: 1) You can't load much of *ANYTHING* into a PDL-OVERFLOW break without getting another PDL-OVERFLOW break. For example, try (rplaca - -) (trace -). This isn't so bad, it's trying to give you another chance to give up before you screw yourself totally. If you type an $P you'll win. 2) It loaded DEFVSX because I couldn't think of a way to get around a problem with having a DEFVST in a separate file. I have now figured out how to get around the problem. The only file now loaded which was not before is EXTSTR, which should not break anyone's environment. It is certainly trivial compared to DEBUG, GRINDEF, FORMAT, YESNOP, or QUERY-IO, all of which have been used for a very very long time (although they did not all get loaded immediately, which used to cause all sorts of screws by autoloading them at bad times). If loading DEBUG now still causes you problems, you have two options: a) Pre-load it, before you run out of available BPS. Usually when you can't load it it's because you allocated all your pages early. You can trade GC time for the space. b) Use your own tiny package that can't pretty-print or ask you questions. It might be reasonale to flush FORMAT/YESNOP, but it would take some work and make DEBUG itself larger and uglier 3) I'm suprised you didn't mention this problem, since it's related to your complaint. If you have a large datastructure (other than cdr-long lists), since the stack is so small when you're in a PDL-OVERFLOW break, a GC can be disasterous. The previous version of the debugger used to cons a lot as you used it, leading to a greater likelyhood of blowouts (PDLOVERFLOW in GC, MAJOR RESTART UNDERTAKEN ...) the longer you used it. The newer one does all of it's consing initially. The NEWEST one neatly solves the problem by a special-case hack: When it encouters a PDL-OVERFLOW break in its scan of the stack, it expects that there may be recursive calls, and checks for calls of identical values. If it finds any, instead of representing each of these stack frames, it omits the duplicates, counting how many times each duplicate is omited. It handles co-recursive functions, etc.. Things which recurse infinitely (or very deeply) with differing arguments are not omitted, of course and any consing at all may be too much. There just isn't any way around it completely, but this heuristic should help. The debugger tells you when it prints a frame how many of its clones have been omitted. Anyway, give it a try and see what you think.  Date: 21 September 1981 04:35-EDT From: Kent M. Pitman Subject: [GJC: DEBUG] To: BUG-LISP at MIT-MC Date: 18 September 1981 01:51-EDT From: George J. Carrette To: KMP Re: DEBUG Ran into that myself. Have a private version of it now.  Date: 20 September 1981 18:42-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC In NILAID: (setq b #B"000000001") #B"000000001" (bit b 8) 1 (bits-posq 1 b 0 8) 8 (bits-posq 1 b 7 8) The 'count' value 8 is out of range for ...  Date: 20 September 1981 16:26-EDT From: David C. Plummer Subject: Why can't things ever be tested? Or, Doesn't anybody else use strings (if they are, why is this breaking for me)? To: BUG-LISP at MIT-MC In the current string package... (string-right-trim '(#\space) "this is a test ") "this is a test " ;; STRING-LEFT-TRIM and STRING-TRIM both trim from the left, but ;; even STRING-TRIM doesn't trim from the right.  Date: 20 September 1981 15:34-EDT From: David C. Plummer Subject: And you thought you could trace ALPHALESSP while sorting... To: BUG-LISP at MIT-MC :l n (trace alphalessp) ;Loading TRACE 67 (ALPHALESSP) (sort '(this is a test) 'alphalessp) (1 ENTER (ALPHALESSP (IS THIS)) (1 EXIT ALPHALESSP T) PURPG; 126744>>HRRM 5,(11) 5/ 740607 27076/ PUSH 16,6 (:L for me acutally gets an XLISP) Ging and poking aroung I find: ;;alphalessp by itself still works and traces correctly. (trace >) (sort '(1 2 3 4) '>) ;; works correctly  Date: 20 September 1981 15:15-EDT From: David C. Plummer Subject: Don't (SORT 'ALPHALESSP), or else... To: BUG-LISP at MIT-MC :l n (make-string 0) ;Loading ... "" (sort '("foo" "bar") 'alphalessp) ;Loading SORT 12 ;(NIL "bar" "foo") NIL CLOBBERED ;BKPT FAIL-ACT (sort '("foo" "bar" "baz") 'alphalessp) ;(NIL "baz" "foo") NIL CLOBBERED (sort '("this" "is" "a" "test") 'alphalessp) ;; this eats CPU time, but never returns. ;; even after all this (sort '(|this| |is| |a| |test|) 'alphalessp) (/a |is| |test| |this|) ;; so something is wrong in the string package. ;; also, alphalessp of strings seems to work.  Date: 18 September 1981 01:44-EDT From: Kent M. Pitman Subject: Gratuitous hair To: BUG-LISP at MIT-MC I think that the currently released DEBUG package is becoming useless. Some effort to trim it is in order. (1) It loads too many things. Many environments just can't tolerate all that junk getting loaded in. (2) I just ran it in a PDL-OVERFLOW break and it caused a PDL-OVERFLOW just trying to run. If a debugger is not going to be friendly to the environs it tries to run in, it's of diminishing value. A few months ago, this debugger was in good shape. Now I am thinking of stopping using it due to excessive hair. Fine to release a fancy-debug package, but let's bring back some measure of simplicity as the standard thing and let the fancy version be loadable for those cases where one can afford it.  Date: 18 September 1981 01:37-EDT From: Kent M. Pitman To: BUG-LISP at MIT-MC (LINEL x n) now returns -m instead of m where m is the old value of linel for that stream. eg, (LINEL TYO) => 78. (LINEL TYO 32.) => -78. (LINEL TYO 78.) => -32. This didn't happen in Maclisp.2057 but does in 2122. I hope it's a bug. -kmp  Date: 18 September 1981 00:27-EDT From: Alan Bawden Subject: string humor To: BUG-LISP at MIT-MC (make-string 5 #/a) "aaaaa" (describe *) The object at #733646 of class STRING, and is 4 Q's long. *  WJL@MIT-ML 09/16/81 13:35:12 To: (BUG LISP) at MIT-ML When the printing sender (whoever it is that sends the message to a user-hunk) passes the printing destination, the ^W information is forgotten, e.g., if outfiles is a list and ^W is nil, the printing only goes to outfiles. This is a long-standing bug -- Is there some reason it is difficult to fix? -Bill Long  Date: 11 September 1981 02:59-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC The BAKER-GC-DAEMON seems to like calling DIFFERENCE with a last argument of NIL sometimes.  KWC@MIT-ML 09/08/81 17:56:36 To: (BUG LISP) at MIT-ML I got the following complr warning: (COMMENT **** CHECK-ARG-CONTROL-STRING Undeclared - taken as SPECIAL in function FIND-MINIMUM-PATH) Find-minimum-path is pretty trivial, as you can see: (defsysr (find-minimum-path pnode) (check-arg pnode (fn (x) (or (null x) (hunkp x))) "a pnode or nil") (find-minimum-path1 pnode)) It sure looks like check-arc is doing something wrong ... (if i'm doing something wrong, then someone should be generating more useful warning messages.) - ken  Date: 7 September 1981 02:59-EDT From: Jonathan Lettvin To: BUG-LISP at MIT-MC A curious bug that GJC and BIL said might be worth mentioning. (DEFMACRO PUSHSET (ELEMENT LIST) `(SETQ ,LIST (CONS ,ELEMENT ,LIST))) does not have the same result as (DEFMACRO PUSHSET (ELEMENT LIST) `(SETQ ,LIST (NCONC (NCONS ,ELEMENT) ,LIST))) although, by all rights, it should behave identically. The example usage under which it fails is a large LISP system of functions such that a trivial demonstration of the problem is difficult. The observed behavior was as follows: (PUSHSET '(A B C D) MYLIST) => ((A B C D) A B C D) which is clearly incorrect. GJC confirmed this by using (CL:CL) although I do not know what that is. When the second form of the macro was performed, the correct action was the result. (PUSHSET '(A B C D) MYLIST) => ((A B C D)) I hope this is helpful in making the world a better place to live. If you want a practical demo, ask me and I will come over and show you.  Date: 3 September 1981 15:55-EDT From: Jon L White To: JPG at MIT-MC, WGD at MIT-MC cc: BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC, GCOOK at MIT-MC Date: 3 September 1981 07:08-EDT From: Jeffrey P. Golden Oops! As it may be argued that the example in my last mail does exhibit "differing declarations", as the first occurrence of X is not declared FLONUM, please replace the example by (defun f (x) (declare (flonum x)) ((lambda (x) (declare (flonum x)) (times x ((lambda (x) (declare (flonum x)) (times x x)) x))) (sin x))) This one fails in the same way anyway. Yup, your're right. I suspect that fixing COMPLR to ignore the *consistent* re-declarations wouldn't be any trouble at all. Maybe with a little more thought, fixing it for overriding declarations could be worked in too. Overrides of NOTYPE are harder to do since NOTYPE generally means the absence of other declarations -- getting this part would involve a little more work, but I'll look into it after returning from England.  Date: 3 September 1981 07:08-EDT From: Jeffrey P. Golden Subject: COMPLR bug To: JONL at MIT-MC cc: GJC at MIT-MC, BUG-LISP at MIT-MC, GCOOK at MIT-MC, MACSYMA-I at MIT-MC Oops! As it may be argued that the example in my last mail does exhibit "differing declarations", as the first occurrence of X is not declared FLONUM, please replace the example by (defun f (x) (declare (flonum x)) ((lambda (x) (declare (flonum x)) (times x ((lambda (x) (declare (flonum x)) (times x x)) x))) (sin x))) This one fails in the same way anyway.  Date: 3 September 1981 06:44-EDT From: Jeffrey P. Golden Subject: COMPLR bug To: JONL at MIT-MC cc: GJC at MIT-MC, BUG-LISP at MIT-MC, GCOOK at MIT-MC, MACSYMA-I at MIT-MC JONL@MIT-MC 08/27/81 00:59:19 To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC, GCOOK at MIT-MC, JPG at MIT-MC, CC: MACSYMA-I at MIT-MC I'm aware of the limitation in COMPLR, whereby you can't nest a local variables with differing declarations. Apart from the fact that it would be nice if the above bug were fixed, GJC's first example did not exhibit "differing declarations": GJC@MIT-MC 08/26/81 23:08:46 Let us look at a simple case: (defun f (x) ((lambda (x) (declare (flonum x)) (times x ((lambda (x) (declare (flonum x)) (times x x)) x))) (sin x))) The declarations here are the same. But the compiler still gives an error: (COMMENT **ERROR** (FLONUM G0001) Local declaration occurs too late in function in function F) ; DATA ERROR - TO PROCEED TYPE $P I think it would be REALLY nice if THIS bug were fixed. It seems to me that one would expect a code generator to generate cases involving consistent declarations, and it is a shame that even that does not work. This really adds to the burden of the code generator. Furthermore, the error message given by the compiler involves a G0001. I don't think that is a good example of human engineering. (Again, I am not saying there is anything wrong (except in terms of clarity of code) with "inconsistent nested local declarations" and that the whole bug shouldn't be fixed. I am just more concerned that the bug also happens when the declarations are consistent.)  Date: 3 September 1981 01:01-EDT From: Robert W. Kerns To: BUG-LISP at MIT-MC GENTEMP and +INTERNAL-TEMP-MARKER should be documented in LISP NEWS!  Date: 2 September 1981 22:48-EDT From: Jon L White Subject: your STRING gripes To: WGD at MIT-MC cc: BUG-LISP at MIT-MC The following two bugs were due to a fence-post-at-0-count error in STRING-REPLACE (now fixed in STRING 165): Date: 31 August 1981 14:34-EDT From: William G. Dubuque (STRING-SUBSEQ "FOO" 0 0) => error, why not "" ?? Date: 24 August 1981 13:25-EDT From: William G. Dubuque (string-subseq "a" 0 0) will get an error from string-replace while trying (string-replace "" "a" 0 0 0) Following fence-post bug is also fixed now in STRING-MISMATCHQ Date: 30 August 1981 23:22-EDT From: William G. Dubuque (STRING-MISMATCHQ "SI:FOO" "SI") => 2 but (STRING-MISMATCHQ "SI" "SI:FOO") => () ? Shouldn't the latter also be 2 ? Following was due to a bug in the open-compilation of FIXNUMP (as opposed to FIXP), which was fixed before the current COMPLR was dumped. Date: 25 August 1981 07:23-EDT From: William G. Dubuque (set-string-length "abc" 2) gives an error. It appears that the compilation of the (<= 0 new-length old-length) has been optimized into () by COMPLR. Actualy, to losing clause was the (FIXNUMP new-length) just before that.  Date: 2 September 1981 06:15-EDT From: Robert W. Kerns To: JL at MIT-MC, BUG-LISP at MIT-MC Loading either of those files into a bare LISP works fine for me. Or were you loading first one and then the other?  Date: 2 September 1981 04:42-EDT From: Jonathan Lettvin To: BUG-LISP at MIT-MC Sorry. JL;N1 1 loads properly. JL;N 1 does not. N1 was a copy of N directly with no changes. Curious.  Date: 2 September 1981 04:39-EDT From: Jonathan Lettvin To: BUG-LISP at MIT-MC When loading MC:JL;N1 1 into a bare LISP The BAKER-GC-DAEMON tries to (APPLY #'DIFFERENCE '(13312. 338. NIL)) I assume this is a bug. Hope it helps out.  Date: 1 September 1981 20:31-EDT From: Richard M. Stallman Sender: RMS0 at MIT-AI Subject: gensym problems To: BUG-LISP at MIT-AI Isn't the value returned by GENSYM uninterned? Why, then, do variables created by GENSYM ever cause conflicts?  Date: 1 September 1981 18:48-EDT From: Jon L White Subject: STRING-TRIM To: WGD at MIT-MC cc: BUG-LISP at MIT-MC Following has been fixed now in STRING 164 and YESNOP 44 Date: 31 August 1981 11:42-EDT From: William G. Dubuque (LOAD '((LISP) STRING)) (YESY-OR-NO-P)YES loses in STRING-TRIM.  Date: 1 September 1981 17:27-EDT From: Jon L White Subject: GENSYM variables in system "macros", and destructiveness To: MACSYMA-I at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC GENSYM variables: Apparently it has to be re-iterated again about the danger of using raw gensym variables in automatically-generated code, in MacLISP, NIL, or any other lisp system with numeric declarations or with global special declarations. Many system facilities automatically generate local variables, sometimes even with numeric declarations. If your code-writer (human possibly, but much more likely some automated system) happens to chose a symbol of the same pname, you will quite likely come into conflict with the scope of the declaration. This applies to any numeric declaration, whether local or global, and to the global (SPECIALS T) declaration. This problem was accurately diagnosed only relatively recently by RLB, RWK and myself. Slowly but surely, I've been converting automated system facilities to use some variant of GENTEMP (an as-yet unadvertised function in the MACAID utility package) -- this involves ** no ** semantic change to any code -- merely the substitution (typically) of SI:GEN-LOCAL-VAR for GENSYM in certain macros. These two facilities ensure that MacLISP (and COMPLR) will treat the variable truly as local, even when some other part of the code introduces a variable of the same pname. This should reduce the ocasional random coincidences (with devastating results!) which have sprung up in this realm now and then. The particular tactic taken in GENTEMP is to ensure a variable that isn't on the obarray. Another approach has been considered, that of providing truly unique names, perhaps incorporating some stamp of date-time-location long enough to insure that no two distinct calls to the future GENSYM could ever generate the same pname. Currently, that might require pnames of 12 or more characters, so this could be somewhat of a problem. Destructiveness: Apparently George Carrette not only doesn't understand this necessity, but has *deleted* numerous files for which I have made the appropriate substitution. It has been my understanding that if someone *thinks* he has a better way to solve a problem, he would update a file, with a higher version number -- not merely try to destroy another person's work. GJC's recent suggestion that this problem is only a COMPLR bug is sheer and utter nonsense. User's of his code, including the MACSYMA-to-lisp translator, may need to be extra-carefully on the lookout, since he still refuses acknowledge the GENTEMP problem. Also his recent note complaining about the msg "WARNING: Function SI:GEN-LOCAL-VAR being illegally defined by file "MC:LIBMAX;MAXMAC" seen while building a LISPM macsyma displays a total lack of understanding about what this means -- it is only that the file was compiled in the macsyma package, but put a macro into the SI package. It does not signal any redefining of a system facility, nor does it cause any bugs or problems whatsoever for the running MACSYMA. Admittedly, it is more in line with LISPM protocol to cons up another intermediate name so that the LISPM system won't even have to see the name SI:..., and I have just done this for the MAXMAC file (indeed any compotent programmer on these mailing lists could have done the same). The rest of his note of 30 August 1981 22:10-EDT may be taken as just so much more of the thoughtless flaming for which he has become so infamous.  Date: 1 September 1981 10:27-EDT From: Kent M. Pitman Sender: ___070 at MIT-MC To: BUG-LISP at MIT-MC I replied to stever's note about MPV; in ALLOC? -kmp  Date: 1 September 1981 02:28-EDT From: Stephen E. Robbins To: BUG-LISP at MIT-MC I did: :LISP LISP 2122 Alloc? ? ;I typed a ? ... Long message ... BADPI;(IOCH1;) 126046>>.IOT 1,1 1/ 15 to quote. P'ing it just repeated the BADPI;... stuff.  Date: 31 August 1981 11:42-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC (LOAD '((LISP) STRING)) (YESY-OR-NO-P)YES loses in STRING-TRIM.  KWC@MIT-ML 08/28/81 14:32:50 To: (BUG LISP) at MIT-ML It would be nice if there were a document that listed the atoms with auto load properties and a little bit of explanation as to what each of these are supposed to do. It is hard to know if you are winning or losing when it tells you that you've autoloaded some strange package.  Date: 27 August 1981 00:59-EDT From: Jon L White Subject: Possible problems in Compiled Macro files for MACSYMA's Transl To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, GCOOK at MIT-MC, JPG at MIT-MC, MACSYMA-I at MIT-MC Yes, George, I'm aware of the limitation in COMPLR, whereby you can't nest a local variables with differing declarations. In fact, in case it had slipped your notice, that is ****precisely**** one of the limitations for which GENTEMP had to be invented (but before you go on, remember that there are ***inherent*** limitations in the local declarations scheme which necessitate GENTEMP anyway). Still, that isn't GCOOK's problem. Date: 26 August 1981 23:08-EDT From: George J. Carrette JONL, you should know as well as any of us that there are known bugs in COMPLR in the handling of LAMBDA binding and declarations. These are what show up in GCOOK's code, not lack of using "SI:GEN-LOCAL-VAR" . . . Ok, where did the gensym come from? Not from any macros! Didn't TRANSL generate the code for him with GENSYM names in it? Or do MACSYMA programmers generally use local variable names like G0017 and G0018? Take another case: . . . Here your compiler confuses the two names "X" in the DO-LOOP, generating: (COMMENT **ERROR** ((IFIX X) NOT-OF-TYPE FLONUM) First item in list is an argument somewhere, but is of the wrong type in function F) See above comment on "nest"ing of local variables. JONL, I really do understand lambda binding, and GENSYM, and GENTEMP, so it is foolish for you to play your game assuming otherwise. You may go on of course as you wish, but you risk a great deal in doing so. If you do understand it, then you'll start converting many of your macros and other automatic-source-code-writers to use SI:GEN-LOCAL-VAR, or something like it, as appropriate. Since you haven't . . . Because it does take the interaction of ***two*** lambda-producing code writers to get into the binds mentioned above, and since it seems unlikely that you'll be able to figure out where to get rid of the GENSYM calls in TRANSL, then I changed one more part of the COMPLR souce-code-rewriting which was using GENSYM instead of its own version of SI:GEN-LOCAL-VAR (LOCAL-VAR, which is perfectly adequate and existed even before GENTEMP) so that at least GCOOK's problem will go away. But that won't stop TRANSL's bad interaction with other code writers, like macro packages etc.  Date: 26 August 1981 23:08-EDT From: George J. Carrette Subject: Possible problems in Compiled Macro files for MACSYMA's Transl To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, GCOOK at MIT-MC, JPG at MIT-MC, MACSYMA-I at MIT-MC JONL, you should know as well as any of us that there are known bugs in COMPLR in the handling of LAMBDA binding and declarations. These are what show up in GCOOK's code, not lack of using "SI:GEN-LOCAL-VAR" Let us look at a simple case: (defun f (x) ((lambda (x) (declare (flonum x)) (times x ((lambda (x) (declare (flonum x)) (times x x)) x))) (sin x))) It is completely clear what is going on here. It is called LAMBDA BINDING. But what does the compiler generate? .. have a look... (COMMENT **ERROR** (FLONUM G0001) Local declaration occurs too late in function in function F) ; DATA ERROR - TO PROCEED TYPE $P Ok, where did the gensym come from? Not from any macros! Take another case: (defun f () ((lambda (x) (declare (flonum x)) (do ((x (ifix x) (1+ x)) (s x (+$ 1.0 s))) ((= x 10) s))) (sin 3.3))) Here your compiler confuses the two names "X" in the DO-LOOP, generating: (COMMENT **ERROR** ((IFIX X) NOT-OF-TYPE FLONUM) First item in list is an argument somewhere, but is of the wrong type in function F) -- JONL, I really do understand lambda binding, and GENSYM, and GENTEMP, so it is foolish for you to play your game assuming otherwise. You may go on of course as you wish, but you risk a great deal in doing so. -gjc  Date: 26 August 1981 22:24-EDT From: Jon L White Subject: Possible problems in Compiled Macro files for MACSYMA's Transl To: GCOOK at MIT-MC, JPG at MIT-MC cc: MACSYMA-I at MIT-MC, BUG-LISP at MIT-MC I've just compiled your file, which you mention below as causing troubles (this may be the same problem which JPG found in ADK's case a couple of weeks ago): Date: 26 August 1981 19:55-EDT From: "Grant O. Cook, Jr." I have just uncovered a LISP bug. The compiler record is in GCOOK;JACOBF _UNFA_ where the LISP source is indicated to be the translated MACSYMA file GCOOK;JACOBF TRLISP . It is JACOBIAN_MATRIX which is crashing the compiler. Having made changes to the names of dummy do-loop indices (to make them unique) when the UMCL compiler failed to work (in the same fashion as indicated in the _UNFA_ file above), and then having it work (but generate code that bombed in MACSYMA: write into read-only memory while in NRECONC), it seems that there might be some problem with variable declarations. Well, I changed the name G0018 to GLOSES0018 and managed to win totally. After compilation, I noticed that the interned symbol G0018 had a NUMVAR property indicating that it had been globally declared FIXNUM. The MACSYMA transl package seems to be picking upon pooor G0018 for a temporary *non-numeric* variable, and is thus causing the poor COMPLR to be schrod. This problem has got to be a manifestation of the compiled macros bug for which there is a simple solution. Nowhere in your TRLISP file does the variable G0018 appear except in JACOBIAN_MATRIX, and it certainly doesn't do any declarations on it (as I mentioned, changing the name to something else causes things to win), so some macro package is managing to snarf this totally random name, and cause it to have a FIXNUM property (and possibly other properties?). I sent out a note explaining this problem a couple of weeks ago as follows: Date: 15 August 1981 13:52-EDT From: Jon L White Subject: LIBDOC;TTY To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 14 August 1981 17:02-EDT From: George J. Carrette In a bare lisp, do (LOAD "LIBLSP;TTY"), then (DO-WITH-TTY-OFF), you get a call to an undefined function: GENTEMP. Missing AUTOLOAD property for GENTEMP, which I added to TTY file -- any other "real" usage of TTY would not have been bothered since most other files would already have put the AUTOLOAD property. Probably GENTEMP should have an AUTOLOAD property in the initial LISP. . . . Furthermore, I challange you to prove why GENSYM is not sufficient for this case. (Excepting the bad practice of using read-time-macroexpansion inside macros of course.) The availability of local declarations in MacLISP, and of the compiler switch SPECIALS which makes all user variables special -- unless properly constructed with SI:GEN-LOCAL-VAR as in the TTY file -- means that system facilites ** must not ** depend upon GENSYM. The "cross-talk" of local declarations between 'gensym'd variables used by compiled macros can occur in the TTY file during usages of the DO-WITH-TTY-insomestate macros which are embedded in other macros usages; and also subsequent macros can occur in the code incorporated by the line ,@(CDR X)) of the DO-WITH-TTY-insomestate macros. The all-specials problem is ever-present If you still don't understand why GENSYM is buggy under these conditions, you'd better talk to someone who does before taking matters into your own hands. Well, GJC apparently didn't listen to the reply to his "challenge" but instead sent out a vituperative on some irrelevant subpart thereof. Too bad, since it is probably the failure of some of his code to use SI:GEN-LOCAL-VAR (as opposed to GENSYM) which has caused all this problem.  Date: 26 August 1981 19:34-EDT From: Jon L White Subject: (1) LOCK REPORT, and (2) "Bare" COMPLR To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 22 August 1981 21:49-EDT From: George J. Carrette "LIBLSP;DUMPGC" has a function (GENERATE-LOCK-REPORT) which by default generates the file "LISP;LOCK REPORT" from the file "LISP;LOCK MAIL" in the required format. Files which do not exist are marked with a "*" Tnx for bringing DUMPGC up to date -- I've incorporated the results of LOCK REPORT into LOCK > now, so the LOCK MAIL file is fairly new. One bug I noticed -- some files are continuously dumped over the same name, like FLAVOR;TS FLAVOR, and there are consequently multiple listings in the report for it; it would be correct to list only the latest dumping. This should save you some time. Can you do something that will save me some time? Can you dump out a COMPLR form me on a BARE MACLISP, that is one with NO MACROS, NO SOURCE-TRANS, of any kind? I'm looking for a bare complr environment, like one would want to dump out a RABBIT or other compiler built on maclisp. I've calculated that I can dump a macsyma-compiler on such a COMPLR, but there is no way I can do it with the present COMPLR, with all the macros and stuff like EXTSR and DEFVSY loaded. (Whatever they are). I made up a CCLOADer file (on GJC;CCLOAD >) to dump GJC;GC.DMP >, which is a fairly minimal COMPLR -- LET, DEFMAC, SETF, and SRCTRN ("source-trans" which account for compiling things like <=, LOGAND, etc.) have been removed resulting in a savings in address space of about 8K, and I made it up over SHARAB rather than MACLISP, which resulted in another 11K savings (partly due to "features" like GRINDEF being preloaded in MACLISP, and partly due to more "slop" when rounding off pure pages.)  Date: 26 August 1981 19:25-EDT From: Jon L White Subject: LOCK REPORT, and (2) Bare To: GJC at MIT-MC cc: BUG-LISP at MIT-MC  Date: 26 August 1981 16:24-EDT From: Jon L White Subject: Re: Multiple values To: GSB at MIT-MC, LAMP at MIT-MC, CWH at MIT-MC cc: BUG-LISP at MIT-MC This can't be the problem: GSB@MIT-ML 08/24/81 01:47:42 Re: Multiple values Date: 22 August 1981 02:28-EDT From: Carl W. Hoffman LAMP@MIT-MC 08/20/81 18:01:15 I've got a question about multiple values. Do you know why (multiple-value (a1 a2 a3) (let ((s1 3) (s2 2) (s3 4)) (values (+ s1 s2) (+ s2 s3) (+ s1 s3)))) gives an error message? I tried it in the lisp under a macsyma. Evan ---- Can somebody answer this? It seems fine to me. ---- Seems fine to me too. But the error message should be self-explanatory. It thinks it's doing you (the user) a favor by barfing that LET MIGHT not return multiple values. Cute, eh? (LET is SYSP, after all, and we all know system functions don't return multiple values.) The multiple-value checking *does* indeed "pass thru" LET -- note the winnitude of LAMP's example with a slightly different structure (defun LAMP () (multiple-value (a1 a2 a3) (let ((s1 3) (s2 2) (s3 4)) (auxillary s1 s2 s3)))) (defun auxillary (s1 s2 s3) (values (+ s1 s2) (+ s2 s3) (+ s1 s3))) I believe that all that was losing was the one part of the tester macroexpanded *before* checking for VALUES explicitly (as the other part of the tester did). I've fixed that now in the installed MLMAC (version 91), and will make up a new MACLISP/COMPLR pronto (a move somewhat overdue anyway since XLISP has been around for several weeks.)  Date: 25 August 1981 07:23-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC (set-string-length "abc" 2) gives an error. It appears that the compilation of the (<= 0 new-length old-length) has been optimized into () by COMPLR.  Date: 24 August 1981 17:52-EDT From: Carl W. Hoffman Subject: SETF and sequence updater's return values To: GSB at MIT-ML cc: JONL at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC Date: 24 August 1981 02:17-EDT From: Glenn S. Burke ... my personal feeling is that the returned value should be undefined. My own versions of setf, even the one written for protosystem 3 years ago, have always had the macro SETV which was like SETF but did guarantee the returned value. In addition to allowing SETF optimizations, I feel this approach makes code easier to read by tagging places in which an assignment is also used for value.  Date: 24 August 1981 13:25-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC (string-subseq "a" 0 0) will get an error from string-replace while trying (string-replace "" "a" 0 0 0)  Date: 24 August 1981 02:17-EDT From: Glenn S. Burke Subject: SETF and sequence updater's return values To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, NIL at MIT-MC $0.02 worth: Since SETF seems to be constrained to operate as a macro, outside of the domain of a smart compiler which could produce appropriate optimizations, my personal feeling is that the returned value should be undefined. My own versions of setf, even the one written for protosystem 3 years ago, have always had the macro SETV which was like SETF but did guarantee the returned value. I think it is unreasonable to make SETF jump through hoops constantly (and thereby tending to produce less optimal code) when the potential exists to make the primitive updating form be more condusive for use with SETF. Thus, if SETF returns the stored value, the updating function should return the value and take its args in the proper order. (If it does not, there should be an internal variant which DOES, and the compiler should understand this and know how to not bother returning the value when it is executed for effects. And most the time anyway, with things which are open-coded, the value will already be in a convenient place. Rather than, for every update which will be open-coded, having the compiler recognize the immediate re-access, as happens with (car (rplaca x y)) now.)  GSB@MIT-ML 08/24/81 01:47:42 Re: Multiple values To: (BUG LISP) at MIT-ML CC: CWH at MIT-MC Date: 22 August 1981 02:28-EDT From: Carl W. Hoffman LAMP@MIT-MC 08/20/81 18:01:15 I've got a question about multiple values. Do you know why (multiple-value (a1 a2 a3) (let ((s1 3) (s2 2) (s3 4)) (values (+ s1 s2) (+ s2 s3) (+ s1 s3)))) gives an error message? I tried it in the lisp under a macsyma. Evan ---- Can somebody answer this? It seems fine to me. ---- Seems fine to me too. But the error message should be self-explanatory. It thinks it's doing you (the user) a favor by barfing that LET MIGHT not return multiple values. Cute, eh? (LET is SYSP, after all, and we all know system functions don't return multiple values.) Why don't we flush this kludgey check altogether? The only place such a check really belongs is in a compiler which keeps track of multiple values properly, and which can REALLY tell you when you are losing, not just guess.  Date: 23 August 1981 01:41-EDT From: George J. Carrette Subject: Why is the value NIL special? To: BUG-LISP at MIT-MC (SETQ MACRO-EXPANSION-USE 'MACROMEMO) (DEFMACRO F1 (X) (PRINT X) ()) (DEFMACRO F2 (X) (PRINT X) '(QUOTE ())) (DEFUN G1 () (F1 "FOOBAR")) (DEFUN G2 () (F2 "FOOBAR")) (G1) ; prints "FOOBAR" (G1) ; continues to print "FOOBAR" (G2) ; prints "FOOBAR" (G2) ; doesn't print "FOOBAR" because the MEMOIZING worked. -gjc  Date: 22 August 1981 21:49-EDT From: George J. Carrette Subject: LISP;LOCK MAIL To: JONL at MIT-MC cc: BUG-LISP at MIT-MC "LIBLSP;DUMPGC" has a function (GENERATE-LOCK-REPORT) which by default generates the file "LISP;LOCK REPORT" from the file "LISP;LOCK MAIL" in the required format. Files which do not exist are marked with a "*" This should save you some time. Can you do something that will save me some time? Can you dump out a COMPLR form me on a BARE MACLISP, that is one with NO MACROS, NO SOURCE-TRANS, of any kind? I'm looking for a bare complr environment, like one would want to dump out a RABBIT or other compiler built on maclisp. I've calculated that I can dump a macsyma-compiler on such a COMPLR, but there is no way I can do it with the present COMPLR, with all the macros and stuff like EXTSR and DEFVSY loaded. (Whatever they are). -gjc  Date: 22 August 1981 02:28-EDT From: Carl W. Hoffman Subject: Multiple values To: BUG-LISP at MIT-MC cc: LAMP at MIT-MC LAMP@MIT-MC 08/20/81 18:01:15 I've got a question about multiple values. Do you know why (multiple-value (a1 a2 a3) (let ((s1 3) (s2 2) (s3 4)) (values (+ s1 s2) (+ s2 s3) (+ s1 s3)))) gives an error message? I tried it in the lisp under a macsyma. Evan Can somebody answer this? It seems fine to me.  Date: 22 August 1981 02:21-EDT From: Jon L White Subject: SETF's return value To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, NIL at MIT-MC I notice that the LISPM still holds that the value of SETF is undefined; the MacLISP/NIL SETF is trying very hard to return the "value" which is put in the the accessed frob, apparently so that SETF will parallel SETQ in some sense. In some cases, SETF doesn't have to try too hard, since the corresponding updator function returns that value, but in others, the updator function returns the frob just updated. E.g., STORE (and ASET) returns the value just placed into the array, but RPLACA returns the cons cell. The NIL documentation has never specified what the return values of the updators for various sequences should be, but we've been assuming all along that they would be parallel to RPLACA -- namely return the sequence instead of the component value. Is there any consensus in leaving these undefined, as with the LISPM SETF? Is there anyone who has a reason to depend upon the value of the new updator functions?  Date: 22 August 1981 02:11-EDT From: Jon L White Subject: The UNWIND-PROTECT/*FUNCTION bug To: KMP at MIT-MC cc: BUG-LISP at MIT-MC I've edited a 1-line correction for this one, and patched XLISP on the ITS systems (as well as LISP on MC -- but ML and AI are sort of down now so can't :INSTALL). Date: 20 August 1981 06:50-EDT From: Kent M. Pitman (SETQ X 3) (LET ((X (*FUNCTION (LAMBDA () X)))) (UNWIND-PROTECT () (FUNCALL X))) PURPG; AL5AB+3>>HRROM AR1,(A) AR1/ 0 IN777/ 0 I believe that *FUNCTION is trying to restore th binding context of the previous binding of X and has to restore +INTERNAL-WITHOUT-INTERRUPTS along the way and is dying. . . it should be careful when it restores that binding. . . . I believe that (WITHOUT-INTERRUPTS (WITH-INTERRUPTS ...)) is an ill-formed notion. Date: 21 August 1981 02:16-EDT From: Kent M. Pitman This bug is not really in *FUNCTION. The 2-arg case of EVAL and the 3-arg case of APPLY lose similarly when there is a WITHOUT-INTERRUPTS or UNWIND-PROTECT type thing on the stack in between the execution of the EVAL/APPLY and the context being re-instantiated. I rather agree with you in that relative evaluations should not try to alter the state of the +INTERNAL-WITHOUT-INTERRUPTS variable -- in fact as you pointed out, UNWIND-PROTECT explicity binds it to non-() when running the clean-up code, so as to lock out interrupts therein. Another way of saying this is the the stupid "variable" +INTERNAL-WITHOUT-INTERRUPTS is not enclosed by *FUNCTION.  Date: 22 August 1981 01:01-EDT From: Robert W. Kerns Subject: (without-interrupts (with-interrupts ...)) To: KMP at MIT-MC cc: BUG-LISP at MIT-MC I do not agree that this is an ill-formed notion. Consider: (without-interrupts ;;don't interrupt until we're ready (do () (()) ;;DO-FOREVER (do-some-interrupt-critical-=stuff) (do-some-more-stuff) (if unusual-state (with-interrupts (interact-with-user))))) WITHOUT-INTERRUPTS says we can't allow interrupts to happen at indiscriminate points within the form. However, there may well be points at which we do know interrupts are OK, and very likely will be highly desirable. WITHOUT-INTERRUPTS and WITH-INTERRUPTS, used together, provide an generalization of polling for interrupts.  Date: 21 August 1981 02:20-EDT From: George J. Carrette Sender: RLB at MIT-MC Subject: APPLY and EVAL lossage and WITHOUT-INTERRUPTS/UNWIND-PROTECT To: KMP at MIT-MC cc: BUG-LISP at MIT-MC GSB demonstrated lossage in the two arg cases of APPLY and EVAL on TOPS-20. The question being "why is evaluation system dependant?" Sounds like a possible stack bug related to observation. -gjc  Date: 21 August 1981 02:16-EDT From: Kent M. Pitman Subject: The UNWIND-PROTECT/*FUNCTION bug To: BUG-LISP at MIT-MC This bug is not really in *FUNCTION. The 2-arg case of EVAL and the 3-arg case of APPLY lose similarly when there is a WITHOUT-INTERRUPTS or UNWIND-PROTECT type thing on the stack in between the execution of the EVAL/APPLY and the context being re-instantiated.  Date: 20 August 1981 15:00-EDT From: Jon L White To: BUG-LISP at MIT-MC Reminder for more error checking: Date: 18 January 1981 23:08-EST From: Kent M. Pitman (SETQ MSGFILES 0) (ERROR) .VAL 0; ... or (SETQ MSGFILES 'FOO) (ERROR) PURPG;.... In .INFO.;LISP NEWS, bad values of MSGFILES are documented to cause an IO-LOSSAGE type error (after setting MSGFILES to '(T)), similar to the way bad BASE and IBASE values are treated with FAIL-ACT breaks. Couldn't Lisp be coaxed to do something along the lines of what it's documented to?  Date: 20 August 1981 14:45-EDT From: Jon L White To: BUG-LISP at MIT-MC Reminder for more error checking: Could this bug be fixed some time? JPG@MIT-MC 26 MAR 1980 0648-EST To: (BUG LISP) at MIT-MC In a fresh LISP, (MERGEF '(1 2 3) DEFAULTF) gives an ILOPR; error. I think some form of bad file specification error would be more appropriate.  Date: 20 August 1981 14:13-EDT From: Jon L White Subject: LISP;LOCK MAIL To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Reminder of need for automated processing of LISP;LOCK MAIL file: Date: 30 January 1981 22:34-EST From: George J. Carrette To: JONL at MIT-MC, KMP at MIT-MC I am mailing a one-line message to DSK:LISP;LOCK MAIL which is the value of *sharing-file-list* for the things I dump. Conveniently it has the responsible hacker and the date/time. I'll perhaps get around to writing a simple frob which generates an indentation-table from this info (marking which dumped files aren't actually around anymore of course). You don't have to look at LOCK MAIL if it is too much trouble. -gjc Shortly after this, I had PURE-SUSPEND also "mail" to LISP;LOCK MAIL -- unfortunately, there hasn't been any processing of this information since I last did it by hand in early May. With more dumps being put on the LSPDMP directory, some older (i.e., not recently used) ones will have to go "off line"; it would be nice if you finished the "indentation-table" program you've been talking about so that dumps "locked" down by other files, ** and not otherwise entered into the LISP;LOCK > file ** can be saved.  Date: 20 August 1981 06:50-EDT From: Kent M. Pitman To: BUG-LISP at MIT-MC (SETQ X 3) (LET ((X (*FUNCTION (LAMBDA () X)))) (UNWIND-PROTECT () (FUNCALL X))) PURPG; AL5AB+3>>HRROM AR1,(A) AR1/ 0 IN777/ 0 I believe that *FUNCTION is trying to restore th binding context of the previous binding of X and has to restore +INTERNAL-WITHOUT-INTERRUPTS along the way and is dying. If that's the case, it should be careful when it restores that binding. In fact, I would not care if it did not restore the proper state of that variable as I believe that (WITHOUT-INTERRUPTS (WITH-INTERRUPTS ...)) is an ill-formed notion. -kmp  Date: 19 August 1981 20:23-EDT From: Jon L White Subject: Twenex SUBFORK, and fix to (STATUS JCL) To: zubkoff at CMU-20C cc: BUG-LISP at MIT-MC, ryland at SRI-KL, gabriel at CMU-20C, feinberg at CMU-20C, scott at SRI-AI Your note of Date: 16 Aug 1981 1657-EDT From: (Leonard N Zubkoff) In-Reply-To: Your message of 15-Aug-81 1534-EDT is right in that Ryland's suggestion would always "enable" the characters in the RESCAN buffer -- however, the MacLISP/LEDIT interface does indeed always read them (the startup and return-from-superior hooks do an FJ) so that's why we didn't notice any difference between the two modes. I've put SUBFORK 50 onto MC and XX which makes the RESCAN subr work the way it did before. I suspect that Chris was "faked out" by a bug in (STATUS JCL), which I just fixed -- under ITS, the JCL is really only acquired at startup time, but if the RESCAN subr is to be of any value for stuffing something to other lisps (as opposed to stuffing into TECO), then (STATUS JCL) will have to make a try to retrieve the current scan-line/JCL. I've patched LISP.EXE.2122 to do this, and edited the sources appropriately. Note, however, that doing (STATUS JCL) also resets to null lisp's internal notion of what the scan line is; so for two calls in a row, the second is pretty much guaranteed to get null.  Date: 19 August 1981 13:08-EDT From: Jon L White Subject: CL startup lossage To: JL at MIT-MC cc: BUG-LISP at MIT-MC, BUG-DDT at MIT-MC Date: 16 August 1981 19:20-EDT From: Jonathan Lettvin Occasionally when I invoke CL^K I get the following garbage: ;Loading FIX file |DSK:LSPDMP;CLFIX 1115| 55512>>.BREAK 12,56667 56667/ 3,,7 But I have found that doing another CL^K works correctly. Hard to say -- this is the .BREAK just after FASLOAD decides that it is inferior to a DDT, and thus tries to get the symbol table pointer via .BREAK 12,[..RSTP,,TT] This may be a DDT bug.  Date: 19 August 1981 13:02-EDT From: Jon L White Subject: &optional losage To: feinberg at CMU-20C cc: BUG-LISP at MIT-MC, zubkoff at CMU-20C Date: 18 Aug 1981 1622-EDT From: Neal Feinberg (setq y 0) (defun foo (&optional (y y)) y) then (foo) => () in Maclisp 2117. I suspect it should evaluate to 0 This was already fixed here in the DEFMACRO file -- I suspect your version of DEFMACRO is out-of-date, so why not just FTP over the more recent copy (current version is 165).  Date: 18 Aug 1981 1622-EDT From: Neal Feinberg Subject: &optional losage To: Bug-lisp at MIT-AI Howdy! If (setq y 0) (defun foo (&optional (y y)) y) then (foo) => () in Maclisp 2117. I suspect it should evaluate to 0 instead. --Neal -------  Date: 18 August 1981 14:06-EDT From: William G. Dubuque Sender: BIL at MIT-MC Subject: SETF total lossage To: BUG-LISP at MIT-MC (DEFSETF MAKNUM ((() OBJECT) ADDRESS) `(SETF ,OBJECT (MUNKAM ,ADDRESS))) will lose whenever SETF decides that object or address is complicated enough that they should be bound to gensyms (thus producing a recursive setf call on gensyms).  Date: 16 August 1981 23:14-EDT From: Carl W. Hoffman Subject: Quotient To: KMP at MIT-MC, Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, GJC at MIT-MC, LPH at MIT-MC, MOON at MIT-MC Date: 3 August 1981 01:20-EDT From: Kent M. Pitman I suspect that few people make use of nary QUOTIENT and that those who do could write (QUOTIENT A (quotient b ...)) themselves or a macro that expands into same. The same for DIFFERENCE. What if only the commutative math ops were allowed to be nary? The key characteristic is associativity, not communtativity. If we let * represent some non-commutative operation (such as matrix multiplication), then (* A B C) makes perfect sense and is different from (* A C B). I don't use n-ary quotient, but I do use unary quotient as reciprocal.  Date: 16 August 1981 19:20-EDT From: Jonathan Lettvin To: BUG-LISP at MIT-MC Occasionally when I invoke CL^K I get the following garbage: ;Loading FIX file |DSK:LSPDMP;CLFIX 1115| 55512>>.BREAK 12,56667 56667/ 3,,7 But I have found that doing another CL^K works correctly. I presume this is a bug for you to digest. -JL@MC-  Date: 16 Aug 1981 1657-EDT From: (Leonard N Zubkoff) Subject: Re: Twenex SUBFORK 48 bug & fix To: JONL at MIT-MC cc: ryland at SRI-KL, BUG-LISP at MIT-MC, gabriel at CMU-20C, feinberg at CMU-20C, scott at SRI-AI In-Reply-To: Your message of 15-Aug-81 1534-EDT Gentlemen, The supposed bug you've found in the RESCAN subr is not a bug at all. By definition, RESCAN only places its string into the RSCAN buffer; it is up to the program inferior to Lisp to determine whether or not to enable this for reading. The separate call with .RsIni is used to enable the contants of the RSCAN buffer into the input stream. It is up to the Emacs/Ledit under the Lisp to perform the .RsIni call. If Lisp performs the .RsIni call itself, and the Emacs underneath does not perform an FJ to read the RSCAN buffer, then the RESCANed string will be read by Emacs as normal user type-in; the FJ call in Teco performs the .RsIni call itself. This use of the RSCAN buffer is in keeping with its normal use as the means for reading the line typed by the user to the Exec. Leonard -------  Date: 15 August 1981 15:58-EDT From: Jon L White Subject: LEDIT in new lisp To: zubkoff at CMU-20C cc: BUG-LISP at MIT-MC, SJK at MIT-MC, gabriel at CMU-20C, feinberg at CMU-20C Scott Kramer fixed a few trivial bugs in LEDIT recently, and I made one minor addition too -- MC:LISP20;LEDIT 38 (and on XX also) is the result. I didn't see any data that had anything like the losing mergef in it which RPG reported before, so I presume this was fixed prior to version 38.  Date: 15 August 1981 15:34-EDT From: Jon L White Subject: Twenex SUBFORK 48 bug & fix To: ryland at SRI-KL cc: BUG-LISP at MIT-MC, zubkoff at CMU-20C, gabriel at CMU-20C, feinberg at CMU-20C, scott at SRI-AI Date: 29 Jul 1981 1558-PDT From: Chris Ryland It seems, under R4, that SUBFORK's RESCAN subr isn't working. What's lacking is: (setz 1) ;Do an .RSINI RSCAN now (jsys 0 #.RSCAN) (setz 1) after the (hrro 1 1) (jsys 0 #.RSCAN) (setz 1) Your note appears to be correct for, as you say, version 4; so this mod is now in SUBFORK 49 (installed on XX and MC).  Date: 15 August 1981 15:16-EDT From: Jon L White Subject: NILAID loader for Twenex systems To: BUG-LISP at MIT-MC cc: scott at SRI-AI It does seem to want to call the version number of the .EXE file 1001 regardless of what the highest version stored on ps:.  Date: 15 August 1981 13:52-EDT From: Jon L White Subject: LIBDOC;TTY To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 14 August 1981 17:02-EDT From: George J. Carrette In a bare lisp, do (LOAD "LIBLSP;TTY"), then (DO-WITH-TTY-OFF), you get a call to an undefined function: GENTEMP. Missing AUTOLOAD property for GENTEMP, which I added to TTY file -- any other "real" usage of TTY would not have been bothered since most other files would already have put the AUTOLOAD property. Probably GENTEMP should have an AUTOLOAD property in the initial LISP. . . . Furthermore, I challange you to prove why GENSYM is not sufficient for this case. (Excepting the bad practice of using read-time-macroexpansion inside macros of course.) The availability of local declarations in MacLISP, and of the compiler switch SPECIALS which makes all user variables special -- unless properly constructed with SI:GEN-LOCAL-VAR as in the TTY file -- means that system facilites ** must not ** depend upon GENSYM. The "cross-talk" of local declarations between 'gensym'd variables used by compiled macros can occur in the TTY file during usages of the DO-WITH-TTY-insomestate macros which are embedded in other macros usages; and also subsequent macros can occur in the code incorporated by the line ,@(CDR X)) of the DO-WITH-TTY-insomestate macros. The all-specials problem is ever-present If you still don't understand why GENSYM is buggy under these conditions, you'd better talk to someone who does before taking matters into your own hands.  Date: 14 August 1981 17:02-EDT From: George J. Carrette To: BUG-LISP at MIT-MC In a bare lisp, do (LOAD "LIBLSP;TTY"), then (DO-WITH-TTY-OFF), you get a call to an undefined function: GENTEMP. This is caused by JONL's recent change to "LIBDOC;TTY", the changing of calls to GENSYM to calls to SI:GEN-LOCAL-VAR. Please don't diddle with working software, leaving it in inconsistent states. Furthermore, I challange you to prove why GENSYM is not sufficient for this case. (Excepting the bad practice of using read-time-macroexpansion inside macros of course.) -gjc  Date: 11 August 1981 17:09-EDT From: George J. Carrette To: DLA at MIT-MC cc: BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC, NIL-I at MIT-MC That '(FOO . #,BAR) example is another neat "SQUID" bug, this will show up in Maclisp too. If you are interested I tell you how we solve the "#," problem in NIL.  Date: 11 August 1981 15:09-EDT From: Jon L White Subject: VECTORs To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Date: 9 August 1981 23:49-EDT From: Alan Bawden (sprinter (vector 1 2 3)) prints: (1 2 3) notice the lack of a leading "#". Also (set-vector-length v n) seems to always get an MPV trying to write a #777777 into nowhere. Fixed now, in VECTOR 71. Problem with SPRINT method was merely missing output of #, and with SET-VECTOR-LENGTH was a 'twiddle' in the args to RPLACX.  Date: 9 August 1981 23:49-EDT From: Alan Bawden Subject: vectors To: BUG-LISP at MIT-MC (sprinter (vector 1 2 3)) prints: (1 2 3) notice the lack of a leading "#". Also (set-vector-length v n) seems to always get an MPV trying to write a #777777 into nowhere.  Date: 8 August 1981 05:54-EDT From: Jon L White Subject: Splicing macros To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 3 August 1981 15:07-EDT From: George J. Carrette In :L with no init do: (setsyntax #/~ 'splicing '(lambda () '(foo bar))) . . . This definition is wrong. you should have used (list 'foo 'bar) instead, for splicing macros, oddly enough, "splice-in" their result.  Date: 8 August 1981 04:17-EDT From: Jon L White Subject: STRING fenceposts, and other problems To: DUFTY at MIT-MC, JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 7 August 1981 09:45-EDT From: Dennis L. Doughty In basic vanilla XL, without string package ((LISP) STRING) loaded: (EQUAL "ASDF" "ASDF") => NIL (ALPHALESSP 'A "B") => T With string package loaded: (EQUAL "ASDF" "ASDF") => T (ALPHALESSP 'A "B") => NIL I really think that these should return T in all four cases... Without the STRING package loaded (EQUAL "ASDF" "ASDF") has to obey the defintion for EQUAL on symbols, namely EQ. Since the losing pseudo-string feature creates un-interned symbols, then these two frobs aren't EQUAL. It would be the wrong approach to try to have EQUAL switch to SAMEPNAMEP instead of EQ for symbols. However, when the STRING package is loaded, the case (ALPHALESSP 'A "B") => NIL was indeed a bug that is finally fixed in STRING version 162. Date: 7 August 1981 21:29-EDT From: Jon L White Subject: STRING-REVERSE-SEARCH- (STRING-REVERSE-SEARCH "ab" "abcdefghi" 4) => NIL (STRING-REVERSE-SEARCH-SET '(#/a) "abca" 3) => 3 . . . These 'fence-post' errors are corrected in STRAUX 72 and STRING 162 so that both cases properly return 0.  Date: 7 August 1981 21:29-EDT From: Jon L White Subject: STRING-REVERSE-SEARCH- To: BUG-LISP at MIT-MC (STRING-REVERSE-SEARCH "ab" "abcdefghi" 4) => NIL (STRING-REVERSE-SEARCH-SET '(#/a) "abca" 3) => 3 i.e., not only is the optional "from" argument not being decremented by these routines before the actual searching begins, but apparently the key-searcher fails to look at the first word?  Date: 7 August 1981 09:45-EDT From: Dennis L. Doughty Subject: String Problems To: BUG-LISP at MIT-MC cc: DUFTY at MIT-MC In basic vanilla XL, without string package ((LISP) STRING) loaded: (EQUAL "ASDF" "ASDF") --> NIL (ALPHALESSP 'A "B") --> T With string package loaded: (EQUAL "ASDF" "ASDF") --> T (ALPHALESSP 'A "B") --> NIL I really think that these should return T in all four cases...  Date: 7 August 1981 04:02-EDT From: Glenn S. Burke Subject: :LISP vs :L on MC To: REM at MIT-MC cc: BUG-LISP at MIT-MC Someone somehow managed to dump out a BBLISP as TS LISP; TS L was still linked to the right thing. The failure to restore interrupts was because it was impure. The file was created on july 25. I reinstalled the correct link.  Date: 7 August 1981 03:03-EDT From: Robert Elton Maas To: BUG-LISP at MIT-MC Addenda to preceding msg. After :LISP of course answer N to the ALLOC? message.  Date: 7 August 1981 03:02-EDT From: Robert Elton Maas To: BUG-LISP at MIT-MC Followup on preceding msg. :LISP (STATUS NOINTERRUPT) --> NIL (LOAD '|REM;FOO >|) ;Contains just a dummy defun of FOO (STATUS NOINTERRUPT) --> T (should be still NIL, is NIL if you used L not LISP)  Date: 7 August 1981 02:57-EDT From: Robert Elton Maas To: BUG-LISP at MIT-MC There's something funny about SYS;TS LISP that is different from SYS;TS L. LISP disables interrupts (permanently) whenever a LOAD or FASLOAD is done whereas L reenables interrupts when done (or doesn't disable them in the first place, I don't care which), thus LISP appears broken.  Date: 6 August 1981 18:42-EDT From: Jon L White To: RIVEST at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC RIVEST@MIT-ML 08/05/81 15:18:57 To: (BUG LISP) at MIT-ML The file ML:RIVEST:PRCBUG > evokes some sort of compiler error (*** ERRORS IN COMPLR -TOPLE ***) What does this mean? . . . I think the problem was that my directory was full. A clearer error message from the compiler would be nice... As KMP pointed out, this is almost always due to a directy full error, or device full error; some work would have to go into LISP itself to be able to separate out these errors, and toss them back to monitor level, which is really what one would like to happen. Just to make life a little simpler, I've modified the error msg to include the file position of the input file and of the (output) fasl file, and to hint that the problem is some kind of I/O error. This change will be evident in XCOMPLR/COMPLR 1118.  kmp@MIT-MC (Sent by ___021@MIT-MC) 08/06/81 13:22:20 To: REM at MIT-MC CC: (FILE [LISP;BUG MAIL]) at MIT-MC Oops. I missed the description of how to reproduce it at end of your bug file. Sorry about that.  Date: 6 August 1981 13:20-EDT From: ___021 at MIT-MC Subject: REM's non-bug To: BUG-LISP at MIT-MC REM was calling (ERROR 'YOU-RANG) explicitly, so Lisp was behaving exactly as it should have been. The full reply to him is CC'd to LISP;BUG MAIL ...  Date: 6 August 1981 13:18-EDT From: Kent M. Pitman Sender: ___021 at MIT-MC To: REM at MIT-MC cc: "(FILE [LISP;BUG MAIL])" at MIT-MC (DEFUN EDIT-ONCE EXPR (BD NEXMOV OKCHANGES) (PROG (CHR OLDCHR DELTA SIZE) ... (COND ((EQUAL (ASCII 7) CHR) (ECHO) (ERROR 'YOU-RANG) (RETURN NIL))) ... )) Does this code look familiar? You requested the behavior you got. The (ERROR 'YOU-RANG) generates a ;YOU-RANG and a ;BKPT *RSET-TRAP (*RSET is the handler that gets errors which have no error channel associated with them). I don't really think the BUG-LISP people should have to debug your code. This is something you clearly could have solved yourself by searching for the YOU-RANG string in your file as I did... Oh, and in future bug reports, please specify: * the filename(s) involved * a procedure for reproducing the bug * a clear description of how the viewed behavior deviates from what you think the correct behavior is. Your bug note contained really none of these. Bug notes really should contain all of that information to be very useful.  Date: 6 August 1981 12:10-EDT From: Robert Elton Maas To: BUG-LISP at MIT-MC I'm trying to disable ^G interrupt in my Go program. (SSTATUS TTYINT 7 NIL) seems to work fine at the top level, but when I put it in my program then hitting ^G resulted in ;YOU-RANG and ;BKPT *RSET. The first part sounds like something I wrote, but I checked (STATUS TTYINT 7) and it's still NIL, which I thought should disable the ^G interrupt. What am I doing wrong? (To see this, :LISP REM;REM LISP then (Q 5) then hit ctrl-G.)  Date: 5 August 1981 15:39-EDT From: Kent M. Pitman To: RIVEST at MIT-MC cc: BUG-COMPLR at MIT-MC, "(FILE [LISP;BUG MAIL])" at MIT-MC This sort of bug should go to BUG-COMPLR, not BUG-LISP. *** ERRORS IN COMPLR -TOPLE *** is a message from the complr saying that its toplevel read-compile loop died in some wierd way. It can mean many things -- it happens to me often due to directory full when it tries to open output files ... Other possible things are maybe read errors? I don't know ... Take a look for unclosed parens or dot errors or whatever ... When in the breakpoint, I think INFILE is bound to your input file object and that if you do (FILEPOS INFILE) it will tell you where it was in the file when it died. If INFILE is closed, probably the read died in unclosed parens or something similar. That's all one can say without looking at it in detail, which I don't have the time to do. But since JONL's not in right now, maybe that'll give you something to go on until he shows up. -kmp  RIVEST@MIT-ML 08/05/81 15:24:44 To: (BUG LISP) at MIT-ML I think the problem was that my directory was full. A clearer error message from the compiler would be nice... Thanks anyway, Ron Rivest  RIVEST@MIT-ML 08/05/81 15:18:57 To: (BUG LISP) at MIT-ML The file ML:RIVEST:PRCBUG > evokes some sort of compiler error (*** ERRORS IN COMPLR -TOPLE ***) What does this mean? Thanks, Ron Rivest  Date: 3 August 1981 15:07-EDT From: George J. Carrette To: BUG-LISP at MIT-MC In :L with no init do: (setsyntax #/~ 'splicing '(lambda () '(foo bar))) '(~) ; this works '(~~) ; this causes lisp to wedge, use ^G to get out. '(~) ; further uses of "~" will wedge.  Date: 3 August 1981 11:52-EDT From: Jon L White Subject: Please stop wasting all our time To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC You deleted the relevant part of the following msg, namely "YOUR PROFANITY", From: Jon L White I didn't read that note. Is that all you sent? You didn't read the note. Very nice. So you want me to send something else, even though you were complaining . . . Furthermore, I sent my note about LSB's SELECTQ to RWK, since I was replying to his comments, ** not your comments **.  Date: 3 August 1981 11:51-EDT From: Jon L White To: BUG-LISP at MIT-MC cc: MACSYMA-I at MIT-MC Has anyone on these two mailing lists either observed the behaviour alleged by GJC below, or been inconvenienced by it? This may be a moot point since both versions of UMLMAC, 33 and 34, were installed for only a short time, and have not been current for many days. Date: 3 August 1981 11:41-EDT From: George J. Carrette . . . Before JONLism: "MC:LSPSRC;UMLMAC 33" (selectq x (a b)) ==> (COND ((EQ X 'A) B)) After JONLism: "MC:LSPSRC;UMLMAC 34" (selectq x (a b)) ==> (AND (EQ (TYPEP X) 'SYMBOL) (COND ((EQ X 'A) B))) Just what are people to think when you replace good code with this kind of junk? Are we to say, well, it is "adequately efficient?" [your term]  Date: 3 August 1981 11:41-EDT From: George J. Carrette To: JONL at MIT-MC cc: MACSYMA-I at MIT-MC, BUG-LISP at MIT-MC From: Jon L White I didn't read that note. Is that all you sent? You didn't read the note. Very nice. So you want me to send something else, even though you were complaining about clogged mail files. Ok, in the interests of others I'll provide the smallest example: [Note: all examples are from installed system code.] Before JONLism: "MC:LSPSRC;UMLMAC 33" (selectq x (a b)) ==> (COND ((EQ X 'A) B)) After JONLism: "MC:LSPSRC;UMLMAC 34" (selectq x (a b)) ==> (AND (EQ (TYPEP X) 'SYMBOL) (COND ((EQ X 'A) B))) Just what are people to think when you replace good code with this kind of junk? Are we to say, well, it is "adequately efficient?" [your term] -gjc  Date: 3 August 1981 10:31-EDT From: Jon L White Subject: Profanity To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC I didn't read that note. Is that all you sent?  Date: 3 August 1981 10:20-EDT From: George J. Carrette Subject: SELECTQ efficiency? To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC JONL, you said you never read my note, so why are you now asking for more examples of your lossage? Furthermore, you haven't answered the $60,000 question, "why did you replace installed code with inferior code?" As for clogging up the mail, I assure you, answer the questions and the issues will resolve themselves.  Date: 3 August 1981 10:09-EDT From: Jon L White Subject: SELECTQ efficiency? To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC Date: 2 August 1981 11:59-EDT From: George J. Carrette . . . That fact that you were later able to get a more winning version from GSB does not support redemption. [Seriously folks, name any feature in maclisp, and you can get a more winning version from GSB. . . .] Since LSB'S SELECTQ, which I corrected for minor bugs, *never* had any bugs in the installed version, and was adequately efficient even in its middle versions, then can you explain why you should clog all our mail files with these continuing complaints? I shouldn't be surprised if someone could find a case that, ** even now **, could be slightly improved.  Date: 3 August 1981 01:20-EDT From: Kent M. Pitman Subject: Quotient To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, GJC at MIT-MC, LPH at MIT-MC, MOON at MIT-MC I suspect that few people make use of nary QUOTIENT and that those who do could write (QUOTIENT A (quotient b ...)) themselves or a macro that expands into same. The same for DIFFERENCE. What if only the commutative math ops were allowed to be nary? (+)=0, (+ A)=A, (+ A B)=A+B, (+ A B C)=A+B+C, (+ A B C ...)=A+B+C+... (*)=1, (* A)=A, (* A B)=A*B, (* A B C)=A*B*C, (* A B C ...)=A*B*C* .... (- x)=-x, (- x y)=x-y, others undefined. (/ x y)=x/y, others undefined. (^ x y)=x^y, others undefined. The same would hold for PLUS, TIMES, QUOTIENT, EXPT, except (- x) would be (MINUS x) and (- x y) would be (DIFFERENCE x y). This seems an acceptable compromise for your standard.  Date: 2 August 1981 11:59-EDT From: George J. Carrette Subject: SELECTQ To: JONL at MIT-MC cc: MACSYMA-I at MIT-MC, BUG-LISP at MIT-MC Since you have chosen to enlarge this disscusion to include Macsyma-I, I might as well lay it on the line. Your big problem JONL is a cavalier attitude that you can do as you please, releasing untested and inferior software upon maclisp users. Let us look carefully at your latest complaint: "By the bye, GSB was actively hacking the SELECTQ macro of LSB, and it had none of the faults or inefficiencies that GJC alleges. He merely looked at the results of an intermediate version." On the contrary, I was looking at the results of a version that was *installed* system code. You installed it. To say that it was "intermediate" is admission of guilt. The reason I took the time to write a SELECTQ macro and install it into maclisp was so that reasonable software would be available to (amoung other systems) macsyma. The reason you had for deinstalling my version, installing what you knew to be inferior software, and leaving it in that "intermediate" state for four days, is something only you know. That fact that you were later able to get a more winning version from GSB does not support redemption. [Seriously folks, name any feature in maclisp, and you can get a more winning version from GSB. Its what comes from thoughtfull consideration of the issues without the rush to install new hacks.] -gjc  Date: 1 August 1981 15:05-EDT From: Jon L White Subject: Who says, "gratuitous"? To: RWK at MIT-MC cc: GJC at MIT-MC, CWH at MIT-MC, GSB at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC Date: Monday, 27 July 1981, 10:13-EDT From: Robert W. Kerns Subject: Penultimate pain-in-the-ass To: JONL at MIT-MC Why do you feel this irresistable compulsion to make gratuitous changes? Please restore the SELECTQ to use GJC's winning version. LSB's SELECTQ is much more a winner. Just because GJC's version is more limited is no reason for you, too, to try your hand at insults. The LSB version, (the one in UMLMAC) is extensible, with current setting to limit datatype, just as the LISPM does. Contrary to what was alleged earlier, there never has been any "incompatibility" with the LISPM, but merely the potential extension. You see, there are many of us who don't simply take the LISPM-implementation of SELECT/SELECTQ as the forever-fixed definition; it should be extended to work for other data types. By the bye, GSB was actively hacking the SELECTQ macro of LSB, and it has none of the faults or inefficiencies that GJC alleges. He merely looked at the results of an intermediate version, and I didn't bother reading his flame due to its obvious profanity.  Date: 1 August 1981 14:55-EDT From: Jon L White Subject: ALPHALESSP & Strings To: DUFTY at MIT-MC cc: BUG-LISP at MIT-MC Date: 30 July 1981 16:58-EDT From: Dennis L. Doughty I do (ALPHALESSP "A" 'FOO) or (ALPHALESSP 'FOO "A") ... both return NIL. I believe this is due to the fact that I load the STRING library, but I'm not sure. Why does this happen? There is a bug in the ALPHALESSP function, when given two args of dissimilar type (one is a string, the other a symbol). I can't patch this problem in the current lisp, since the patch area is essentially all used up, but I did assemble a new lisp (version 2122) and things are fixed in it.  Date: 1 August 1981 12:26-EDT From: Jon L White Subject: Context of &OPTIONAL and &AUX calculations To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 1 August 1981 12:14-EDT From: George J. Carrette Subject: I hate to tell you but... ... (DEFUN G (Y) (SETQ X (+ X Y))) (DEFUN H (&OPTIONAL (X (G X))) X) ... I'll admit that the example is contrived, however, note well that it used to work, when the code generated was a simple use of LET* . . . At one time, the LISPM did the following for &OPTIONAL and &AUX calculations: 1) Create a bind frame with all the relevant variables in it, being bound to their previous values, if any. 2) Sequentially set each &OPTIONAL variable to either the input arg [which might mean no code output], or set it to the default calculation. Then sequentially set each &AUX variable to its calculation. This order has the happy effect that &OPTIONAL and &AUX calculations don't disturb any special variable bindings in the outer contour, where there is an ** apparent LAMBDA binding ** of that special variable in the function. I still feel that that original scenario is the better one, since it is more in accord with the notion that the implicit LAMBDA binding of the argument variables will "shield" the outer contour. Could this situation possibly have any practical significance? or is it only going to occur in, as you say, "contrived" circumstances?  Date: 1 August 1981 12:14-EDT From: George J. Carrette Subject: I hate to tell you but... To: JONL at MIT-MC cc: BUG-LISP at MIT-MC DEFUN still doesn't work even though you have patched some cases. (DEFVAR X 0) (DEFUN F (&OPTIONAL (X X)) X) ; you have fixed the above case, but the next one: (DEFUN G (Y) (SETQ X (+ X Y))) (DEFUN H (&OPTIONAL (X (G X))) X) In the function H, G gets called with X in a new binding context bound to what it was in the outside binding context, this is of course not the same thing as being in the outer binding context. I'll admit that the example is contrived, however, note well that it used to work, when the code generated was a simple use of LET* we had ==> (DEFUN H *NARGS* (LET* ((X (IF (> *NARGS* 0) (ARG 1) (G X)))) X)) Note also, that the above simple code compiles into better machine language than the more complex incorrect code that is the result of optimizations that try to use a LET instead of a LET*. I'll admit that it is worth doing the optimizations in most cases, but I question, "Is it worth giving up correctness?" -gjc  Date: 31 July 1981 22:41-EDT From: Jon L White Subject: Quotient To: MOON at MIT-MC cc: KMP at MIT-MC, GJC at MIT-MC, LPH at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, Guy.Steele at CMU-10A Date: 31 July 1981 22:35-EDT From: David A. Moon . . . I would say to change QUOTIENT and REMAINDER to be the same as // and - with one argument. Jonl, can you reproduce Pratt's reasons for wanting them to be different? Merely backwards compatibility. // was a relatively new function, so changing its definition from that of QUOTIENT would have affected few people, but changing QUOTIENT may have raised a ruckus from some. Pratt wanted the mathematical notions for the operators that CGOL could go into, but didn't want to take on any possible 'incompatibility' charge. I'd be happy with the change, but I thinke it's deep enough to require some sort of poll of the community.  Date: 31 July 1981 22:35-EDT From: David A. Moon Subject: Quotient To: Guy.Steele at CMU-10A cc: KMP at MIT-MC, MOON at MIT-MC, GJC at MIT-MC, LPH at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC I use the more-than-two-argument minus sign all the time. Keep it. I would say to change QUOTIENT and REMAINDER to be the same as // and - with one argument. Jonl, can you reproduce Pratt's reasons for wanting them to be different?  Date: 31 July 1981 19:30-EDT From: Jon L White Subject: Rational operations of one argument To: MOON at MIT-MC, KMP at MIT-MC, GJC at MIT-MC cc: LPH at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 31 July 1981 03:31-EDT From: David A. Moon Subject: Inconsistency of 1-argument QUOTIENT with //,//$ This appears to be a documented feature, at least in the red manual. I wonder why? Perhaps it's a (possibly spurious) analogy with the difference between DIFFERENCE and - ? GLS has already quite satisfactorily given the reply to this query, (esp. w.r.t. reasons behind the two different extensions, and the irrelevance of hardware considerations), but I'd like to add the historical note that this question was really only faced when CGOL started to get some usage (when? I'm not sure, but maybe in 1973), and PRATT was instrumental in maintaing the difference (no pun intended) between the two extensions. Thus, e.g., DIFFERENCE of one argument remained the identity function, instead becoming the group inverse operator, whereas "-" of one argument was defined to become the negation operation.  Date: 31 July 1981 1225-EDT (Friday) From: Guy.Steele at CMU-10A To: jonl at MIT-MC, Scott.Fahlman at CMU-10A, gabriel at CMU-20C, brooks at CMU-20C, moon at MIT-AI, dlw at MIT-AI Subject: Query about splicing macros CC: bug-lisp at MIT-MC, bug-lispm at MIT-AI Message-Id: <31Jul81 122556 GS70@CMU-10A> Question: does anyone, anywhere, ever use splicing macros to return more than one thing (i.e., other than zero or one thing)? The feature grossly hairs up the reader, which I would dearly like to simplify for Common LISP (in a compatible manner if possible). --Guy  Date: 31 July 1981 1223-EDT (Friday) From: Guy.Steele at CMU-10A To: Kent M. Pitman Subject: Quotient CC: moon at MIT-MC, gjc at MIT-MC, lph at MIT-MC, bug-lisp at MIT-MC, bug-lispm at MIT-MC In-Reply-To: Kent M. Pitman's message of 31 Jul 81 02:40-EST Message-Id: <31Jul81 122330 GS70@CMU-10A> Well, it is bullshit that // and - of one argument were motivated by hardwre considerations. How do you omit one argument to the FDVR instruction? Extension of nonassociative operators to other than two arguments is always a tricky business. There was confusion in FORTRAN for quite a while over whether X/Y/Z should mean X/(Y/Z) or (X/Y)/Z = X/(Y*Z). (FORTRAN 77 resolves this in favor of the latter.) Now note that the definition of (QUOTIENT a b c ... z) = a/b/c/.../z = (...((a/b)/c).../z) = a/(b*c*...*z) is not the only "natural" extension. One could equally well define it to be a/b/c/.../z = a/(b/(c/...z)). This is actually easier for the PDP-10 hardware given the LSUBR convention! It is also what APL does when division-reduction is requested. I strongly suspect that the real reason // and - are the way they are is because of the appealing analogy to the standard infix and prefix (i.e., binary and unary) interpretations of these operators. Thus (- x y) = x-y and (- x) = -x which is certainly nice. The three-or-more-argument cases arise seldom anyway, so I suppose consistency for that extension was not a prime concern. Actually, the main argument for keeping three-argument - and // in Common LISP is mostly compatibility, while there are good arguments against (clarity). One can just as well write (- x (+ y z)) as (- x y z). (By the way, I think old PDP-1 LISP defined - and // to work as APL reduction does.) LISP 1.5 and InterLISP have only two-argument quotient and difference. Opinioc xx opinions? --Guy  Date: 31 July 1981 1209-EDT (Friday) From: Guy.Steele at CMU-10A To: gjc at MIT-MC Subject: Re: Inconsistency of 1-argument QUOTIENT with //,//$ CC: moon at MIT-MC, bug-lisp at MIT-MC, bug-lispm at MIT-MC, lph at MIT-MC In-Reply-To: David A. Moon's message of 31 Jul 81 02:31-EST Message-Id: <31Jul81 120936 GS70@CMU-10A> The behavior of QUOTIENT and //$ is entirely analogous to that of DIFFERENCE and -; they were, after all, invented simultaneously. The analogy is not spurious; // and - of one argument are each the inverse operator of the group to which it belongs. // is the inverse operator for the multiplicative group, and - of the additive group. --Guy  Date: 31 July 1981 03:40-EDT From: Kent M. Pitman To: MOON at MIT-MC, GJC at MIT-MC cc: JONL at MIT-MC, GLS at MIT-MC, "(FILE [DSK:LISP;BUG MAIL])" at MIT-MC It was my understanding that DIFFERENCE, QUOTIENT, TIMES, and PLUS wanted to do the `right' thing with their one-arg cases and that //, //$, ... were defined (sad definition in my opinion) to do whatever machine-specific hardware operation was around that seemed to do the right thing... The explanation I got from Jonl (I think) was that the odd behavior was a logical fall-out of what the hardware does when that state is reached... It strikes me as very un- uniform that (quotient x y z) => x/y/z and (quotient x y) => x/y and (quotient x) => 1/x, so I'm not sure either why (quotient x) doesn't just return x ... but that was the description I understood. I'll let them reply to Bug-Lisp/Bug-LispM on this ...  Date: 31 July 1981 03:31-EDT From: David A. Moon Subject: Inconsistency of 1-argument QUOTIENT with //,//$ To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, LPH at MIT-MC, BUG-LISPM at MIT-MC This appears to be a documented feature, at least in the red manual. I wonder why? Perhaps it's a (possibly spurious) analogy with the difference between DIFFERENCE and - ?  Date: 30 July 1981 23:53-EDT From: George J. Carrette To: BUG-LISP at MIT-MC cc: LPH at MIT-MC, BUG-LISPM at MIT-MC There are some inconsistencies in "//$" and "QUOTIENT" in the one-argument case. (QUOTIENT 0.0) => 0.0 (//$ 0.0) => 1.0 Actually, the LISPM behaves the same way with respect to QUOTIENT of one argument, its the identity function rather than the multiplicative inverse function, not that it makes any sense at all either way of course. This showed up as a subtle bug in the Macsyma->lisp translator, where the declaration of the modes of variables discontinuously changed the behavior of the arithmetic. I guess thats what happens when try and build on lisp and be too cute at the same time. -gjc  Date: 30 July 1981 1702-EDT (Thursday) From: Guy.Steele at CMU-10A To: John G. Aspinall Subject: Re: SUBLIS with arrays CC: bug-lisp at MIT-MC In-Reply-To: John G. Aspinall's message of 30 Jul 81 15:21-EST Message-Id: <30Jul81 170209 GS70@CMU-10A> SUBLIS can only be used to substitute things for SYMBOLs. It's a crock, but what can one do? Sigh.  Date: 30 July 1981 16:58-EDT From: Dennis L. Doughty Subject: ALPHALESSP & Strings To: BUG-LISP at MIT-MC cc: DUFTY at MIT-MC I do (ALPHALESSP "A" 'FOO) or (ALPHALESSP 'FOO "A") ... both return NIL. I believe this is due to the fact that I load the STRING library, but I'm not sure. Why does this happen?  Date: 30 July 1981 16:21-EDT From: John G. Aspinall Subject: SUBLIS with arrays To: BUG-LISP at MIT-MC cc: JGA at MIT-MC (setq edge-1 (*array nil 'flonum 2)) (setq edge-2 (*array nil 'flonum 2)) (setq face (list edge-1)) (setq alist (list (cons edge-1 edge-2))) (sublis alist face) ;will produce the error ;#FLONUM-2-70774 NON-ATOMIC ITEM - SUBLIS John.  Date: 30 July 1981 14:16-EDT From: Robert W. Kerns To: REM at MIT-MC cc: BUG-LISP at MIT-MC Oh, I forgot to say that SPRIN1 is just like PRIN1, except it prety-prints.  Date: 30 July 1981 14:15-EDT From: Robert W. Kerns Subject: Grinding to a file To: REM at MIT-MC cc: BUG-LISP at MIT-MC You must not have looked very carefully, since SPRIN1 was added in late 1979 and included in the table of changes at the top of the file. It was also documented in LISP NEWS at that time, so you could have found it out by searching that file for "grind" or "pretty-print". Or look in the non-existant manual under "pretty printing". It's really too bad one has to be a wizard to use MacLisp. Looking at the code is one way wizards find features; searching LISP NEWS is another you can add to your inventory of techniques.  Date: 30 July 1981 13:24-EDT From: Robert Elton Maas Sender: ___074 at MIT-AI Subject: Prettyprint to file?? To: BUG-LISP at MIT-AI cc: REM at MIT-MC To LISP hackers -- Does anybody know of a clean way in NEWIO to prettyprint or grindef to a file other than the TTY? I looked at GFN and GFILE, but GFN (the usual pretty printer) is hardwired to use the TTY and would seem to need total rewriting to use a general file (all TYO/PRIN1/PRIN2 etc. would have to be changed to use another argument...) while GFILE is specially written to read one file and write another rather than write arbitrary stuff from memory to a file. (At least that's how it looked to me when I perused those files.) -- What I'm doing now is writing to a file with PRIN1 and later using EMACS to MM Grind Sexpr. Anybody have a better way programmed in LISP?  Date: 29 July 1981 22:22-EDT From: Kent M. Pitman Subject: Oops. That last note was from KMP, not GJC To: BUG-LISP at MIT-MC cc: GJC at MIT-MC, REM at MIT-MC Sorry. -kmp  Date: 29 July 1981 22:14-EDT From: George J. Carrette To: BUG-LISP at MIT-MC cc: REM at MIT-MC I replied to REM with some suggestions about MPV's...  Date: 29 Jul 1981 1740-PDT From: Chris Ryland Subject: PS to previous note To: bug-lisp at MIT-MC I believe the lack in RESCAN which I noted in my previous mail is only a problem under Release 4 and above of Tops-20. In fact, it may not work under earlier releases; I don't have any easy way to find out. -------  Date: 29 July 1981 19:13-EDT From: Robert Elton Maas To: BUG-LISP at MIT-MC Is there a way to restart a LISP core image that got a MPV? I tried $G but it still hit the MPV. I had been doing (IOTA ((TYO ...)) ...) when it died.  Date: 29 Jul 1981 1558-PDT From: Chris Ryland Subject: Twenex SUBFORK 48 bug & fix To: bug-lisp at MIT-MC It seems, under R4, that SUBFORK's RESCAN subr isn't working. What's lacking is: (setz 1) ;Do an .RSINI RSCAN now (jsys 0 #.RSCAN) (setz 1) after the (hrro 1 1) (jsys 0 #.RSCAN) (setz 1)  GSB@MIT-ML 07/29/81 16:17:39 Re: random pdl overflow To: (BUG LISP) at MIT-ML CC: MOON at MIT-ML I've gotten this a couple times in the last few days during loading of complr init file  WJL@MIT-ML 07/28/81 11:10:26 To: (BUG LISP) at MIT-ML (push 'foo (cxr 3 bar)) |Function..10| undefined function object  EB@MIT-ML 07/27/81 10:05:19 To: Bug-GJC If messages about SELECTQ bugs are going to be abusive, perhaps they are not proper for polite distribution over Bug-Lisp.  Date: Monday, 27 July 1981, 10:13-EDT From: Robert W. Kerns Subject: Penultimate pain-in-the-ass To: JONL at MIT-MC Cc: GJC at MIT-MC, CWH at MIT-MC, GSB at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC In-reply-to: The message of 26 Jul 81 17:27-EDT from Jon L White Why do you feel this irresistable compulsion to make gratuitous changes? Please restore the SELECTQ to use GJC's winning version.  Date: 27 July 1981 00:06-EDT From: Glenn S. Burke Subject: format, fyi To: BUG-LISP at MIT-MC Apparently i never noted this: The hack whereby the "format string" may be a list is going away. It is still supported just-in-case, except that the EVAL kludge is gone. The fact that the latest lispm manual documents this "feature" is an oversight.  Date: 26 July 1981 17:27-EDT From: Jon L White Subject: Penultimate SELECTQ? To: GJC at MIT-MC cc: CWH at MIT-MC, GSB at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC Date: 25 July 1981 17:14-EDT From: George J. Carrette Subject: The ultimate disposal of the SELECTQ problem. To: JONL at MIT-MC I noticed you asked CWH about this. Well, the installed SELECTQ is one I wrote that accepts items of types SYMBOL and FIXNUM, is LISPM compatible, and generates code as good as CASEQ when it can. Actually, I had suggested in some earlier mail that we use the macro defintion that GSB had in LSB. It had only a minor glitch or two (which I corrected when moving it into UMLMAC), but is a super-winner since it handles *all* cases, and does so most efficiently. That's the SELECTQ macro now in UMLMAC. GSB: the "glitch" was that it failed when the calling form didn't end in one of (T OTHERWISE :OTHERWISE). Also, I updated the calls to gensym to be si:gen-local-var.  Date: 26 July 1981 15:27-EDT From: Jon L White Subject: Taking CAR and CDR of hunks To: KRONJ at MIT-MC cc: BUG-LISP at MIT-MC Date: 25 July 1981 23:46-EDT From: David Eppstein To: BUG-LISP at MIT-MC (car '(foo.)) => #777777 (cdr '(foo.)) => FOO . . . Why are the CAR and CDR of a one-element hunk switched from what I would expect? Maybe they should both return FOO, in my example above. This example of 1-element hunks is just another reason why the idea of treating hunks as generalized lists is bad. Interpretively, at least, CXR and RPLACX will certify the length before trying to access an i'th element; CDR was defined to get the 0'th element, and CAR the 1'st element; possibly extra code could be added to CAR to check for hunks of length 1.  Date: 25 July 1981 23:46-EDT From: David Eppstein To: BUG-LISP at MIT-MC (car '(foo.)) => #777777 (cdr '(foo.)) => FOO (**self-eval** .) => ;#777777 UNDEFINED FUNCTION OBJECT Why are the CAR and CDR of a one-element hunk switched from what I would expect? Maybe they should both return FOO, in my example above.  Date: 25 July 1981 17:14-EDT From: George J. Carrette Subject: The ultimate disposal of the SELECTQ problem. To: JONL at MIT-MC cc: CWH at MIT-MC, GSB at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC I noticed you asked CWH about this. Well, the installed SELECTQ is one I wrote that accepts items of types SYMBOL and FIXNUM, is LISPM compatible, and generates code as good as CASEQ when it can.  Date: Saturday, 25 July 1981, 16:33-EDT From: Robert W. Kerns To: JONL at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 25 Jul 81 09:15-EDT from Jon L White Date: 25 July 1981 09:15-EDT From: Jon L White To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Date: Tuesday, 14 July 1981, 15:25-EDT From: Robert W. Kerns Subject: SEND In-reply-to: The message of 5 Jul 81 01:12-EDT from Jon L White Date: 5 July 1981 01:12-EDT From: Jon L White (SEND -CLASS 'PRINT) results in ILOPR. so does the sending of a variety of other msgs, including :PRINT-SELF. Admittedly, the :PRINT-SELF msg might require all those silly extra args that PRINT-OBJECT takes, but why can't the PRINT methods default them to appropriate values? At least, it shouldn't ILOPR, but die more gracefully. Why not fix LISP's LSUBR calling sequence, which is at fault here? Note that the PRINT method is an OBSOLETE name for :PRINT-SELF. Why not just call the function PRINT, which does the defaulting for you? I'm not sure what you're suggesting here -- since a PRINT msg is acceptable, then why should it be totally equivalent to the :PRINT-SELF msg? The latter can take all the extra args it wants, but the former could simulate a call to PRINT. NO! You cannot use the name PRINT. It is already used, and should never have been reused to mean what :PRINT-SELF means. When the LISPM people finally realized this they went to :PRINT-SELF, which I hadn't wanted to do until then because I didn't want to introduce gratuitous incompatibility. (SEND STREAM 'PRINT OBJECT) "simulates" (PRINT OBJECT STREAM). "Implements" is more accurate, actually. I absolutely do not understand and cannot imagine (so please tell me like I asked) why you don't just want to call the function PRINT?  Date: 25 July 1981 09:15-EDT From: Jon L White To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Date: Tuesday, 14 July 1981, 15:25-EDT From: Robert W. Kerns Subject: SEND In-reply-to: The message of 5 Jul 81 01:12-EDT from Jon L White Date: 5 July 1981 01:12-EDT From: Jon L White (SEND -CLASS 'PRINT) results in ILOPR. so does the sending of a variety of other msgs, including :PRINT-SELF. Admittedly, the :PRINT-SELF msg might require all those silly extra args that PRINT-OBJECT takes, but why can't the PRINT methods default them to appropriate values? At least, it shouldn't ILOPR, but die more gracefully. Why not fix LISP's LSUBR calling sequence, which is at fault here? Note that the PRINT method is an OBSOLETE name for :PRINT-SELF. Why not just call the function PRINT, which does the defaulting for you? I'm not sure what you're suggesting here -- since a PRINT msg is acceptable, then why should it be totally equivalent to the :PRINT-SELF msg? The latter can take all the extra args it wants, but the former could simulate a call to PRINT.  Date: 25 July 1981 08:28-EDT From: Jon L White Subject: Definition of SELECTQ To: CWH at MIT-MC cc: GSB at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC Date: 17 July 1981 15:53-EDT From: Carl W. Hoffman Subject: SELECTQ using = or EQ Date: 17 July 1981 12:02-EDT From: Jon L White Fixed now. Prior to this buggy state, it produced a CASEQ, which insists on either symbols or numbers, but not mixtures thereof. Whoa, what's going on here. I've been assuming until now that CASEQ and SELECTQ are just different names for the same thing. Are you saying this is no longer the case? During my virus-induced absence, I never got down to this part of my mail file, but noticed in the later parts the RWK seems to have satisfactorily answered this. He's produced a corrected SELECTQ macro, and GSB has offered the one from LSB. Any more comments?  Date: 25 July 1981 08:20-EDT From: Jon L White Subject: DEFCONST To: ALAN at MIT-MC, GSB at MIT-MC, CWH at MIT-MC cc: INFO-MACLISP at MIT-MC, BUG-LISP at MIT-MC Date: 18 July 1981 02:37-EDT From: alan,gsb,cwh at MIT-MC Subject: defconst How about putting a defconst macro somwhere? It is quite distinct from defvar, and quite usefull. (It's used all over the place on the LispMachine) I put DEFCONST into MLMAC file, but as yet there is no autoload property for it. It's just the DEFVAR facility using SETQ instead of SETQ-IF-UNBOUND.  Date: 25 July 1981 08:01-EDT From: Jon L White Subject: SI:EXTEND-LENGTH To: WGD at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 July 1981 21:15-EDT From: Richard L. Bryan Sender: BIL at MIT-MC Subject: Gobble, gobble To: BUG-LISP at MIT-MC The current EXTBAS has SI:EXTEND-LENGTH subr defined as (defun si:extend-length (x) (si:extend-length x)) or something equivalent, expecting a macro definition for si:extend-length to come in from EXTHUK. It did, but after that SI:EXTEND-LENGTH was own-symbol'ified, leading to a short inner loop on si:extend-length tail recursing to itself, but not terminating in finite time. This hasn't been fixed yet -- so I fixed it merely by removing the OWN-SYMBOL declaration in the EXTBAS file, and recompiling.  Date: Friday, 24 July 1981, 13:46-EDT From: Robert W. Kerns Subject: PUSH, or is it SETF? SHOVE maybe? To: RLB at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 22 Jul 81 22:20-EDT from Richard L. Bryan Date: 22 July 1981 22:20-EDT From: Richard L. Bryan Subject: PUSH, or is it SETF? To: BUG-LISP at MIT-MC In a bare lisp, (PUSH 'X (GET 'Y 'Z)) finds |Function..24| undefined function. It has a gentemp marker. Sorry 'bout that. MC died a horrible death while I was working on this stuff and GJC stole my LISPM with modified buffers while I was waiting for it to come up. I intruduced it while extending DEFSETF to make it easier to fix this bug: Date: 20 July 1981 21:15-EDT From: Richard L. Bryan Sender: BIL at MIT-MC Subject: Gobble, gobble To: BUG-LISP at MIT-MC The current EXTBAS has SI:EXTEND-LENGTH subr defined as (defun si:extend-length (x) (si:extend-length x)) or something equivalent, expecting a macro definition for si:extend-length to come in from EXTHUK. It did, but after that SI:EXTEND-LENGTH was own-symbol'ified, leading to a short inner loop on si:extend-length tail recursing to itself, but not terminating in finite time. (btw, this is the source of the previous bug I misreported - BIL) However, WGD pointed out that it is easier and better just to move the offending LET to inside the SI:XREF, which makes it all work. Since I had to do it all over again, thanks to DEC and GJC, I did it WGD's winning way. However, my improvement to DEFSETF still stands: Instead of just a name of a function, DEFSETF can take a list of functions. Similarly, in the slot that was always () in the argument pattern, it will actually take a function name, for arbitrary use by the invert pattern.  Date: 22 July 1981 22:20-EDT From: Richard L. Bryan Subject: PUSH, or is it SETF? To: BUG-LISP at MIT-MC In a bare lisp, (PUSH 'X (GET 'Y 'Z)) finds |Function..24| undefined function. It has a gentemp marker.  Date: 20 July 1981 21:52-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC It is not possible to use SETF on any of the class structure slots given the way SI:CLASS-SLOT-ACCESSOR macro is defined in EXTMAC (well only when running interpreted code - since then the accessor turns into a lambda which confuses SETF).  Date: 20 July 1981 21:15-EDT From: Richard L. Bryan Sender: BIL at MIT-MC Subject: Gobble, gobble To: BUG-LISP at MIT-MC The current EXTBAS has SI:EXTEND-LENGTH subr defined as (defun si:extend-length (x) (si:extend-length x)) or something equivalent, expecting a macro definition for si:extend-length to come in from EXTHUK. It did, but after that SI:EXTEND-LENGTH was own-symbol'ified, leading to a short inner loop on si:extend-length tail recursing to itself, but not terminating in finite time. (btw, this is the source of the previous bug I misreported - BIL)  Date: 20 July 1981 20:32-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-LISP at MIT-MC (si:extend-length (si:extend 1)) hangs forever. Can't the extend stuff ever all work at the same time?  Date: Monday, 20 July 1981, 16:15-EDT From: Robert W. Kerns To: GJC at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 20 Jul 81 14:06-EDT from George J. Carrette George, let me help you out. Don't scream about there being too many optimizations. The problem here is the lack of one. Don't scream about correctness... I think that's why = and EQ were being used, the reasoning being along the lines of simple translation with an exception for them nasty fixnums. Remember when you were flaming about defining a new predicate to do this kind of comparison? I could be wrong, but I think this was probably what JONL was thinking...it certainly was when I saw what he did. So anyway, I now perceive that you are (currently at least) perceiving the situation correctly. I apologize for all my flaming back at you. I admit I didn't get much sleep last night and am probably overreacting to the flaming tone and content of your notes with flaming of my own. Rather than try to show you on a point by point basis why I was mislead by your notes, let me just show you how easily you could have said what I now think you meant. What you really wanted to tell us: 1) You have a bug (unquoted symbol). Please check before installing. 2) You can optimize out the (AND (NOT ) ...) check 3) You can optimize for codesize (typically a 30% savings, for my guess of "typical" code) at mere order-of-magnitude cost in speed, and GJC believes it's worth it in MacLisp. Use EQ on clauses with single symbols, otherwise use MEMBER or EQUAL.  Date: 20 July 1981 14:06-EDT From: George J. Carrette To: RWK at MIT-MC cc: BUG-LISP at MIT-MC For your information I did try the EQ before I sent the bug note. Your problem is that you go out of your way to find out why somebody is wrong rather than finding out why they are right. Furthermore, the problem is the optimization. Lately people hacking maclisp have been spending so much time worrying about open-coding type optimizations that they forget about CORRECTNESS. They also forget about code compactness, which is incredibly important in poor little maclisp. Generating code like ((LAMBDA (|NumP..2|) (SETQ |NumP..2| (MEMQ (TYPEP X) '(FIXNUM FLONUM))) (COND ((AND (NOT |NumP..2|) (EQ X 'Y)) Z))) NIL) for (selectq x (y z)) is pretty darn stupid when (if (eq x 'y) z) is perfectly correct and a hell of a lot more compact. [Also faster damn it.] The main idea: Is to use EQ whenever possible, and to punt to EQUAL if needed. The idea to use "=" because "=" is the correct thing for comparing fixnums is (compiled) maclisp sounds nice, but doesn't pan out. If you want a SELECTQ that produces correct and compact code, and code which is faster than the present installed abortion, then try GJC;SELECT >. -gjc  Date: 20 July 1981 12:51-EDT From: Robert W. Kerns To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Foo on you, turkey, one minute you say one thing, then you complain when I catch you on it. The optimization is *NOT* the source of *ANY* problem with the code. The problem is the missing quote-mark. In your previous note you pointed out that MacLisp does not support EQ of numbers. Now you suggest that it just use it anyway, because the compiler will convert this to EQUAL. Never mind the obnoxious warning message this generates, why call EQUAL in this case when = will do it very nicely? As far as defining a new predicate, well, what we have here is EXACTLY that, open-coded. You can try to cover up your mistake by accusing me of attacking you, but it won't wash. First you say MacLisp doesn't support EQ of numbers, then you claim it does, but you obviously didn't really try it and see that it generates a warning message totally inapropriate to the purpose, so you accuse ME of not trying it. And you try to blame the entire problem on non-working optimizations, when the optimizations work just fine. If you promise not to waste more of my time flaming about this I'll fix the missing quote mark for you.  Date: 20 July 1981 11:21-EDT From: George J. Carrette To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Accusing me of punting on Lispm compatibility is really stupid Kerns. If SELECTQ expanded into a friggin EQ, then things like (SELECTQ X ((3 4) Y)) would work just fine. The compiler turns (EQ X 3) into (EQUAL X 3), knowing this beforehand, SELECTQ could simply use EQUAL when comparing with fixnums, or perhaps, gosh, perhaps even define a new predicate to support the required functionality! (Think of it, a new predicate). [Now, if you had taken two seconds to try this, instead wasting your time with silly attacks...] The problem is there is too much optimization going on. Damn code won't even run though. Boy, this code sure runs faster than before, now all I gotta do is get it to work. -gjc  Date: Monday, 20 July 1981, 09:07-EDT From: Robert W. Kerns Subject: What *is* this total horse-shit? To: GJC at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 19 Jul 81 23:17-EDT from George J. Carrette Date: 19 July 1981 23:17-EDT From: George J. Carrette Subject: What *is* this total horse-shit? To: BUG-LISP at MIT-MC (selectq x (y z)) ==> ((LAMBDA (|NumP..1|) (SETQ |NumP..1| (MEMQ (TYPEP X) '(FIXNUM FLONUM))) (COND ((AND (NOT |NumP..1|) (EQ X Y)) Z))) NIL) Worse is (selectq x ((3 y) z)) ==> ((LAMBDA (|NumP..3|) (SETQ |NumP..3| (MEMQ (TYPEP X) '(FIXNUM FLONUM))) (COND ((OR (AND |NumP..3| (= X 3)) (AND (NOT |NumP..3|) (EQ X Y))) Z))) NIL) [1] The code is broken, screwing lots of people. Please test these things. [2] Since when does maclisp support the use of EQ on FIXNUMs? SELECTQ is defined to use EQ is it not? If somebody wants a selector in maclisp to work on both atoms and numbers then they can define one to use EQUAL. -gjc [1] It sure is. Perhaps rename this one to be SELECT? Looks like a perfectly good SELECT macro to me. [2] A brief quote from the LISPM manual: A test may be any of: 1) A symbol If the key is EQ to the symbol, it matches 2) A number If the key is EQ to the nuimber, it matches. Only small numbers (fixnums) will work. 3) A list If the key is EQ to one of the elements of the list, then it matches. The elements of the list should be symbols or fixnums. 4) T or OTHERWISE The symbols T and OTHERWISE are special keywords which match anything. Either symbol may be used, it makes no differnce; T is mainly for compatibility with MacLisp's CASEQ construct. To be useful, this should be the last clause in the SELECTQ. Note two things: First, SELECTQ isn't defined to use EQ blindly, it is defined by type on a case by case basis. FLONUMS aren't even legal, JONL! Second, the comparison 'EQ' when applied to fixnums on the LISPM has the exact behaviour of the comparison '=' applied to fixnums in MAcLisp. I therefore submit that the use of '=' in MacLisp's is THE correct way to translate the LISPM construct 'SELECTQ' to MacLisp. George, consider, if you will, that you are proposing that fixnums be BANNED in MacLisp's version of SELECTQ on the grounds that MacLisp doesn't support the use of EQ on them ("Since when does maclisp support the use of EQ on FIXNUMs?"). Since this then removes the incompatibility between CASEQ and SELECTQ in MacLisp, we can just make SELECTQ turn into CASEQ and save ourselves a lot of effort. And if someone wants to run his LISPM code in MacLisp, he can save himself the effort too. (You might also note that if you depend on the LISPM manual for your MacLisp definitions of things, George, that CASEQ as described would also use EQ and forbid the use of FIXNUMS!)  Date: 19 July 1981 23:17-EDT From: George J. Carrette Subject: What *is* this total horse-shit? To: BUG-LISP at MIT-MC (selectq x (y z)) ==> ((LAMBDA (|NumP..1|) (SETQ |NumP..1| (MEMQ (TYPEP X) '(FIXNUM FLONUM))) (COND ((AND (NOT |NumP..1|) (EQ X Y)) Z))) NIL) Worse is (selectq x ((3 y) z)) ==> ((LAMBDA (|NumP..3|) (SETQ |NumP..3| (MEMQ (TYPEP X) '(FIXNUM FLONUM))) (COND ((OR (AND |NumP..3| (= X 3)) (AND (NOT |NumP..3|) (EQ X Y))) Z))) NIL) [1] The code is broken, screwing lots of people. Please test these things. [2] Since when does maclisp support the use of EQ on FIXNUMs? SELECTQ is defined to use EQ is it not? If somebody wants a selector in maclisp to work on both atoms and numbers then they can define one to use EQUAL. -gjc  GSB@MIT-ML 07/19/81 21:12:34 To: (BUG LISP) at MIT-ML (defun foo n ...) (args 'foo '(1 . 2)) (foo) does not cause the evaluator to complain.  Date: Sunday, 19 July 1981, 19:15-EDT From: Robert W. Kerns Subject: Simple example of my bug of 13 July 1981 15:27-EDT To: JGA at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 19 Jul 81 13:25-EDT from John G. Aspinall I forgot to mention, of course, that I fixed it.  Date: Sunday, 19 July 1981, 19:12-EDT From: Robert W. Kerns Subject: Simple example of my bug of 13 July 1981 15:27-EDT To: JGA at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 19 Jul 81 13:25-EDT from John G. Aspinall Date: 19 July 1981 13:25-EDT From: John G. Aspinall Subject: Simple example of my bug of 13 July 1981 15:27-EDT To: BUG-LISP at MIT-MC cc: JGA at MIT-MC ;; OK here's a simple example of the bug I reported before - ;; in JGA;T1 find the following - (include ((libmax) gprelude)) (load '((jga) t2)) (setq current-foo (make-foo)) (defun blowout (x y this-foo) (declare (flonum x y)) (setf (foo-slot-a this-foo) x) (setf (foo-slot-b this-foo) y)) ;; and JGA;T2 (which is compiled) just contains the defstruct - (include ((libmax) gprelude)) (defstruct (foo (type flonum-array)) (foo-slot-a 0.0) (foo-slot-b 0.0)) ;; now in a regular lisp (load '((jga) t1)) (blowout 2.0 3.0 current-foo) ;; will demonstrate the bug - you will find x bound to STRUCT=INFO I hope this is simple enough to allow you to track it down easily. John. The culprit here is not SETF, but rather the loading (autoloading in this case) of the file EXTSTR, which was recently broken to do a (SETQ X ...) without binding it!  Date: 19 July 1981 14:59-EDT From: George J. Carrette Subject: JGA's SETF BUG. To: JGA at MIT-MC cc: BUG-LISP at MIT-MC Of course, when you do (TRACE SETF) before trying BLOWOUT you have no problem. Heisenberg was right.  Date: 19 July 1981 13:25-EDT From: John G. Aspinall Subject: Simple example of my bug of 13 July 1981 15:27-EDT To: BUG-LISP at MIT-MC cc: JGA at MIT-MC ;; OK here's a simple example of the bug I reported before - ;; in JGA;T1 find the following - (include ((libmax) gprelude)) (load '((jga) t2)) (setq current-foo (make-foo)) (defun blowout (x y this-foo) (declare (flonum x y)) (setf (foo-slot-a this-foo) x) (setf (foo-slot-b this-foo) y)) ;; and JGA;T2 (which is compiled) just contains the defstruct - (include ((libmax) gprelude)) (defstruct (foo (type flonum-array)) (foo-slot-a 0.0) (foo-slot-b 0.0)) ;; now in a regular lisp (load '((jga) t1)) (blowout 2.0 3.0 current-foo) ;; will demonstrate the bug - you will find x bound to STRUCT=INFO I hope this is simple enough to allow you to track it down easily. John.  Date: 18 July 1981 18:02-EDT From: Robert W. Kerns Subject: SELECTQ vs CASEQ To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Wording in the manual? You mean the LISPM manual? The LISPM manual's wording for CASEQ says The CASEQ special form is provided for Maclisp coompatibility. It is exactly the same as SELECTQ. This is not perfectly compatible with MacLisp, because SELECTQ accepts OTHERWISE as well as T where CASEQ would not accept OTHERWISE, *** and because MACLISP does some error-checking that SELECTQ does not. *** Maclisp programs that use CASEQ will work correctly so long as they don't use the symbol OTHERWISE as the key. PLEASE NOTE THAT NO CHANGE TO ANY SEMANTICS IS BEING MADE! Also please note that what is being repaired here is the incompatibility between MacLISP's SELECTQ and the LISPM one. MACLISP's old SELECTQ was WRONG, because it used CASEQ, which did some 'error checking', which was WRONG in the context of SELECTQ. Implementing CASEQ in terms of SELECTQ on a machine with fixnums as part of the pointer produces something which behaves almost like CASEQ in MACLISP. The reverse is simply not true.  Date: 18 July 1981 02:37-EDT From: alan,gsb,cwh at MIT-MC Sender: ALAN at MIT-MC Subject: defconst To: BUG-LISP at MIT-MC How about putting a defconst macro somwhere? It is quite distinct from defvar, and quite usefull. (It's used all over the place on the LispMachine)  Date: 18 July 1981 0034-EDT (Saturday) From: Guy.Steele at CMU-10A To: kmp at MIT-MC, rwk at MIT-MC, alan at MIT-MC, bug-lisp at MIT-MC, cwh at MIT-MC, jonl at MIT-MC, gsb at MIT-ML Subject: Why am I typing all these names that are on BUG-LISP anyway (like myself!) -- oh yes, SELECTQ and = or EQ Message-Id: <18Jul81 003426 GS70@CMU-10A> I've always "known" that SELECTQ allows mixed-mode keys while CASEQ doesn't, and indeed that was the historical motivation for the different name. RWK is quite correct -- that distinction is as widely advertised as any other MacLISP feature invented at about the same time. You know whom you can blame for that (your friendly neighborhood Quux). --Guy  Date: 18 July 1981 00:20-EDT From: Kent M. Pitman Subject: SELECTQ using = or EQ To: RWK at MIT-MC cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, CWH at MIT-MC, JONL at MIT-MC, GSB at MIT-ML, Steele at CMU-20C Date: Friday, 17 July 1981, 21:15-EDT From: Robert W. Kerns To: CWH cc: GSB at MIT-ML, JONL, ALAN, BUG-LISP, Steele at CMU-20C Re: SELECTQ using = or EQ ... So if you've been using them interchangably, you've been laboring under a misconception. This distinction has been widely advertised. The wording in the manual is that they ae exactly identical except for the use of the keyword OTHERWISE. There is hardly a widely advertised distinction. I think there has been widely advertised confusion.... I agree with CWH that changing the semantics of existing operators is a poor way of dealing with the need for a new feature.  Date: Friday, 17 July 1981, 21:15-EDT From: Robert W. Kerns Subject: SELECTQ using = or EQ To: CWH at MIT-MC Cc: GSB at MIT-ML, JONL at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC, Steele at CMU-20C In-reply-to: The message of 17 Jul 81 17:31-EDT from Carl W. Hoffman Date: 17 July 1981 17:31-EDT From: Carl W. Hoffman Subject: SELECTQ using = or EQ To: GSB at MIT-ML cc: JONL at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC, Steele at CMU-20C Date: 17 July 1981 16:02-EDT From: Glenn S. Burke The semantics of SELECTQ are leaning towards allowing "mixed types", and those of CASEQ requiring everything to be of the same type. "knowning" that everything is of the same type can help the compilation of such a construct where that matters (pdp10 maclisp, for instance). Elsewhere such a constraint doesn't hurt; you just use EQ all the time anyway. Guy, are you there? Words of wisdom? Sure, I understand the need for mixed types. I use a construct called CASEQ-EQUAL when I need EQUAL comparison for a CASEQ. What I object to is changing the definition of a construct as a result of a "bug fix". It is a completely different thing to propose a change to the semantics of SELECTQ or CASEQ, discuss it, and then implement the change. It's too bad, actually, that we're using the name CASEQ to mean CASE-QUOTE rather than CASE-EQ. Most people assume it stands for the latter. Carl, I think you must be slightly confused about what is happening here. SELECTQ is what is being changed, not CASEQ, which has always been the way it is. And it is being changed to be more general. The BUG being fixed was that SELECTQ was not compatible with the LISPM one, i.e. it didn't allow you to compare fixnums and symbols in the same SELECTQ. CASEQ has always barfed when you give it a fixnum when it expects a symbol, or vice versa. This Maclisp-ism is the reason it wasn't just called SELECTQ ... it ISN'T SELECTQ, and never has been. So if you've been using them interchangably, you've been laboring under a misconception. This distinction has been widely advertised.  Date: 17 July 1981 17:31-EDT From: Carl W. Hoffman Subject: SELECTQ using = or EQ To: GSB at MIT-ML cc: JONL at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC, Steele at CMU-20C Date: 17 July 1981 16:02-EDT From: Glenn S. Burke The semantics of SELECTQ are leaning towards allowing "mixed types", and those of CASEQ requiring everything to be of the same type. "knowning" that everything is of the same type can help the compilation of such a construct where that matters (pdp10 maclisp, for instance). Elsewhere such a constraint doesn't hurt; you just use EQ all the time anyway. Guy, are you there? Words of wisdom? Sure, I understand the need for mixed types. I use a construct called CASEQ-EQUAL when I need EQUAL comparison for a CASEQ. What I object to is changing the definition of a construct as a result of a "bug fix". It is a completely different thing to propose a change to the semantics of SELECTQ or CASEQ, discuss it, and then implement the change. It's too bad, actually, that we're using the name CASEQ to mean CASE-QUOTE rather than CASE-EQ. Most people assume it stands for the latter.  Date: 17 July 1981 16:02-EDT From: Glenn S. Burke Subject: SELECTQ using = or EQ To: CWH at MIT-MC cc: Steele at CMU-20C, JONL at MIT-MC, ALAN at MIT-MC, BUG-LISP at MIT-MC Date: 17 July 1981 15:53-EDT From: Carl W. Hoffman Date: 17 July 1981 12:02-EDT From: Jon L White Fixed now. Prior to this buggy state, it produced a CASEQ, which insists on either symbols or numbers, but not mixtures thereof. Whoa, what's going on here. I've been assuming until now that CASEQ and SELECTQ are just different names for the same thing. Are you saying this is no longer the case? The semantics of SELECTQ are leaning towards allowing "mixed types", and those of CASEQ requiring everything to be of the same type. "knowning" that everything is of the same type can help the compilation of such a construct where that matters (pdp10 maclisp, for instance). Elsewhere such a constraint doesn't hurt; you just use EQ all the time anyway. Guy, are you there? Words of wisdom?  Date: 17 July 1981 15:53-EDT From: Carl W. Hoffman Subject: SELECTQ using = or EQ, and ARRAYP To: JONL at MIT-MC cc: ALAN at MIT-MC, GSB at MIT-MC, BUG-LISP at MIT-MC Date: 17 July 1981 12:02-EDT From: Jon L White Fixed now. Prior to this buggy state, it produced a CASEQ, which insists on either symbols or numbers, but not mixtures thereof. Whoa, what's going on here. I've been assuming until now that CASEQ and SELECTQ are just different names for the same thing. Are you saying this is no longer the case?  Date: 17 July 1981 12:02-EDT From: Jon L White Subject: SELECTQ using = or EQ, and ARRAYP To: ALAN at MIT-MC, GSB at MIT-MC cc: BUG-LISP at MIT-MC Date: 16 July 1981 03:26-EDT From: alan,gsb at MIT-MC To: BUG-LISP at MIT-MC 1) The selectq macro in UMLMAC is busted. Try something like: (selectq foo ((1 2 a) t) (t nil)) And watch it compare symbols with =. Fixed now. Prior to this buggy state, it produced a CASEQ, which insists on either symbols or numbers, but not mixtures thereof. 2) How about putting an ARRAYP function or macro somwhere. It seems that ALL the other lisps in the world have this function (even Multics!). Ok, there is a little subr version of ARRAYP in the MLMAC file now, but it will take some time to decide how to "connect" it up -- putting an initial autoload property would seem fine, next time that's possible!  GSB@MIT-ML 07/16/81 23:30:23 Re: losing outfiles To: (BUG LISP) at MIT-ML CC: WJL at MIT-ML WJL@MIT-ML 07/16/81 12:18:52 Re: printing hunks with (define-user-hunk-type 'x 'y 'z) and z defined with (z a b (optional c) ...) and :print-self done by (?format c '|....| ..) the printing only goes to outfiles when it exists even if ^w is nil. The situation is printing node in wjl1;tms > with dribble (of liblsp;dribbl) turned on. Any ideas? -Bill Long ---- I believe this is the same old problem that the user-hunk guy is being called on the value of OUTFILES when it should be given the filespec NIL. If i remember correctly, the usage of that crock whereby there is a bit in the left half of AR1 or AR2A (signifying output to the tty) is restricted enough that it can be kludged to re-construct the original filespec so that this will not happen.  Date: 16 July 1981 03:26-EDT From: alan,gsb at MIT-MC Sender: ALAN at MIT-MC To: BUG-LISP at MIT-MC 1) The selectq macro in UMLMAC is busted. Try something like: (selectq foo ((1 2 a) t) (t nil)) And watch it compare symbols with =. 2) How about putting an ARRAYP function or macro somwhere. It seems that ALL the other lisps in the world have this function (even Multics!).  Date: 16 July 1981 02:12-EDT From: George J. Carrette Subject: Fexprs. To: RLB at MIT-MC cc: BUG-LISP at MIT-MC Would you believe that COMPLR optimizes (declare (*fexpr foobar)) (defun foo (l) (eval (list 'foobar l))) to produce the code: (JSP T %PDLNC) (JCALL 17 'FOOBAR) Now thats what I call a going out of your way to satisfy some strange tastes. -gjc p.s. I found this code in some very old macsyma source.  Date: 14 July 1981 15:33-EDT From: John G. Aspinall Subject: follow-up to my previous report of 13 July 1981 15:27-EDT To: BUG-LISP at MIT-MC cc: JGA at MIT-MC An even more interesting test is when I replace my lambda variable x with z in the function houst:move the bug disappears! Clearly something is side-effecting x beyond its intended scope. John.  Date: Tuesday, 14 July 1981, 15:25-EDT From: Robert W. Kerns Subject: SEND To: JONL at MIT-MC Cc: BUG-LISP at MIT-MC In-reply-to: The message of 5 Jul 81 01:12-EDT from Jon L White Date: 5 July 1981 01:12-EDT From: Jon L White Subject: SEND To: BUG-LISP at MIT-MC (SEND -CLASS 'PRINT) results in ILOPR. so does the sending of a variety of other msgs, including :PRINT-SELF. Admittedly, the :PRINT-SELF msg might require all those silly extra args that PRINT-OBJECT takes, but why can't the PRINT methods default them to appropriate values? At least, it shouldn't ILOPR, but die more gracefully. Why not fix LISP's LSUBR calling sequence, which is at fault here? Note that the PRINT method is an OBSOLETE name for :PRINT-SELF. Why not just call the function PRINT, which does the defaulting for you?  Date: 14 July 1981 12:24-EDT From: George J. Carrette Subject: Reader/TTY-PRESCAN: BUG To: BUG-LISP at MIT-MC Get a fresh lisp. Type a "'" and then type ")" and then "^L", the "'" isn't part of the redisplay. -gjc  Date: 13 July 1981 15:27-EDT From: John G. Aspinall Subject: SETF ; I think To: BUG-LISP at MIT-MC cc: JGA at MIT-MC I'm sorry that I don't have a simpler example of this. (load '((jga) ht)) this will load other files - notably JGA;PLOT, JGA;HOUSPL and JGA;GDEFS. If none of those files are compiled, it runs fine - ignore the wierd characters output to the tty - those will be understood by the plotter this will eventually speak to. However if JGA;PLOT and JGA;GDEFS are compiled, the same code bombs out. Some poking around reveals the problem happens in the function houst:move but in a pretty strange manner. (defun houst:move (x y) (declare (fixnum x y) (special current-tty-state current-viewport)) (let ((dx (- x (view-pen-x))) (dy (- y (view-pen-y)))) (declare (fixnum dx dy)) (let ((adx (abs dx)) (ady (abs dy)) (sign-x (if (minusp dx) 40 100)) (sign-y (if (minusp dy) 40 100))) (declare (fixnum adx ady sign-x sign-y)) (set-pen-position #\HOUST-PENUP) (mapc #'(lambda (vector) (set-vector-repeat (car vector)) (+tyo (+ (cadr vector) sign-x) graphic-output) (+tyo (+ (caddr vector) sign-y) graphic-output)) (what-to-move adx ady (houst-x-step-size) (houst-y-step-size) (houst-max-multiplier))))) (setf (view-pen-x) x) (setf (view-pen-y) y) T) When evaluating the setf at the end - (setf (view-pen-x) x) it finds x is bound to the symbol STRUCT=INFO. This symbol appears nowhere in any of my code, however it does appear in the EXTSTR package. The setf and the structure reference (view-pen-x) expand correctly into (store (arraycall fixnum ...)...) but x is now bound to this clearly out-of-place symbol. Furthermore, this happened sometime during the evaluation of this function, because x is used at the beginning of the let form that starts the function, and this does not give an error. This looks as if it might be a missing comma, or something similar, but I have exhausted the obvious avenues of approach. John.  Date: 10 July 1981 19:46-EDT From: Jon L White Subject: SETF expansions on LDB To: DCP at MIT-MC cc: RWK at MIT-MC, BUG-LISP at MIT-MC Date: 9 July 1981 01:01-EDT From: David C. Plummer (macroexpand-1 '(setf (ldb 1404 (arraycall fixnum foo-array 0)) (+ 3 4))) (PROGN ((LAMBDA (G0026 G0027) (STORE (ARRAYCALL FIXNUM G0026 0) G0027)) FOO-ARRAY (DPB (+ 3 4) 1404 (ARRAYCALL FIXNUM FOO-ARRAY 0))) (+ 3 4)) is correct, but (macroexpand-1 '(setf (ldb 1404 (arraycall fixnum foo-array 0)) (+ 3 (length '(4))))) ((LAMBDA (G0030 G0031) (SETQ G0030 (DPB G0031 1404 G0030)) G0031) (ARRAYCALL FIXNUM FOO-ARRAY 0) (+ 3 (LENGTH (QUOTE (4))))) . . . RWK will have to look at this -- this is a BUG in the expansion of forms like (SETF (LDB ...) ...). I suspect that the SETF info for LDB and LOAD-BYTE will have to be handled like that for PROGN and ARRAYCALL, namely, DEFSETF can't be used.  Date: 10 July 1981 17:20-EDT From: Jon L White To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 July 1981 17:27-EDT From: George J. Carrette Why the hell is *PURE set to T in MACLISP^K? This sure messes up any programs that want to run! Looks wrong -- it'll be set to () in the next dumping, which could be any day now.  Date: 9 July 1981 01:01-EDT From: David C. Plummer To: BUG-LISP at MIT-MC (macroexpand-1 '(setf (ldb 1404 (arraycall fixnum foo-array 0)) (+ 3 4))) (PROGN ((LAMBDA (G0026 G0027) (STORE (ARRAYCALL FIXNUM G0026 0) G0027)) FOO-ARRAY (DPB (+ 3 4) 1404 (ARRAYCALL FIXNUM FOO-ARRAY 0))) (+ 3 4)) is correct, but (macroexpand-1 '(setf (ldb 1404 (arraycall fixnum foo-array 0)) (+ 3 (length '(4))))) ((LAMBDA (G0030 G0031) (SETQ G0030 (DPB G0031 1404 G0030)) G0031) (ARRAYCALL FIXNUM FOO-ARRAY 0) (+ 3 (LENGTH (QUOTE (4))))) is confusing to say the least. Does it not bash the new value back into the array because SETF cannot determine if it is a constant thing? I thought (setf (foo-reference) ) was supposed to allow you to do (foo-reference) and get back what was at the time. I know that (foo-reference) and might be different if I computed again, but does that mean I must lose my first computation by trying to use SETF, which in turn tries to out-smart me?  Date: 8 July 1981 17:27-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Why the hell is *PURE set to T in MACLISP^K? This sure messes up any programs that want to run!  Date: 6 July 1981 16:05-EDT From: George J. Carrette To: BUG-LISP at MIT-MC Is it possible to hack the GCST in such a way that you can get "TYPE NIL" hunks? That is, something of TYPEP HUNKN, but which the garbage-collector doesn't bother to mark recursively?  Date: 6 July 1981 13:32-EDT From: George J. Carrette Subject: Trampolines for SUBRCALL. To: KMP at MIT-MC cc: JAR at MIT-MC, BUG-LISP at MIT-MC Here is a way to get garbage-collectable SUBR trampolines in maclisp. A demo should suffice: (defun make-jcall (number-of-arguments name-to-call) (boole 7 13._27. (lsh number-of-arguments 23.) (maknum name-to-call))) (defun foo () '(hack hack)) (putprop 'bar (make-jcall 0 'foo) 'subr) (bar) => (hack hack) -gjc  Date: 5 July 1981 20:20-EDT From: George J. Carrette Subject: The LISP directory is FULL. To: JONL at MIT-MC cc: BUG-LISP at MIT-MC I think we have only two choices here, [1] PUNT the losing ITS filesystem. [2] Add a PPN-L property, like the PPN property, but one which gives a LIST of PPN's. Build searching over that list into the function LOAD. -gjc  Date: 5 July 1981 01:12-EDT From: Jon L White Subject: SEND To: BUG-LISP at MIT-MC (SEND -CLASS 'PRINT) results in ILOPR. so does the sending of a variety of other msgs, including :PRINT-SELF. Admittedly, the :PRINT-SELF msg might require all those silly extra args that PRINT-OBJECT takes, but why can't the PRINT methods default them to appropriate values? At least, it shouldn't ILOPR, but die more gracefully.  Date: 4 July 1981 18:30-EDT From: Jon L White Subject: EXPLODE on random EXTEND objects To: BUG-LISP at MIT-MC The EXPLODE method seems to be always exploding the internal stream instead of the object passed to EXPLODE function.  Date: 3 July 1981 14:45-EDT From: Jon L White Subject: SXHASH and/or ABS peculiarities To: rivest at MIT-ML cc: BUG-LISP at MIT-MC, Guy.Steele at CMU-10A In your note of RIVEST@MIT-ML 06/23/81 00:15:05 you have the function (defun count-hash-index (expr) (remainder (abs (sxhash expr)) 5000.)) If the ABS is open-compiled here, you will lose; however, such a function would not normally cause ABS to be open-compiled. The generic-arithemtic works ok on this example. However, note the following emmendation of 'count-hash-index', which will be optimally fast (no closed-codings) by checking explicitly for the overflow case: (defun count-hash-index (expr) (let ((n (sxhash expr))) (declare (fixnum n)) (if (= n -1_35.) #.(remainder (abs -1_35.) 5000.) (\ (abs n) 5000.))))  Date: 3 July 1981 07:31-EDT From: Jeffrey P. Golden To: JONL at MIT-MC cc: BUG-LISP at MIT-MC As we have discussed, the &AUX in JONL;AXR 1 is mishandled. It (at least the compiler) sets $LINSOLVE_PARAMS to NIL before binding it. Converting the &AUX into the obvious LET wins.  Date: 28 June 1981 22:53-EDT From: George J. Carrette Subject: SOURCE-TRANS To: BUG-LISP at MIT-MC It would be very usefull in macsyma to have a special form available in the compiler (with-source-trans-off ....) or, use (compiler-let ((source-transp nil)) ...). In some cases we need to turn off the use of source-trans properties. Come to think of it, FOO, just put in COMPILER-LET, and that is enough to do the hacks we need. -gjc  Date: 28 June 1981 20:34-EDT From: George J. Carrette To: BUG-LISP at MIT-MC If I (trace |FOO MACRO| BAR-SOURCE-TRANS) during compilation, nothing prints out!!!! How can I get print out during compilation?  Date: 24 Jun 1981 1614-EDT From: MORGENSTERN at RUTGERS Subject: tops-20 To: bug-lisp at MIT-MC What is needed to get rubout processing (and cursorpos if possible) on the Tops-20 version here at Rutgers? Matt -------  Date: 23 June 1981 1050-EDT (Tuesday) From: Guy.Steele at CMU-10A To: RIVEST at MIT-ML Subject: (SXHASH '(1 . 0)) CC: bug-lisp at MIT-MC In-Reply-To: RIVEST@MIT-ML's message of 23 Jun 81 00:15-EST Message-Id: <23Jun81 105024 GS70@CMU-10A> Ron, There seems to be some confusion here. First of all, the PDP-10 is a two's-complement machine, so the word octal 400000000000 isn't -0, but -2^35. It's just as good as any other integer. SXHASH returns integers in the range [-2^35,2^35-1] (that is, those which fit into single PDP-10 words). Now, indeed ABS of this number will overflow and fail, *if* ABS somehow believes that it is not allowed to use bignums; this should only happen in *compiled* code where the compiler believes that it can open-code ABS. This could happen because of a compiler bug, or because you declared (FIXSW T). In the interpreter (REMAINDER (ABS (SXHASH '(1 . 0))) 5000.) works fine. A bignum gets used for the result of ABS. I suggest that you pursue this further to discover the problem. However, another way to express the computation is (ABS (REMAINDER (SXHASH '(1 . 0)) 5000.)), which does the same thing because REMAINDER is symmetric about the origin in its first argument. --Guy  RIVEST@MIT-ML 06/23/81 00:15:05 To: (BUG LISP) at MIT-ML I think I have just been burnt by the apparent fact that SXHASH returns a -0 for the input '(1 . 0) I was trying to hash S-expressions using the hash index computation (defun count-hash-index (expr) (remainder (abs (sxhash expr)) 5000.)) This doesn't work since ABS will not change the sign of -0 when compiled and remainder screws things up even further... Shouldn't SXHASH always return a proper number, instead of this wierd thing? Ron Rivest  Date: 22 June 1981 22:48-EDT From: Kent M. Pitman Sender: ___033 at MIT-MC To: FONER at MIT-MC cc: BUG-LISP at MIT-MC The bug you describe with BADPI; during ALLOC? is well-known and indeed aggravating. It will be fixed some day. If you're on a slow terminal, you can win by doing ^_M to turn off more processing before you type the "?" to ALLOC? ... it will then not pause at the bottom of the screen for more and hence will not die so awfully ... Typing ^_M later in that job (AFTER ALLOC IS DONE RUNNING) will re-enable more interrupts. Sorry about the lossage. No one's had time to look at it in the many months since it was first reported.  Date: 22 June 1981 21:34-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-MACLISP at MIT-MC PROGV doesn't give an error message when an attempt is made to bind T or NIL, it just ignores the attempted bindings.  Date: 22 June 1981 1139-EDT (Monday) From: Guy.Steele at CMU-10A To: David C. Plummer Subject: Cursorpos and ^P CC: bug-lisp at MIT-MC In-Reply-To: David C. Plummer's message of 21 Jun 81 19:11-EST Message-Id: <22Jun81 113951 GS70@CMU-10A> It wasn't really intended that you output your own ^P codes for two reasons: (1) If a new ^P code is invented, CURSORPOS should be upgraded. (2) Outputting your own ^P codes on an ASCII TTY object will probably screw up the CHARPOS and/or LINENUM counts, which is why you want point (1) to happen. ASCII mode output is intended to be relatively abstract and portable. If you go outputting your own ^P codes, it isn't going to work on a TOPS-20 -- maybe not even on a LISP Machine. So you're provided with the interface functions TYO and CURSOROS, which can be implemented on many systems reasonably. If you are willing to be non-portable, then use IMAGE or FIXNUM mode. --Guy  Date: 21 June 1981 21:10-EDT From: Leonard N. Foner Subject: Strange behavior duing initialization dialog To: BUG-LISP at MIT-AI cc: FONER at MIT-AI I tried invoking LISP and saying ? to Alloc? just now, and got the following error message: BADPI;(IOCH1;) 126045>>.IOT 1,1 1/ 40 : I get the same error message whenever the explanatory text reaches the bottom of the screen. It does not matter where in the text LISP is (i.e., if I started LISP at the top of a page or in the middle, it still screws up when it hits the bottom of the page). I am currently running with TCTYP H19, if that's important. If the explanatory stuff is not used (in other words, if I just say N to Alloc? and use the default), this problem does not occur. If someone will be kind enough to tell me how to dump the entire LISP core image to CRASH; I'll do that so people can analyze what happened (assuming that the above error message is not sufficient).  Date: 21 June 1981 20:23-EDT From: David C. Plummer To: BUG-LISP at MIT-MC The most recent documentation on QUIT found in LISP;LISP NEWS THURSDAY MARCH 03,1977 FQ+6D.12H.27M.23S. LISP 1258 - GLS - VALUES FOR THE ARGUMENT: A FIXNUM ARGUMENT IS MACHINE-DEPENDENT. ON ITS, IT IS FED AS THE EFFECTIVE ADDRESS FOR .BREAK 16,. This is does set the effective address. As far as I can tell, it always does a .break 16,160000 I tried (quit 0) which should simply do a breakpoint without self kill. NOPE, it killed.  Date: 21 June 1981 20:11-EDT From: David C. Plummer To: BUG-LISP at MIT-MC LISP;LISP NEWS states (Spetember 14, 1976) (CURSORPOS 'P) (OUTPUT A ^P) HAS BEEN FLUSHED. (TYO 20) NOW DOES THE RIGHT THING IN NEWIO. Well, if (TYO 20) is supposed to output a ^P to the terminal it indeed does. So HOW????? do you output a ^P to the system so that you can put your own ^P sequences after it? The ONLY way I have found to do this is opening the tty with (out fixnum). (cursorpos 'p) does the same thing as (tyo 20). What is going on? and more inportantly, what SHOULD be going on?  Date: 21 June 1981 10:26-EDT From: Robert W. Kerns Subject: Crocks in the evaluator To: BUG-LISP at MIT-MC cc: ALAN at MIT-MC I was just scrod by this a few minutes ago, myself. In my case, I was funcalling something that was supposed to be a symbol, but due to a typo was actually NCONS of that symbol. I would much rather have been told that FUNCALL got a random LIST than that somebody called the function with the wrong number of arguments!  Date: 21 June 1981 06:49-EDT From: Alan Bawden Subject: CLI & crocks in evaluator To: BUG-LISP at MIT-MC, CSTACY at MIT-AI Your problem is that the cli-message handler is supposed to be a function of ONE argument: (defun cli-handler (ignore) ignore ;will always be nil I believe (valret)) will do what you want. (valret of no arguments makes lisp kill itself, not really a good way to determine if you know what's going on.) (setq cli-message '(cli-handler)) works because of the following strange property: (funcall '(progn (print 'foo) 'cons) 1 2) FOO (1 . 2) A list is evaluated before lisp decides that it isn't a reasonable function, and if it returns a reasonable function, then that is used instead. Can't we flush this losing property? I cannot imagine a reasonable defense for it not to be commented out of the evaluator. No one who should be taken seriously writes code that depends on this, and if there really is old code using it, then it must be time to rewrite that as well. If anything at all is a crock, then this "feature" is one too. Surely we all can agree on this?  Date: 21 June 1981 05:59-EDT From: Christopher C. Stacy Subject: CLI To: BUG-LISP at MIT-AI On AI in MACLISP version 2100 with IOTA and MLMAC: If I signal a CLI to a LISP job which has the following defined and has run ENABLE-CLI-DEVICE, I get ;((CLI-HANDLER NIL) NIL) TOO MANY ARGS (defun enable-cli-device () (setq cli-message #'cli-handler) (sstatus cli T)) (defun cli-handler () (valret)) If I change ENABLE-CLI-HANDLER to (defun enable-cli-device () (setq cli-message '(cli-handler)) (sstatus cli T)) It seems to work. Chris  Date: 21 June 1981 00:33-EDT From: George J. Carrette Subject: CASEQ To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Well, you know ALAN, it would be a lot easier to get helpfull error messages, and even messages that weren't in ALL UPPER CASE, if CASEQ were an autoloading FSUBR written in LISP, instead of an assembled-into-the-system piece of pdp-10 machine language.  Date: 21 June 1981 00:13-EDT From: Alan Bawden Subject: CASEQ error message To: BUG-LISP at MIT-MC (caseq 3 (x t)) ;X DOES NOT MATCH MATCHING EXPRESSION TYPE ;BKPT WRNG-TYPE-ARG I thought we had fixed that error message to say something about CASEQ. Its kind of helpfull when debugging to be able to know just WHERE an error message is coming from. How about: ;X DOES NOT MATCH MATCHING EXPRESSION TYPE -- CASEQ  Date: 20 June 1981 19:49-EDT From: George J. Carrette To: BUG-LISP at MIT-MC The lack of error checking of the syntax of MACRO forms, really sucks the big hairy one. Example: (LET . 0.8) This gives you a nice MPV; 13041>>HRLZ 2,(3) We gotta have a version of the destructuring frobulator that does compatibility checking on the pattern and form. -gjc  Date: 20 June 1981 15:42-EDT From: John Batali To: BUG-LISP at MIT-AI Is there any possibility of bringing the latest version of MacLISP >and< COMPLR from AI to SPEECH and/or EE? Soon?