Date: Fri, 28 Sep 1984 15:45 EDT Message-ID: From: EB%MIT-OZ@MIT-MC.ARPA To: Bug-Complr%MIT-OZ@MIT-MC.ARPA Subject: ferror In the COMPLR on Oz (Complr 1128, in Lisp 2140), FERROR has an AUTOLOAD property of ((LISP) MLSUB FASL). That should be CERROR, not MLSUB.  Date: 4 February 1984 11:53 EST From: Devon S. McCullough Subject: Further adventures with DO To: BUG-COMPLR @ MIT-MC (do (this that other) (endtest etc) etc etc) works fine in the interpreter and the compiler. The only time it gets a MPV is if you run such a do loop inside a macro expansion. I took a look at the file COMLAP;PHAS1 > and noticed that it explicitly allows individual atoms as a var-init-repeat (in a function named P1DO) so I'm totally mystified.  Date: Tue, 24 Jan 1984 21:49 EST Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: "Devon S. McCullough" Cc: ALAN@MIT-MC, BUG-COMPLR@MIT-MC Subject: yech In-reply-to: Msg of 24 Jan 1984 20:40-EST from Devon S. McCullough Date: Tuesday, 24 January 1984 20:40-EST From: Devon S. McCullough (defmacro ask-cond (subject . choices) (let ((questions (mapcar #'car choices)) (actions (do ((n 1 (1+ n)) action actions) ((null choices) actions) (setq action (cdar choices)) (setq choices (cdr choices)) (push (cons n action) actions)))) `(caseq (ask-cond-really ,subject ',questions) ,@actions))) The code works perfectly in the interpreter. I tried it again just to make sure... By some sad coincidence DO loops of this form seem to work interpreted in Maclisp, but it isn't because they should. The index variable specifiers "action" and "actions" should be parenthesized.  Date: 24 January 1984 20:40 EST From: Devon S. McCullough Subject: The comment is not mine To: ALAN @ MIT-MC cc: BUG-COMPLR @ MIT-MC In-reply-to: Msg of 24 Jan 1984 18:10 EST from Alan Bawden Date: 24 January 1984 18:10 EST From: Alan Bawden Subject: The comment is not mine To: DEVON @ MIT-MC cc: BUG-COMPLR @ MIT-MC In-reply-to: Msg of 01/24/84 08:58:06 from DEVON at MIT-ML Date: 01/24/84 08:58:06 From: DEVON at MIT-ML I get MPV; 11607>>HRRZ 1,(1) 1/ 777000 777000/ ?? when I try :COMPLR USERS1;DEVON NUTRI on ML.. Because the DO in the following macro is mal-formed: (defmacro ask-cond (subject . choices) (let ((questions (mapcar #'car choices)) (actions (do ((n 1 (1+ n)) ;RMS's pine goise: }I{ action actions) ((null choices) actions) (setq action (cdar choices)) (setq choices (cdr choices)) (push (cons n action) actions)))) `(caseq (ask-cond-really ,subject ',questions) ,@actions))) If you had tried running this code interpreted you would have found the problem yourself. The code works perfectly in the interpreter. I tried it again just to make sure. The cryptic comment contains some actual line noise generated when RMS picked up the phone, which I preserved for posterity.  Date: 24 January 1984 18:10 EST From: Alan Bawden Subject: The comment is not mine To: DEVON @ MIT-MC cc: BUG-COMPLR @ MIT-MC In-reply-to: Msg of 01/24/84 08:58:06 from DEVON at MIT-ML Date: 01/24/84 08:58:06 From: DEVON at MIT-ML I get MPV; 11607>>HRRZ 1,(1) 1/ 777000 777000/ ?? when I try :COMPLR USERS1;DEVON NUTRI on ML.. Because the DO in the following macro is mal-formed: (defmacro ask-cond (subject . choices) (let ((questions (mapcar #'car choices)) (actions (do ((n 1 (1+ n)) ;RMS's pine goise: }I{ action actions) ((null choices) actions) (setq action (cdar choices)) (setq choices (cdr choices)) (push (cons n action) actions)))) `(caseq (ask-cond-really ,subject ',questions) ,@actions))) If you had tried running this code interpreted you would have found the problem yourself.  DEVON@MIT-ML 01/24/84 08:58:06 To: (BUG COMPLR) at MIT-ML I get MPV; 11607>>HRRZ 1,(1) 1/ 777000 777000/ ?? when I try :COMPLR USERS1;DEVON NUTRI on ML..  Date: Mon, 2 May 1983 00:36 EDT From: EB@MIT-OZ To: bug-complr@MIT-MC CC: Bug-Lisp@MIT-MC @COMPLR on OZ gets its JFNs in restricted mode. The EXEC can't find them, and SYSDPY says they are restricted. This is a screw, because there is no way to close or see the _UNFA_ files if random errors happen in the middle of a compilation. I complained long ago about the fact that Twenex Maclisp treats files this way, and so did many other people, but I don't know if the problem was ever fixed. Is Twenex Maclisp still broken, or do we just have an old COMPLR on OZ?  Date: 9 April 1983 02:23 EST From: Alan Bawden Subject: Gratuitous optimization To: BUG-COMPLR @ MIT-MC I note that < has an optimizer that causes (< 1 x 8) to compile as one might expect, while in the interpreter this is an error...  Date: Thu, 7 Apr 1983 18:59 EST From: Alan Bawden To: bug-complr@MIT-MC Subject: So where IS ferror? For a good time try compiling: (eval-when (eval compile) ;This eval-when is necessary to get the bug. (defmacro foo (x) (ferror nil "Bad: ~S" x))) (defun test (x) (foo x) x) It seems that in COMPLR (at least on OZ) FERROR has a bogus autoload property of ((LISP) LMSUB FASL).  Date: 30 March 1983 23:21 EST From: Alan Bawden Subject: ALAN's trouble To: BUG-COMPLR @ MIT-MC In-reply-to: Msg of 30 Mar 1983 20:57 EST from Kent M. Pitman Date: 30 March 1983 20:57 EST From: Kent M. Pitman This was traced to be caused by his not specifying ((PS ALAN/.MACLISP) BINDA FASL) If FASL is not specified, the autoload handler should do EXACTLY what LOAD would do. I believe that means to check for both .LSP and .FASL files (I think in the other order). Slightly wrong. If you look carefully at my bug report you will see that the autoload handler is working just fine. The problem is caused by complr "manually" autoloading special forms it must compile. (If it was the autoload handler, I could just replace it.) It is true that my explicitly saying "FASL" will cause complr not to barf. Ammend KMP's message to say that COMPLR (rather than +internal-autoload) should check for both .LSP and .FASL files.  Date: 30 March 1983 20:57 EST From: Kent M. Pitman Subject: ALAN's trouble To: BUG-COMPLR @ MIT-MC cc: ALAN @ MIT-OZ This was traced to be caused by his not specifying ((PS ALAN/.MACLISP) BINDA FASL) If FASL is not specified, the autoload handler should do EXACTLY what LOAD would do. I believe that means to check for both .LSP and .FASL files (I think in the other order).  Date: Wed, 30 Mar 1983 19:58 EST From: Alan Bawden To: bug-complr@MIT-MC Subject:autoload properties @complr foo(t) { I really wish I could type "foo (t)" here... } LISP COMPILER 1127 [in LISP 2129] Loading fix-up file |PS:CLFIX.1127.2| Compilation begun on ((PS |ALAN.CM|) FOO LSP /7) ;Loading CERROR 47 ; Loading FORMAT ([ML]DSK:FORMAT;FORMAT 827) ;((PS |ALAN.MACLISP|) BINDA), autoload file for BIND-ARGUMENTS, is missing ;:WRONG-TYPE-ARG -- Unknown or un-proceedable condition { !? } (COMMENT **** ((TOPFN TEST) (87. = BEGINNING FILEPOS)) Lisp Error during file compilation in function TEST) ;BKPT LISP-ERROR (plist'bind-arguments) (AUTOLOAD ((PS |ALAN.MACLISP|) BINDA)) (bind-arguments) ;(BIND-ARGUMENTS) -- wrong number of args in macro form (plist'bind-arguments) (MACRO |BIND-ARGUMENTS MACRO| AUTOLOAD ((PS |ALAN.MACLISP|) BINDA)) Here is the entire file: (declare (defprop bind-arguments ((ps alan/.maclisp) binda) autoload)) (defun test () (bind-arguments)) This one is going to be a real pain in the ass to subvert.  Date: 20 March 1983 09:19 EST From: George J. Carrette Subject: odds and ends after a night of hacking To: ALAN @ MIT-OZ cc: BUG-COMPLR @ MIT-MC In-reply-to: Msg of Sun 20 Mar 1983 09:09 EST from Alan Bawden There is also an "optimization" for (EVAL '(FOO)) => (FOO). (SET (PROGN 'FOO) X) will not "optimize."  Date: Sun, 20 Mar 1983 09:09 EST From: Alan Bawden Subject: odds and ends after a night of hacking To: BUG-COMPLR@MIT-MC I discovered the hard way that there is a function named OUTPUT on the user's obarray in complr. Sure does break things to redefine it by accident. I wonder what it is for? (It isn't mentioned in any documentation that I can find...) Also this: (defun test (x) (set 'test x)) Generates this: (COMMENT **** TEST Undeclared - taken as SPECIAL in function TEST) Now if I had meant SETQ, I would have said SETQ. Looks like a mis-guided optimization to me.  Date: Wed 16 Mar 83 22:21:25-PST From: MacLisp Hackers Subject: [sjk@srijoyce: complr bug?] To: Bug-Complr@MIT-MC.ARPA Date: Wed 16 Mar 83 16:05:09-PST From: Mabry Tyson Subject: Maclisp compiler error I get a complaint that says to Call JONL on the file COMPLR.BUG. The problem seems to be in the first LOOP construct. When I changed it to a MAPCAN it worked ok. But I thought you might see if it barfs on a compiler at MIT. If so, pass it on with a note saying how I got by it. Thanks, Mabry ------- @c:COMPLR.EXE.938 LISP COMPILER 938 [in LISP 2137] _complr.bug(t) Compilation begun on ((PS MACLISP) COMPLR BUG /1) |NODE-CONS* MACRO| Compiled and assembled |NODE-LIST* MACRO| Compiled and assembled |MAKE-NODE* MACRO| Compiled and assembled |MAKE-LIST-NODE* MACRO| Compiled and assembled ;Loading LOOP 725 (COMMENT **ERROR** (G0071) Lost datum - ILOCMODE in function MAKE-NODE-FROM-TER M1) ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% ;BKPT BARF The losing file is in MC:SJK;COMPLR BUG if someone wants to take a quick look at it. Thanx. -------  Date: 24 February 1983 10:36 EST From: Kent M. Pitman To: GUMBY @ MIT-MC cc: BUG-COMPLR @ MIT-MC INFO-LISP is not a list to send questions to. Please use BUG-LISP. INFO-LISP is a one-way channel from the implementors to a large user community. In any case, this isn't a matter for BUG-LISP to decide. It's up to the implementors of each system to decide what the setting is, since that's an attribute that's an attribute that's external to Lisp. In point of fact, I disagree with you completely. Nothing could be more of a screw than being caught in a job with no way to exit it than killing it. It may be a minor irritation that the COMPLR fork doesn't kill itself, but it's a much worse problem the other way around. Many people like to do ^C and c,b for example. I think what you want is that when it finishes a compilation, it kills itself. The problem there is that Twenex (at least until Rel 5, I assume even then) has no primitive for jobs to ask that their superior kill them. So COMPLR cannot, in a system-independent transportable way, ask that it be killed. If this ever changes, then of course COMPLR would be changed to kill itself after a single compilation if it had been invoked with JCL (as is the behavior on ITS).  Date: 9 NOV 1982 2030-PST From: JONL at PARC-MAXC Subject: Re: Great error handling To: BIL at MIT-MC, BUG-COMPLR at MIT-MC cc: JONL at MIT-MC, JPG at MIT-MC, JONL In response to the message sent 9 November 1982 23:17-EST from BIL@MIT-MC PDERR is a COMPLR macro acronymic for "Proceedable Data ERRor". Maybe someone could just recompile PHAS1 (or whatever the file is called), making sure that CDMACS.FAS is loaded first. Each complr-connected file is supposed to check for CDMACS being loaded, I think in an eval-when compile.  Date: 9 November 1982 23:17-EST From: William G. Dubuque Sender: BIL at MIT-MC Subject: Great error handling To: BUG-COMPLR at MIT-MC cc: JONL at MIT-MC, JPG at MIT-MC Attempting to compile a function which maps a macro gets ;PDERR UNDEFINED FUNCTION OBJECT For example, try compiling: (defmacro m (x) `(- ,x)) (defun ms (l) (mapcar #'m l)) Presumably PDERR is a complr macro which wasn't around while compiling some piece of complr. Since this is probably an easy fix and such a painful obstruction to debugging, it would be nice if it could be taken care of soon.  Date: Tuesday, 9 November 1982 16:22-EST Sender: ALAN at MIT-OZ From: Alan Bawden To: bug-complr at MC Subject:Filename parser. #@!#!@#!$%#@$%! filename parser on 20X won't let you put any spaces between your filename and your switches. Typing "TMS.LSP (T)" gets it to barf that it couldn't find the file ((PS ALAN) TMS |LSP |), you have to type "TMS.LSP(T)". I'm sure glad it didn't PRINC the filename in that error message otherwise I would be really confused. This has been broken like this for as long as I can remember. I find it particularly annoying now that I have started using the M-X Compile command in Emacs which INSISTS on putting that space there...  Date: Wednesday, 27 October 1982 23:52-EDT From: Leonard N. Zubkoff To: Martin David Connor Cc: Bug-Complr at MIT-MC, Bug-Lisp at MIT-MC Subject: Strange interaction between LEDIT and COMPLR on Tops-20 Assuming that the default Ann Arbor Teco terminal type does not have a meta key, then I know the problem very well as I used to have it on my Concept-LNZ with meta key. The fix I used is Teco code in my Emacs init library of the following sort: !* Create Sail Mode and Meta Key Variables. These variables save the ! !* values of FS Sail$ and FS Tty Fci$ so that FS Tty Macro$ can reset them ! !* automatically if Emacs is restarted. ! -1 M.V Zubkoff_Sail_Mode !* Initialize Sail Mode to -1. ! 0 M.V Zubkoff_Meta_Key !* Initialize Meta Key to 0. ! 1: !* Assume Sail Font on Concept-LNZ's. ! !* If the System doen't know what Baud Rate the terminal is using, ! !* set it to 1200 baud. Also, reset FS Sail$ and FS Tty Fci$ from ! !* the variables Zubkoff_Sail_Mode and Zubkoff_Meta_Key. ! @:I*| 2 FS Echo Lines FS OSpeed"E 1200 FS OSpeed' QZubkoff_Sail_Mode"G 1 FS Sail' QZubkoff_Meta_Key FS Tty Fci | FS TTY Macro FS TTY Init I hope this helps. Leonard  Date: 27 October 1982 22:17-EDT (Wednesday) Sender: MARTY at MIT-OZ From: Martin David Connor To: Bug-Lisp at MC, Bug-Complr at MC Subject: Strange interaction between LEDIT and COMPLR on Tops-20 Here is an interesting problem: When using LEDIT, the system recognizes that I have an Ann Arbor, with a Meta key. If I later create a COMPLR fork with ^K, it seems to lose that fact that I have a Meta key when I return to my LEDIT fork. Has anyone else experienced this before? Can anyone suggest a fix? Thanks, Marty; -------  Date: 26 October 1982 17:30-EDT From: V. Ellen Golden Subject: forwarded for JLL To: GSB at MIT-MC, GJC at MIT-MC, BUG-COMPLR at MIT-MC cc: JLL at MIT-MC Date: 26 October 1982 11:00-EDT From: Joseph L. Leva Subject: compiling lisp code To: ELLEN at MIT-MC cc: JLL at MIT-MC I have been having trouble getting some compiled lisp code to run properly. Who can offer help in such matters, i.e. is there some bug file I can send my questions to? I have enclosed a description of the problem. Thanks for your help. I'm having trouble compiling the lsubrcall function where the 2nd argument is flonum. The following function works fine in the interpreter but gives an error when run from compiled code. (defun fls (fun a1 a2) ((lambda (fpt) (cond ((null fpt)(displa fun)(error '| has no LSUBR|))) (lsubrcall flonum fpt a1 a2)) (get fun 'lsubr))) From the interpreter: (fls '+$ 1.0 2.0) ==> 3.0 From compiled version: (fls '+$ 1.0 2.0) ==> ;write into read-only memory from location 15414 ;program trapped while in EXP  Date: Saturday, 11 September 1982 14:58-EDT From: Skef Wholey To: Glenn S. Burke Cc: BUG-complr at MIT-MC, BUG-lisp at MIT-MC, feinberg at CMU-20C, SROBINSON at DEC-MARLBORO Subject: load-byte/deposit-byte miscompilation Much thanks for your help. Nice to know that the number of bugs in MacLisp decreases some of the time... --Skef  Date: 11 September 1982 05:15-EDT From: Glenn S. Burke Subject: load-byte/deposit-byte miscompilation To: BUG-lisp at MIT-MC cc: feinberg at CMU-20C, Wholey at CMU-20C, BUG-complr at MIT-MC, SROBINSON at DEC-MARLBORO This has been fixed in the source of SRCTRN. One problem was that an original argument was being used for compile-time evaluation rather than the macroexpanded and un-quoted form in several places. There was also a shift missing in one case. A patch file has been made for the currently installed ITS compilers (version 1131) and those on OZ and XX (version 1127). For lack of a better mechanism, i consed up a twenex compiler patch file scheme, which is just a trivial variation of what is already in use on ITS. The file COMPILER-PATCH-TEMPLATE.LSP is the basic template, with directions: in this case, the specific files are CLFIX.1127, which loads COMPILER-PATCH-1127.FASL, which was made from COMPILER-PATCH-1127.LSP.  Date: 8 September 1982 00:55-EDT From: Glenn S. Burke Subject: load-byte/deposit-byte miscompilation To: Wholey at CMU-20C cc: BUG-COMPLR at MIT-MC I have identified the problem in the source, but not tested or installed the fixes yet (get to it tomorrow). There were a couple things wrong. Stay tuned...  Date: Tuesday, 7 September 1982 20:14-EDT From: Skef Wholey To: Bug-Complr at MIT-MC Subject: Complr's losing lossage, of course Let's see what complr does with the following code: ----- ;;; -*- Lisp -*- ;;; ;;; COMPLR LOSSAGE!!! ;;; (defconst const-1 0) (defconst const-2 3) (defmacro combine-somehow (a b) `(deposit-byte ,b 28 4 ,a)) (defun fleep () (print (combine-somehow const-1 const-2)) (print (combine-somehow const-2 const-1)) (print (combine-somehow 0 3)) (print (combine-somehow 3 0))) ----- When compiled, (fleep) prints the following: 3 0 3 805306368 Seems a little bogus, huh? [I realize that no one does much MacLisp maintainence these days, but I just needed someone to flame at...] --Skef  Date: 26 Jul 1982 03:58 PDT From: JonL at PARC-MAXC Subject: Re: macro/function competition In-reply-to: GSB's message of 24 July 1982 16:31-EDT To: Glenn S. Burke cc: KMP at MIT-MC, BUG-COMPLR at MIT-MC DEFCOMPLRMAC is 1/2 of the DEFBOTHMACRO hack. The code that implements it in MacLISP is probably arcane, but nevertheless it sufficed at one time, modulo the lack of true function cells.  Date: 24 July 1982 16:31-EDT From: Glenn S. Burke Subject: macro/function competition To: KMP at MIT-MC cc: BUG-COMPLR at MIT-MC A better way to handle this, and what is apparently the reason perturbations of this code have not shafted me, is to use the source-trans instead. This then introduces an ordering problem if what you want is a least-preferred source-trans... The code that produces this diagnostic in COMPLR is highly suspect. In particular it calls P1KNOWN on an incorrect argument. It checks for a DEFCOMPLRMAC property to bypass the diagnostic. However as far as i can tell, that property is only put on by the DECOMPLRMAC macro, which does not seem to do this defsubst-like stuff, i.e., that is not a valid test to bypass the diagnostic on. (DEFCOMPLRMAC appears to be sort of a DEFMACRO that does (eval-when (eval compile load-but-only- when-in-the-compiler) ...).) I will probably look at this some and fix it in the source.  Date: Wednesday, 14 July 1982 16:22-EDT From: Jonathan Rees To: Bug-Complr at MIT-MC Subject: (LOGNOT 7) doesn't compile right?! In COMPLR 925 (LISP 2088): (defun foo () (lognot 7)) FOO (foo) -8 (chomp foo) (FOO) (foo) 6285322496 The LAP code for FOO does a (SETCM 7 7) but doesn't initialize register 7, so the result is trash.  Date: 14 July 1982 04:37-EDT From: Kent M. Pitman To: BUG-COMPLR at MIT-MC The compiler message: (COMMENT **ERROR** (MAPCAR (FUNCTION F) Y) Function to MAP is macro, or randomness in function H) ; DATA ERROR - TO PROCEED TYPE $P should just be print a warning, but should not break. The compiler cannot reliably enough determine for sure if this is worth halting a compilation from. Since it can compile something, it should just proceed the compilation and continue on. I'm not objecting to getting the warning, only to the warning causing the compiler to want human intervention in order to proceed. I have an application which falsely generates this diagnostic (ie, where F is both a macro and a function and will map correctly) and it is irritating to not be able to :PROCEED the compilation and let it run without having to occasionally $P and type $P to the breakpoint. Thanks. --kmp  Date: 12 June 1982 14:23-EDT From: George J. Carrette To: MACRAK at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 11 June 1982 16:39-EDT From: Stavros M. Macrakis To: BUG-COMPLR (defun xx (a) (let ((q a)) (cond ((eq q a) (cdr q)) (t q)))) produces a jrst .+1 . I thought Complr didn't do that, ever. I hate to have to break the news to you, but I seriously doubt if any of the many bug notes you have been sending to BUG-COMPLR and BUG-LISP of late will ever see the light of day as bug fixes.  Date: 11 June 1982 16:39-EDT From: Stavros M. Macrakis To: BUG-COMPLR at MIT-MC (defun xx (a) (let ((q a)) (cond ((eq q a) (cdr q)) (t q)))) produces a jrst .+1 . I thought Complr didn't do that, ever.  Date: 5 June 1982 17:15-EDT From: Alan Bawden Subject: random output to MSGFILES in LAP files... To: BUG-COMPLR at MIT-MC Sorry about the message I just sent, I spazzed and typed a ^C by accident. File TEST contains just: (herald test) File TEST1 contains: (declare (load 'test)) (defprop test t test) (defprop foo t foo) Compiling TEST1 works just fine normally. However, if you compile it with the switch -K so that you get to look at the LAP file, then the lap file looks like: '(THIS IS THE LAP FOR ((DSK ALAN) TEST1 /2)) '(COMPILED BY LISP COMPILER /936 COMAUX /25 PHAS1 /86 MAKLAP /80 INITIA /118) ;COMPILED ON SATURDAY, JUNE 5, 1982, AT 5:07 PM ;Loading TEST 2(DEFPROP TEST T TEST) (DEFPROP FOO T FOO) Which doesn't assemble into the same thing since the herald message has commented out the first defprop! BARF!  Date: 5 June 1982 17:09-EDT From: Alan Bawden Subject: random output to MSGFILES in LAP files... To: BUG-COMPLR at MIT-MC File TEST contains just: (herald test) File TEST1 contains:  Date: 5 June 1982 16:47-EDT From: Alan Bawden Subject: #$&$&!#&!#! mis-use of fixpdl To: JonL at PARC-MAXC cc: BUG-COMPLR at MIT-MC Date: 5 Jun 1982 11:32 PDT From: JonL at PARC-MAXC Sigh, this is an old one, and not likely to go away easily, although one can rather try to avoid it. Could it be that the part of your source code (omitted in your original msg) had some COND clauses which were not discernably numeric? (abs (remainder (cond *...* (... (lsh atom 0)) (t (maknum atom))) *hashtable-size*)) The *...* is the part in question. The missing clause was ((fixp atom) atom). The possibility that atom might be a bignum is the reason for calling remainder rather than \. Indeed, I am finding it rather difficult to rearrange my code to make complr do this right. Currently I have it producing (MOVE 7 0 P) (PUSH FXP 7) (MOVEI 1 0 FXP) (SUB FXP (% 0 0 1 1)) G0012 (JSP T PDLNMK) for the call to maknum. If I wasn't looking at the LAP so carefully now I would probably never notice this, since I would have to be screwed by a rather unlikely interrupt. I guess I have to separate the bignum case from the fixnum cases to get this to work right?  Date: 5 Jun 1982 11:32 PDT From: JonL at PARC-MAXC Subject: Re: mis-use of fixpdl In-reply-to: ALAN's message of 5 June 1982 04:12-EDT To: Alan Bawden cc: BUG-COMPLR at MIT-MC Sigh, this is an old one, and not likely to go away easily, although one can rather try to avoid it. Could it be that the part of your source code (omitted in your original msg) had some COND clauses which were not discernably numeric? (abs (remainder (cond *...* (... (lsh atom 0)) (t (maknum atom))) *hashtable-size*)) The *...* is the part in question.  Date: 5 June 1982 04:12-EDT From: Alan Bawden Subject: mis-use of fixpdl To: BUG-COMPLR at MIT-MC (abs (remainder (cond ... (... (lsh atom 0)) (t (maknum atom))) *hashtable-size*)) compiles into: (MOVE 7 @ 0 P) (PUSH FXP 7) (MOVEI 1 0 FXP) (SUB FXP (% 0 0 1 1)) ;??? (JRST 0 G0010) G0012 (MOVE 7 0 P) (PUSH FXP 7) (MOVEI 1 0 FXP) (SUB FXP (% 0 0 1 1)) ;??? G0010 (MOVE 2 (SPECIAL *HASHTABLE-SIZE*)) (CALL 2 'REMAINDER) (CALL 1 'ABS) The whole function can be found in the file LSPMAI;ALAN FIXPDL.  Date: 26 May 1982 12:58-EDT From: Glenn S. Burke Subject: (lap-a-list backquoted) To: DCP at MIT-EECS cc: BUG-complr at MIT-MC I guess unfortunately it's not clear that what complr does here is a bug. I would suggest something like (defmacro deflap (name type list) `(lap-a-list '((lap ,name ,type) ,@(eval list)))) which would even make it come out nice with tags.  Date: 26 May 1982 1113-EDT From: David C. Plummer Subject: (lap-a-list ... To: bug-complr at MIT-MC It appears that (lap-a-list `((lap ... doesn't work becuase COMPLR is looking for a quoted argument for lap-a-list, and I must cheat with (lap-a-list '#.`(lap ... Is this true? Or do I just have a screw case? Should it be true? -------  Date: 22 April 1982 19:11-EST From: Stavros M. Macrakis To: BUG-COMPLR at MIT-MC (defun sdfsdf (wer) (cond ((null wer) nil))) compiles to push p,1 sub p,[1,,1] jrst pdlnkj which is wrong and weird. I've noticed that complr is doing a lot of unnecessary stack saves and pdlnmk's lately. Complr used to produce really beautiful code. What's happened?  Date: 22 April 1982 16:24-EST From: Stavros M. Macrakis To: BUG-COMPLR at MIT-MC (defun f (a b) (let ((x (f1 a)) (y (f2 a))) (cond ((not x) y) ((eq x y) y) ((eq y x) y) ((eq x y) x) ((eq y x) x))))))) (which admittedly is weird code) produces a whole succession of code sequences like: caxx jrst g1 jrst g2 g1: while the same code without the Let doesn't.  Date: 14 April 1982 06:47-EST From: Jon L White Subject: ACS properties in COMPLR To: RWK at MIT-MC cc: BUG-COMPLR at MIT-MC, GSB at MIT-MC Contrary to your note of Date: 14 April 1982 05:52-EST From: Robert W. Kerns The ACS property is not a "silly" place for keeping the information that a system-function is side-effect free -- only those that are so merit consideration about the optimization of not saveing-and-restoring volatile quantities (which include pending special variables). This isn't a general user feature, but is only for reducing the number of PUSH's and POP's around simple sytem functions. But what you pointed out about CLOSE is quite revealing -- it's not just CLOSE, but any SFA-able function which can have general side effects. The poor COMPLR database proably hasn't been updated since before SFA days, for this effect; I've just edited the sources to try to reflect the danger of SFAs, by removing the ACS properties from SFA-able functions. Also added these remprops to the CLFIX file.  Date: 14 April 1982 05:52-EST From: Robert W. Kerns Subject: CLOSE and ACS property To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC, GSB at MIT-MC Since when is it guarenteed that CLOSE on an SFA won't SETQ any special variables?????? This is a completely silly place to try to put such an optimization anyway.  Date: 13 APR 1982 2310-PST From: JONL at PARC-MAXC Subject: CLOSE has ACS property To: gsb at MIT-ML cc: bug-complr at MIT-MC First, a review of the "technology" of COMPLR patches: LSPDMP;CLFIX xxxx is the canonical file of patches for the COMPLR version xxxx; it is LOAD'd, but can flexibly only be EXPR code, so generally we have the convention that a file LSPDMP;CL.FIX xxxx may also exist and be a fasl file (it too is LOAD'd, but LOAD knows about fasl files). As a convention, the source for the compiled fasl file is LSPDMP;CL%FX xxxx So, I made a CLFIX 1131 by copying the "form" of CLFIX > -- as it happens, the trivial patch for CLOSE doens't need any of the auxillary files. By tthe bye, CLOSE could have an ACS of 5, since this signals that no special variables are SETQ'd by calling CLOSE; no ACS prop at all would mean "totally unknown function". P.S. I installed this CLFIX to ML, but AI seems to be still down. -------  GSB@MIT-ML 04/13/82 20:52:22 To: (BUG COMPLR) at MIT-ML I'm getting nauseous, i cannot make a patch with that technology  Date: 13 April 1982 20:48-EST From: Glenn S. Burke To: BUG-COMPLR at MIT-MC CLOSE has an ACS property of 1. This is completely wrong; AR1 gets clobbered by AFOSP, and B and C also if it is an SFA, and AR2A also if the SFA function so desires. I will attempt to patch.  Date: 24 March 1982 19:29-EST From: George J. Carrette Subject: DEFUN& To: ALAN at MIT-MC cc: BUG-COMPLR at MIT-MC The important point is that I think the use of OWN-SYMBOL in your BINDA file is losing. Various symbols are already wired into the environment, using OWN-SYMBOL can be ok at compile-time within a file to suppress warning messages, but it will lose if used at FASLOAD time. My experience was that REMPROP and PUTPROP are better tools for this, since it wasn't the symbols that were obnoxious, but the properties they had. If your PLIST offends you, pluck it out, better to lose a few properties than to be lost forever in the package system.  Date: 24 March 1982 1607-EST (Wednesday) From: Guy.Steele at CMU-10A To: alan at MIT-MC, gjc at MIT-MC Subject: Powerful tools CC: bug-complr at MIT-MC And if PUTPROP and REMPROP aren't powerful enough, there are always SYSCALL and DEPOSIT. --Quux  Date: 24 March 1982 15:40-EST From: Alan Bawden Subject: Redefining DEFUN& To: GJC at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 24 March 1982 14:58-EST From: George J. Carrette Well, for compiling the NIL cross-compiler I loaded stuff into COMPLR which redefined *everything*, DEFUN&, LET, DESETQ, DEFMACRO, you name it. I never used the OWN-SYMBOL declaration though, instead, the trick for something like DEFUN& goes like this: (eval-when (eval compile) (defprop defun& defun&-macro macro) (defprop defun&-macro |DSK:VAXMAX;DEFUN& FASL| autoload)) (defun f (&optional a b) (list a b)) In general, PUTPROP and REMPROP are powerful tools for dealing with COMPLR. Wonderful. Perhaps I am being dense, but in what way does what you advise here differ from what I am already doing? Are you telling me that giving defun& a macro property of defun&-macro instead of defun&/ macro will solve my problem?  Date: 24 March 1982 14:58-EST From: George J. Carrette Subject: Redefining DEFUN& To: ALAN at MIT-MC cc: BUG-COMPLR at MIT-MC Well, for compiling the NIL cross-compiler I loaded stuff into COMPLR which redefined *everything*, DEFUN&, LET, DESETQ, DEFMACRO, you name it. I never used the OWN-SYMBOL declaration though, instead, the trick for something like DEFUN& goes like this: (eval-when (eval compile) (defprop defun& defun&-macro macro) (defprop defun&-macro |DSK:VAXMAX;DEFUN& FASL| autoload)) (defun f (&optional a b) (list a b)) In general, PUTPROP and REMPROP are powerful tools for dealing with COMPLR.  Date: 23 March 1982 18:24-EST From: Alan Bawden To: BUG-COMPLR at MIT-MC cc: DANNY at MIT-MC Looks to me as if it is impossible for users to redefine defun&. I tried compiling a file containing: ;;;-*-Lisp-*- (eval-when (eval load compile) (load "alan;binda fasl")) ;this redefines defun& (defun test (a &optional (b 1)) (list a b)) And it generated the following UNFASL: ;CAUTION! |DEFUN& MACRO|, A USER SUBR AT 143362, IS BEING REDEFINED ; AS A SUBR BY FASL FILE ((DSK ALAN) BINDA FASL) (COMMENT **** &OPTIONAL Undeclared - taken as SPECIAL in function TEST) (COMMENT **** A Undeclared - taken as SPECIAL in function TEST) (COMMENT **** B Undeclared - taken as SPECIAL in function TEST) (COMMENT **** (EXPR) Unused LAMBDA variables in function TEST) (COMMENT **FASL** 0. (LAP TEST LSUBR)) (COMMENT **** (B A) have been used but remain undefined in this file) (COMMENT **FASL** TOTAL = 15. WORDS) Well at first I thought that the DEFUN& macro defined in the file ALAN;BINDA was broken. But it has no problems in the interpretor and if I change the DEFUN in the test file to a DEFUN& it compiles fine. ALAN;BINDA does an (OWN-SYMBOL DEFUN&) which seems not to improve the situation any. The code generated looks as if the following had been compiled: (defun test (listify ) (a &optional (b 1)) (list a b)) Which explains all of the warnings in the UNFASL except: (COMMENT **** (EXPR) Unused LAMBDA variables in function TEST) WHAT variable EXPR? There is no symbol EXPR in the test file or in ALAN;BINDA or in the resulting FASL file! Does it come from part of sombody's property list? I even tried doing a (sstatus uuolinks) figuring that perhaps someone was doing (defun&/ macro x) somewhere. No change. I'm totally mystified as to what is happening and how to prevent it.  Date: 6 March 1982 22:04-EST From: Alan Bawden Subject: how am I supposed to deal with this behavior? To: BUG-COMPLR at MIT-ML (defun test (x y) (declare (fixnum x y)) (plus x y)) compiles into: (LAP TEST SUBR) (ARGS TEST (() . 2)) (MOVE 7 0 1) (ADD 7 0 2) (JSP T FXCONS) (POPJ P) () This is incorrect. Nowhere did I specify that the sum of x and y was a fixnum too. Similarly: (defun test (x y) (plus (1+ x) (1+ y))) Compile into: (LAP TEST SUBR) (ARGS TEST (() . 2)) (MOVE 7 0 1) (ADDI 7 1) (MOVE 10 0 2) (ADDI 10 1) (ADD 7 10) (JSP T FXCONS) (POPJ P) () Same bug.  Date: 27 February 1982 15:05-EST From: Jon L White Subject: Compilation bug seen in DO loop To: ROD at MIT-MC cc: BUG-COMPLR at MIT-MC Yes, the bug you noticed in "baz" below is a manifestation of the local-variable-side-effected-by-fixnum-value bug, which you (and a handful of others, notably GLR) discovered some time ago. The simplest way to avoid this COMPLR problem is to declare such local variable as FIXNUM, since it is the lack such declaration which permits the bug to be seen; I've added a DECLARE in caps below to indicate it. The declaration isn't necessary in "foo" since the side-effects don't occur at the wrong time there, but it won't hurt anything by having it (may even make the code marginally faster). Date: 22 Feb 1982 0120-PST From: Rod Brooks . . . (defun foo (l) (do ((i 1 (1+ i)) (last 0 ch) (ch (arraycall fixnum l 0) (arraycall fixnum l i))) ((= i 5)) (DECLARE (FIXNUM CH)) (print (list ch last)))) (defun baz (l) (do ((i 1 (1+ i)) (ch (arraycall fixnum l 0) (arraycall fixnum l i)) (last 0 ch)) ((= i 5)) (DECLARE (FIXNUM CH)) (print (list ch last))))  Date: 22 February 1982 16:31-EST From: Glenn S. Burke Subject: DO loses. To: ROD at SU-AI cc: BUG-complr at MIT-MC Yes, this is that old hard-to-fix bug. The insertion of type declarations, (defun foo (l) (do ((i 1 (1+ i)) (last 0 ch) (ch (arraycall fixnum l 0) (arraycall fixnum l i))) ((= i 5)) --> (declare (fixnum i last ch)) (print (list ch last)))) causes it to perform correctly. As a general rule declarations for known-fixnum quantities, most especially inside loops as these are, both stifle this bug and produce better code.  Date: 22 Feb 1982 0120-PST From: Rod Brooks Subject: DO loses. To: bug-complr at MIT-MC I can't remember if this is a manifestation of a bug that bit me a couple of times a few years ago, and which JONL said was too hard to fix, but it sure surprised me. The only difference between foo and baz below is the order of their supposedly side-effectless do steppers. I couldn't get it to lose cdr-ing down a list, rather than using the array. (*array 'arr 'fixnum 6) (fillarray 'arr '(8 7 6 5 4 3 2)) (setq arr (get 'arr 'array)) (defun foo (l) (do ((i 1 (1+ i)) (last 0 ch) (ch (arraycall fixnum l 0) (arraycall fixnum l i))) ((= i 5)) (print (list ch last)))) (defun baz (l) (do ((i 1 (1+ i)) (ch (arraycall fixnum l 0) (arraycall fixnum l i)) (last 0 ch)) ((= i 5)) (print (list ch last)))) .lisp LISP 2133 Alloc? n * (fasload lose fas) 34121 (foo arr) (10 0) (7 10) (6 6) (5 5) NIL (baz arr) (10 0) (7 10) (6 7) (5 6) NIL  Date: 19 February 1982 12:51-EST From: Jon L White Subject: discussion of autoloading macros To: GSB at MIT-MC cc: BUG-COMPLR at MIT-MC, JPG at MIT-MC GSB@MIT-ML 02/19/82 04:01:01 Re: autoloading macros It seems to me that either this was put in and taken out again, or it was aborted just before being put in, some time ago. . . . I found a little discussion in the mail from about two years ago relevant to this, and reproduced it below. But the real problem is this: A long time ago, we made the decision that MACROEXPAND would call the function FIND-MACRO-DEFINITION, which would try autoloading an "autoloadable" function name ** if no other information were available **. Thus a user who hasn't very carefully separated his compilation environment from his object environment may have many more autoload properties in the former than is necessary, and that may cause spurious autoloadings in order to find out information about random function names. Until this week, the COMPLR was not consistent about when it obeyed this protocol, and when it tried "on its own" to expand a macro. But heres the discussion from long ago: Date: 20 April 1980 17:43-EST From: Mark L. Miller Subject: Autoload To: KMP at MIT-MC, BUG-LISP at MIT-MC It seems to me that there is very little conceptual difference between AUTOLOADable functions and macros. Indeed it might be preferable to have the value of the AUTOLOAD property BE a macro definition which would receive the calling form as its one input, and return a revised form for further evaluation. A built-in function AUTOLOAD would be the usual body, e.g.,: (defun GRIND macro (form) (autoload form '((com) grindef fasl))). where autoload was defined as something like: (defun AUTOLOAD (form file) (load file) (comment possibly remprop the macro defn here) form) -- just to make the current behavior trivial to implement; but one could then also do cleverer things instead. Would this sort of thing solve the problem? Has this sort of idea been considered and rejected already? Regards, Mark Date: 26 April 1980 08:42-EST From: Kent M. Pitman Subject: Autoload To: MILLER at MIT-AI . . . I have been kind of out of it and am not sure if someone properly responded to you but it's is essential that AUTOLOADable things be FUNCALL-able and MACRO's are not. So no scheme for autoloading anything to be used by compiled code by appealing to a autoload-macro can work. -kmp Date: 1 May 1980 16:48-EDT From: John L. Kulp Subject: Autoload properties and stuff To: KMP at MIT-MC . . . Your comments are rather full of inconsistencies. Making a macro autoloadable does not make it part of the language. If a user provides his own definition of a macro, it does not affect other compiled code. It is certainly not the case that anywhere near everything that is autoloadable is documented in the manual (new or old), and there are many other things autoloadable which are not part of the language in any sense. . . .  GSB@MIT-ML 02/19/82 04:01:01 Re: autoloading macros To: (BUG COMPLR) at MIT-ML It seems to me that either this was put in and taken out again, or it was aborted just before being put in, some time ago. Perhaps some brute-forcing through the archives is in order.  Date: 16 February 1982 19:18-EST From: Jon L White Subject: Recognizing AUTOLOADing macros To: DEVON at MIT-MC, CSTACY at MIT-MC cc: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC The following deficiency in COMPLR is now corrected: Date: 9 February 1982 23:10-EST From: Christopher C. Stacy DEVON@MIT-MC (Sent by DEVON0@MIT-MC) 02/04/82 01:14:37 Isn't it reasonable for compiled and interpreted code to have the same environment? I tried (eval-when (compile) (load "guest5;devon lisp")) which puts autoload properties on many of my commonly used macros, etc, but the compiler ignores that, and I've been reduced to keeping two copies of everything, one for the compiler and one for the interpreter since I don't know how to make the compiler recognise synonyms and do autoloads! And I keep having to fix the smae bugs twice!!! Help!!! Actually, some parts of the COMPLR did already "recognize" these autoload properties (e.g., top-level forms), but there was a deficiency in the way that "code" was being macroexpanded which caused it to ignore autoloadable macros unless they had a FUNTYP-INFO property. I've changed this so that it will try autoloading unless the function is already FBOUNDP. I've tried this out with your macros on a little test file: (eval-when (compile) (load "guest5;devon lisp")) (defun foo (x) (iff (eq x 'FOO) 5)) and it wins now. Unfortunately, the net to AI was down, so the patch is only on MC and ML as of now. By the bye, DEVON, did you know that there is a function ARRAYP in the file MLSUB (for MacLisp SUBroutines)? It checks to be sure that the array isn't one of the "funny" kind, like READTABLE, FILE, SFA, or whatever; these "funny" kinds are of typep ARRAY, but are of differing array-type. This function may be documented soon.  Date: 13 February 1982 18:18-EST From: Glenn S. Burke To: REM at MIT-MC cc: BUG-COMPLR at MIT-MC If you give the compiler the Y switch then error and warning messages will get printed at you. e.g., a command line of "reawri (y)". In any event the error message is in the unfasl file, and can be found in the partially written one even if the compilation is aborted after the error.  Date: 13 February 1982 07:56-EST From: Robert Elton Maas To: BUG-COMPLR at MIT-MC When COMPLR complains of an error during macro expansion, how can I easily discover exactly the nature of the error? (I don't know if part of the macro I defined earlier in the same file is somehow not available to the compiler, or there's a recursion loop, or some random ERROR is happening during compilation and the compiler isn't printing the original ERROR message.) REM;REAWRI > is the file that bombs the compiler.  Date: 25 January 1982 13:01-EST From: Jon L White Subject: DPB miscompilation fixed! To: HES at MIT-MC, ALAN at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 24 January 1982 20:49-EST From: Alan Bawden Date: 23 January 1982 10:34-EST From: Jon L White If the following report from HES is true, namely that the cited code works ok interpretively, then this isn't a SETF/DPB problem: HES@MIT-AI 01/11/82 12:25:08 The maclisp complr seems to generate the wrong stuff for the code in ai:reason;foobar > ; in particluar the form (setf (tms-support-status node) *in*) . . . Did I ever send a note to anyone saying that HES's problem had anything to do with a SETF bug? I will admit that I THOUGHT that for a while, but I don't remember ever telling anyone that. If I did, then I take it back and I revert to the suspicion voiced in the note you have conveniently included above, namely that this is the compiler mis-compiling a DBP. (Which I remember it doing in the past, no?) The bug is mine, on two accounts: 1) As ALAN puts it "the suspicion voiced in the note ..." blames SETF expansion; indeed, there is a bug here regardless of any compilation question, and I too quickly assumed that the SETF expansion for LDB was turning into a bad call to DPB, but that isn't HES's problem. Apologies for mistaken view of ALAN's comments. 2) One of the many arcane cases of LDB/DPB optimization did indeed have a bug in it, and it is now fixed both in source file, and in a COMPLR patch file (doing COMPLR^K will load in the patch file).  Date: 24 January 1982 20:49-EST From: Alan Bawden To: JONL at MIT-MC cc: HES at MIT-MC, BUG-COMPLR at MIT-MC Date: 23 January 1982 10:34-EST From: Jon L White If the following report from HES is true, namely that the cited code works ok interpretively, then this isn't a SETF/DPB problem: Date: 14 January 1982 12:54-EST From: Alan Bawden To: BUG-COMPLR at MIT-MC HES@MIT-AI 01/11/82 12:25:08 The maclisp complr seems to generate the wrong stuff for the code in ai:reason;foobar > ; in particluar the form (setf (tms-support-status node) *in*) turns into the wrong thing. Note that this code works interpretively. My complr init loads lisp;struct fasl as does my lisp init in case this is relevant. tms-support-status is a two bit byte field in one word of a defstruct. That means that (setf (tms-support-status node) *in*) turns into a DPB. Thus, I suspect that this is another case of the compiler mis-understanding DPB. Especially if it works interpreted. The SETF problem occurs independently of any compilation, as seen by this report: ... Did I ever send a note to anyone saying that HES's problem had anything to do with a SETF bug? I will admit that I THOUGHT that for a while, but I don't remember ever telling anyone that. If I did, then I take it back and I revert to the suspicion voiced in the note you have conveniently included above, namely that this is the compiler mis-compiling a DBP. (Which I remember it doing in the past, no?)  Date: 23 January 1982 10:42-EST From: Jon L White To: RIVEST at MIT-MC cc: BUG-COMPLR at MIT-MC RIVEST@MIT-ML 01/14/82 23:23:43 To: (BUG COMPLR) at MIT-ML Why is it that when I do :COMPLR filename the job does not kill itself when it is done, but rather waits until the next time when I do :COMPLR filename2 asks me if I want to clobber the existing job (I type space for yes) starts up the new job, and then KILLS THEM BOTH without doing anything new? Are you sure the job doesn't kill itself? Since it probably normally quits by doing a .BREAK to DDT, then DDT needs to select it in order to complete the job kill; usually the 'next time' DDT gets the chance, it finishes off the 'kill', and selects another job. On the other hand, if this isn't the case, then possibly the first call :COMPLR is getting hung due to some error; if your command line didn't include the D switch, for disowning the job, then any error will just go into a BREAK loop so that you may have the opportunity to fix it; 'errors' includes file system errors too.  Date: 23 January 1982 10:34-EST From: Jon L White To: ALAN at MIT-MC, HES at MIT-MC cc: BUG-COMPLR at MIT-MC If the following report from HES is true, namely that the cited code works ok interpretively, then this isn't a SETF/DPB problem: Date: 14 January 1982 12:54-EST From: Alan Bawden To: BUG-COMPLR at MIT-MC HES@MIT-AI 01/11/82 12:25:08 The maclisp complr seems to generate the wrong stuff for the code in ai:reason;foobar > ; in particluar the form (setf (tms-support-status node) *in*) turns into the wrong thing. Note that this code works interpretively. My complr init loads lisp;struct fasl as does my lisp init in case this is relevant. tms-support-status is a two bit byte field in one word of a defstruct. That means that (setf (tms-support-status node) *in*) turns into a DPB. Thus, I suspect that this is another case of the compiler mis-understanding DPB. Especially if it works interpreted. The SETF problem occurs independently of any compilation, as seen by this report: Date: 23 January 1982 10:16-EST From: Jon L White Subject: SETF on LDB constructs Date: 16 January 1982 13:35-EST From: David C. Plummer I BUGged this last year, and I just got screwed by it again: (macroexpand '(setf (ldb 0410 (arraycall fixnum foo 0)) (length bar))) ==> ((LAMBDA (|T..120| |T..121|) (SETQ |T..120| (DPB |T..121| 410 |T..120|)) |T..121|) (ARRAYCALL FIXNUM FOO 0) (LENGTH BAR)) It appears that if the new value involves a computation, setf gets quite confused. The SETF inversion process is a murky one, especially for the 'composed' operators like ARRAYCALL, PROGN, and LDB; RWK knows the most about this code, and should probably look into it (he has promised, again!, to do so.)  Date: 15 January 1982 18:34-EST From: Alan Bawden Subject: holding a grudge To: BUG-DDT at MIT-MC cc: RIVEST at MIT-MC, BUG-COMPLR at MIT-MC RIVEST@MIT-ML 01/14/82 23:23:43 This is very minor... Why is it that when I do :COMPLR filename the job does not kill itself when it is done, but rather waits until the next time when I do :COMPLR filename2 asks me if I want to clobber the existing job (I type space for yes) starts up the new job, and then KILLS THEM BOTH without doing anything new? Rather mysterious... Thanks Ron Rivest To get the correct bogus behavior you must have set GENJFL to 0 of course, but then it really is true that DDT kills the newly loaded complr before it can do anything. It happens when complr is doing a .BREAK 12,[..RSTP,,TT] which is a fairly innocuous thing for it to do. I would guess that that is simply the first time that the complr job has interrupted DDT. I guess you might say that DDT is still holding a grudge at that point...  RIVEST@MIT-ML 01/14/82 23:23:43 To: (BUG COMPLR) at MIT-ML This is very minor... Why is it that when I do :COMPLR filename the job does not kill itself when it is done, but rather waits until the next time when I do :COMPLR filename2 asks me if I want to clobber the existing job (I type space for yes) starts up the new job, and then KILLS THEM BOTH without doing anything new? Rather mysterious... Thanks Ron Rivest  Date: 14 January 1982 12:54-EST From: Alan Bawden To: BUG-COMPLR at MIT-MC cc: HES at MIT-MC HES@MIT-AI 01/11/82 12:25:08 The maclisp complr seems to generate the wrong stuff for the code in ai:reason;foobar > ; in particluar the form (setf (tms-support-status node) *in*) turns into the wrong thing. Note that this code works interpretively. My complr init loads lisp;struct fasl as does my lisp init in case this is relevant. howie tms-support-status is a two bit byte field in one word of a defstruct. That means that (setf (tms-support-status node) *in*) turns into a DPB. Thus, I suspect that this is another case of the compiler mis-understanding DPB. Especially if it works interpreted.  HES@MIT-AI 01/11/82 12:25:08 To: (BUG COMPLR) at MIT-AI CC: ALAN at MIT-AI The maclisp complr seems to generate the wrong stuff for the code in ai:reason;foobar > ; in particluar the form (setf (tms-support-status node) *in*) turns into the wrong thing. Note that this code works interpretively. My complr init loads lisp;struct fasl as does my lisp init in case this is relevant. howie  Date: 25 December 1981 08:39-EST From: Jon L White To: REM at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-HARDWARE at MIT-MC Date: 25 December 1981 05:47-EST From: Robert Elton Maas ILOPR; 672240>>CONSO PI,@672237 662451/ TROE 11,662446(12) I was attempting to compile REM;PCNSR6 > Sometime during the past day or so, the file SYS;PURQIO 2122 suffered the following bit changes: 44245:/ 254000,,44240 ==> 254000,,672240 I reloaded from the unpurified file BBLISP 122QIO and redumped. (also checked ML and AI and saw that they were not similarly perturbed).  Date: 25 December 1981 05:47-EST From: Robert Elton Maas To: BUG-COMPLR at MIT-MC ILOPR; 672240>>CONSO PI,@672237 662451/ TROE 11,662446(12) This is either a bug or a very poorly-user-compatible error message. I was attempting to compile REM;PCNSR6 >  Date: 19 December 1981 04:09-EST From: Jon L White To: JPG at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 17 December 1981 09:24-EST From: Jeffrey P. Golden Compiling JPG;SIMP 1 with CL^K loses with "GO or RETURN not in PROG". This error message is false, as MAPEX is T. The file compiles with OCL^K with no problem. . . . Fixed now -- minor typo when checking for known system FSUBRs caused it to try functionifying in some cases. Complr fix file installed and sources edited.  Date: 17 December 1981 09:24-EST From: Jeffrey P. Golden To: BUG-COMPLR at MIT-MC cc: JPG at MIT-MC Compiling JPG;SIMP 1 with CL^K loses with "GO or RETURN not in PROG". This error message is false, as MAPEX is T. The file compiles with OCL^K with no problem. You can compile by specifying e.g. JPG;SIMP 1(FTUK) (I have since changed the MAPC into a DOLIST to win, but that's besides the point.)  Date: 12 December 1981 16:48-EST From: Jon L White To: BUG-COMPLR at MIT-MC How about optimizing out quoted arguments to CASEQ? These can happen in macro-generated code, e.g. (CASEQ 'A ((B C) 5) (A 6) (T 7)) could just be turned into 6.  Date: 8 December 1981 16:49-EST From: Jon L White Subject: Fixing weird COMPLR bug fixes SI:INVALIDATED loss too? To: ALAN at MIT-MC, WGD at MIT-MC, eb at MIT-ML cc: BUG-MACLISP at MIT-MC, BUG-COMPLR at MIT-MC Date: 20 November 1981 00:13-EST From: Alan Bawden I reported a bug several months back and left a test case in ALAN;LOSS >. . . (This is the (foo x ) bug again, remember?) This bug is now fixed in COMPLR 1130. It resulted from a bad interaction between "optimizing" COND compilations and PROGN compilations, and only occured in quite contorted situations. This problem is probalby responsible for the lossage noted by WGD and EB previously when some displaced macro got munged; since the munging was not due to any bug in DEFMAX, it would have to be some bug like this one (or, horrors, a GC bug). Probaly EB and WGD should recompile their macro files, and report any future SI:INVALIDATED comments to bug-complr too. (The SI:INVALIDATED note ocurs when displaced macro call gets randomly RPLAC'd, which could certainly happen when "foo" in alan's example is the call to DISPLACE for macro displacement).  Date: 8 December 1981 16:32-EST From: Jon L White Subject: Spurious SPECIALizations To: RLB at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 5 October 1981 17:39-EDT From: Richard L. Bryan In a bare CL, the following symbols have SPECIAL properties: CLASS OBJECT SEQUENCE STRUCT STRUCT=INFO VECTOR Note that symbols with the above names suffixed with "-CLASS" are also special, e.g. VECTOR-CLASS. Ok, it's fixed now in COMPLR 1130 that the random symbols CLASS OBJECT SEQUENCE STRUCT STRUCT=INFO VECTOR don't have SPECIAL properties, and the correspondents suffixed by "-CLASS" get SPECIAL properties only when a modest-sized piece of the EXTEND system is loaded in.  Date: 7 December 1981 17:52-EST From: Jon L White To: JGA at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 7 December 1981 16:59-EST From: John G. Aspinall Compiling a function containing - . . . (defun visibility-list (s-edge grid window) . . . . . . (COMMENT **** DX Undeclared - taken as SPECIAL in function VISIBILITY-LIST) (COMMENT **** DY Undeclared - taken as SPECIAL in function VISIBILITY-LIST) (COMMENT **** (DX DY) Unused LAMBDA variables in function VISIBILITY-LIST) This problem is entirely due to the use of DX and DY as free variables in the little lambda function; the #' (which turns into FUNCTION) does not produce any kind of "closure", so when compiled these become special (free) variables: (sort (edge-segments s-edge) #'(lambda (p1 p2) (sort-pred (point-x p1) (point-y p1) (point-x p2) (point-y p2) dx dy))) You will win if you merely add the declarations to your function (defun visibility-list (s-edge grid window) (declare (special DX DY)) . . . From looking over your code, I don't believe you will even suffer from time spent in flonum consing to make DX and DY free. By the way, this problem is not the same as the "lexically-scoped" question -- some other construct in MacLISP could be used to mean "add to the closure all the lexically aparent variables"; but there aren't any real "closures" in MacLISP anyway, since *FUNCTION is useful only in the 'downwards' stack case.  Date: 7 December 1981 16:59-EST From: John G. Aspinall To: BUG-COMPLR at MIT-MC cc: JGA at MIT-MC Compiling a function containing - (defmacro sort-pred (x0 y0 x1 y1 dx dy) `(< (+$ (*$ ,dx ,x0) (*$ ,dy ,y0)) (+$ (*$ ,dx ,x1) (*$ ,dy ,y1)))) (defun visibility-list (s-edge grid window) (let ((dx (-$ (edge-x1 s-edge) (edge-x0 s-edge))) (dy (-$ (edge-y1 s-edge) (edge-y0 s-edge)))) (declare (flonum dx dy)) (setf (edge-segments s-edge) (cons (make-point point-x (edge-x0 s-edge) point-y (edge-y0 s-edge) point-z (edge-z0 s-edge)) (nconc (sort (edge-segments s-edge) #'(lambda (p1 p2) (sort-pred (point-x p1) (point-y p1) (point-x p2) (point-y p2) dx dy))) (cons (make-point point-x (edge-x1 s-edge) point-y (edge-y1 s-edge) point-z (edge-z1 s-edge)) nil)))))..... I get the following things in my UNFASL file - (COMMENT **** DX Undeclared - taken as SPECIAL in function VISIBILITY-LIST) (COMMENT **** DY Undeclared - taken as SPECIAL in function VISIBILITY-LIST) (COMMENT **** (DX DY) Unused LAMBDA variables in function VISIBILITY-LIST) (COMMENT **FASL** 3211. (LAP |JGA;HIDDEN 219_11| SUBR)) (COMMENT **FASL** 3235. (LAP VISIBILITY-LIST SUBR)) It seems to me that DX and DY have (1) been declared and (2) been used in the function. Complete file is JGA;HIDDEN > . John.  Date: 30 November 1981 17:49-EST From: Jon L White Subject: Open-compilation of DPB/DEPOSIT-BYTE To: gsb at MIT-ML cc: BUG-COMPLR at MIT-MC GSB@MIT-ML 11/29/81 17:06:14 Re: well shaft me royally To: (BUG COMPLR) at MIT-ML The "nice" case of DPB does not compile correctly. e.g., (DPB 1 3606 foo), which turns into (boole 7 foo -10_33). . . . This bug is correctly fixed now in SRCTRN, and put into the COMPLR FIX file -- the problem was that the expanders for DPB and DEPOSIT-BYTE were "sharing the load", so that as bugs got removed, the remaining ones showed up in different places. Now, the DEPOSIT-BYTE expander is primary, and open-codeable DPB's just turn into DEPOSIT-BYTE's. GSB@MIT-ML 11/29/81 19:37:07 To: (BUG COMPLR) at MIT-ML I fixed the b.d. in SRCTRN, and installed a fix file for ldb-expander. Someone could have at least tested that thing somewhat when it was last twiddled. The time to test the optimizations twiddled between SRCTRN 16 and SRCTRN 17 would have been negligible next to the time . . . The little test file for 'simple' DPB expansions COMLAP;TSTDPB > shows that SRCTRN version 16 wins only 1 of the 6 cases, version 17 wins on 3 of the 6, and your addendum makes it win on 4 of the 6; version 19 wins on all 6 cases. OCOMPLR has version 10, and it wins on all 6 cases too, but it fails to open-compile 3 of the 6 cases -- instead it uses the archaic, soon-to-be forgotten function *DPB; also it has egregious errors in other cases of DEPOSIT-BYTE.  Date: 30 November 1981 16:53-EST From: Jon L White Subject: COMPLR init files To: KWC at MIT-MC cc: BUG-COMPLR at MIT-MC KWC@MIT-ML 11/23/81 08:33:28 To: (BUG COMPLR) at MIT-ML when the complr says that it is loading an init file, it would be nice if it would say exactly what file it is loading. . . . Ok, I've fixed this in the sources, but this will not do anything in the ITS version untile the next dump (loading init files happens thru a lower-level non-COMPLR function); at least in the next TWENEX version you'll see the true name name of the file.  GSB@MIT-ML 11/29/81 19:37:07 To: (BUG COMPLR) at MIT-ML I fixed the b.d. in SRCTRN, and installed a fix file for ldb-expander. Someone could have at least tested that thing somewhat when it was last twiddled. The time to test the optimizations twiddled between SRCTRN 16 and SRCTRN 17 would have been negligible next to the time i had to spend tracking down a compilation error deep in the guts of some code which had hardly been touched. Maybe you don't have anything better to do with your time, but i'm a little disgusted because my day has been wasted.  GSB@MIT-ML 11/29/81 17:06:14 Re: well shaft me royally To: (BUG COMPLR) at MIT-ML The "nice" case of DPB does not compile correctly. e.g., (DPB 1 3606 foo), which turns into (boole 7 foo -10_33). The bogousity is that (logand this that) is being used for predicate value to determine if all the bits of the byte field are being set to ones, a test which is brain damaged on at least two counts.  KWC@MIT-ML 11/23/81 08:33:28 To: (BUG COMPLR) at MIT-ML when the complr says that it is loading an init file, it would be nice if it would say exactly what file it is loading. It may be fairly obvious on ITS, but now that I am starting to use n different systems, it sometimes gets to be somewhat difficult to remember all the different conventions.  Date: 20 November 1981 00:13-EST From: Alan Bawden To: BUG-COMPLR at MIT-MC I reported a bug several months back and left a test case in ALAN;LOSS >. The bug hasn't been fixed yet and so I am still holding on to the test case. Any chance that it will be fixed so that I can free up some room on my directory? (This is the (foo x ) bug again, remember?)  Date: 16 November 1981 17:11-EST From: Communications Satellite Subject: Compilation differences between CXR 1 and CXR 3 To: PSZ at MIT-ML CC: JONL at MIT-MC, (FILE ["MC:LSPMAI;COMPLR BUGS"]) at MIT-MC CC: GSB at MIT-ML Date: 12 November 1981 20:18-EST From: Peter Szolovits When I try to compile the file (defun foo (x) (cxr 1 x)) (defun bar (x) (cxr 3 x)) . . . Is there any reason for the PUSH and POP in the second case? This is a pretty bad slow-down of a lot of code generated by structure defining macros. Obviously, there is some semi-bug in COMPLR (i.e., still generates correct code, but not quite the code we thought we'd get). Before I go looking for this one, I wonder how it affects you -- it may just be related to the non-PUSHing heuristics for simple functions, but if your macros produce a bunch of 'in-line' CXRs for some non-trivial function, there may be no problem at all.  Date: 15 November 1981 21:25-EST From: Glenn S. Burke Subject: &optional arguments and complr To: BUG-COMPLR at MIT-MC cc: SOLEY at MIT-MC The problem is not that COMPLR (or DEFUN& or whatever) should output a *LEXPR declaration for something, but that the relationship between the in-core definition and complr's default declaration/arg-number-checking stuff is poorly defined, and inconsistent. Consider the following small file: ---- (eval-when (compile) ;Define, in the compilation environment, a dummy lsubr FOO which takes ; from 0 to 0 args. Easier than bothering with two files. (lap-a-list '((lap foo lsubr) (args foo (0 . 0)) (setz a) (popj p) nil))) (defun bar (x) (foo x)) ---- This produces the following interesting diagnostics: ---- (COMMENT **** FOO Has been previously used with wrong number of arguments in function BAR) (COMMENT **** (FOO) have been used but remain undefined in this file) ---- What in the world does that first one mean? Obviously complr is deciding something on the basis of the ARGS of FOO. However, it is NOT deciding to use the fact that FOO is defined as an LSUBR to do anything--BAR calls FOO using standard subr calling-sequence. An even more amusing demonstration of this schizophrenia can be demonstrated by the following perturbation: ---- (eval-when (compile) ;This time, FOO is an lsubr taking from 1 to 1 args, and it returns that one. (lap-a-list '((lap foo lsubr) (args foo (1 . 1)) (pop p a) (jrst 0 pdlnkj) nil))) (declare (*expr foo)) (defun bar (x) (foo x)) ---- which produces the following pack of lies: ---- (COMMENT **** FOO Has been previously used with wrong number of arguments in function BAR) (COMMENT **ERROR** (FOO X) Wrong number of args in function BAR) ; DATA ERROR - TO PROCEED TYPE $P (COMMENT **** (X) Unused LAMBDA variables in function BAR) (COMMENT **** (BAR) - Failed to compile) ---- Why is this, you might ask? FOO now takes from 1 to 1 args, and it was given exactly one arg. And for the single call to FOO, i am being told BOTH that it was PREVIOUSLY given the wrong number of args (implying that the current call has the correct number?), and that the current call has the wrong number of args. (Note that i'm not told about not declaring FOO -- the call to it was deleted.) Got me. I bet that complr is doing something like getting (1 . 1) and assuming it is a fixnum because of the *EXPR declaration. ---- So what should complr do? There are (at least) 5 situations of interest: (1) There is no in-core definition, and no declaration info. (2) There is no in-core definition, but declaration info was given. (3) There is an in-core definition, and no declaration info. (4) There is an in-core definition, and consistent declaration info. (5) There is an in-core definition, and differing declaration info. The first 2 are handled consistently already; it is the last three where the problems arise. (Also, i am assuming that "in-core definition" includes args-info when possible.) (3) probably the declaration info should be defaulted from the in-core definition. This is not actually unreasonable, since (1) the private stuff in complr is already insulated on another obarray and (2) the other stuff which is NOT is going to be part of packages which the user will be exposed to anyway. (4) No difference, really. There is no documented way to tell the compiler how many arguments a function takes. In both this situation and the one above, if there is argsinfo for the function, the compiler should issue a diagnostic (correctly phrased), but NOT abort the compilation or consider it to be in error. (Unless of course the user could declare the number of args and that was what differed.) (5) If (say) the function is an LSUBR and the user declares it *EXPR, then all in-core definition info should be ignored absolutely and the declaration info treated as in case (2). Additional sophistication can be introduced by having the compiler be able to distinguish between user declarations and those it has made itself because it compiled the function.  Date: 4 November 1981 14:34-EST From: Kent M. Pitman To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC, wjl at MIT-ML Date: 30 October 1981 11:28-EST From: Jon L White To: wjl at MIT-ML cc: BUG-COMPLR WJL@MIT-ML 10/29/81 09:18:41 To: (BUG COMPLR) at MIT-ML Is it possible to get the complr to give an error message when a mapping function is given a macro as the functional argument? If its a case of something like (MAPC X (...some-list...)) then X isn't evaluated until runtime, and there is of course no way the COMPLR can check anything. But if its a case of something like (MAPC (some-macro ...) (...some-list...)) then the COMPLR should expand the macro call and try again; it's a bug that it doesn't do so now, and will be fixed in the next dump of COMPLR (probably over the weekend). ----- I suspect that the bug is more like (MAPCAR #'F ...) or (MAPCAR 'F ...) where the compiler does not complain that F is undefined and where no macroexpansion is possible... the result is that the file compiles normally. I think perhaps if you noted that a non-macro definition of F was needed and kept the F in the list of undefined functions, that would be pretty helpful. It would probably be possible to keep enough info around to know that F had been mapped and indicate to the user that since F was defined as a macro, he was losing for not having given a subr definition or a *expr/*lexpr/(shudder)*fexpr declaration.  Date: 30 October 1981 11:28-EST From: Jon L White To: wjl at MIT-ML cc: BUG-COMPLR at MIT-MC WJL@MIT-ML 10/29/81 09:18:41 To: (BUG COMPLR) at MIT-ML Is it possible to get the complr to give an error message when a mapping function is given a macro as the functional argument? If its a case of something like (MAPC X (...some-list...)) then X isn't evaluated until runtime, and there is of course no way the COMPLR can check anything. But if its a case of something like (MAPC (some-macro ...) (...some-list...)) then the COMPLR should expand the macro call and try again; it's a bug that it doesn't do so now, and will be fixed in the next dump of COMPLR (probably over the weekend).  JONL@MIT-MC 10/30/81 11:20:50 To: EAK at MIT-MC CC: (FILE MC:LSPMAI;BUG COMPLR) at MIT-MC Date: 30 October 1981 02:02-EST From: Earl A. Killian Why does function TEST3 push A and B when TEST1 and TEST2 don't? It must think the values are going to be needed after the call to FOO. (defun test1 (a b) (foo a b)) (defun test2 (a b) (foo b a)) (defun test3 (a b) (if (< a b) (foo a b) (foo b a))) That's not quite it -- although this might at first appear to be a matter of tail-recursion, the COMPLR doesn't try to be general about it. There are two "tricks" that COMPLR uses here: 1) If the lambda variables are all used within their first "lifetime" [roughly, no updating operations or function calls intervening] then there is no need to provide stack homes for them; 2) If the last few instructions of compiled code are merely a function call and stack-level fixups, then (modulo stack-allocated arguments to the function call) they can be re-orderd to do the fixups first and the function call can be made "tail-recursive". TEST3 satisfies neither rule. Even if tail-recursiveness were fully analyzed, it still wouldn't fit into rule 1 because the notion of "lifetime" extends over both calls to FOO [i.e., much more analysis than rule 1 would be needed to make it work "right"].  WJL@MIT-ML 10/29/81 09:18:41 To: (BUG COMPLR) at MIT-ML Is it possible to get the complr to give an error message when a mapping function is given a macro as the functional argument? That would be a help in debugging. -Bill Long  Date: 5 October 1981 17:39-EDT From: Richard L. Bryan To: BUG-COMPLR at MIT-MC In a bare CL, the following symbols have SPECIAL properties: CLASS OBJECT SEQUENCE STRUCT STRUCT=INFO VECTOR Note that symbols with the above names suffixed with "-CLASS" are also special, e.g. VECTOR-CLASS.  Date: 23 September 1981 17:16-EDT From: Jon L White To: ALAN at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 21 September 1981 00:59-EDT From: Alan Bawden I just noticed that I was using XCOMPL to produce that bug if it makes any difference. COMPLR is currently claiming to be version 1123 whereas XCOMPLR claims to be 1121??!?!? I just installed a link which makes XCOMPLR^K get the latest COMPLR -- if there is a true XCOMPLR in the future, it will supersede the link.  Date: 21 September 1981 00:59-EDT From: Alan Bawden Subject: Re: My last message. To: BUG-COMPLR at MIT-MC Wonderful. I just noticed that I was using XCOMPL to produce that bug if it makes any difference. COMPLR is currently claiming to be version 1123 whereas XCOMPLR claims to be 1121??!?!? I just checked and COMPLR loses just like XCOMPLR.  Date: 21 September 1981 00:22-EDT From: Alan Bawden Subject: Old bug returns? To: BUG-COMPLR at MIT-MC The file ALAN;LOSS 1 and LOSS LAP exhibit a bug that I thought was stomped out in some form some time ago. This is the bug where calling a function like (displace foo ) causes the value of the hairy expression to get lost. This fragment shows how the second argument to OLD-GOAL (see file) sometimes gets to be incorrect: ... (JCALL 16 'REPORT) ;Loads A with NIL, but it shouldn't matter. G0008 (MOVE 2 0 P) ;The correct 2nd argument is cleverly moved into B! (JRST 0 G0006) ... G0006 (SUB P (% 0 0 1 1)) (MOVEI 2 0 1) ;But somebody expected to find it in A... (POP P 1) ;Correct 1st arguemnt. (CALL 2 'OLD-GOAL) ...  Date: 18 September 1981 00:00-EDT From: David C. Plummer To: BUG-COMPLR at MIT-MC Compile the file with (eval-when (compile) (load '((lisp) string))) (defmacro foo () '(string-append "foo" " bar")) in it. It compiles without error. Now try loading the FASL into the current vanilla XLISP. It gives the error ;((DSK LISP) STRING FASL) INCORRECTLY NESTED FASLOAD ;BKPT FAIL-ACT First of all, I don't understand what is going on. Second, whatever it is, it should probably be fixed. The code does not specify that a load should take place at LOAD time, yet it appears somebody is disobeying.  Date: 6 September 1981 02:05-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-COMPLR at MIT-MC For an example of our favorite compiler merrily bashing things on FXP search for "COMPLR" in FLAVOR;HASHTA >. This lossage cost me a couple hours to track it down.  Date: 2 September 1981 18:34-EDT From: Jon L White Subject: Refinements for local declaration capabilities? To: gsb at MIT-ML cc: BUG-COMPLR at MIT-MC GSB@MIT-ML 09/02/81 16:40:07 Re: come come now To: (BUG COMPLR) at MIT-ML The following works, and i claim that it should: (defun foo (x) (declare (flonum x)) ((lambda (x) (declare (fixnum x)) (* x x)) (fix (1+$ x)))) There is no rational reason to disallow NOTYPE declarations here ... While a local flonum/fixnum declaration seems to override a global fixnum/flonum declaration, a local notype declaration doesn't seem to have much effect. As GSB, MOON, KWC, and I discussed verbally, what seems to be needed is a further refinement of the MacLISP local declaration capability -- one whereby the user can specify whether a declaration is to be "inherited" by sub-contours or not. In any case, the original MacLISP declaration scheme didn't promise much in the way of locally-overriding declarations, so some work would have to be done.  GSB@MIT-ML 09/02/81 16:40:07 Re: come come now To: (BUG COMPLR) at MIT-ML The following works, and i claim that it should: (defun foo (x) (declare (flonum x)) ((lambda (x) (declare (fixnum x)) (* x x)) (fix (1+$ x)))) There is no rational reason to disallow NOTYPE declarations here either. I suspect the problem with the 3-deep rebinding/declaration has something to do with the handling of the renamelist (RNL) in declaration processing, rather than with the declaration mechanism itself. The reason i suspect this is that at the point the lossage occured in (defun foo (x) (declare (notype x)) ((lambda (x) (declare (notype x)) ((lambda (x) (declare (notype x)) (quux x x)) (baz x x))) (bar x x))) there was not a new entry pushed on RNL for the innermost X: the G0001 it showed was the renaming for the middle X. Am i correct in assuming that the innermost X would have eventually been named to something distinct?  Date: 2 September 1981 15:33-EDT From: Jon L White Subject: local declarations in COMPLR To: kwc at MIT-ML cc: BUG-COMPLR at MIT-MC Date: 1 September 1981 23:53-EDT From: Glenn S. Burke Sender: KWC at MIT-ML (defun foo (x) (declare (notype x)) ((lambda (x) (declare (notype x)) . . . (quux x x)) (baz x x)) (bar x x)) produces the lossage (COMMENT **ERROR** (NOTYPE G0001) Local declaration occurs too late in function in function FOO) . . . I had expected lossage like this for changing types, but not for simple same-type NOTYPE declarations! Actually, the original MacLISP notes on COMPLR declarations mention that one cannot re-declare by nesting -- the outermost scope (except for global declarations) takes precedence. I'm a little amazed that the notype declaration is even acceptable as a local declaration, since it can't override any "outer" declarations.  Date: 1 September 1981 23:53-EDT From: Glenn S. Burke Sender: KWC at MIT-ML Subject: give me a break To: BUG-COMPLR at MIT-ML cc: KWC at MIT-ML (defun foo (x) (declare (notype x)) ((lambda (x) (declare (notype x)) ((lambda (x) (declare (notype x)) (quux x x)) (baz x x))) (bar x x))) produces the lossage (COMMENT **ERROR** (NOTYPE G0001) Local declaration occurs too late in function in function FOO) Examination of the stack (of a similar and much more complicated example) indicates that the losing declaration is the innermost one; i.e., it takes multiple nestings for this to lose. I had expected lossage like this for changing types, but not for simple same-type NOTYPE declarations!  Date: 26 August 1981 16:00-EDT From: Jon L White To: RWK at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 24 August 1981 15:15-EDT From: Robert W. Kerns Will you kindly build a new COMPLR with a reasonbly recent SETF already? I'd do it myself but this delay makes me think there may be some unsolved problem I don't know about. I announced the new XLISP/XCOMPLR several weeks ago, which has the new SETF stuff in it. Possibly its about time for the change from XLISP/XCOMPLR to LISP/COMPLR?  Date: 24 August 1981 15:15-EDT From: Robert W. Kerns To: BUG-COMPLR at MIT-MC Will you kindly build a new COMPLR with a reasonbly recent SETF already? I'd do it myself but this delay makes me think there may be some unsolved problem I don't know about.  Date: 21 August 1981 20:48-EDT From: Jon L White Subject: LAP and LAP-A-LIST with missing () at end To: zubkoff at CMU-20C cc: BUG-COMPLR at MIT-MC I've fixed the MAKLAP and FASLAP files to handle this user bug correctly now -- will be in the ITS dumped complr version 1121. I'll be moving this stuff to XX, so that by early next week, it will be possible for you to retrieve all the fasl files from there too, and perhaps give the new stuff another try at CMUC. No new functions per se, but bug repairs made since May.  Date: 21 August 1981 20:21-EDT From: Jon L White Subject: TTYNOTES-FUNCTION To: BIL at MIT-MC cc: BUG-COMPLR at MIT-MC, "(FILE [LISP;NEW RECENT])" at MIT-MC Ok, so this now works as we discussed -- namely if a symbol has a TTYNOTES-FUNCTION property, then that is assumed to be some function which when applied to the symbol will either return a re-nameing of it for the unfasl and ttynotes purposes, or will return () meaning "I've alredy outputted all the msgs I care to see". This works in MAKLAP 80, which will be in the next installed version of COMPLR (probably version 1122). Currently it doesn't support the re-naming for break-point error msgs, but I'll try to remember to look into this.  Date: 15 August 1981 13:25-EDT From: Jon L White To: WGD at MIT-MC cc: JPG at MIT-MC, BUG-COMPLR at MIT-MC Date: 14 August 1981 23:48-EDT From: William G. Dubuque The current complr has setf version 288 loaded, which has problems trying to expand a push in flavor;flav1 >. The problem goes away when the most current setf is loaded. Use XCOMPLR. Probably sometime middle of next week, we should convert XLISP into LISP, and dump out a new COMPLR in latest stuff.  Date: 14 August 1981 23:48-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-COMPLR at MIT-MC The current complr has setf version 288 loaded, which has problems trying to expand a push in flavor;flav1 >. The problem goes away when the most current setf is loaded.  Date: 13 August 1981 14:46-EDT From: Jon L White Subject: Missing COMPLR on AI To: gsb at MIT-ML cc: BUG-COMPLR at MIT-MC, tlp at MIT-AI GSB@MIT-ML 08/12/81 16:11:39 Re: missing installation? I installed COMPLR 1115 on AI, and deleted the link you had made. This is the one installed on ML and MC (for some time now); it starts up fine. If you prefer to use the one you had linked COMPLR to you can use XCOMPLR instead. Possibly someone had deleted the dump of 1115 on AI by accident? Anyway, it was I that put the link to XCOMPLR there, using TLP's terminal because the load on AI was so heavy most of yesterday afternoon that I couldn't even login (let along FTP anything).  GSB@MIT-ML 08/12/81 16:11:39 Re: missing installation? To: TLP at MIT-AI CC: (BUG COMPLR) at MIT-MC I installed COMPLR 1115 on AI, and deleted the link you had made. This is the one installed on ML and MC (for some time now); it starts up fine. If you prefer to use the one you had linked COMPLR to you can use XCOMPLR instead.  TLP@MIT-AI 08/12/81 13:58:06 To: (BUG COMPLR) at MIT-AI The COMPLR on AI is busted. It is version 1114, rather than version 1115, which runs on MC. Are things in an inconsistent state or what? BTW it dies on an MPV, apparently before getting to actually look at the input file. Tomas  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.  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  Date: Tuesday, 28 July 1981, 18:05-EDT From: Robert W. Kerns To: WGD at MIT-MC Cc: BUG-COMPLR at MIT-MC In-reply-to: The message of 28 Jul 81 06:07-EDT from William G. Dubuque Date: 28 July 1981 06:07-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-COMPLR at MIT-MC Current COMPLR is dumped out with version 288 of SETF; it should have version 290 since the former is buggy (e.g. try compiling flavor;addmth >). This was due to your having a bogus DEFSETF in your file, but indeed, COMPLR should be made current.  Date: 28 July 1981 06:07-EDT From: William G. Dubuque Sender: BIL at MIT-MC To: BUG-COMPLR at MIT-MC Current COMPLR is dumped out with version 288 of SETF; it should have version 290 since the former is buggy (e.g. try compiling flavor;addmth >).  Date: Friday, 24 July 1981, 13:59-EDT From: Robert W. Kerns To: DICK at MIT-ML Cc: (BUG COMPLR) at MIT-ML, JONL at MIT-MC In-reply-to: The message of 21 Jul 81 22:18-EDT from DICK at MIT-ML DICK@MIT-ML 07/21/81 22:18:11 To: (BUG COMPLR) at MIT-ML, JONL at MIT-MC the following warning about DEFSETF suddenly appeared today without my changing anything in my programs. Also I don't get it when the same files are loaded in lisp 2100 itself. I wonder if you could tell me more about what it means, so that I could figure out what I am doing wrong. Dick Waters '(THIS IS THE UNFASL FOR ((DSK FORPAS) VIEW /455)) '(ASSEMBLED BY FASLAP /390) '(COMPILED BY LISP COMPILER /933 COMAUX /25 PHAS1 /80 MAKLAP /77 INITIA /111) ;COMPILED ON TUESDAY, JULY 21, 1981, AT 10:05 PM ;Loading GPRINT 526 ;Loading DEFSETF 99 ;Warning! Incompatibly redefining the structure SETF ; Methods will not be preserved in the newly-created class. (COMMENT **FASL** 0. (LAP TV:BEEP SUBR)) (COMMENT **FASL** 2. (LAP |@CAR MACRO| SUBR)) etc. There is no problem here. COMPLR needs to be re-built sometime, since it is dumped with an old version of SETF, but the only incompatibility is this message. However, if you compiled a DEFSETF before this afternoon, you should recompile it, because of an unrelated bug.  DICK@MIT-ML 07/21/81 22:18:11 To: (BUG COMPLR) at MIT-ML, JONL at MIT-MC the following warning about DEFSETF suddenly appeared today without my changing anything in my programs. Also I don't get it when the same files are loaded in lisp 2100 itself. I wonder if you could tell me more about what it means, so that I could figure out what I am doing wrong. Dick Waters '(THIS IS THE UNFASL FOR ((DSK FORPAS) VIEW /455)) '(ASSEMBLED BY FASLAP /390) '(COMPILED BY LISP COMPILER /933 COMAUX /25 PHAS1 /80 MAKLAP /77 INITIA /111) ;COMPILED ON TUESDAY, JULY 21, 1981, AT 10:05 PM ;Loading GPRINT 526 ;Loading DEFSETF 99 ;Warning! Incompatibly redefining the structure SETF ; Methods will not be preserved in the newly-created class. (COMMENT **FASL** 0. (LAP TV:BEEP SUBR)) (COMMENT **FASL** 2. (LAP |@CAR MACRO| SUBR)) etc.  Date: 1 July 1981 16:49-EDT From: George J. Carrette To: BUG-COMPLR at MIT-MC cc: JPG at MIT-MC Use MCL to compile the file MAXSRC;SYNEX 9. You get a PURPG; error.  Date: 30 June 1981 22:45-EDT From: Jon L White Subject: #, To: BROOKS at CMU-20C cc: BUG-COMPLR at MIT-MC, scott.fahlman at CMU-10A, steele at CMU-20C, dill at CMU-20C, scherlis at CMU-20C, gabriel at CMU-20C I believe you have run upon a deficiency in the compilation of CASEQ rather than any problem with the #, notation: Date: 29 Jun 1981 1016-EDT From: BROOKS at CMU-20C . . . that simple code which works interpreted won't work compiled. E.g. (eval-when (compile eval load) (setq foo 3)) (defun baz (x) (caseq x ((2 4) 'even) ((1 #,foo) 'odd) (t 'too-big))) fails to compile as the second clause of the case gets read as ((1 (SQUID FOO)) 'ODD) The reason that this is a COMPLR deficiency is that COMPLR insists on certifying that the comparators are either all symbols, or all fixnums. Obviously, whatever internal form #,foo will take, it won't pass this test. 2. In S-1 LISP at least, the rationale for the "feature" does not hold as the list-structure to fasl and fasl to list-structure code is able to correctly handle arbitrarily circular structures (which are not printable). I trust SPICE lisp will also be able to handle such. There is then no need for the SQUID feature. The need for the SQUID feature is only exemplified by the creation of circular structures -- more generally, it is for the insertion of "constants" into the code which cannot be determined at compile time. Many persons were merely using lots of SPECIAL variables to hold such constants, and thought it is marginally faster to use the constant directly, it is the expressivity of the code which is the more important factor. Just for the record, you can circumvent the above-mentioned deficiency by writing the function as (defun baz (x) (cond ((or (= x 1) (= x #,foo)) 'odd) ((or (= x 2) (= x 4)) 'even) (t 'too-big))) Probably COMPLR should be fixed.  Date: 26 June 1981 06:52-EDT From: Jeffrey P. Golden To: BUG-COMPLR at MIT-MC Loading up a fresh COMPLR gives a Warning about incompatibly redefining the structure STRUCT=INFO.  Date: 20 June 1981 14:16-EDT From: Edward Barton Subject: XX complr weirdness To: JONL at MIT-MC cc: EB at MIT-AI, BUG-COMPLR at MIT-MC Date: 15 June 1981 13:16-EDT From: Jon L White This didn't happen for me: Date: 13 Jun 1981 1528-EDT From: GUEST at MIT-XX cc: EB at MIT-AI @complr LISP COMPILER 1113 [in LISP 2117] _ps:undot.lsp ;when I type a carriage-return, I get a control-T message -- ; COMPLR IO wait at 47270 Used 0:00:01.3 in 0:00:18, Load 1.62 ; when I type CR again, I get ((DSK GUEST) |eudot| |l| *) - File Not Found - MAKLAP ; which is not the filename I typed Similar weirdness if I type control-L during the filename. I typed everything exactly as you did, but got no control-T message; furthermore, the error from the complr was ((|ps| |guest|) undot lsp *) - File not Found - MAKLAP Is there something weird about the terminal you are using? I can't reproduce this on a net connection, but I tried it again last night on a directly connected line to XX (the VT52 by the CPU). Sure enough, I got exactly the weirdness I described. Note that characters come out right as they echo, though that doesn't seem to correspond to COMPLR's idea of them.  Date: 15 June 1981 13:16-EDT From: Jon L White Subject: XX complr weirdness To: EB at MIT-AI cc: BUG-COMPLR at MIT-MC This didn't happen for me: Date: 13 Jun 1981 1528-EDT From: GUEST at MIT-XX cc: EB at MIT-AI @complr LISP COMPILER 1113 [in LISP 2117] _ps:undot.lsp ;when I type a carriage-return, I get a control-T message -- ; COMPLR IO wait at 47270 Used 0:00:01.3 in 0:00:18, Load 1.62 ; when I type CR again, I get ((DSK GUEST) |eudot| |l| *) - File Not Found - MAKLAP ; which is not the filename I typed Similar weirdness if I type control-L during the filename. I typed everything exactly as you did, but got no control-T message; furthermore, the error from the complr was ((|ps| |guest|) undot lsp *) - File not Found - MAKLAP Is there something weird about the terminal you are using?  Date: Sunday, 14 June 1981, 19:07-EDT From: Robert W. Kerns To: SGR at MIT-MC Cc: BUG-COMPLR at MIT-MC In-reply-to: The message of 13 Jun 81 13:36-EDT from Stephen G. Rowley Date: 13 June 1981 13:36-EDT From: Stephen G. Rowley To: BUG-COMPLR at MIT-MC when trying to compile a program, the complr immediately came forth with: MPV; 127362>>SKIPL 4000(7) 505616/ ?? I cannot reproduce this without any useful information. Perhaps you would consider including such details as what file you were trying to compile when you submit your bug reports?  Date: 13 Jun 1981 1528-EDT From: GUEST at MIT-XX Subject: XX complr weirdness To: Bug-Complr at MIT-MC cc: EB at MIT-AI @complr LISP COMPILER 1113 [in LISP 2117] _ps:undot.lsp ;when I type a carriage-return, I get a control-T message -- ; COMPLR IO wait at 47270 Used 0:00:01.3 in 0:00:18, Load 1.62 ; when I type CR again, I get ((DSK GUEST) |eudot| |l| *) - File Not Found - MAKLAP ; which is not the filename I typed Similar weirdness if I type control-L during the filename. -------  Date: 13 June 1981 13:36-EDT From: Stephen G. Rowley To: BUG-COMPLR at MIT-MC when trying to compile a program, the complr immediately came forth with: MPV; 127362>>SKIPL 4000(7) 505616/ ??  Date: 12 June 1981 21:29-EDT From: Stephen G. Rowley To: BUG-COMPLR at MIT-MC I got the following error message: ILOPR; 1653>>200,,75073 4/ 0 75073/ 100126,,620552  Date: 7 June 1981 07:21-EDT From: Jeffrey P. Golden To: BUG-COMPLR at MIT-MC cc: JPG at MIT-MC In a fresh COMPLR: ^G (INITIALIZE) #-(OR ITS MULTICS) T Gives: ;Loading LOOP 705 ;THEREIS unknown keyword in LOOP macro .  Date: 5 June 1981 17:07-EDT From: George J. Carrette To: BUG-COMPLR at MIT-MC See the bug in MACSYMA;MACSYMA MAIL  Date: 5 June 1981 1015-EDT (Friday) From: Guy.Steele at CMU-10A To: Kent M. Pitman Subject: Unique lists? CC: alan at MIT-MC, dick at MIT-MC, bug-complr at MIT-MC In-Reply-To: Kent M. Pitman's message of 30 May 81 03:36-EST Message-Id: <05Jun81 101503 GS70@CMU-10A> While the reader does indeed cons fresh lists, it has always been implicit in my mind that quoted constants in code may be assumed to be read-only by the compiler (and therefore sharable). Maybe this needs to be made explicit. Maybe there needs to be a way to turn it off. While it apparently is a property only of FASLOAD and not of the compiler, in reality it is a property of the compiler because not all list structure loaded by FASLOAD is uniquized, but only those which the compiler has indicated as being used as constants by code. --Guy  Date: 4 June 1981 11:38-EDT From: George J. Carrette To: BUG-COMPLR at MIT-MC COMPILER-STATE looses because it is a special variable. (defun f () (bar 33)) (defmacro bar (X) (baz x)) (defmacro baz (y) (cond ((memq compiler-state '(maklap compile)) one-thing) ('else another-thing))) ; Now: (cl:cl f) When the macro BAZ gets called COMPILER-STATE is bound to COMPILE, yet the macro BAZ is NOT being called by the compiler, it is being called by the interpreter. Obviously the interpreter should always bind COMPILER-STATE to NIL when it funcall's a macro expander. -gjc  Date: 4 June 1981 06:00-EDT From: Jeffrey P. Golden To: GJC at MIT-MC, ADK at MIT-MC cc: BUG-COMPLR at MIT-MC, JPG at MIT-MC GJC@MIT-MC 06/03/81 18:18:10 To: ADK at MIT-MC (COMMENT **** (7. -2051.) PUSHPOP - RESTORE in function $SECTOR) I've never seen this error message before, could be bad news. I think it may not be bad news, but JONL may be interested in it anyway. I believe it means that the function RESTORE in COMPLR found a useless PUSH, i.e. one followed immediately by the complementary unPUSHing POP.  Date: 3 June 1981 00:07-EDT From: Jon L White Subject: BUG-OF-THE-DECADE! To: GSB at MIT-MC cc: BUG-COMPLR at MIT-MC GSB@MIT-ML 06/02/81 19:53:50 Re: Talk about slow no-ops (defun frobnicate (name &aux (c 0)) (map '(lambda (x) (and (not (< (setq c (car x)) #/a)) (not (> c #/z)) (rplaca x (- c 32.)))) (exploden name))) The above function calls EXPLODEN twice. It maps over one, but the map returns the other, which has not been uppercasified. Fixed by patch 1112. By the way, this has gotta be the "bug of the decade, since I believe this "feature" has been around for 10 years at least.  GSB@MIT-ML 06/02/81 19:53:50 Re: Talk about slow no-ops To: (BUG COMPLR) at MIT-ML (defun frobnicate (name &aux (c 0)) (declare (fixnum c)) (pnget (maknam (map '(lambda (x) (and (not (< (setq c (car x)) #/a)) (not (> c #/z)) (rplaca x (- c 32.)))) (exploden name))) 7)) --- The above function calls EXPLODEN twice. It maps over one, but the map returns the other, which has not been uppercasified.  Date: 30 May 1981 16:56-EDT From: Alan Bawden Subject: still not convinced To: KMP at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 30 May 1981 04:36-EDT From: Kent M. Pitman Your statement that people would never write such programs is not really relevant. Compilers should, as much as possible, make correct mappings from interpreted code to compiled code... any code the user cares to write, not just code the compiler writer wanted him to write. [It is TOO relevant, you just don't happen to agree with it!] "as much as possible"? Then why doesn't complr run in (declare (setq special t)) mode all the time? Because we agree with the compiler writer that code that neads this switch to compile correctly is "unnatural", and we agree that we should have to explicitly inform the compiler of all our special variables. Now the current discussion is not going to be settled by any general sounding rules such as you have proposed here. It is going to be settled as a compromise between the "naturalness" of the screw cases you generate, and the gains the hack buys us. The more natural a screw case you can generate, the less we should be willing to put up with the hack. The more gains that JPG (or whoever) can point out, the more we should be willing to put up with it. Clearly, doing (EQ '(A B C) '(A B C)) seems silly to you, but suppose instead we have the following isomorphic case (DEFUN NCONS-GENERATING-SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(READ)) ((READ) '(NIL)))) (SETQ NCONS-GENERATOR-STREAM (SFA-CREATE 'NCONS-GENERATING-STREAM 0 "(NIL)")) and then suppose you pass this to some other program which does the well-known hack of: (DEFUN READ-FORMS-UNTIL-EOF (STREAM) (LET* ((EOF '(NIL)) (FORM (READ STREAM EOF))) (IF (EQ FORM EOF) NIL (CONS FORM (READ-FORMS-UNTIL-EOF STREAM))))) Well this is a MUCH better example of a screw case than the last. But I am still not convinced. I have been writing (let ((eof (list 'eof))) ...) all along without really knowing why. I guess there is something unflavorfull to me about wanting a unique object like this, and NOT consing it up.  Date: 30 May 1981 12:15-EDT From: Glenn S. Burke Subject: constant list structure To: BUG-COMPLR at MIT-MC cc: DICK at MIT-MC For one, none of this stuff really is bug-complr material, as the uniquization happens at load time and is totally within the domain of fasload and its subsidiary gcprotect. The ruin-constant-list example would get a write-in-read-only error if the stuff were loaded in with *PURE set to T and the lisp then purified. Presumably dick's blowup occurs inside of gcprotect, which uniquizes with sxhash and equal. This feature can be turned off dynamically by hacking the value of GCPROTECT; if it is not NIL then this uniquization process will not be performed (nor will the purification of stuff so uniquizied). Note also that the the circular list cannot be purified, because that involves a copying operation. I believe this flag was implemented for XLMS or one of its predecessors; interestingly, the current implementation of XLMS no longer uses this, because XLMS nodes (and other objects) are user-hunks and support EQUAL and SXHASH, and no longer blow up because they are circular. Brand-X does need to set GCPROTECT, however, because it uses a more lisp-like recurse-through-the-components definition of EQUAL. I'm also not even sure that this really is a maclisp-only problem; other lisp implementations presumably have to remember structure referenced from compiled code somewhere, and it seems to me that uniquization of equal structure is very tempting. I believe lispm does this on a per-function basis. And the types of data to which arguments about uniquizing applies really are only composite ones; lists, hunks (when they are not in fact logically atomic, as are "strings"). I doubt, for example, that there would be any argument that there is harm in uniquizing numbers of any type referenced from compiled code.  Date: 30 May 1981 04:36-EDT From: Kent M. Pitman To: ALAN at MIT-MC cc: DICK at MIT-MC, BUG-COMPLR at MIT-MC One of the things violated is the fact that lists which are read is unique. People are used to the idea that (SETQ A '(A B C)) (SETQ B '(A B C)) (RPLACA A 'D) (CAR A) => D (CAR B) => A So it can be just plain confusing (and yes, I have seen people make this mistake) when the compiler compiles something like (DEFUN CONSTANT-LIST () '(A B C)) (DEFUN SETUP-A () (SETQ A '(A B C))) (DEFUN RUIN-CONSTANT-LIST () (SETUP-A) (RPLACA A 'D) (CONSTANT-LIST)) Note that interpreted (RUIN-CONSTANT-LIST) does not bash (CONSTANT-LIST), but compiled it does. This sort of lossage is exceedingly difficult to track down. It is worse when you don't know someone is RPLACA'ing something and when the effect shows up in a totally unrelated piece of code that happens only by coincidence to have the same constant list in it. I agree that squids and this unique-izing trick are probably not really incompatible. I spoke with Jonl and he said there is (undocumented) control of the process which GSB is already making use of somehow or other. I also think that while this may buy some small amount of space, it's not clear to me that it's worth it ... There are thousands of places in Macsyma where things like (CONS '(MLIST) ...) are done where I would prefer to see (MAKE-MLIST ...) and let MAKE-MLIST retrieve the constant element from some table. JPG has hit me with the argument that (CONS '(MLIST) ...) is more storage efficient and less code, so (alas) the progress of abstracting data structures in Macsyma fails to move faster because of this crockish guarantee by Maclisp ... I just don't see the point in trying to save space this way. There are many more-worthwhile and less-opaque ways that large programming systems (certainly Macsyma) could save space than by having daemons running around making random pieces of constant structure unique. These arguments are not intended to sound purist. The question is less one of that Lisp should or shouldn't do a certain thing than it is one of that the compiler and the interpreter should, wherever possible, agree. This is a case where there's clearly lots of occasion for code to run radically differently. Your statement that people would never write such programs is not really relevant. Compilers should, as much as possible, make correct mappings from interpreted code to compiled code... any code the user cares to write, not just code the compiler writer wanted him to write. Clearly, doing (EQ '(A B C) '(A B C)) seems silly to you, but suppose instead we have the following isomorphic case (DEFUN NCONS-GENERATING-SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(READ)) ((READ) '(NIL)))) (SETQ NCONS-GENERATOR-STREAM (SFA-CREATE 'NCONS-GENERATING-STREAM 0 "(NIL)")) and then suppose you pass this to some other program which does the well-known hack of: (DEFUN READ-FORMS-UNTIL-EOF (STREAM) (LET* ((EOF '(NIL)) (FORM (READ STREAM EOF))) (IF (EQ FORM EOF) NIL (CONS FORM (READ-FORMS-UNTIL-EOF STREAM))))) Now what happens when we do (READ-FORMS-UNTIL-EOF NCONS-GENERATOR-STREAM). I haven't run this code, but would suspect this gives a PDL-OVERFLOW in the interpreter and just NIL when run compiled... Why? Those (NIL)'s coming out of the NCONS-GENERATING-STREAM are gonna look an awful lot like the EOF object picked by READ-FORMS-UNTIL-EOF, which one would have hoped was an unrelated, function. Bad enough we have to worry about the dynamic scope of our variables without even being able to have `lexically scoped' immediate data. Doesn't that seem significant to you? It seems thoroughly obnoxious to me! I'm still not saying the unique-izing should go away -- just that TO ME it is is obnoxious and painful and if I had it my way, I wouldn't want the feature...  Date: 30 May 1981 03:07-EDT From: Alan Bawden Subject: Lossage with #, To: KMP at MIT-MC cc: BUG-COMPLR at MIT-MC, DICK at MIT-ML Date: 29 May 1981 23:02-EDT From: Kent M. Pitman I will say that the unique-izing feature is provided as a hack to help minimize the amount of storage used by quoted constants and the amount of space which must be walked by the garbage collector... As such it violates a number of well-known lisp abstractions, which in my eyes is a bad thing, too. I guess I'm not surprised if bugs occasionally crop up. eg, consider: (DEFUN F () (G '(A B))) (DEFUN G (X) (EQ X '(A B))) where (F) returns NIL interpreted or T compiled. Sad, sad. What can I say? Well, this example is unreasonable. This is similar to the examples that show that "Lisp is a language that connot be compiled". The problem with those examples is always that nobody would EVER write code like that. That is the problem here as well, the function G does something that in practice is NEVER useful. (You might as well have just written (DEFUN F () (EQ '(A B) '(A B))), it is equally reasonable.) Now there may well BE reasonable examples where constant sharing can screw you, but this message doesn't convince me of their existence. (What is a "lisp abstraction" anyway? well-known or otherwise? Smacks of "Pure Lisp" and other such heresies to me!) The current "bug" isn't an example of an inherent problem with constant sharing (as far as I can tell), it's just a problem with the way it was implemented. Perhaps it can be shown that constant sharing doesn't mix well with SQUIDs (I doubt it), or perhaps just that SQUIDs and constant sharing are hard to do right (which I don't see either), in either case I would be happy to give up constant sharing. But lets not throw the ENTIRE thing away untill we have a screw case that isn't a crock!  Date: 29 May 1981 23:02-EDT From: Kent M. Pitman Subject: Lossage with #, To: DICK at MIT-ML cc: BUG-COMPLR at MIT-MC The problem with #, which you described is almost certainly a Maclisp-only bug. Hopefully Jonl will be able to tell you more better, but I don't see why the code you sent ought to lose even with unique-izing going on. If you find that this is not a trivially correctable bug, I would suggest addressing this discussion to Maclisp-Forum rather than Lisp-Forum, since it is not something of relevance to the full Lisp-Forum audience (which is intended to discuss topics of interest to Lisp users of all dialects). I will say that the unique-izing feature is provided as a hack to help minimize the amount of storage used by quoted constants and the amount of space which must be walked by the garbage collector... As such it violates a number of well-known lisp abstractions, which in my eyes is a bad thing, too. I guess I'm not surprised if bugs occasionally crop up. eg, consider: (DEFUN F () (G '(A B))) (DEFUN G (X) (EQ X '(A B))) where (F) returns NIL interpreted or T compiled. Sad, sad. What can I say?  Date: 29 May 1981 18:51-EDT From: Richard C. Waters To: BUG-COMPLR at MIT-ML, LISP-FORUM at MIT-ML further investiagation shows that #,form does uniquizing of the list returned by form. This just isn't going to work if form is circular unless it really does it right. I suggest that if nothing else it just stop doing uniquizing unless it is going to do it right! #. can continue to do uniquizing, so you can get the space savings if you want it. Dick Waters  DICK@MIT-ML 05/29/81 18:20:00 To: (BUG COMPLR) at MIT-ML If you compile the following: (defun foo () (let ((x (ncons nil))) (rplacd x x))) (defun bar () (list '#,(foo))) The complr doesn't complain, but when you try to fasload the result, you get an unrecoverable fixnum pdl overflow while BAR is being loaded. Dick Waters  DICK@MIT-AI 05/19/81 12:25:50 To: (BUG COMPLR) at MIT-AI the complr still gets a pure page vilation when trying to compile dick;gprint >! dick waters  Date: 12 May 1981 14:07-EDT From: Gail Zacharias Subject: mapc (?) bug To: BUG-COMPLR at MIT-MC cc: GZ at MIT-MC The code shown below works differently interpreted than compiled (the interpreter is correct). It appears that in the expression (mapc #'(lambda (tm) (setf (cxr i tm) expt)) (pform-to-ep coef vars))) [towards the end of pform-to-ep below] the second argument to mapc get evaluated twice when running compiled. (defun make-ev (vars) (let* ((var-no (length vars)) (v (makhunk (1+ var-no)))) (declare (fixnum var-no)) (do i 1 (1+ i) (> i var-no) (declare (fixnum i)) (rplacx i v 0)) v)) (defun pform-to-ep (pform vars &aux (i 0)) ;pform=(var expt coef expt coef ...) (declare (fixnum i)) (if (atom pform) (ncons (rplacd (make-ev vars) (cons pform 1))) (setq i (length (memq (car pform) vars))) (do ((ep nil) (ep-last nil coef) (p (cdddr pform) (cddr p)) (expt (cadr pform) (car p)) (coef (caddr pform) (cadr p)) ) ((null expt) ep) ;until run off end (setq coef (mapc #'(lambda (tm) (setf (cxr i tm) expt)) (pform-to-ep coef vars))) (if ep (nconc ep-last coef) (setq ep coef)) ) )) (defun test () ;sample arguments (pform-to-ep '($Y 3 1 0 ($X 2 1)) '($X $Y)))  Date: 30 April 1981 09:19-EST From: Jon L White To: REM at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 30 April 1981 02:32-EST From: Robert Elton Maas I notice that COMPLR has started complaining about (COND (FOO ...) (1 ...)) where 1 evaluates to itself which is non-null thus being an ELSE clause. . . . WELL, OK, THE NEXT DUMP OF THE COMPLR WILL LET THIS CASE EXPLICITLY GO THRU. BUT A "1" IN AN INTERIOR PART WILL GENERATE THE MSG; E.G. (COND (FOO ...) (1 ...) (BAR ...) ...) IS PROBABLY WRONG.  Date: 30 April 1981 02:32-EST From: Robert Elton Maas To: BUG-COMPLR at MIT-MC I notice that COMPLR has started complaining about (COND (FOO ...) (1 ...)) where 1 evaluates to itself which is non-null thus being an ELSE clause. Are you planning to change MacLISP or NIL so that numbers don't evaluate to themselves, or so that numbers aren't considered to be non-null for the sake of COND testing, or just hassling us poor programmers? Note that using 'T instead of 1 takes one more keystroke and in interpreted code takes an extra cell for the (QUOTE T), while T doesn't work in some strange LISPs that allow T to be rebound. I've changed my code to use 'T instead of 1 now, to avoid warning message from compiler.  WJL@MIT-ML 04/29/81 10:17:10 To: (BUG COMPLR) at MIT-ML Why doesn't the second definition of a function in a file deserve a comment (ie, a message when the y switch is on)?  GSB@MIT-ML 04/22/81 20:01:09 Re: my fxpdl is losing VERY BADLY To: (BUG COMPLR) at MIT-ML (declare (special *gchash-all-tables *gchash-fillarray *gchash-marker)) (defun make-gcable-hash-table (size) (declare (fixnum size)) (setq size (gchash-good-size size)) (let ((key-table (*array nil nil size)) (val-table (*array nil t size))) (let ((gchash (hunk *gchash-marker (fillarray key-table *gchash-fillarray) (fillarray val-table *gchash-fillarray) 1.3 size (// size 16.) 'gchash-rehash 0.))) (push gchash *gchash-all-tables) gchash))) Look at the code produced for the pushes of "size" and "(// size 16.)".  Date: 19 April 1981 17:48-EST From: Jon L White Subject: "I thought this had been fixed." To: gsb at MIT-ML cc: BUG-COMPLR at MIT-MC GSB@MIT-ML 04/17/81 18:01:15 . . . Even better is the following: (defun (^ foo bar) (x) x) (defun test (n) (^ n)) One discovers that not only does it complain incorrectly, it removes the args information. Well, this at least is fixed in XCOMPLR version 1110.  Date: 19 April 1981 13:26-EST From: Jon L White To: ALAN at MIT-MC cc: BUG-COMPLR at MIT-MC 'fraid so: Date: 18 April 1981 12:26-EST From: Alan Bawden (defun foo (a quote b) (list a quote b)) (COMMENT **ERROR** QUOTE Can't be used as a variable - you lose. in function FOO) Bullshit. What's more, the simple variable "T" will also cause barfage at you (and only after many years of MacLISP life did the interpreter enforce this also.) Use NIL in order to use "NIL".  EB@MIT-AI 04/18/81 21:26:15 To: GJC at MIT-MC CC: (BUG COMPLR) at MIT-MC XCOMPLR on AI does indeed have my ATOMIC SYMBOL REQUIRED bug fixed.  Date: 18 April 1981 18:53-EST From: George J. Carrette Subject: COMPLR BUG To: EB at MIT-MC cc: BUG-COMPLR at MIT-MC That ATOMIC SYMBOL REQUIRED error you are getting is probably the same one I got. It is fixed in XCL, and it isn't detected in CL if you compile with *RSET NIL. Give it a try.  DICK@MIT-AI 04/18/81 16:03:58 To: (BUG COMPLR) at MIT-AI when compiling ai:dick;gprint 49 (this loads two other files from ai too) complr 1106 gets a pure page violation while compiling the last fn in the file. Everything works purfectly in complr 1063. I have no idea what is going on at all, hopefully it will be clear to you when you look at it. Dick Waters  Date: 18 April 1981 12:26-EST From: Alan Bawden To: BUG-COMPLR at MIT-MC In XCOMPLR: (defun foo (a quote b) (list a quote b)) (COMMENT **ERROR** (QUOTE FROM (A QUOTE B)) Not permissible in bound variable list in function FOO) ; DATA ERROR - TO PROCEED TYPE $P (COMMENT **ERROR** QUOTE Can't be used as a variable - you lose. in function FOO) ; DATA ERROR - TO PROCEED TYPE $P Bullshit.  EB@MIT-AI 04/18/81 02:08:54 To: (BUG COMPLR) at MIT-AI On AI, see EB;BUG30 SAVE which gets ;((FILE . G00115) (C . G0014)) ATOMIC SYMBOL REQUIRED Lisp error during file compilation. See BUG30 UNFASL. See also BUG31 SAVE, which compiles file, and BUG30 SRCCOM which contains the differences. Sorry to give you the whole file, but this bug has hit me several times in the past, I have never come up with a small example of it, and I am sick of it.  GSB@MIT-ML 04/17/81 18:01:15 To: (BUG COMPLR) at MIT-ML (COMMENT **** * Redefining system function in function *) (COMMENT **FASL** 1718. (LAP * FORMAT-CTL-MULTI-ARG)) I thought this had been fixed. I thought this had been fixed sometime before the last time i thought it was fixed, and maybe even once before that. Even better is the following: (defun (^ foo bar) (x) x) (defun test (n) (^ n)) One discovers that not only does it complain incorrectly, it removes the args information. I suppose i should be happy it doesn't complain that T is a verrry pooor choice of a function name.  GSB@MIT-ML 04/15/81 16:04:09 To: (BUG COMPLR) at MIT-ML CC: WJL at MIT-ML (expt guaranteed-flonum constant-fixnum) should get turned into ^$. There is no overflow or checking loss in doing so, and will be one less flonum cons.  JONL@MIT-MC 04/15/81 16:02:16 To: ALAN at MIT-MC CC: (BUG complr) at MIT-AI ALAN@MIT-AI 04/14/81 23:44:07 On AI tryind to run XCOMPLR gets: ;(OPEN #FILE-IN-|* *|-70762 (IN MPV; 15007>>HLRZ 1,(7) 1/ 640661 711014/ ?? Fixed -- twas due to a :INSTALL which made it for ML, but somehow didnt finishh for AI.  ALAN@MIT-AI 04/14/81 23:44:07 To: (BUG COMPLR) at MIT-AI On AI tryind to run XCOMPLR gets: ;(OPEN #FILE-IN-|* *|-70762 (IN MPV; 15007>>HLRZ 1,(7) 1/ 640661 711014/ ??  WJL@MIT-ML 04/10/81 10:55:12 To: (BUG COMPLR) at MIT-ML Why doesn't (+$ 1 (...)) give an error message?  Date: 5 April 1981 20:44-EST From: Jonathan A. Rees Subject: Twenex .FASL version number To: BUG-COMPLR at MIT-MC It would be nice if the complr could arrange for the FASL file to have the same version number as the source it's compiled from.  Date: 5 APR 1981 0030-EST From: JONL at MIT-MC (Jon L White) To: PSZ at MIT-MC CC: (BUG COMPLR) at MIT-MC In current XCOMPLR, this bug is finally fixed: PSZ@MIT-ML (Sent by PSZ0@MIT-ML) 03/26/81 18:02:52 Re: lose lose (DEFUN |fmt.B.op/|| (ARG PARAMS) (COND ((AND (CAR PARAMS) (> (FLATC ARG) (CAR PARAMS))) (LOOP FOR I FROM 1 TO (CAR PARAMS) AS X IN (EXPLODEN ARG) DO (TYO X STANDARD-OUTPUT))) (T (PRINC ARG STANDARD-OUTPUT)))) The LAMBDA for generated by LOOP was failing to find the value of (CAR PARAMS) in the numerical accumulator where the compilation of the ">" had left it, causing a (PUSH FXP @ () ) But this is now fixed.  Date: 5 APR 1981 0028-EST From: JONL at MIT-MC (Jon L White) Subject: "Unused variable" comments losing To: GSB at MIT-MC, GJC at MIT-MC CC: (BUG COMPLR) at MIT-MC In current XCOMPLR (version 1107), the bug in the "Unused Variable" comment generator is fixed, which gave rise to the following bugs: GSB@MIT-ML 04/02/81 19:49:36 Re: what kind of error message is this To: (BUG COMPLR) at MIT-ML (COMMENT **** (((TEM . G0002) (DOC-TYPE . G0001)) STREAM) Unused LAMBDA variables in function LSB:TEXT-DIVSTREAM-MANAGER-1) Apparently this meant to say "(TEM STREAM)"; it took a while to figure this out, as there were several branches in the function which bound the vars TEM and DOC-TYPE... and GSB@MIT-ML 03/13/81 21:07:17 Re: foo on error checking If the following is compiled in (*RSET T) mode, it croaks because GETCHARN is called on a bad arg (an RNL entry perhaps?), from UUVP. (DEFUN |+Int.SET-CHARACTER-SYNTAX.Aux.F| (CHAR SYMBOLIC-DESCRIPTOR RDTBL) ((LAMBDA (RDTBL DATA) (OR (FIXP CHAR) (SETQ CHAR (GETCHARN CHAR 1.))) . . .) (SCSRT RDTBL) (SCSSD SYMBOLIC-DESCRIPTOR))) The inner lambda was supposed to be READTABLE, not RDTBL. and Date: 4 April 1981 15:26-EST From: George J. Carrette Subject: PRATT;BUG 1 Shows a bug where GETCHARN is called by the compiler on something that is not a symbol. This used to show up as a normal unused-lambda-variable message the last time CGOL was compiled.  GSB@MIT-ML 04/02/81 19:49:36 Re: what kind of error message is this To: (BUG COMPLR) at MIT-ML (COMMENT **** (((TEM . G0002) (DOC-TYPE . G0001)) STREAM) Unused LAMBDA variables in function LSB:TEXT-DIVSTREAM-MANAGER-1) Apparently this meant to say "(TEM STREAM)"; it took a while to figure this out, as there were several branches in the function which bound the vars TEM and DOC-TYPE...  EB@MIT-ML 04/02/81 01:45:34 Re: Previous file references To: (BUG COMPLR) at MIT-ML Sorry, those are ML:EB;RWCK43 BUG and RWCK43 UNFASL.  EB@MIT-ML 04/02/81 01:40:18 To: (BUG COMPLR) at MIT-ML The UNFASL file ML:EB;RWCK UNF43 compiled from ML:EB;RWCK BUG43, which is admittedly incorrect, says "Show JONL - NLNVASG ...."  GSB@MIT-ML 03/27/81 18:14:29 Re: hack To: (BUG COMPLR) at MIT-ML When you compile (error "Frobozzery is losing" ...), for instance, instead of doing (push p (% 0 0 '"Frobozzery is losing")) how about reverting it back to the way it used to be, (push p (special "Frobozzery is losing")) eliminating that extra literal? The quoting optimization is still good for moves-into-accumlators, though.  PSZ@MIT-ML (Sent by PSZ0@MIT-ML) 03/26/81 18:02:52 Re: lose lose To: (BUG COMPLR) at MIT-ML (DEFUN |fmt.B.op/|| (ARG PARAMS) (COND ((AND (CAR PARAMS) (> (FLATC ARG) (CAR PARAMS))) (LOOP FOR I FROM 1 TO (CAR PARAMS) AS X IN (EXPLODEN ARG) DO (TYO X STANDARD-OUTPUT))) (T (PRINC ARG STANDARD-OUTPUT))))  GSB@MIT-ML 03/20/81 19:43:52 Re: AND or OR loss .... To: (BUG COMPLR) at MIT-ML (declare (special *ttyscan-output-stream *ttyscan-output-sfap *ttyscan-original-stream)) (defun ttyscan-finish () (force-output *ttyscan-output-stream) (or (cond ((not (null *ttyscan-output-sfap)) (and (memq 'finish *ttyscan-output-sfap) (sfa-call *ttyscan-output-stream 'finish nil))) (t (syscall 0 'finish *ttyscan-output-stream) (let ((crap (list 'filemode *ttyscan-output-stream))) (and (memq 'tty (car (apply 'status crap))) (or (> (apply 'status (rplaca crap 'ospeed)) 1200.) (not (= (apply 'status (rplaca crap 'ttytype)) 7))))))) (plusp (listen *ttyscan-original-stream)) (sleep 0.4)) t)  Date: 19 MAR 1981 1618-EST From: JONL at MIT-MC (Jon L White) Subject: Source-trans schizophrenia To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 03/19/81 10:16:30 Re: Source-trans schizophrenia (from JONL) I believe it was made fairly clear that SOURCE-TRANS would not be "optimizers"; and that compiler "optimizers" in the LISPM sense could be implemented useing the general mechanism of SOURCE-TRANS. The semantics documented gives no indication of this. It sounds, with the exception of the returned value(s), exactly like lispm optimizers to me. Hmmm. You're quite right here -- the long discussion of this new feature went on in the LISP-FORUM mailings rather than in the LISP NEWS, which latter has only that "SOURCE-TRANS's are like optimizers except that ...". But there was certainly no promise that the features of "optimizers" which weren't explicity documented in LISP NEWS would be supported. . . . I'm not saying that i totally object to the use of source-trans in toplevel macro expansion, but i am disturbed by the change of semantics which occurred with absolutely no notification whatsoever, when in fact the original behaviour was what was documented. Not in LISP NEWS -- it said precisely that SOURCE-TRANS's were performed before *any* macroexpansion; and it has been standard for many years that eval-mungeables were macro-expanded. A trick which is often used to stop that expansion is (EVAL '(DONT-EXPAND-THIS-MACRO UNTIL RUNTIME)) If the semantics you inferred are really needed, then we'd need some way to distinguish the two, (like evalquote abve), right? So why not COMPILER-STATE?  GSB@MIT-ML 03/19/81 10:16:30 Re: Source-trans schizophrenia To: JONL at MIT-MC CC: (BUG COMPLR) at MIT-MC Date: 18 MAR 1981 1536-EST From: JONL at MIT-MC (Jon L White) I believe it was made fairly clear that SOURCE-TRANS would not be "optimizers"; and that compiler "optimizers" in the LISPM sense could be implemented useing the general mechanism of SOURCE-TRANS. The semantics documented gives no indication of this. It sounds, with the exception of the returned value(s), exactly like lispm optimizers to me. Since the state of COMPILER-STATE is available to a SOURCE-TRANS function (as well as a MACRO, as well as any function whatsoever), then one can be sensitive to the "producing instructions" versus "expand-out-lisp-code-for-mungeable" phases. Although this is true for SOURCE-TRANS, checking compiler-state does not work in ordinary macros because they cannot tell whether they are being called by the interpreter (by virtue of being called inside the definition of a macro being expanded) or directly the compiler. I'm not saying that i totally object to the use of source-trans in toplevel macro expansion, but i am disturbed by the change of semantics which occurred with absolutely no notification whatsoever, when in fact the original behaviour was what was documented. I was luckily able to de-install an LSB version when i discovered this "fix" (it had been installed about an hour and only used by me). If i had not and it had been used, i probably would have had to go find everything which had been compiled with it.  GSB@MIT-ML 03/18/81 19:15:15 Re: missing To: (BUG COMPLR) at MIT-ML HUNKSIZE isn't declared FIXNUM in complr  Date: 18 MAR 1981 1536-EST From: JONL at MIT-MC (Jon L White) Subject: Source-trans schizophrenia To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC I believe it was made fairly clear that SOURCE-TRANS would not be "optimizers"; and that compiler "optimizers" in the LISPM sense could be implemented useing the general mechanism of SOURCE-TRANS. Since the state of COMPILER-STATE is available to a SOURCE-TRANS function (as well as a MACRO, as well as any function whatsoever), then one can be sensitive to the "producing instructions" versus "expand-out-lisp-code-for-mungeable" phases.  Date: 18 March 1981 15:28-EST From: Glenn S. Burke Subject: source-trans schizophrenia To: BUG-COMPLR at MIT-MC Date: 14 MAR 1981 2354-EST From: JONL at MIT-MC (Jon L White) GSB@MIT-ML 03/13/81 23:27:00 Re: source-trans schizophrenia Nowhere is it documented that the source-trans property will be used for toplevel macro-expansion. . . . I note that RWK fixed MACROEXPAND so that it looks on MACROLIST. It's not clear that all SOURCE-TRANS will be supported at all load-times, so it seemd wise for the MACRO-EXPAND phase (that is, expand out for a top-level mungeable) to do this too. Perhaps there shold be some more refinement as to when to expand. I had assumed that the change was made for this reason. My complaints are that i don't believe that source-trans should be allowed to be used in that environment, and even if they were, this was not documented. I guess the problem is conceptually that the things this change was made for are more macros than "optimizers". Perhaps more liberal use should be made of macrolist for them. This would not only allow source-trans to remain defined as being for the use of only the compiler when it is compiling code, but also help out potential ordering problems with the use of the source-trans property when there is some "distinguished" source-trans property which always expands (i.e., it is really a macro-like extension of the compiler, telling it how to process the form in an eval-mungeable, how to compile it by default, etc.).  Date: 14 MAR 1981 2354-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC, RWK at MIT-MC GSB@MIT-ML 03/13/81 23:27:00 Re: source-trans schizophrenia Nowhere is it documented that the source-trans property will be used for toplevel macro-expansion. . . . I have recently converted LSB to use this property instead of MACROLIST for this very reason; i had been getting scrod by the fact that macrolist was used by the toplevel form macro expander. . . . I note that RWK fixed MACROEXPAND so that it looks on MACROLIST. It's not clear that all SOURCE-TRANS will be supported at all load-times, so it seemd wise for the MACRO-EXPAND phase (that is, expand out for a top-level mungeable) to do this too. Perhaps there shold be some more refinement as to when to expand.  GSB@MIT-ML 03/13/81 23:27:00 Re: source-trans schizophrenia To: (BUG COMPLR) at MIT-ML Nowhere is it documented that the source-trans property will be used for toplevel macro-expansion. In fact, the lisp recent documentation says "... when a form is being compiled ..." or somesuch, explicitly saying COMPILED. I have recently converted LSB to use this property instead of MACROLIST for this very reason; i had been getting scrod by the fact that macrolist was used by the toplevel form macro expander. I would suggest that if it is necessary or desirable for certain calls in toplevel forms to be expanded out to reduce load-time dependencies (such as LOGIOR and <= and friends, which always expand) that they use MACROLIST instead, or some new mechanism be consed up.  GSB@MIT-ML 03/13/81 21:07:17 Re: foo on error checking To: (BUG COMPLR) at MIT-ML If the following is compiled in (*RSET T) mode, it croaks because GETCHARN is called on a bad arg (an RNL entry perhaps?), from UUVP. (DEFUN |+Int.SET-CHARACTER-SYNTAX.Aux.F| (CHAR SYMBOLIC-DESCRIPTOR RDTBL) ((LAMBDA (RDTBL DATA) (OR (FIXP CHAR) (SETQ CHAR (GETCHARN CHAR 1.))) (COND ((FIXP DATA) (SETSYNTAX CHAR DATA CHAR)) (T (SETSYNTAX CHAR (CAR DATA) (CADR DATA)) (AND (CADDR DATA) (APPLY 'SSTATUS (LIST 'SYNTAX CHAR (BOOLE 7. (APPLY 'STATUS (LIST 'SYNTAX CHAR)) (CADDR DATA)))))))) (SCSRT RDTBL) (SCSSD SYMBOLIC-DESCRIPTOR))) The inner lambda was supposed to be READTABLE, not RDTBL.  GSB@MIT-ML 03/12/81 01:24:00 Re: arraycall types To: (BUG COMPLR) at MIT-ML CC: CWH at MIT-ML it would be nice if complr accepted OBARRAY as a type keyword forr arraycall. Multics maclisp requires this (as opposed to T) when one is referencing an obarray.  Date: 10 March 1981 18:41-EST From: Robert W. Kerns To: KMP at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 8 March 1981 21:57-EST From: Kent M. Pitman To: RWK at MIT-MC cc: BUG-COMPLR at MIT-MC There is no reason that the compiler should assume that a subr f available at compile time has any relation to the subr that will be runtime. Hence, the LSUBR and ARGS info is correctly ignored. Use a *LEXPR definition. If you want the args info set up, put them on the EOF-COMPILE-QUEUE or use DEFUN& or expand into a progn'compile which does an args or ... Did you look at the example???????? Whether it ignored the LSUBR or ARGS info, or not, it did not do the correct thing. It complained about the number of arguments being wrong, ** YET THEY WERE THE SAME IN BOTH CASES ** !!!!!!! This is incontrovertably a bug and gross screw.  Date: 9 March 1981 00:35-EST From: Glenn S. Burke To: KMP at MIT-MC cc: RWK at MIT-MC, BUG-COMPLR at MIT-MC The problem is that the LSUBR property is totally ignored, but the ARGS info is not, at least once the *EXPR property is put on - it is then misinterpreted. Try: (declare (*expr foo) (args 'foo '(1 . 2))) (defun bar (x) (foo x x))  Date: 8 March 1981 21:57-EST From: Kent M. Pitman To: RWK at MIT-MC cc: BUG-COMPLR at MIT-MC There is no reason that the compiler should assume that a subr f available at compile time has any relation to the subr that will be runtime. Hence, the LSUBR and ARGS info is correctly ignored. Use a *LEXPR definition. If you want the args info set up, put them on the EOF-COMPILE-QUEUE or use DEFUN& or expand into a progn'compile which does an args or ...  Date: 8 MAR 1981 1423-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG COMPLR) at MIT-MC If FOO is loaded into the compiler, with no properties other than the LSUBR property, and with (ARGS 'FOO) ==> (1 . 510.), then the following loses: (defun t1 (x) (foo x)) (cl:cl t1) ;correct program with JCALL at end (plist 'foo) (*EXPR T LSUBR #!@#%$) (defun t2 (x) (+ 5 (foo x))) (cl:cl t2) ;complains that FOO has previously been used with the wrong number of arguments!  EB@MIT-AI 03/04/81 19:59:39 To: (BUG COMPLR) at MIT-MC On AI: qc^K! COMPLR 1102 (in SHARABLE 41, LISP 2077) _eb;lbug (COMMENT **ERROR** NIL No free acs - FREEREGAC in function RUN) ;%%%%%%%% COMPILER ERROR - CALL JONL %%%%%%%% ;BKPT BARF  Date: 3 MAR 1981 1831-EST From: JONL at MIT-MC (Jon L White) Subject: ARGS props for LEXPR-SEND etc To: RWK at MIT-MC CC: (BUG COMPLR) at MIT-MC Date: 2 March 1981 11:18-EST From: Robert W. Kerns Date: 19 February 1981 05:02-EST From: Robert W. Kerns LEXPR-SEND DOES NOT HAVE ARGS PROPERTIES SET UP!!... The args info is set up by the defining file, namely EXTEND, which isn't pre-loaded into the COMPLR. Ok, I've started teh assembly for a new complr INITIA file, which will set up args information for SEND-AS, LEXPR-SEND, and LEXPR-SEND-AS. Should be installed in COMPLR version 1102.  Date: 2 March 1981 11:18-EST From: Robert W. Kerns To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 20 February 1981 10:59-EST From: Jon L White To: RWK at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 19 February 1981 05:02-EST From: Robert W. Kerns LEXPR-SEND DOES NOT HAVE ARGS PROPERTIES SET UP!!... The args info is set up by the defining file, namely EXTEND, which isn't pre-loaded into the COMPLR. That is indeed the situation. Do you plan to fix it? If LISP doesn't get the symbol as an autoload, at least the compiler should know about it.  Date: 25 FEB 1981 2136-EST From: JONL at MIT-MC (Jon L White) Subject: FIXP applied to fixnum variable To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 02/25/81 11:20:15 Re: pretty please? (defun foo () (or (and (fixp ibase) (plusp ibase) (< ibase 37.)) (error ))) produces the error FIXNUM NON-NULL TERMINATION OF LIST (or whatever) and later on tells me that IBASE has been used but not defined. Fixed in XCOMPLR version 1099.  Date: 25 FEB 1981 2103-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 02/24/81 06:49:50 To: (BUG COMPLR) at MIT-ML (defprop loop (macro) funtyp-info) (defprop define-loop-path (macro) funtyp-info) (defprop define-loop-sequence-path (macro) funtyp-info) (or (fboundp 'define-loop-sequence-path) (get 'define-loop-sequence-path 'autoload) (putprop 'define-loop-sequence-path (get 'loop 'autoload) 'autoload)) What is the alleged "complr" bug? The LOOP file in fact didn't define "define-loop-sequence-path".  GSB@MIT-ML 02/25/81 11:20:15 Re: pretty please? To: (BUG COMPLR) at MIT-ML (defun foo () (or (and (fixp ibase) (plusp ibase) (< ibase 37.)) (error ))) produces the error FIXNUM NON-NULL TERMINATION OF LIST (or whatever) and later on tells me that IBASE has been used but not defined.  GSB@MIT-ML 02/24/81 06:49:50 To: (BUG COMPLR) at MIT-ML (defprop loop (macro) funtyp-info) (defprop define-loop-path (macro) funtyp-info) (defprop define-loop-sequence-path (macro) funtyp-info) (or (fboundp 'define-loop-sequence-path) (get 'define-loop-sequence-path 'autoload) (putprop 'define-loop-sequence-path (get 'loop 'autoload) 'autoload))  Date: 20 FEB 1981 1059-EST From: JONL at MIT-MC (Jon L White) To: RWK at MIT-MC CC: (BUG COMPLR) at MIT-MC Date: 19 February 1981 05:02-EST From: Robert W. Kerns LEXPR-SEND DOES NOT HAVE ARGS PROPERTIES SET UP!!... The args info is set up by the defining file, namely EXTEND, which isn't pre-loaded into the COMPLR.  Date: 19 FEB 1981 0502-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG COMPLR) at MIT-MC LEXPR-SEND DOES NOT HAVE ARGS PROPERTIES SET UP!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  RIVEST@MIT-AI 02/17/81 22:58:10 To: (BUG COMPLR) at MIT-AI Please ignore my last message. I found the problem -- a bad macro in the code...  RIVEST@MIT-AI 02/17/81 22:11:03 To: (BUG COMPLR) at MIT-AI The following seems to consistently cause the LISP compiler on the ai machine to bomb out. I'm logged in as RIVEST, and I start the compiler up (which is COMPLR 1095, in SHARABLE 39, LISP 2071) with the command rr;picdx (f s k) which ought to compile that file. Instead I get thrown back to DDT with a line of the form: MPV; 13403>>HLRZ 1,(1) 1/ 777000 777000/ (memory protection violation, I assume.) The code runs OK in the interpreter, although some of it (the end sections) are totallly untested sections written by a student. Anyway, this kind of thing shouldn't happen to the compiler... Cheers, Ron  Date: 14 FEB 1981 0538-EST From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC CC: (BUG COMPLR) at MIT-MC This is pretty random: Date: 14 February 1981 00:40-EST From: Alan Bawden (lap foo bar) (movei a 'foo) (popj p) () (COMMENT **** FOO Has been incorrectly declared *EXPR or *FEXPR -- Discovered while ) Huh? The file contains nothing else, so FOO has never been seen before. And the "error" was discovered while ""? Has been fixed in current XCOMPLR.  Date: 14 FEB 1981 0040-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG COMPLR) at MIT-MC Compiling the following: (lap foo bar) (movei a 'foo) (popj p) () Gets you the following silly error message: (COMMENT **** FOO Has been incorrectly declared *EXPR or *FEXPR -- Discovered while ) Huh? The file contains nothing else, so FOO has never been seen before. And the "error" was discovered while ""?  Date: 12 FEB 1981 1150-EST From: JONL at MIT-MC (Jon L White) Subject: SOURCE-TRANS To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 02/11/81 23:29:25 Re: source-trans is wedged The function SOURCE-TRANS is trying to be a bit too optimal. It is iterating down the old optimizers on the newly-expanded form. . . . Although this behaviour can't hurt (since SOURCE-TRANS's are done before macro expansions), it probably doesn't do any good, and may wast time; will be changed in COMPLR 1096.  GSB@MIT-ML 02/11/81 23:29:25 Re: source-trans is wedged To: (BUG COMPLR) at MIT-ML The function SOURCE-TRANS is trying to be a bit too optimal. It is iterating down the old optimizers on the newly-expanded form. It should either recalculate again or simply return to P1 (or whatever caller) to be recursively/iteratively called again, after the first successful transformation.  Date: 7 FEB 1981 1021-EST From: JONL at MIT-MC (Jon L White) Subject: COMPLR not at fault To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, CWH at MIT-MC Re: Date: 5 February 1981 17:21-EST From: Jeffrey P. Golden Subject: Bug in (TAN 10), continued This looks like it is a compilation bug (AC being clobbered?) Just get a MACSYMA, quit into LISP, and (TRACE SIN COS). You'll see that the argument to COS (which should be the same as the argument to SIN, obviously) is being clobbered. The function TAN is defined in MRG;TRIGI > . the bug is entirely due to the faulty declaration in the TRIGI file reproduced here: ;; This declaration applies to the parameter variables and local variables ;; of many of the functions defined below. They do not apply to special ;; variables. If you use these names in any context below, the compiler ;; will assume them to be flonums. (DECLARE (FLONUM Y YY X)) X certainly isn't being used as a FLONUM variable in TAN.  Date: 5 FEB 1981 1721-EST From: JPG at MIT-MC (Jeffrey P. Golden) Subject: Bug in (TAN 10), continued To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC CC: JPG at MIT-MC This looks like it is a compilation bug (AC being clobbered?) Just get a MACSYMA, quit into LISP, and (TRACE SIN COS). You'll see that the argument to COS (which should be the same as the argument to SIN, obviously) is being clobbered. The function TAN is defined in MRG;TRIGI > . (Please try this in OA^K rather than A^K, so I can fix MACSYMA.)  Date: 4 FEB 1981 1617-EST From: JONL at MIT-MC (Jon L White) Subject: COMPLR address space To: PSZ at MIT-MC, GSB at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC I've just made an investigation of packages the were put on the list of things to be pre-loaded into complr, and removed a few that there only due to "obarray dyslexia". Current XCOMPLR (version 1088) now has only 2K less space than the COMPLR of 6 months ago, and this seems reasonable as the amount by which the primitive facilities have grown. Note that the two (STATUS MEMFREE)'s differ by 6K, but that the more recent compiler has and additional 4K of reclaimed LIST storage, so the net loss is only 2K.  Date: 3 February 1981 10:09-EST From: Kent M. Pitman Subject: '*REG-LIST* in an UnFasl file To: GJS at MIT-AI cc: BUG-COMPLR at MIT-AI Any quoted text (or code that expands into quoted text) in a lisp source file is typed in the Unfasl file. eg, '(THIS IS STUFF TO GO IN UNFASL FILE) would also do it. As it happens, (DEFVAR var val) expands into something of the form (PROGN 'COMPILE ...init code... 'var), which is flattened out, and then the 'var ends up in the unfasl file. It's nice once you get used to it. Since DEFVARs don't get compiled, you otherwise wouldn't have a record in the unfasl file of what vars were DEFVAR'd ...  GJS@MIT-AI 02/02/81 23:18:05 To: (BUG COMPLR) at MIT-AI (DEFVAR *REG-LIST* NIL) in SCHIP3;AI:GENMAC > causes '*REG-LIST* to appear on a line by itself in the UNFASL file. Weird.  Date: 30 JAN 1981 0931-EST From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC CC: (BUG COMPLR) at MIT-MC Date: 29 January 1981 17:39-EST From: Alan Bawden I tried to compile this file in XCOMPLR: (defmacro logand (x y) `(+ ,x ,y)) (defun foo (x) (logand x (1+ x))) It complained mightily about redefining LOGAND: (COMMENT **** (LOGAND FROM USER FILE #FILE-IN-|DSK:ALAN;FOO 1|-70756) being redefined as a MACRO -- definition is pushed onto MACROLIST) But it STILL produced code that did an AND instead of an ADD. Yes, the semantics of SOURCE-TRANS's are that they are expanded before any macro-expansions are done. Could it be that macro definitions in the complr should remove SOURCE-TRANS properties? At least the XLISP/XCOMPLR documentation warns about LOGAND etc. as using the SOURCE-TRANS property.  Date: 30 January 1981 00:30-EST From: Alan Bawden Subject: source-trans bug To: GJC at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISPM at MIT-MC Well, george I guess you're right. The fact that this doesn't work right on the LispMachine humbles me and I hereby withdraw my bug report. MacLisp has no obligation to do something right if the LispMachine does it wrong. Seriously, the bug is that he redifinition of something as a macro by the user, should cause the compiler to forget everything else it knows about that thing.  Date: 29 JAN 1981 2038-EST From: GJC at MIT-MC (George J. Carrette) To: ALAN at MIT-MC CC: (BUG COMPLR) at MIT-MC, (BUG LISPM) at MIT-MC Alan, just for the heck of it I tried out your last COMPLR-BUG (with respect to SOURCE-TRANS properties) on a Lisp-machine. (defun foo (f x) (apply f (list x))) (defmacro apply (f l) `(print "hey man!")) ; the above give a rather stern warning/error message, to ; which I reply "Y", i.e. "yes, let me screw myself" (compile 'foo) (foo #'car '(a)) ; this does not cause "hey man!" to be printed. I think you have to admit that the only COMPLR bug in this SOURCE-TRANS stuff is that it might seem like you are going to be able to redefine something. [The macro-list stuff]. Whereas on the lispm it really warns you about the illegality of the definition, giving you less confidence. However, it is still a bug that it doesn't know about "the compiler" and tell you that the redefinition couldn't possibly win. On that note, I think your statement "a new way to get screwed: The source-trans property" is WAY OUT OF LINE. Inflamatory in fact, considering that this SOURCE-TRANS thing is a good item to have for methodological compatibility with the Lispm.  Date: 29 January 1981 17:39-EST From: Alan Bawden Subject: A new way to get screwed: the source-trans property. To: BUG-COMPLR at MIT-MC I tried to compile this file in XCOMPLR: (defmacro logand (x y) `(+ ,x ,y)) (defun foo (x) (logand x (1+ x))) It complained mightily about redefining LOGAND: (COMMENT **** (LOGAND FROM USER FILE #FILE-IN-|DSK:ALAN;FOO 1|-70756) being redefined as a MACRO -- definition is pushed onto MACROLIST) But it STILL produced code that did an AND instead of an ADD.  GSB@MIT-ML 01/27/81 19:52:15 To: (BUG COMPLR) at MIT-ML (declare (special foo)) (defun foo () (fixnum-identity (store (arraycall fixnum foo 9.) 2)) nil) This complains mightily about losing some value. This is not an unreasonable construct, as it might be produced by a macro which cannot tell that it is being called for effect only.  Date: 20 JAN 1981 1529-EST From: kmp at MIT-MC (Kent M. Pitman) Sent-by: ___105 at MIT-MC To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC Experimentally, doing a (REMPROP 'BASE 'NUMVAR) and (REMPROP 'IBASE 'NUMVAR) seems to do the right thing...  GSB@MIT-ML 01/20/81 13:32:59 Re: come off it, will you? To: (BUG COMPLR) at MIT-ML (defun foo (f) ((lambda (base) (funcall f)) 'roman)) '(THIS IS THE UNFASL FOR ((DSK GSB) TEMP /2)) '(ASSEMBLED BY FASLAP /389) '(COMPILED BY LISP COMPILER /924 COMAUX /20 PHAS1 /67 MAKLAP /68 INITIA /98) ;COMPILED ON TUESDAY, JANUARY 20, 1981, AT 1:32 PM (COMMENT **ERROR** (BASE (QUOTE ROMAN)) Binding number variable to quantity of wrong type in function FOO) ; DATA ERROR - TO PROCEED TYPE $P (COMMENT **** (FOO) - Failed to compile) (COMMENT **FASL** TOTAL = 0. WORDS)  GSB@MIT-ML 01/19/81 18:11:36 Re: journal of unexpected results To: (BUG COMPLR) at MIT-ML (defun foo (x) (declare (fixnum x)) (cons ((lambda (x) (declare (flonum x)) (times x x)) (mumble)) x))  Date: 19 JAN 1981 1653-EST From: JONL at MIT-MC (Jon L White) Subject: Believe it! To: DCP at MIT-MC CC: (BUG COMPLR) at MIT-MC Date: 18 January 1981 12:20-EST From: David C. Plummer Subject: I DON'T BELIEVE IT !!! . . . (defun foo (n) (print (- n #/A -13))) (defun foo$ (n) (print (-$ n 101.0 -13.0))) . . . Please??? Yes, I too scarcely believe that such an egregious bug has withstood the attentions of time. Problem is that numerical "constant collapsing" is doing the wrong operation for - and -$. Thus (- n (+ #/A -13)) wins, but (- n #/A -13) loses. I'll try to look into it tonite.  Date: 19 January 1981 16:40-EST From: Glenn S. Burke Subject: RESTORE lossage To: BUG-COMPLR at MIT-MC the second case (involving FIRST-PARTICIPLE-PHRASE) was tracked down to a case of giving an argument of "(RETURN NIL)" to an expr (which was supposed to be a macro). When the macro was properly defined all such RESTORE problems went away.  Date: 19 JAN 1981 1633-EST From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 01/19/81 08:31:32 Re: space saving . . . Either give me an XCOMPLR in an installed lisp, or even better install XCOMPLR as COMPLR in the current lisp. This abortion with the universe loaded in it should never have been installed in the first place; at least undo it. Krns and I have been intending to install a new LISP -- slowed down due to the flu etc.  Date: 19 JAN 1981 1224-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: JONL at MIT-MC CC: (BUG COMPLR) at MIT-MC Is there any chance of complr supporting a compiler-let simlilar to that of the Lispm? Otherwise, one has to use a meta-evaluator to do the work the compiler should be doing in the first place--a tremendous waste.  GSB@MIT-ML 01/19/81 11:28:30 Re: RESTORE is very upset (moreso this time) To: (BUG COMPLR) at MIT-ML ARGS is: (((FIRST-PARTICIPLE-PHRASE . IDUP) (MADE-STATE) (CONSTITUENT)) |/ | ((NIL NIL NIL NIL NIL) (NIL NIL NIL) (NIL NIL NIL) ((MADE-STATE) (CONSTITUENT)) NIL NIL)) TOPFN is: FIRST-PARTICIPLE-NON-MODAL-AUXILIARY-VERB-AGENT I have no idea what this crap means, and i don't remember the exact error message. FIRST-PARTICIPLE-PHRASE is SPECIAL. While compiling MARPAR;PARSE 626 (In XLSBCL 174, COMPLR 1077)  GSB@MIT-ML 01/19/81 11:02:14 Re: helpful To: (BUG COMPLR) at MIT-ML (COMMENT **** (8208666156. -2.) PUSHPOP - RESTORE in function IN-QUESTION-AGENT) While doing :XLSBCL on MARPAR;PARSE  GSB@MIT-ML 01/19/81 08:31:32 Re: space saving To: (BUG COMPLR) at MIT-ML Fine and dandy. I just use XCOMPLR, which is an experimental compiler in an experimental lisp. Can't i just use one at a time? I don't want to have to go through the business of trying to maintain a dozen different dumps in the same transient version of XLISP. Either give me an XCOMPLR in an installed lisp, or even better install XCOMPLR as COMPLR in the current lisp. This abortion with the universe loaded in it should never have been installed in the first place; at least undo it.  Date: 18 JAN 1981 0411-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG COMPLR) at MIT-MC (defmacro lose () (and (memq compiler-state '(compile maklap)) (print 'lose msgfiles)) '(bar)) (let ((foo 'bar)) (lose) (do-something)) When the above is compiled, LOSE will be printed twice. This is not good when the macro lose side-effects the environment (like pushes things on eof-compile-queue as how I was screwed).  Date: 16 JAN 1981 0630-EST From: JONL at MIT-MC (Jon L White) To: gsb at MIT-ML CC: (BUG COMPLR) at MIT-MC, psz at MIT-ML, wam at MIT-ML GSB@MIT-ML 01/12/81 18:38:20 Re: gluttony (avarice?) I suppose it is now featureful for complr to contain the following modules which it did not contain one month ago: YESNOP DEFVSY DEFSETF GRINDEF EXTSFA TRACE ERRCK FORMAT EVONCE CERROR . . . This adds 15K to the starting size of the LSB compiler, which is a significant fraction of the memfree. This gluttony was the result of a somewhat unsuccessful attempt to have an intermediate sharable "MacLISP" dump. The current XCOMPLR has 15.K more free space -- try it.  Date: 14 JAN 1981 1812-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG COMPLR) at MIT-MC sorry. that last mail i sent was intended for bug-its ... sigh.  Date: 14 JAN 1981 1801-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: When disk channels are all taken... To: MOON at MIT-MC CC: ELLEN at MIT-MC, RLB at MIT-MC, BIL at MIT-MC, JONL at MIT-MC CC: (BUG COMPLR) at MIT-MC, (BUG DDT) at MIT-MC What would *really* help would be for ITS to do typeout on everyone's console saying that disk channels are all used up and to kill un-needed jobs that might have files still open or some such message as appropriate. One can't do SEND or SHOUT at this point which is a very sad thing, and one can't run P or VV to find out who has channels open. Is it possible for DDT to offer a subroutine that printed out the names of people and jobs holding open disk channels? I think one or more of these ideas or something along these lines is what's needed. Your help is appreciated. Thanks. -kmp  GSB@MIT-ML 01/12/81 18:38:20 Re: gluttony (avarice?) To: (BUG COMPLR) at MIT-ML CC: WAM at MIT-ML, PSZ at MIT-ML I suppose it is now featureful for complr to contain the following modules which it did not contain one month ago: YESNOP DEFVSY DEFSETF GRINDEF EXTSFA TRACE ERRCK FORMAT EVONCE CERROR I will be willing to believe in ERRCK, EVONCE, and maybe DEFVSY, if complr itself uses it, but TRACE and GRINDEF are a bit much. I hope that EXTSFA is included only as a joke. Now it might look to some that this would result in some sharing benefits, but on this side of the arpa net the ONLY one of those which gets used with any frequency at all in the compiler is FORMAT. This adds 15K to the starting size of the LSB compiler, which is a significant fraction of the memfree.  Date: 12 JAN 1981 1755-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Address space! To: (BUG COMPLR) at MIT-MC Good grief. The latest COMPLR seems to have lost about 24.5K of (STATUS MEMFR) since the previous. Where did all that space go to? Signed, Curious  Date: 12 JAN 1981 0033-EST From: GZ at MIT-MC (Gail Zacharias) Subject: mlmac To: (BUG COMPLR) at MIT-MC If I don't load mlmac, I don't get logand etc. If I do load it, I get a bunch of ";CAUTION! ..., A USER SUBR ... BEING REDEFINED" messages. See GZ;TEST LISP, with and without the eval-when. Thanks.  Date: 31 DEC 1980 1521-EST From: JONL at MIT-MC (Jon L White) To: RWK at MIT-MC CC: NIL-I at MIT-MC, (BUG COMPLR) at MIT-MC, GJC at MIT-MC CC: JPG at MIT-MC Despite the conclusion that the intervention of the MACLISP layer costs us about 14K of address space, the current compiler (version 1073) and current NILAID (version 1019) are still composed over MACLISP. There are about 38. pages being shared with MACLISP, and that, too, isn't to be sneezed at.  Date: 31 DEC 1980 1420-EST From: JONL at MIT-MC (Jon L White) Subject: Address space being "lengthened" To: RWK at MIT-MC CC: NIL-I at MIT-MC, (BUG COMPLR) at MIT-MC So I just made up a fresh complr from SHARAB, and there is 103. pages free, as oppsed to the mere 90. free mentioned earlier. That's 26,624 words -- not something to be sneezed at.  Date: 31 DEC 1980 0653-EST From: JONL at MIT-MC (Jon L White) Subject: Paucity of addresses To: RLB at MIT-MC, RWK at MIT-MC CC: NIL-I at MIT-MC, (BUG COMPLR) at MIT-MC Regardless of any loss due to other means, it was shocking to see COMPLR lose 3K of address space for a trivial change! Just try (STATUS MEMFREE) in each case. I'd like to know why. Indeed, some 10. pages of (STATUS MEMFREE) have disappeared from NILAID over the past two months, and this means an additional 20K loss for NACOMPLR. This is most discouraging. I've tracked down most of it as follows: 1 page (2K) -- New SHARAB takes a little more free storeage and thus 'slops over' on two segments. 7 pages (14K) -- Use of MACDMP as an intermediate file costs this much!!! due to 'slop overs'. 1 page (~2K) -- More code added to system; this is purely a guess on my part, but it cant be less than 1K. 1 page (??) -- More 'packages' being loaded now maybe? Certainly for NILAID, DEFSET is new, and there may be another. Likely, we may have to abandon MACLISP^K as an intermediate sharing; I've just made up a new NILAID on this basis. I might remind ourselves that most of the 'new code' added recently should pay for itself in terms of savings on DEFVST definitions -- this 'dividend' won't be visible, of course, in a bare NILAID/NIL, but comes only after a file with some structure definitions is loaded.  Date: 31 December 1980 05:40-EST From: Robert W. Kerns To: JPG at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC Date: 30 December 1980 06:14-EST From: Jeffrey P. Golden To: BUG-COMPLR at MIT-MC cc: JPG at MIT-MC Doing the following gives ;IMPROPER USE OF MACRO - EVAL : CL^K ^G (LOAD '|JPG;CHOMP|) (CHOMP) RWK looked at this a few days ago, and a likely theory is that the call to (INITIALIZE) is REMOBing something needed by the FORMAT package. Anyway something within the FORMAT package ends up pointing into the freelist, leading to the above error condition. I'm not 100% clear as to what is happening here, but it IS clear that symbols are getting bashed that have no right to be bashed. While looking at various SY2 blocks, I found one symbol with a PNAME that ended in IN0 instead of NIL! Other than that, I found a number of other symbols with PNAME's which pointed to things they shouldn't, all with the Compiled-Code-Needs-me bit set. My theory is that the GC collects symbols with SY.CCN set, if they're not pointed to by any obarray. I can't find anything to contradict this in the code. But there's nothing to say the compiled code in question isn't still referenced just because it references a symbol not on any obarray. Just for the record, the function referencing the symbol is FORMAT-FROBNICATE-LISP-OBJECT, the symbol bashed is FMT-FROB/|, and the error message is purest nonsense. If you APPLY the former FMT-FROB/| (it now looks something like |n v|), it complains about illegal use of a MACRO, while if you look at it's PLIST, it may be GUBBISH, but nowhere is there a MACRO property...)  Date: 31 December 1980 04:29-EST From: Robert W. Kerns Subject: Shortage of addresses in COMPLR To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 30 December 1980 06:21-EST From: Jon L White To: RWK cc: BUG-COMPLR Re: Shortage of addresses in COMPLR FOO! Something you did between Midnite and 4AM today caused the Compiler to lose over #3K of address space. One of my files now won't compile, since it needs to 'load in the world' first, and there is this shortage of space to . . . The only thing I did to ANY file the compiler loads was to make it load EXTHUK like it's supposed to be. That's only .5K, but it could have fallen over a page boundary of BPS. Maybe even of pure list and/or pure fixnum space, although it would seem unlikely. I don't still have the pice of mail to which RLB refers. What are you doing with the 92K still free?  Date: 30 December 1980 17:09-EST From: Richard L. Bryan Subject: Shortage of addresses in COMPLR To: JONL at MIT-MC, RWK at MIT-MC cc: BUG-COMPLR at MIT-MC Date: 30 DEC 1980 0621-EST From: JONL at MIT-MC (Jon L White) FOO! Something you did between Midnite and 4AM today caused the Compiler to lose over #3K of address space. One of my files now won't compile, since it needs to 'load in the world' first, and there is this shortage of space to . . . FOO! Something you guys did a couple weeks ago lost over 33,000 words of address space. NILC and (hence) the NIL simulator are useless because of it. I tracked down which two versions differed so much, shipped the info off to my and RWK's mail, and deleted it from mine, so I can't say which the versions were.  Date: 30 DEC 1980 0621-EST From: JONL at MIT-MC (Jon L White) Subject: Shortage of addresses in COMPLR To: RWK at MIT-MC CC: (BUG COMPLR) at MIT-MC FOO! Something you did between Midnite and 4AM today caused the Compiler to lose over #3K of address space. One of my files now won't compile, since it needs to 'load in the world' first, and there is this shortage of space to . . .  Date: 30 DEC 1980 0614-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG COMPLR) at MIT-MC CC: JPG at MIT-MC Doing the following gives ;IMPROPER USE OF MACRO - EVAL : CL^K ^G (LOAD '|JPG;CHOMP|) (CHOMP) RWK looked at this a few days ago, and a likely theory is that the call to (INITIALIZE) is REMOBing something needed by the FORMAT package. Anyway something within the FORMAT package ends up pointing into the freelist, leading to the above error condition.  Date: 19 DEC 1980 1409-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: WGD's UNLESS bug To: (BUG COMPLR) at MIT-MC He isn't loading UMLMAC, so he gets UNLESS defaulting to *EXPR, ARGS of (0 . 2) COMPLR may be dying due to some unreachable-code problem...? Just a guess. As Bill points out though, the error diagnostic is far from helpful and COMPLR still shouldn't die in this way.  Date: 16 DEC 1980 1116-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Closed-compiled MAP bug fixed. To: REM at MIT-MC, GZ at MIT-MC, GJC at MIT-MC, JPG at MIT-MC To: RLB at MIT-MC, ASB at MIT-MC, (BUG LISP) at MIT-MC To: (BUG COMPLR) at MIT-MC Yup.  Date: 16 December 1980 10:31-EST From: Robert W. Kerns To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC, JPG at MIT-MC, RLB at MIT-MC, ASB at MIT-MC Date: 15 December 1980 15:13-EST From: George J. Carrette To: BUG-LISP at MIT-MC CL^K ^B (DB) (DEFUN FOO (L) (MAPCAR #'(LAMBDA (X) (CONS X 'FOO)) L)) (CL FOO) (COMMENT **** (L) Bound variable used as Function name in function FOO) (COMMENT **** (L) Unused LAMBDA variables in function FOO) ; the code produced looks ok though. FOO JONL!!!!!!! Actually, this particular bug is mine. However, it is better than the sneakier bug that JONL had that I was fixing (before, without telling you it was losing, it stepped by (CDR 'T) instead of CDRing down the list...). Unfortunately I had to leave so I couldn't test 100%, but it was working better than before. I can't believe the 10 or so files I compiled didn't show this up though. Sigh. I'll fix it now. Any code compiled between 12/14 21:53 and 12/16 2:42 with any mappers in it should be recompiled.  Date: 16 DEC 1980 0249-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG COMPLR) at MIT-MC CC: RWK at MIT-MC, GJC at MIT-MC, BMT at MIT-MC, RLB at MIT-MC Because of the problems we have been having compiling MAP's, (1) I linked SYS;TS COMPLR to LSPDMP;CL.DMP 1057. (2) I created COMLAP;CLFIX 1051 (which see) so that GENTEMP would be defined. Hopefully, this should hold us until JONL returns and fixes things right.  Date: 15 DEC 1980 2053-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG COMPLR) at MIT-MC See MC:REM;COMPLR BUG and COMPLR UNFASL COMPLR generates a superfluous error message about a perfectly normal (EXPLODEN ) being a computed function that needs to be changed to a FUNCALL. It's about at the end of both files. I was able to sidestep this bug by changing (FUNCTION (LAMBDA (X) (-- X))) to be just (FUNCTION --) but that shouldn't have anything to do with this part of the parse, so COMPLR must be confused.  Date: 15 DEC 1980 1323-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MAP expansion fixed To: (BUG COMPLR) at MIT-MC CC: (BUG LISP) at MIT-MC P1MAP was the culprit, due to JONL getting confused when converting an SI:GEN-LOCAL-VAR back to a LOCAL-VAR call, and not preserving the implicit SETQ involved. However, in order to understand this function enough to find where it was happening, I had to re-arrange this function, LETifying it, etc. I'm pretty sure my change is functionally equivalent, minus the reported bug. I recompiled EXTEND; I'll look for other things that may need recompiling.  Date: 15 DEC 1980 1151-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: MAP expansion broken To: (BUG COMPLR) at MIT-MC CC: (BUG LISP) at MIT-MC WHICH-OPERATIONS is busted because the compiler compiled it (and a few other functions in the file EXTEND) incorrectly. I don't know what's going on here, but a (HRRZ 1 'T) is being output, apparently where the map variable should be being stepped. Needless to say, this leads to endless hacking of T's PLIST (which is non-null if you have FORMAT loaded). This seems to happen with any expansion of MAPC!  SJOBRG@MIT-AI 12/10/80 10:24:12 To: (BUG COMPLR) at MIT-AI Please ignore my message headed SJOBRG@MIT-AI 12/07/80 15:00:33 To: (BUG COMPLR) at MIT-AI CC: SJOBRG at MIT-AI My problem was that I can't write declarations right ... (sigh) --Bob  Date: 9 December 1980 22:24-EST From: Robert W. Kerns Subject: Where does SHBDMP live? To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC, tlp at MIT-AI Date: 9 December 1980 17:50-EST From: Jon L White Subject: Where does SHBDMP live? To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC, tlp at MIT-AI Re: TLP@MIT-AI 12/09/80 16:53:33 To: (BUG COMPLR) at MIT-AI COMPLR is trying to load some file from lspdmp; which does not exist on AI. A new SHBDMP and complr dump is on its way now, to AI and ML. Apparently you changed the SHARAB init file to dump its result on SHBDMP instead of LISP? This works fine on MC, but ML and AI don't have LSPDMP directories, and for the past year or so I've been :INSTALLing the dumps from COMLAP instead of rebuilding them on each system. In general, in the past, I've found the using links with sharab doesn't work -- the PURQIX file on LISP; may be linked to SYS;PURQIO because it is the built-in part of lisp's SUSPEND which finds those pages. But SHARAB-dumped files need to know exactly where their parts are. Well, foo, if you'd read your mail before installing you'd have know about this. I explicitly told you what I had done, and that there might be problems, and so since you knew what was going on with this, you should figure out the right thing to do and undo my changes if necessary.  Date: 9 DEC 1980 1750-EST From: JONL at MIT-MC (Jon L White) Subject: Where does SHBDMP live? To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, tlp at MIT-AI Re: TLP@MIT-AI 12/09/80 16:53:33 To: (BUG COMPLR) at MIT-AI COMPLR is trying to load some file from lspdmp; which does not exist on AI. A new SHBDMP and complr dump is on its way now, to AI and ML. Apparently you changed the SHARAB init file to dump its result on SHBDMP instead of LISP? This works fine on MC, but ML and AI don't have LSPDMP directories, and for the past year or so I've been :INSTALLing the dumps from COMLAP instead of rebuilding them on each system. In general, in the past, I've found the using links with sharab doesn't work -- the PURQIX file on LISP; may be linked to SYS;PURQIO because it is the built-in part of lisp's SUSPEND which finds those pages. But SHARAB-dumped files need to know exactly where their parts are.  TLP@MIT-AI 12/09/80 16:53:33 To: (BUG COMPLR) at MIT-AI COMPLR is trying to load some file from lspdmp; which does not exist on AI.  Date: 9 December 1980 11:27-EST From: Glenn S. Burke Subject: Macroexpanding toplevel forms To: JONL at MIT-MC cc: MOON at MIT-MC, BUG-COMPLR at MIT-MC [Excuse the goddamn spastic vt52] The "problem" is effectively that i am "illegally" using MACROLIST in order to have differing "macro definitions" for use when CALLED INTERPRETED and when expanded in code being compiled. Note that checking the value of COMPILER-STATE causes failure in other cases: specifically, the case where a macro being expanded during compilation contains code which calls another macro. If that macro examines the value of COMPILER-STATE it then will think that IT is being expanded by the compiler. The problem is that MACROLIST seems to have no formal definition of what it is used for. The compiler uses it for holding the definitions of macros which are "redefining system functions", a use i find extremely questionable, because then the case of a macro-calling-a-macro again fails, because the Lisp interpreter does not recognize the existence of MACROLIST when looking for a definition (which is as it should be). I don't think it is correct for the compiler to use what is on MACROLIST to expand code which is not being compiled. Saying that i should check the value of COMPILER-STATE simply means that i have to have TWO definitions of everything inside of every one of these "macros", which is ridiculous. Even the multics compiler has a *MACRO property which it does not confuse with a definition valid for interpreted use. Probably the best solution is to have a clearly defined feature: the COMPILER:OPTIMIZERS property. It can't be too difficult to implement. (I can even give you the code in LSB which macro-expands-code-being-compiled, and hacks these.)  Date: 9 December 1980 11:10-EST From: Glenn S. Burke Subject: Macroexpanding toplevel forms To: JONL at MIT-MC cc: MOON at MIT-MC, BUG-COMPLR at MIT-MC The "problem" is effectively that i am "illegally" using MACROLIST in order to have differing "macro definitions" for use when CALLED INTERPRETED and when expanded in code being compiled. Note that checking the value of COMPILER-STATE causes failure in other cases: specifically, the case where a macro being expanded during compilation contains code which calls another macro. If that macro examines the value of COMPILER-STATE it then will think that IT is being expanede by the compiler.  Date: 9 DEC 1980 0718-EST From: JONL at MIT-MC (Jon L White) Subject: Macroexpanding toplevel forms To: GSB at MIT-MC CC: MOON at MIT-MC, (BUG COMPLR) at MIT-MC I hope you're not serious about not macroexpanding: MOON5@MIT-ML 12/09/80 00:46:45 Here is a good reason not to macroexpand arguments to top-level forms in the file being compiled. Try using LOOP in this fashion, the resulting FASL file will get "GOFOO undefined function". The reason is that LOOP thinks it is being macroexpanded in the compiler and runs into a typical Maclisp compiler/interpreter incompatibility. The bug here is entirely in LOOP -- it should be checking COMPILER-STATE and producing the GOFOO stuff only when it is 'COMPILE (as opposed to 'MAKLAP or 'DECLARE or 'TOPLEVEL). Also, since the GOFOO is entirely ONE BIG KLUDGE, it is not a documented feature of the copiler, and is not a part of any compiler/interpreter incompatibility. Those that use kludges (as indeed we all must from time to time) must take the "slings and arrows of outrageous fortune".  MOON5@MIT-ML 12/09/80 00:46:45 To: (BUG COMPLR) at MIT-ML CC: GSB at MIT-ML Here is a good reason not to macroexpand arguments to top-level forms in the file being compiled. Try using LOOP in this fashion, the resulting FASL file will get "GOFOO undefined function". The reason is that LOOP thinks it is being macroexpanded in the compiler and runs into a typical Maclisp compiler/interpreter incompatibility.  Date: 8 DEC 1980 0940-EST From: JONL at MIT-MC (Jon L White) Subject: "bean-bag" bugs To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC Following problem is fixed now, with a COMPLR fix file for version 1045: GSB@MIT-ML 12/08/80 08:36:46 Re: xcomplr not fixed, it is broken more In the following, in XCOMPLR 1045, BAR compiles but FOO does not. (defun bar (x) (and (cdr (rplacd frob x)) (setq frob (last (cdr frob))))) (defun foo (x) (and (cdr (rplacd frob (cdr x))) (setq frob (last (cdr frob))))) I hope this just doesn't push the bug into some other corner, but a lot of test cases have been tried now, including your foo and bar.  GSB@MIT-ML 12/08/80 08:36:46 Re: xcomplr not fixed, it is broken more To: (BUG COMPLR) at MIT-ML In the following, in XCOMPLR 1045, BAR compiles but FOO does not. (declare (special frob)) (defun bar (x) (and (cdr (rplacd frob x)) (setq frob (last (cdr frob))))) (defun foo (x) (and (cdr (rplacd frob (cdr x))) (setq frob (last (cdr frob)))))  Date: 8 DEC 1980 0451-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, HENRY at MIT-MC CC: MACSYMA-I at MIT-MC JONL@MIT-MC 12/05/80 04:50:18 Re: Fresh COMPLR (or XCOMPLR) ! To: (BUG LISP) at MIT-MC, henry at MIT-AI CC: (BUG COMPLR) at MIT-MC, MACSYMA-I at MIT-MC Almost always when I use a "used" compiler to compile a file (i.e., one that has already compiled some other file), the result has gibberish in many of the list-structure parts in the FASL. I am thankful this has never happened to me as in the course of compiling for MACSYMA, I have used the same loading of COMPLR to compile many MACSYMA source files for over 6 years now. Maybe the fact that I call (INITIALIZE) between source file compilations has saved me, I don't know. JONL, since you maintain COMPLR, have you tracked down the phenomenon you describe?  SJOBRG@MIT-AI 12/07/80 15:00:33 To: (BUG COMPLR) at MIT-AI CC: SJOBRG at MIT-AI Consider the following two function definitions: (array EA flonum 1) ;error array (declare (flonum (Albedo6 fixnum fixnum))) (defun Albedo6 (x y) (declare (fixnum x y) (flonum Z R H RHO err)) (Set-surface-orientation x y) (let ((Z (float (Elevation x y))) (R (if (shadow? x y) 0.0 (cos-thetai))) (H (*$ 0.5 (1+$ (UN)))) (RHO (Albedo x y))) (let ((err (-$ (Landsat x y) (+$ (*$ (+$ (X 0) (*$ (X 1) Z)) R RHO) (-$ (X 2) (*$ (X 3) Z)) (*$ (-$ (X 4) (*$ (X 5) Z)) H RHO))))) (store (EA 0) (+$ (EA 0) (*$ err err)))) (//$ (-$ (Landsat x y) (-$ (X 2) (*$ (X 3) Z))) (+$ (*$ (+$ (X 0) (*$ (X 1) Z)) R) (*$ (-$ (X 4) (*$ (X 5) Z)) H))))) (declare (flonum (Albedo4 flonum flonum))) (defun Albedo4 (x y) (declare (fixnum x y) (flonum Z R RHO err)) (Set-surface-orientation x y) (let ((Z (float (Elevation x y))) (R (if (shadow? x y) 0.0 (cos-thetai))) (RHO (Albedo x y))) (let ((err (-$ (Landsat x y) (+$ (*$ (+$ (X 0) (*$ (X 1) Z)) R RHO) (-$ (X 2) (*$ (X 3) Z)))))) (store (EA 0) (+$ (EA 0) (*$ err err)))) (cond ((zerop R) 0.0) ;shadowed (t (//$ (-$ (Landsat x y) (-$ (X 2) (*$ (X 3) Z))) (*$ (+$ (X 0) (*$ (X 1) Z)) R)))))) The first one compiles fine, and the second, which follows exactly as shown above, generates messages like ... (COMMENT **FASL** 2068. (LAP ALBEDO6 SUBR)) (COMMENT **ERROR** ((ELEVATION X Y) NOT-OF-TYPE FIXNUM) First item in list is an argument somewhere, but is of the wrong type in function ALBEDO4) (COMMENT **ERROR** ((ALBEDO X Y) NOT-OF-TYPE FIXNUM) First item in list is an argument somewhere, but is of the wrong type in function ALBEDO4) (COMMENT **ERROR** ((LANDSAT X Y) NOT-OF-TYPE FIXNUM) First item in list is an argument somewhere, but is of the wrong type in function ALBEDO4) (COMMENT **ERROR** ((LANDSAT X Y) NOT-OF-TYPE FIXNUM) First item in list is an argument somewhere, but is of the wrong type in function ALBEDO4) ... All functions invoked by the above functions have been declared type flonum to allow NCALL'ing, except (shadow? ... ) which is a predicate. X is a flonum array. The file is SJOBRG;QUAD FOO.  Date: 7 DEC 1980 0758-EST From: JONL at MIT-MC (Jon L White) To: GJS at MIT-MC CC: (BUG COMPLR) at MIT-MC, HAL at MIT-MC Major bug fixed in XCOMPLR now, and minor lossage fixed too. GJS@MIT-AI (Sent by GJS0@MIT-AI) 12/05/80 21:53:17 Nothing really wrong with this code, but I wonder how it is generating that spurious PUSH, SUB? (defun bar () (subrcall nil (symeval (car (cxr 3 *barf))))) spurious PUSH, SUB no longer generated. Also, you analysis, that a RPLACX was invalidating an "optimization" was correct, and the bug reported below is now fixed too. GJS@MIT-AI 11/30/80 02:52:45 I have just spent 5 hours tracking down a compiler failure, ugh. The compiler is so clever, that it shafted me again... Look at the tag G0022 in the (LAP EVAL-COMB-3 SUBR), below. The optimizer seems to have noticed that the second elided section does not clobber reg#7 so it makes use of the common subexpression from the JUMPN 7,G0023 in the computation of the JUMPE 7,G0028. But it hasn't noticed that the HRLM clobbers a special variable which was used in the computation of the predicate. Thus the HRLM invalidates the bum.  Date: 6 DEC 1980 0440-EST From: JONL at MIT-MC (Jon L White) Subject: 5 Minute bug To: GJS at MIT-MC CC: (BUG COMPLR) at MIT-MC Tnx for bringing this up: GJS@MIT-AI (Sent by GJS0@MIT-AI) 12/05/80 21:53:17 (defun bar () (subrcall nil (symeval (car (cxr 3 *barf))))) (LAP BAR SUBR) (MOVE 1 (SPECIAL *BARF)) (HLRZ 1 1 1) (JSP T (CARCDR 36) 0 CDDAAR) (PUSH P 1) ;??? (SUB P (% 0 0 1 1)) ;??? (JRST 0 0 1) () one line in COMPFORM was the offender (EQ FNARGS (CAAR SPLDLST)) ==> (EQ (CAR FNARGS) (CAAR SPLDLST)) Will be fixed in next release of XCOMPLR, which should be in a few hours anyway.  GJS@MIT-AI (Sent by GJS0@MIT-AI) 12/05/80 21:53:17 To: (BUG COMPLR) at MIT-AI Nothing really wrong with this code, but I wonder how it is generating that spurious PUSH, SUB? (defun bar () (subrcall nil (symeval (car (cxr 3 *barf))))) (LAP BAR SUBR) (ARGS BAR (() . 0)) (MOVE 1 (SPECIAL *BARF)) (HLRZ 1 1 1) (JSP T (CARCDR 36) 0 CDDAAR) (PUSH P 1) ;??? (SUB P (% 0 0 1 1)) ;??? (JRST 0 0 1) ()  Date: 5 DEC 1980 0633-EST From: JONL at MIT-MC (Jon L White) Subject: Possible EVONCE bug in COMPLR To: GJC at MIT-MC CC: RWK at MIT-MC, (BUG COMPLR) at MIT-MC This is entirely due to data-rot, which has been corrected in XCOMPLR (which, by the way, should become COMPLR sometime today).  Date: 5 DEC 1980 0630-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG COMPLR) at MIT-MC CC: RWK at MIT-MC :CL MAXSRC;TRMODE shows what I think is some EVONCE bug. error is ;NSYM UNBOUND VARIABLE presumably during macro expansion of some SETF.  Date: 5 December 1980 04:57-EST From: George J. Carrette Subject: Fresh COMPLR (or XCOMPLR) ! To: JONL at MIT-MC cc: BUG-COMPLR at MIT-MC, BUG-LISP at MIT-MC, MACSYMA-I at MIT-MC, henry at MIT-AI Date: 5 DEC 1980 0450-EST From: JONL (Jon L White) To: (BUG LISP), henry at MIT-AI cc: (BUG COMPLR), MACSYMA-I Re: Fresh COMPLR (or XCOMPLR) ! Almost always when I use a "used" compiler to compile a file (i.e., one that has already compiled some other file), the result has gibberish in many of the list-structure parts in the FASL. Seems like that happens to me only when I ^G during compilation. One side effect from too much COMPLR usage is brain damage.  Date: 5 DEC 1980 0450-EST From: JONL at MIT-MC (Jon L White) Subject: Fresh COMPLR (or XCOMPLR) ! To: (BUG LISP) at MIT-MC, henry at MIT-AI CC: (BUG COMPLR) at MIT-MC, MACSYMA-I at MIT-MC Almost always when I use a "used" compiler to compile a file (i.e., one that has already compiled some other file), the result has gibberish in many of the list-structure parts in the FASL.  GSB@MIT-ML 12/04/80 01:30:31 Re: making life hard To: (BUG COMPLR) at MIT-ML The "multiple entry with duplicated name" error wwhich comes from faslap doesn't say what entry was duplicated, only the initial lap function name.  Date: 2 December 1980 18:00-EST From: Glenn S. Burke Subject: MAX not open-coded To: BUG-complr at MIT-MC cc: Guy.Steele at CMU-10A, MOON at MIT-MC The compiler already has the smarts to hack MAX and MIN when it knows the argument types. It succeeds well with lots of other things. The grotesquery is that the lsubr calling sequence makes trivial calls to them not only take longer, but result in more inline code, between pushing things on the stack and making pdl-numbers. Pretty please?  GJS@MIT-AI 11/30/80 03:18:17 To: (BUG COMPLR) at MIT-AI CC: HAL at MIT-AI I have an ultra-simple case of the screw: (defun barf () (cond ((= (cxr 1 *ugh) 0) (setq *foo 1)) (t (rplacx 1 *ugh 0))) (cond ((not (= (cxr 1 *ugh) 0)) (setq *foobaz 2)) (t (setq *foobaz 3)))) (COMMENT **** *UGH Undeclared - taken as SPECIAL in function BARF) (COMMENT **** *FOO Undeclared - taken as SPECIAL in function BARF) (COMMENT **** *FOOBAZ Undeclared - taken as SPECIAL in function BARF) (LAP BARF SUBR) (ARGS BARF (() . 0)) (HLRZ 7 @ (SPECIAL *UGH)) (MOVE 7 0 7) (JUMPN 7 G0002) (MOVEI 5 '1) (MOVEM 5 (SPECIAL *FOO)) (JRST 0 G0001) G0002 (MOVEI 1 '0) (HRLM 1 @ (SPECIAL *UGH)) ;Here you screw the G0001 (JUMPE 7 G0006) ;poor bastard. (MOVEI 1 '2) (MOVEM 1 (SPECIAL *FOOBAZ)) (JRST 0 G0005) G0006 (MOVEI 1 '3) (MOVEM 1 (SPECIAL *FOOBAZ)) G0005 (POPJ P) ()  GJS@MIT-AI 11/30/80 02:52:45 To: (BUG COMPLR) at MIT-AI CC: GJS at MIT-AI, HAL at MIT-AI I have just spent 5 hours tracking down a compiler failure, ugh. The compiler is so clever, that it shafted me again... why is it always me? In any case. The evidence is in SCHEME;NEWSYS BUGLAP, compiled from SCHEME;NEWSYS BUG. Look at the tag G0022 in the (LAP EVAL-COMB-3 SUBR), below. The optimizer seems to have noticed that the second elided section does not clobber reg#7 so it makes use of the common subexpression from the JUMPN 7,G0023 in the computation of the JUMPE 7,G0028. But it hasn't noticed that the HRLM clobbers a special variable which was used in the computation of the predicate. Thus the HRLM invalidates the bum. ... (HLRZ 7 @ (SPECIAL *FREE-MARKS)) (MOVE 7 0 7) (JUMPN 7 G0023) ... (JRST 0 G0022) G0023 (MOVEI 1 '0) (HRLM 1 @ (SPECIAL *FREE-MARKS)) G0022 (JUMPE 7 G0028) ... Ugh, bletch. What shall I do?  Date: 28 NOV 1980 1348-EST From: RLB at MIT-MC (Richard L. Bryan) To: (BUG COMPLR) at MIT-MC COLLECTATOMS no longer runs useratoms-hook for SYMBOLs. This has broken the NIL simulator. My fix will not affect the rest of the universe.  Date: 12 NOV 1980 1957-EST From: JONL at MIT-MC (Jon L White) To: RWK at MIT-MC CC: DUFTY at MIT-MC, KMP at MIT-MC, (BUG COMPLR) at MIT-MC Date: 12 November 1980 17:46-EST From: Robert W. Kerns Subject: XCOMPLR completely broken . . . I'd back up to a previous version of XCOMPLR, but unfortunately you have deleted the relavant SHARAB dump. New XCOMPLR version 1039 has COUTPUT etc in it now. By the way, there was one losing XC.DMP 1037 (which had "lost" PURQIX 2051), but XC.DMP 1033 has always been around and has not been "undercut".  Date: 12 NOV 1980 1916-EST From: JONL at MIT-MC (Jon L White) To: DUFTY at MIT-MC, KMP at MIT-MC, RWK at MIT-MC CC: (BUG COMPLR) at MIT-MC Date: 12 November 1980 17:46-EST From: Robert W. Kerns Subject: XCOMPLR completely broken If I define COUTPUT the way it used to be defined, I get MACRO-EXPAND as an undefined function. Really? What is with these incompatible changes of flushing COUTPUT and MACRO-EXPAND, anyway? Machine crashed yesterday while I was editing several COMPLR files -- and one of my buffers didn't get written out, (MAKLAP, the one with COUTPUT in it). Apparently several compilations went thru without noticing the lack of COUTPUT, but I will fix pronto.  Date: 12 NOV 1980 1746-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: XCOMPLR completely broken To: (BUG COMPLR) at MIT-MC CC: DUFTY at MIT-MC, KMP at MIT-MC If I define COUTPUT the way it used to be defined, I get MACRO-EXPAND as an undefined function. Really? What is with these incompatible changes of flushing COUTPUT and MACRO-EXPAND, anyway? I'd back up to a previous version of XCOMPLR, but unfortunately you have deleted the relavant SHARAB dump.  Date: 12 NOV 1980 1721-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: More brokenness. To: (BUG COMPLR) at MIT-MC CC: DUFTY at MIT-MC COUTPUT has been deleted from COMAUX, which makes it impossible to compile NILCOM;SUBSEQ >  Date: 8 NOV 1980 0805-EST From: JONL at MIT-MC (Jon L White) Subject: FERROR in COMPLR To: dla at MIT-EECS CC: (BUG COMPLR) at MIT-MC, sjk at MIT-EECS Part the problem was that this symbol was assembled without any ARGS information into the initial LISP environment; this has been corrected in the current assembly on MC, but this version won't be transported to EE until I can certify that the remaining "latent features" of the VTS code are gone.  Date: 7 Nov 1980 1820-EST From: Dave Andre Subject: FERROR. To: sjk at MIT-EE, bug-complr at MIT-MC cc: DLA at MIT-EE COMPLR at EE thinks that FERROR is an *EXPR and barfs appropriately. -------  Date: 6 NOV 1980 0850-EST From: JONL at MIT-MC (Jon L White) Subject: CMP-LAPFUN To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 11/05/80 23:44:13 Re: cmp-lapfun Come come now. I never said it should never do a putprop. What i said was that given the tests it was doing, it was only doing a putprop when it was redundant. But it SHOULD go and do nothing at all if the function property is not SUBR/LSUBR/FSUBR. That goes for UNDFUNS also. I believe you're wrong about that Glen -- the tests were designed to stop it from puttpropping a *EXPR/*LEXPR/*FEXPR property when the function being defined is not an SUBR/LSUBR/FSUBR. The new version will also not touch UNDFUNS, but currently it is always removing a lap function from UNDFUNS. But regardless of current bugs, the new one is correct, and as I said before, it will come up in the new XCOMPLR (version 1034 or greater).  Date: 6 November 1980 00:24-EST From: Alan Bawden Subject: NO! NO!! NO!!! To: BUG-COMPLR at MIT-MC cc: ALAN at MIT-MC (COMMENT **** (PROGN FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function PROGN) (COMMENT **FASL** 1509. (LAP PROGN C-CONVERT-SUBR)) (COMMENT **** (PROG1 FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function PROG1) (COMMENT **FASL** 1516. (LAP PROG1 C-CONVERT-SUBR)) (COMMENT **** (COMMENT FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function COMMENT) (COMMENT **FASL** 1686. (LAP COMMENT C-CONVERT-SUBR)) (COMMENT **** (DECLARE FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function DECLARE) (COMMENT **FASL** 1731. (LAP DECLARE C-CONVERT-SUBR)) (COMMENT **** (RETURN FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function RETURN) (COMMENT **FASL** 2093. (LAP RETURN C-CONVERT-SUBR)) (COMMENT **** (GO FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function GO) (COMMENT **FASL** 2169. (LAP GO C-CONVERT-SUBR)) (COMMENT **** (QUOTE FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function QUOTE) (COMMENT **FASL** 2482. (LAP QUOTE C-CONVERT-SUBR)) (COMMENT **** (SETQ FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function SETQ) (COMMENT **FASL** 2528. (LAP SETQ C-CONVERT-SUBR)) (COMMENT **** (AND FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function AND) (COMMENT **FASL** 2863. (LAP AND C-CONVERT-SUBR)) (COMMENT **** (OR FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function OR) (COMMENT **FASL** 2966. (LAP OR C-CONVERT-SUBR)) (COMMENT **** (NOT FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function NOT) (COMMENT **FASL** 3069. (LAP NOT C-CONVERT-SUBR)) (COMMENT **** (PROG2 FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function PROG2) (COMMENT **FASL** 3458. (LAP PROG2 C-MACRO-SUBR)) (COMMENT **** (PROG FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function PROG) (COMMENT **FASL** 3486. (LAP PROG C-MACRO-SUBR)) (COMMENT **** (COND FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function COND) (COMMENT **FASL** 3510. (LAP COND C-MACRO-SUBR)) (COMMENT **** (DO FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function DO) (COMMENT **FASL** 3618. (LAP DO C-MACRO-SUBR)) (COMMENT **** (EVAL FROM USER FILE |DSK:LIL;KERNEL >|) Redefining system function in function EVAL) (COMMENT **FASL** 4104. (LAP EVAL C-DECLARE-SUBR))  GSB@MIT-ML 11/05/80 23:44:13 Re: cmp-lapfun To: JONL at MIT-MC CC: (BUG COMPLR) at MIT-ML Come come now. I never said it should never do a putprop. What i said was that given the tests it was doing, it was only doing a putprop when it was redundant. But it SHOULD go and do nothing at all if the function property is not SUBR/LSUBR/FSUBR. That goes for UNDFUNS also.  Date: 5 NOV 1980 1257-EST From: JONL at MIT-MC (Jon L White) To: GBS at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 11/04/80 23:48:37 CMP-LAPFUN is totally brain-damaged. It calls PUTPROP with incorrect argument ordering, thus putting T properties all over the place. It's unclear why it calls PUTPROP anyway, since it calls it only when it doesn't need to, or when the function hasn't been declared (in which case it puts NIL on as the T property). If the functional property being defined is not one of SUBR LSUBR FSUBR it should do absolutely NOTHING, not even touch UNDFUNS. I've fixed the inadvertent misordering of the args to that PUTPROP, and it will appear in the next XCOMPLR, which should be any day now. But I believe you're wrong about not needing any putprop -- this is supposed to inform the system that, say, FOOBAR is not undefined in this file.  GSB@MIT-ML 11/05/80 02:38:57 Re: Goddamned fucking stupid shits To: (BUG COMPLR) at MIT-ML Attempting to bind BASE to 'ROMAN causes the compiler to eat shit. I have complained about this many times before, in the context of (EQUAL BASE 'ROMAN). COME ON!! WAKE UP!!  GSB@MIT-ML 11/04/80 23:48:37 To: (BUG COMPLR) at MIT-ML CMP-LAPFUN is totally brain-damaged. It calls PUTPROP with incorrect argument ordering, thus putting T properties all over the place. It's unclear why it calls PUTPROP anyway, since it calls it only when it doesn't need to, or when the function hasn't been declared (in which case it puts NIL on as the T property). If the functional property being defined is not one of SUBR LSUBR FSUBR it should do absolutely NOTHING, not even touch UNDFUNS.  Date: 26 OCT 1980 1512-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG COMPLR) at MIT-MC There is no COMPLR currently on XX. Can you please bring it back? Thanks. -kmp  Date: 18 OCT 1980 1754-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC There are now three lists on MC. BUG-LISP (add yourself here to just be on BUG-LISP) BUG-COMPLR (add yourself here to just be on BUG-COMPLR) LISP-AND-COMPLR-PEOPLE (add yourself here to be on both) I don't think the two lists should get merged, but those of you interested in complr bugs should realize there is a list you can put yourself on. If you were on bug-lisp and bug-complr already, you have been moved to LISP-AND-COMPLR-PEOPLE. -kmp  Date: 18 OCT 1980 1113-EDT From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 10/17/80 17:42:28 Re: how to save code, time, and make baktrace work all at once When an lsubr is called from code, rather than doing ... why not do (pushj p foo) with FOO being a random branch: foo (push p arg1) ... (movni t nargs) (jcall 16 'fn) This gives one less instruction executed, one less word of bps, and pc flags on the stack for baktrace to find. This is a verry interesting idea -- It would require some capability of the COMPLR which it currently doesn't have in a general way (namely, compilation to multiple "sections" of code), but that shouldn't be too hard to do. The reason for the two instructions, (MOVEI T ADDR) (PUSH P T) as opposed to the original (PUSH P (% 0 0 ADDR)) was so that someday there could be position-independent code, and to achieve that would only mean modifying the (MOVEI T ADDR) instruction. But your idea should work well too in the position-independent model.  Date: 18 OCT 1980 1059-EDT From: JONL at MIT-MC (Jon L White) Subject: (DEFUN ( FOO BAR) ...) To: ALAN at MIT-MC CC: (BUG COMPLR) at MIT-MC, (BUG LISP) at MIT-MC Date: 18 October 1980 06:39-EDT From: Alan Bawden I complained a long time ago that something of the form (defun (let foo bar) ...) caused the following nasty error message: (COMMENT **** (LET FROM USER FILE #FILE-IN-|DSK:LIL;KERNEL 262|-70722) Redefining system function in function LET) Now I am being screwed because the presence of this message in the unfasl file makes it impossible to READ back in again. (I guess I am lucky that there wasn't a #F macro defined.) Well the random appearance of a useless error comment doesn't seem nearly as bad as the inablility to read in the unfasl file -- so I've fixed both; this fix only appears in XCOMPLR now, but within shortly a new XLISP (and XCOMPLR) will be announced, and after a few weeks they will replace the current LISP (and COMPLR). (By the bye, is there some special reason that this plaint should go to BUG-LISP too? or should BUG-COMPLR forward all comments to BUG-LISP?)  Date: 18 October 1980 06:39-EDT From: Alan Bawden Subject: Double Screw To: BUG-COMPLR at MIT-MC cc: BUG-LISP at MIT-MC I complained a long time ago that something of the form (defun (let foo bar) ...) caused the following nasty error message: (COMMENT **** (LET FROM USER FILE #FILE-IN-|DSK:LIL;KERNEL 262|-70722) Redefining system function in function LET) Now I am being screwed because the presence of this message in the unfasl file makes it impossible to READ back in again. (I guess I am lucky that there wasn't a #F macro defined.) Could someone fix the original bug or perhaps just fix the place where file objects are PRINTed into unfasl files?  GSB@MIT-ML 10/17/80 17:42:28 Re: how to save code, time, and make baktrace work all at once To: (BUG COMPLR) at MIT-ML When an lsubr is called from code, rather than doing ... (movei t return-address) (push p t) (push p arg1) ... (movni t nargs) (jcall 16 'fn) return-address ... why not do (pushj p foo) ... with FOO being a random branch: foo (push p arg1) ... (movni t nargs) (jcall 16 'fn) This gives one less instruction executed, one less word of bps, and pc flags on the stack for baktrace to find.  Date: 16 OCT 1980 1804-EDT From: JONL at MIT-MC (Jon L White) Subject: ALLUSERATOMS and USERATOMS-INTERN To: GSB at MIT-MC CC: (BUG COMPLR) at MIT-MC GSB@MIT-ML 10/13/80 04:24:13 the ALLUSERATOMS and USERATOMS-INTERN variables should be reset to NIL by FASL-START and/or FASL-CLOSEOUT, since they are only valid for a particular fasl file generation. CORRECT. I'VE EDITED THIS IN THE SOURCE, AND IT WILL BE IN THE NEXT XCOMPLR WHICH WILL BE DUMPED OUT WITH THE UPCOMING XLISP (VERSION 2025)  Date: 16 OCT 1980 1632-EDT From: RZ at MIT-MC (Richard E. Zippel) To: (BUG COMPLR) at MIT-MC The ``Obslete form - please use *THROW ...'' message misspells Obsolete.  Date: 13 October 1980 16:50-EDT From: Kent M. Pitman Subject: +INTERNAL-STRING-MARKER lossage To: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC cc: KMP at MIT-MC, RWK at MIT-MC, GJC at MIT-MC, GSB at MIT-ML ;; Intern the ``string'' MY-BUG ... (EVAL-WHEN (EVAL COMPILE) (INTERN "MY-BUG")) ;; Define an ordinary function ... (DEFUN MY-BUG (X) X) ----- This works niftily in the interpreter. This doesn't work if you try to compile and fasload it into a lisp. I wonder why? Could it have anything to do with the +INTERNAL-STRING-MARKER that is still on the *interned* symbol in the compiler after the (INTERN "MY-BUG") is executed? Probably. I think that probably the compiler should also redefine INTERN to do a normal intern only if that property is absent. Presumably if the property is present, you should treat the symbol as a string. What does that mean? Well, how about... (DEFUN REDEFINED-INTERN (X) (COND ((AND (SYMBOLP X) (GET X '+INTERNAL-STRING-MARKER)) (STANDARD-INTERN (COPYSYMBOL X ()))) ; Don't copy plist!! (T (STANDARD-INTERN X)))) ie, if the thing has such a marker, it's a string. strings cannot live on the obarray, so get a symbol which looks like the string and put *that* on the obarray... if you don't do something like this, the result is confusing. it lost me about 2 hours last night trying to find out why my function ran interpreted but lost compiled ... disappeared. the UNFASL file even claims that the function is getting defined... -kmp  GSB@MIT-ML 10/13/80 04:24:13 To: (BUG COMPLR) at MIT-ML the ALLUSERATOMS and USERATOMS-INTERN variables should be reset to NIL by FASL-START and/or FASL-CLOSEOUT, since they are only valid for a particular fasl file generation.