Date: 3 December 1980 21:22-EST From: Robert W. Kerns Subject: ~ --> To: BUG-LISP at MIT-MC MOVEI A,STR%AR JSP TT,$GCMKAR is wrong. STR%AR becomes a *FIXNUM* array, and $GCMKAR doesn't check the type of the array before hacking the AOBJN ptr. Thus this FIXNUM array gets marked from. Thus RLB's bug report of XNIL having all these random arrays left lying around. It seems that it was marking the GCMKL or some sublist, and some sublist of the freelist, and who knows what else. It'll probably break something else, but for now I'll patch out the two offending instructions until JONL can figure out what he really meant. I have no model of why this array has been built into LISP. How about an exposition? GCP6D is near the offending instructions.  Date: 3 December 1980 18:43-EST From: Kent M. Pitman Subject: BACKQ fixed? To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, JGA at MIT-MC Date: 3 December 1980 07:16-EST From: Jon L White You just moved the bug around! ` on hunks is broken now! Date: 2 December 1980 19:42-EST From: Kent M. Pitman Date: 2 December 1980 10:39-EST From: John G. Aspinall I just got ;BKPT +ibx-unhunkp| under the same sort of circumstances as yesterday's error. Um. I fixed this yesterday. JONL seems to have broken it. I fixed it again. . . . Well, here's the fourth attempt to get this bug flushed! Kent, you have to distinguish between just quotifying a thing, like `"abc", and descending it, like `(A . ,b .). I've put in some code near where that BKPT used to be to get this to work, and tested it on all cases so far mentioned in the mails. ----- There's no problem with having `(A . ,b .) turn into '(A . (|+internal-`-,-marker/|| . b) .) or whatever... At least then it does SOMETHING. All I'm complaining about is that I had it fixed so that it worked in some cases because someone needed the code to work to get his work done. Your making it breakpoint in that case means it doesn't work for anyone and that's totally useless to everyone. I doubt anyone does `(A . ,B .) while I am sure a lot of people use the strings package -- so I wanted something to work. I am fully aware that it doesn't do what the code was intended to do in full scale -- but it does allow JGA's code to run for the application he has, and that struck me as important -- especially since we had recent bug mail from him indicating that he was relying on this case to work. -kmp  Date: 3 DEC 1980 0716-EST From: JONL at MIT-MC (Jon L White) Subject: BACKQ fixed? To: KMP at MIT-MC CC: JGA at MIT-MC, (BUG LISP) at MIT-MC You just moved the bug around! ` on hunks is broken now! Date: 2 December 1980 19:42-EST From: Kent M. Pitman Subject: I don't think BACKQUOTE was fixed completely AGAIN... Date: 2 December 1980 10:39-EST From: John G. Aspinall Re: I don't think BACKQUOTE is fixed completely yet. I just got ;BKPT +ibx-unhunkp| under the same sort of circumstances as yesterday's error. Um. I fixed this yesterday. JONL seems to have broken it. I fixed it again. . . . Well, here's the fourth attempt to get this bug flushed! Kent, you have to distinguish between just quotifying a thing, like `"abc", and descending it, like `(A . ,b .). I've put in some code near where that BKPT used to be to get this to work, and tested it on all cases so far mentioned in the mails.  Date: 3 DEC 1980 0716-EST From: JONL at MIT-MC (Jon L White) Subject: BACKQ fixed? To: KMP at MIT-MC CC: JGA at MIT-MC, (BUG LISP) at MIT-MC You just moved the bug around! ` on hunks is broken now! Date: 2 December 1980 19:42-EST From: Kent M. Pitman Subject: I don't think BACKQUOTE was fixed completely AGAIN... Date: 2 December 1980 10:39-EST From: John G. Aspinall Re: I don't think BACKQUOTE is fixed completely yet. I just got ;BKPT +ibx-unhunkp| under the same sort of circumstances as yesterday's error. Um. I fixed this yesterday. JONL seems to have broken it. I fixed it again. . . . Well, here's the fourth attempt to get this bug flushed! Kent, you have to distinguish between just quotifying a thing, like `"abc", and descending it, like `(A . ,b .). I've put in some code near where that BKPT used to be to get this to work, and tested it on all cases so far mentioned in the mails.  Date: 2 December 1980 19:42-EST From: Kent M. Pitman Subject: I don't think BACKQUOTE was fixed completely AGAIN... To: BUG-LISP at MIT-MC, JGA at MIT-MC Date: 2 December 1980 10:39-EST From: John G. Aspinall Re: I don't think BACKQUOTE is fixed completely yet. I just got ;BKPT +ibx-unhunkp| under the same sort of circumstances as yesterday's error. In fact it was expanding `((lambda (x) (pnput (string-pnget x 7) T)) (string-append ,s1 ":" ,s2)) ----- Um. I fixed this yesterday. JONL seems to have broken it. I fixed it again. Can we please not install versions of the thing that can't do `"FOO" correctly? My correction is clearly marked. I don't think there's any excuse for having it ;BKPT on the guy for using a system-provided facility. Worse, if you $P'd the bug, you didn't get a correct answer when a perfectly reliable thing was to return (LIST 'quote x) on the thing. -kmp  Date: 2 DEC 1980 1742-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, MACSYMA-I at MIT-MC, ELLEN at MIT-MC The compiler is currently outputing ((LISP)DEFMAX) as an autoload property for FLUSH-MACROMEMOS where ((LISP) DEFMAX FASL) should rightfully be expected. The result of this is that it doesn't work in Macsyma. (1) That putprop should be conditional on there not being an autoload property already there. (2) You'd save a few CONS's if you didn't do (PUTPROP 'FLUSH-MACROMEMOS '((LISP) ...) ...) but rather did (PUTPROP 'FLUSH-MACROMEMOS (GET 'MACROMEMO 'AUTOLOAD) 'AUTOLOAD) so that you got the piece of structure already existed instead of locking down new cons's. (3) I don't think you should assume that the second filename of an autoload is going to default to FASL. Macsyma doesn't default the second filename to anything and gives a [DEFMAX,*,DSK,LISP] NO SUCH FILE type error ... I think since you KNOW you want the FASL file, you should put it there. I think that convention should be made clear in Maclisp -- that the default autoload handler will look for FASL files, but that user autoload handlers needn't be bound by that and that the Maclisp system will define system autoloads to actually have the word FASL there. This broke PRIMER in Macsyma. ELLEN has added in an explicit LOAD of DEFMAX at the top of SCRIPT INTRO (which uses `... interpreted and so loads DEFMAX). When this explicit load becomes removable, please let us know. Thanks.  Date: 2 December 1980 1034-EST (Tuesday) From: Guy.Steele at CMU-10A To: David A. Moon Subject: MAX not open-coded CC: bug-lisp at MIT-MC In-Reply-To: David A. Moon's message of 25 Nov 80 03:17-EST Message-Id: <02Dec80 103444 GS70@CMU-10A> I lobbied some time ago to change the current MAX and MIN to MAXIMUM and MINIMUM, and have MAX, MIN, MAX$, MIN$ -- but it would have been incompatible. Sigh.  Date: 2 DEC 1980 1039-EST From: JGA at MIT-MC (John G. Aspinall) Subject: I don't think BACKQUOTE is fixed completely yet. To: (BUG LISP) at MIT-MC CC: JGA at MIT-MC I just got ;BKPT +ibx-unhunkp| under the same sort of circumstances as yesterday's error. In fact it was expanding `((lambda (x) (pnput (string-pnget x 7) T)) (string-append ,s1 ":" ,s2)) John.  Date: 2 DEC 1980 0819-EST From: JONL at MIT-MC (Jon L White) Subject: DEFUN with &WHOLE To: WGD at MIT-MC CC: (BUG LISP) at MIT-MC Re: Date: 1 December 1980 23:08-EST From: William G. Dubuque (defun foo ((&whole x) y) &whole) then (foo '(a b) 1) => a. But (defun foo (&whole x) &whole) => infinite recursion. First, &WHOLE is supposed to have absolutely no special meaning with DEFUN; what happened here was that DEFUN was tricked by an inadvertent ordering of several atom headers (as with so many other places inthe LISP system, a test like (MEMQ X '(ATOM1 ATOM2 ...)) is done merely by ensuring that the symbol headers for ATOM1, ATOM2 etc occupy consecutive locations, and then just doing a between-p address comparison. Pooor &WHOLE happened to be in the middle of some range which it shouldn't. I patched XLISP, and edited the source.  Date: 2 DEC 1980 0700-EST From: JONL at MIT-MC (Jon L White) Subject: YES-OR-NO-P and friend To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 1 December 1980 19:11-EST From: Alan Bawden y-or-n-p and yes-or-no-p should accept 0 arguments. Fixed now. Also reminder that the first agrument, the stream, is super-optional, in that (YES-OR-NO-P "..." frob1 frob2 ...) is entirely equivalent to (YES-OR-NO-P QUERY-IO "..." frob1 frob2 ...) In MacLISP, the usual standard-output is TYO, and that won't do for a stream to YES-OR-NO-P, since it isn't bi-directional. Thus you have your choice of either T, or some bi-directional SFA (which is what QUERY-IO is).  Date: 2 DEC 1980 0649-EST From: JONL at MIT-MC (Jon L White) Subject: || To: (BUG LISP) at MIT-MC I just found the most incredible screw in current XLISP (patched now in dump, and corrected in source). Due to a typo, the PNAME for +INTERNAL-WITHOUT-INTERRUPTS was getting identified with that of ||, and it caused the latter to have a pname list containing a null. Poooor FASLAP would die horribly. If you saw any such irrepropducible bug, be happy that it is now gone.  Date: 2 DEC 1980 0510-EST From: JONL at MIT-MC (Jon L White) Subject: Another bug (almost!) bites the dust To: KMP at MIT-MC, JGA at MIT-MC CC: (BUG LISP) at MIT-MC Regarding Date: 1 December 1980 15:25-EST From: John G. Aspinall Subject: STRING and ` . . . `(foo "bar") (FOO T) The bug here related to hunks which weren't VECTORs, thus `(foo #(a b c)) would win OK. However, backquote on hunks has been losing for a long time. Date: 1 December 1980 16:01-EST From: Kent M. Pitman Oh, well. Another bug bites the dust. I made a patch to NILCOM;BACKQ and recompiled it so that the `"FOO" bug doesn't occur. . . . So I took this opportunity to fix up the whole thing, including other kinds of backquoted hunk lossage. For the record, there is a simple place in the (new) code where Q-sequences are backquoted over, and it would be a trivial thing to make ` work over, say, STRUCTures (if only we knew what we wanted to do about printing them!).  Date: 1 DEC 1980 2356-EST From: ALAN at MIT-MC (Alan Bawden) Subject: ................!!! To: (BUG LISP) at MIT-MC If you compile something like: (defun (cdr foo bar) (x y z) (list x y z)) (in XCOMPLR) you will no only get an obnoxious message from the compiler about redefining cdr (which you aren't). But when you load the fasl file the args property of the symbol cdr will be set to nil. (Not (nil . 3), just nil.)  Date: 1 DEC 1980 2308-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG LISP) at MIT-MC (defun foo ((&whole x) y) &whole) then (foo '(a b) 1) => a. But (defun foo (&whole x) &whole) => infinite recursion.  Date: 1 DEC 1980 1911-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC y-or-n-p and yes-or-no-p should accept 0 arguments.  Date: 1 DEC 1980 1601-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: STRING and ` To: JGA at MIT-MC CC: (BUG LISP) at MIT-MC Oh, well. Another bug bites the dust. I made a patch to NILCOM;BACKQ and recompiled it so that the `"FOO" bug doesn't occur. There was some bad #-conditionalization there where (COND ... ('T #+... #+...)) was reading as (COND ... ('T)) because both #+'s failed. I suspect one shoulda been #- but since they were essentially identical, I made a reasonable compromise which I think will not hurt anyone. Someone familiar with this ugly code should check my patch which was to |+ibx/||. The old and new code is pretty clearly marked. The new version of BACKQ is 44 and I've installed it on ITS. -kmp  Date: 1 DEC 1980 1541-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG NIL) at MIT-MC CC: (BUG LISP) at MIT-MC Hey, at least one of #8rT and #oT should not complain of T being non-numeric. One of them should just bind IBASE and read normally!  Date: 1 DEC 1980 1525-EST From: JGA at MIT-MC (John G. Aspinall) Subject: STRING and ` To: (BUG LISP) at MIT-MC CC: JGA at MIT-MC ;; In a bare lisp .... (load '((lisp) string)) `(foo ,"bar") (FOO "bar") `(foo "bar") (FOO T) ;; really ! ;;; without the string package loaded you get the usual `(foo "bar") --> (FOO |bar|) `(foo ,"bar") --> (FOO |bar|) John.  Date: 1 DEC 1980 1415-EST From: JONL at MIT-MC (Jon L White) Subject: DEFVST To: RLB at MIT-MC CC: (BUG LISP) at MIT-MC Finally looks like the new DEFVST is a winner. some features: 1) All selector macros share same code; also, all constructor macros share too. 2) Output of DEFVST macro is primarily a setup of a call to an internal initializatino function; output of cons-a-FOO is also minimal. 3) STRUCT-TYPEP uses the typep slot of the class object, thereby saving one slot which used to be in each instance. 4) Integrates smoothly with the CLASS system, whether or not it is initially loaded (by constructing up "skeletal" classes for the three big important ones, and keeping a list of skeletons which need to be "fleshed-out" when EXTEND is loaded.  Date: 1 DEC 1980 1117-EST From: JGA at MIT-MC (John G. Aspinall) Subject: STRING error messages To: (BUG LISP) at MIT-MC CC: JGA at MIT-MC (load '((lisp) string)) (setq a 'ards) (string-append "foo" a) ;ARDS ~1G~S does not pass the ~0G~S test, for function ~2G~S ? I don't think this is very informative. John.  Date: 1 DEC 1980 0604-EST From: JONL at MIT-MC (Jon L White) Subject: DEFUN To: (BUG LISP) at MIT-MC I would be nice if DEFUN checked for "documentation strings", like DEFUN& does. Also, I'm not sure if the following complaint was ever fixed: Date: 2 October 1980 18:24-EDT From: Kent M. Pitman Subject: DEFUN doesn't check enough By the way, with STRING loaded, (DEFUN "ABC" (X) ...) returns **SELF-EVAL**. I dread to think what is happening internally in order to achieve this wondrous effect. I suspect it thinks it sees a list in the name position and is randomly CDR'ing it. It seems to put a **CLASS-SELF-EVAL** property of (LAMBDA (X) ...) on it.  Date: 1 DEC 1980 0546-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC I dunno if this ever got replied to Date: 16 October 1980 16:57-EDT From: Kent M. Pitman (defun foo () '(expr definition)) (macro foo (nil) ''(macro definition)) (foo) => (macro definition) (funcall 'foo) => (expr definition) (apply 'foo ()) => ;IMPROPER USE OF MACRO - EVAL It's fixed in current XLISP.  Date: 1 DEC 1980 0505-EST From: JONL at MIT-MC (Jon L White) Subject: Incompatible Fsubr for SETF To: KMP at MIT-MC CC: GZ at MIT-MC, (BUG LISP) at MIT-MC For the record, there are *no* separate fasl files for XLISP and LISP -- a buggy fasl file is a buggy fasl file, even if the lisp into which it is loaded masks the problem. Re Date: 1 December 1980 04:51-EST From: Kent M. Pitman This is also `fixed' in Lisp if you have done a complex SETF that causes SETF FASL to load. Eg, . . . I bring this up not because I care about this instance, but it does bother me that we have no mechanism for filenaming or autoloading which allows us to separate the FASL files used by XLisp from the FASL files used by Lisp. I think this should be thought out more carefully and a real solution worked out. It has always been true (sadly) that there was a divergence between the FSUBR SETF and the macro; at one time even, there was a majority opinion that the value of SETF should be undefined.  Date: 1 DEC 1980 0451-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: (SETF (CDR X) Y) ... To: JONL at MIT-MC CC: GZ at MIT-MC, (BUG LISP) at MIT-MC This is also `fixed' in Lisp if you have done a complex SETF that causes SETF FASL to load. Eg, (LIST (SETQ A '(A B)) (SETF (CDR A) 'C) (SETF (SFA-GET (SFA-CREATE #'(LAMBDA N NIL) 1 "FOO") 0) 'A) (SETQ A '(A B)) (SETF (CDR A) 'C)) ;Loading SHARPM 66 ;Loading SETF 272 ;Loading DEFMAX 64 ;Loading MACAID 98 ((A . C) (A . C) A (A . C) C) Note the 2nd and 5th elements are different. Sigh. I bring this up not because I care about this instance, but it does bother me that we have no mechanism for filenaming or autoloading which allows us to separate the FASL files used by XLisp from the FASL files used by Lisp. I think this should be thought out more carefully and a real solution worked out.  Date: 1 DEC 1980 0445-EST From: JONL at MIT-MC (Jon L White) Subject: DEFMACROs with DECLAREs in them To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC I don't remember if there has been a reply to Date: 2 November 1980 18:10-EST From: Kent M. Pitman (DEFMACRO FOO (&REST BAR) (DECLARE (SPECIAL BAR)) (FUNCALL BAR)) gets the following error from the COMPLR: (COMMENT **ERROR** (DECLARE (SPECIAL BAR)) Local declaration at wrong place in function |FOO MACRO|) but my earlier note about fixing (DEFMACRO FOO () () ) mentions that the current DEFMACRO attempts to be clever about finding DECLAREs and documentation strings.  Date: 1 DEC 1980 0444-EST From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC Moreover, I suspect that in the case of ((LAMBDA (F &FUNCTION G) (SETF #'G F) #'G) #'H) or whatever syntax is or will eventually bind functions locally, you'd want this to return #'H in compiled code. Making (SETF #'... ) mean the same as (SETF (FSYMEVAL '...) ...) is like making (SETF sym ...) mean the same as (SETF (EVAL 'sym) ...). You don't want to enforce a special variable requirement to make things work. Now in Maclisp it turns out that there are no local functions, so having (SETF #'F #'G) do something like (PUTPROP 'F #'G 'EXPR) is an ok implementation; but you don't want that to be its definition.  Date: 1 DEC 1980 0434-EST From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC, (BUG LISP) at MIT-MC (SETF #'F #'G) on the lisp machine does the right thing -- it puts the function G in F's function cell.  Date: 1 DEC 1980 0433-EST From: JONL at MIT-MC (Jon L White) Subject: return value of SETF To: GZ at MIT-MC CC: (BUG LISP) at MIT-MC Date: 11 November 1980 02:58-EST From: Gail Zacharias (setf (cdr x) y) returns x. I thought the value of a setf was its second arg? This is fixed in XLISP, since the former inconsistent FSUBR version had to go away (lack of space, gleeep!).  Date: 1 DEC 1980 0431-EST From: JONL at MIT-MC (Jon L White) Subject: SETF on functions cells? To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 11 November 1980 17:37-EST From: Kent M. Pitman Shouldn't (SETF #'ADD3 #'(LAMBDA (X) (PLUS X 3))) work? It says that (FUNCTION ADD3) is an obscure format... Shouldn't this intention be written as (SETF (FSYMEVAL 'ADD3) #'(LAMBDA (X) (PLUS X 3))) which would get expanded into (FSET 'ADD3 #'(LAMBDA (X) (PLUS X 3))) On the other hand, if #'ADD3 is considered to be fully equivalent to (FSYMEVAL 'ADD3), then maybe both should do the expansion? Such equivalence is true in NIL, but I'm not sure how MacLISP could support it 100% correctly. Also, what does LISPM do?  Date: 1 DEC 1980 0417-EST From: JONL at MIT-MC (Jon L White) Subject: DEFMAXing of () To: ALAN at MIT-MC, GSB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 1 December 1980 04:06-EST From: Alan Bawden Just because a macro expanded into NIL, there is no reason to believe that the calculation involved in computing that NIL was trivial. It is a bug if the cache scheme doesn't work for NIL. In this scheme, inherited from Chuck Rich's and integreated into PSZ's, there was general agreement amongst those users that a () returned by such a macro was the bug -- the output of such a macro should always appear in an EVAL context, so returning (QUOTE () ) or (PROGN () ) should always be correct. I'm leary of having MACROMEMO do that conversion (as GSB suggested), but will certainly fix it so that a given cell won't get infinitely "cache"'d. Is there any comment on GSB's proposal to have MACROMEMO do the fixup at runtime?  Date: 1 December 1980 04:06-EST From: Alan Bawden Subject: DEFMAXing on () To: JONL at MIT-MC cc: GSB at MIT-MC, BUG-LISP at MIT-MC Just because a macro expanded into NIL, there is no reason to believe that the calculation involved in computing that NIL was trivial. It is a bug if the cache scheme doesn't work for NIL.  Date: 1 DEC 1980 0401-EST From: JONL at MIT-MC (Jon L White) Subject: DEFMAXing on () To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC While a () returned by a macro won't get "cached" by DEFMAX, this has always been true, and isn't exactly a bug (just a limitation of the "cache"ing scheme). How important is it to extend "cache"ing to this case?  Date: 1 DEC 1980 0359-EST From: JONL at MIT-MC (Jon L White) Subject: Read-Modify-Write mode To: REM at MIT-MC CC: (BUG LISP) at MIT-MC I guess we never considered this for MacLISP. Initially, the ITS file system didn't encourage this kind of file usage, so one normally just loads a whole file into a "buffer", modifies it, and then re-writes it, either to a new file, or replacinng the old one.  GSB@MIT-ML 12/01/80 03:53:05 Re: defmax losing To: (BUG LISP) at MIT-ML MACROMEMO should transpose an expansion of NIL into either (QUOTE NIL) or (PROGN NIL) because otherwise MACROFETCH will return the expansion, NIL, and be considered to have failed.  Date: 1 DEC 1980 0351-EST From: JONL at MIT-MC (Jon L White) Subject: new DEFMACRO To: WGD at MIT-MC, KMP at MIT-MC CC: (BUG LISP) at MIT-MC, ALAN at MIT-MC, CWH at MIT-MC Very simple explanation (and fix) for (defmacro foo () nil): Date: 30 November 1980 21:59-EST From: Kent M. Pitman Date: 26 November 1980 22:58-EST From: William G. Dubuque (defmacro foo () nil) then do (foo) and you get infinite recursion. ----- This is the result of a bad interaction between the NIL return value -- which fights with the (OR (MACROFETCH ...) ; NIL falls through! (MACROMEMO ...)) ; expansion returned and the fact that the thing being memo-ized isn't CDR'd as it would be . . . Something in the new DEFMAX is still losing badly. Someone should have noticed that DEFMACRO was producing (PROGN FOO-MACROARG) as the main code, rather than (PROGN FOO-MACROARG NIL) as should have been expected. This bug is entirely due to the new part of DEFMACRO which tries to permit a documentation "string" (or symbols, as in the case of MacLISP -- it seems that NIL looked like a "documentation string"). I've fixed this and installed version 138. I don't seen anything at all losing badly in the new DEFMAX, but if you have an example, send it along.  Date: 30 November 1980 21:59-EST From: Kent M. Pitman To: WGD at MIT-MC cc: BUG-LISP at MIT-MC, ALAN at MIT-MC, CWH at MIT-MC Date: 26 November 1980 22:58-EST From: William G. Dubuque Sender: BIL To: BUG-LISP (defmacro foo () nil) then do (foo) and you get infinite recursion. ----- This is the result of a bad interaction between the NIL return value -- which fights with the (OR (MACROFETCH ...) ; NIL falls through! (MACROMEMO ...)) ; expansion returned and the fact that the thing being memo-ized isn't CDR'd as it would be in (DEFMACRO FOO (X) ...) => (DEFUN FOO MACRO (FOOMACROARG) (OR ... (MACROMEMO ... (PROGN ... (LET (((X) (CDR FOOMACROARG))))) ...))) which ends up displacing the source form returning (MACROEXPANDED A (0 . 0) (A) (MACROEXPANDED A (0 . 0) (A) (MACROEXPANDED ...))) which is circular with respect to its expansion... I can't fathom enough of the code to suggest a fix or even to more precisely characterize the problem. I will point out that I was expecting (DEFUN FOO (&WHOLE X) NIL) to manifest the same bug, but it doesn't -- you can't even DEFINE that one without getting a PDL-OVERFLOW ... Something in the new DEFMAX is still losing badly.  Date: 29 November 1980 15:11-EST From: Kent M. Pitman Subject: Getting characters into Lisp To: Leonard.Zubkoff at CMU-10A cc: BUG-LISP at MIT-MC Date: 28 November 1980 1540-EST (Friday) From: Leonard.Zubkoff at CMU-10A (C410LZ60) Re: Getting characters into Lisp I am running MacLisp on the Dec-20 (CMU-20C) and appear to be unable to get certain control characters through to lisp under any circumstances. That is, even slashifying them fails and a tyo when one is typed does not return to its caller. Two such characters are specifically ^A and ^V. Leonard ----- Some characters are trapped by the operating system. Others are not seen because they have lisp interrupt properties. Try doing (SSTATUS TTYINT #^A NIL) to turn off ^A's interrupt property and see if that lets you TYI it then. I'm pretty sure that will work. Making ^S and ^Q be readable on a Tops-20 may be much harder since they are hacked by the operating system. -kmp  Date: 29 NOV 1980 0523-EST From: JONL at MIT-MC (Jon L White) Subject: DEFMACRO and DEFUN& To: GSB at MIT-MC, RLB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 11/28/80 20:32:05 Re: defmacro produces (PROGN 'COMPILE FLUSH-MACROMEMOS (|forget-macromemos/|| '...) ...) The bug (not corrected in DEFMACRO 137) was that it should have produced (PROGN 'COMPILE (DEFPROP FLUSH-MACROMEMOS ((LISP) DEFMAX) AUTOLOAD) (|forget-macromemos/|| '...) ...) So that lisps prior to 2056 won't get too confused as where this new fun lives. Also my prior note Date: 29 November 1980 00:36-EST From: Jon L White Subject: VECTOR-S-IFY Date: 28 November 1980 15:29-EST From: Richard L. Bryan (defun foo (&restv x) x) (foo 1) ;VECTOR-S-IFY UNDEFINED FUNCTION OBJECT Since true stack-allocated vectors were never put into MacLISP, this name is an anachronism, so in DEFMAC 137 it will just do TO-VECTOR. is buggy -- it will not call TO-VECTOR, but rather some weird internal fun. (This now works in version 137).  Date: 29 NOV 1980 0307-EST From: JONL at MIT-MC (Jon L White) Subject: MacLISP's LDB "moves" from out-of-core To: ALAN at MIT-MC, DLW at MIT-MC CC: (BUG LISP) at MIT-MC Date: 28 November 1980 16:34-EST From: Alan Bawden I have been working on some new features for defstruct and I compiled a version that should have run in MacLisp. I asked DLW and Moon to try it out (in MacLisp) confident that it would work in anybody's SETF. I was wrong of course: . . . I'm so very sorry Alan, but your artfully worded complaint was just totally off base again -- DLW's symptom has nothing to do with SETF per se, nor of any "macrology", but to the lack of address space in the PDP10 MacLISP which has caused us to try keep only a minimal amount of code and symbols in the initial lisp. LDB etc used to be macros which autoloaded from some file (the out-dated autoload properties in current L^K caused a minor lossage which I've corrected thru a "patch" in the file which does get autoloaded). But in XLISP, these functions are system SUBRs,(just a few words each) and the COMPLR uses the former macro properties to do a half-job of open-coding. This was noted in LISP RECENT: Tuesday OCT 28,1980 FM+4D.17H.18M.10S. LISP 2033 - Jonl - 1) Some new functions: LOAD-BYTE, DEPOSIT-BYTE, LDB, and DPB are now installed as SUBR's. . . . Neither in the old lisp, nor in the new, was the correct property set up for SETF to find for inverting LDB, but I've corrected this and recompiled the offending files. Essentially the same thing applies to the apparent use of *:XREF in old lisp. *DPB is a part of the PDP10-only macroexpansions of LDB, and is not a bug. We may only conclude that no PDP10 user has ever used SETF on a LDB, reinforcing our common observation that the "ppss" part of the LISPMachine defstruct is not a particlularly useful tool on the 10. However, users seem to be sensitive to the slightest change in LDB etc, since there were quite a few who reported when XCOMPLR had (buggily!) forgotten the FIXNUM declarations for LDB, *LDB etc. If you had remembered the conversation I had with you last month, when you first asked what the *LDB and *DPB were, you might have recognized the problem, and might have been able to tell DLW something constructive.  Date: 29 NOV 1980 0036-EST From: JONL at MIT-MC (Jon L White) Subject: VECTOR-S-IFY To: RLB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 28 November 1980 15:29-EST From: Richard L. Bryan (defun foo (&restv x) x) (foo 1) ;VECTOR-S-IFY UNDEFINED FUNCTION OBJECT Since true stack-allocated vectors were never put into MacLISP, this name is an anachronism, so in DEFMAC 137 it will just do TO-VECTOR.  Date: Friday, 28 November 1980 18:25-PST From: MACRAKIS at USC-ISIE To: Jonl Subject: Complr on XX There is currently no Complr on XX for me to filch!  Date: Friday, 28 November 1980 18:25-PST From: MACRAKIS at USC-ISIE To: Jonl Subject: Complr on XX There is currently no Complr on XX for me to filch!  GSB@MIT-ML 11/28/80 20:32:05 Re: defmacro To: (BUG LISP) at MIT-ML produces (PROGN 'COMPILE FLUSH-MACROMEMOS (|forget-macromemos/|| '...) ...) where i presume that should be "(FLUSH-MACROMEMOS)". This apparently wins only because in the interpreter FLUSH-MACROMEMOS is bound, and the compiler ignores the random atom.  Date: 28 November 1980 16:34-EST From: Alan Bawden Subject: suckage To: BUG-LISP at MIT-MC cc: DLW at MIT-MC, MOON at MIT-MC I have been working on some new features for defstruct and I compiled a version that should have run in MacLisp. I asked DLW and Moon to try it out (in MacLisp) confident that it would work in anybody's SETF. I was wrong of course: Date: 28 November 1980 01:56-EST From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI OK, I tried it, and found that *DPB was an undefined function. I will try this again when you give me a version that runs on the LispM; I'm sorry, but I cannot deal with Maclisp; it's just too hard. Now I don't use *DPB, so it must be something that your SETF produces. So I tried: In the current LISP: (setq x 123456) 123456 (setf (ldb 0303 x) 7) ;Loading SETF 271 ;Loading DEFMAX 63 ;Loading LODBYT 38 ;Loading LDBHLP 1 ;Loading MACAID 97 ;*:XREF UNDEFINED FUNCTION IN UUO CALL ;BKPT UNDF-FNCTN In the current XLISP: (setq x 123456) 123456 (setf (ldb 0303 x) 7) ;Loading SETF 271 ;Loading DEFMAX 63 ;Loading MACAID 97 ;(LDB 303 X) Obscure format - SETF ;BKPT WRNG-TYPE-ARG I have no idea how DLW got the *DPB bug, but I am not surprised that the code that defstruct constructs causes a different set of bugs since it probably causes yet another set of packages to autoload. Sure makes me glad I have my own macrology!  Date: 28 November 1980 1540-EST (Friday) From: Leonard.Zubkoff at CMU-10A (C410LZ60) To: bug-lisp at MIT-MC Subject: Getting characters into Lisp Reply-To: Leonard.Zubkoff at CMU-10A (C410LZ60) Message-Id: <28Nov80 154051 LZ60@CMU-10A> I am running MacLisp on the Dec-20 (CMU-20C) and appear to be unable to get certain control characters through to lisp under any circumstances. That is, even slashifying them fails and a tyo when one is typed does not return to its caller. Two such characters are specifically ^A and ^V. Leonard  Date: 28 NOV 1980 1529-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: VECTOR-S-IFY deleted?? To: (BUG LISP) at MIT-MC In a fresh XLISP: (load'((lisp)vector)) (defun foo (&restv x) x) (foo 1) ;VECTOR-S-IFY UNDEFINED FUNCTION OBJECT  Date: 28 NOV 1980 0554-EST From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC Is there any way in MacLISP to open a file in read-modify-write mode? (I.e. you can read data in from random places, and you can overwrite existing data with new data or extend the end of the file with new data.) I hoped APPEND mode of NEWIO would work, but it forbids reading. I need to be able to read in words containing 8-bit bytes and write back out data with some bytes changed and others left as read-in.  Date: 27 NOV 1980 0945-EST From: JONL at MIT-MC (Jon L White) Subject: '|| To: (BUG LISP) at MIT-MC I find an ocasional bug when compiling a file with instances of a null symbol; the bug is that the pname-list is ablsolutely null, instead of "(0)", and this causes FASLAP to die when trying to output the symbol into the fasl file. Has anyone else ever seen this problem?  Date: 27 NOV 1980 0548-EST From: JONL at MIT-MC (Jon L White) Subject: (STATUS TERPRI ) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC This now returns false (always!). At least that should be a little better than an error, and since the global value of TERPRI defaults to "don't do the auto-terpri hack", this will be consistent with the cop-out state for SFA's. I've just edited the source, and patched this in XLISP version 2056.  Date: 26 NOV 1980 2258-EST From: WGD at MIT-MC (William G. Dubuque) Sent-by: BIL at MIT-MC To: (BUG LISP) at MIT-MC (defmacro foo () nil) then do (foo) and you get infinite recursion.  GSB@MIT-ML 11/26/80 02:39:51 To: (BUG LISP) at MIT-ML bleagh, i had to delete some links on LISP; in order to install a format with a bug fixed. (FORMAT INFO & FORMAT DOC).  BEN@MIT-ML 11/25/80 11:51:07 Re: CGOLPRIN1 To: (BUG LISP) at MIT-ML CC: pratt at MIT-AI (CGOLPRIN1 '(QUOTIENT 1 2)) loses with the message illegal argument -- CAADR -- (1 2), or some such. I run MACLISP under TOPS-10 at Tufts. I find that cgolprint and cgolprin1 don't even exist in the current ML version of MACLISP, so I can't verify the bug, but it turns out quite irritating to my students. Thanks. Ben  Date: 25 NOV 1980 0756-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: DEFVST To: (BUG LISP) at MIT-MC I see loading a compiled DEFVST loads EXTEND. It didn't used to, I don't believe.  Date: 25 NOV 1980 0654-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: More DEFVST non-transparency To: (BUG LISP) at MIT-MC The DEFSETF for *:XREF lives in EXTMAC, but Macro-expansion of selectors produces it without causing the DEFSETF to first happen. Probably the DEFSETF wants to be moved, but I'm not sure where to.  Date: 25 NOV 1980 0641-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: DEFVST lossage To: (BUG LISP) at MIT-MC I haven't thought this out, but there exists a problem aproximately as follows: If you load a compiled DEFVST, without EXTEND being loaded, then do (CONS-A-FOO), it loads EXTEND and lots of other guys, then barfs that NIL isn't a class. It got the NIL from the STRUCT=INFO-CLSS slot of the STRUCT=INFO structure. Perhaps the right thing to do at this juncture is to create the class? I don't know.  Date: 25 NOV 1980 0440-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (LOAD '((LISP) BITS)) (SETQ BB #B"1") ;Loading SHARPM 64 ;/b Unknown dispatch character after # ;BKPT *RSET-TRAP Really, now, BITS should conspire to make #B work. Probably the code for handling it should be in BITS, not in SHARPM.  Date: 25 November 1980 03:17-EST From: David A. Moon To: BUG-LISP at MIT-AI My God! MAX of 2 fixnums isn't open coded. Even MOVE TT,ARG1 MOVE F,ARG2 CAMGE TT,F MOVE TT,F would be better than what it does now!  Date: 24 November 1980 2348-EST (Monday) From: Scott.Fahlman at CMU-10A To: guy.steele at CMU-10A, bug-lisp at mit-ai Subject: TOPS-20 Lisp.Ini Message-Id: <24Nov80 234837 SF50@CMU-10A> It appears that the TOPS-20 version of maclisp looks for its ini file as PS:LISP.INI. This means that when you are connected to another dir and run maclisp, it doesn't find any ini file unless there is a local one. I think it would be better if the system looked for HOME:LISP.INI, which the user can define to be whatever he wants -- PS: only as at present, PS: followed by the login dir, the login dir only, or whatever. Trivial change, and I can't see how it can screw anyone except the first time they run the altered version. -- Scott  Date: 24 NOV 1980 0259-EST From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC CC: DUFTY at MIT-MC, (BUG LISP) at MIT-MC LISP;DEFVST FASL which wants to autoload doesn't exist. I have linked DEFVST FASL to DEFVST OFASL for now so that some things can work. Can you check this and see if that was an appropriate fix? -kmp  Date: 23 Nov 1980 2024-PST Sender: SCOTT at SRI-KL From: Scott J. Kramer Subject: Re: Re: LEDIT on MIT-EE To: Dave Touretzky at CMU-10A, bug-lisp at MIT-MC In-Reply-To: Your message of 23-Nov-80 2006-PST Personally, I would prefer LISPT style commands. -------  Date: 23 November 1980 2306-EST From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: Re: LEDIT on MIT-EE In-Reply-To: Scott J. Kramer's message of 23 Nov 80 21:38-EST Some folks here at CMU are working on Twenex LEDIT; trying to get it to work with the Emacs tags facility, among other things. Send mail to Wohl @ CMUC if you want to know what's going on, or have code to share with him.  Date: 23 NOV 1980 2141-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JIS at MIT-MC ... I may at some point flesh out the ULedit package used in 6.001 this term for ULisp and release that as a Ledit alternative. It has the feature of being extremely small and straightforward to use; it doesn't use subforks, which may be either an advantage or a disadvantage depending on how it's viewed. I see it as an advantage. In any case, that's probably a ways off. Maybe some vacation time when I'm not so busy. -kmp  Date: 23 Nov 1980 1838-PST Sender: SCOTT at SRI-KL From: Scott J. Kramer Subject: Re: LEDIT on MIT-EE To: JIS at MIT-EECS, Bug-Lisp at MIT-MC In-Reply-To: Your message of 22-Nov-80 2323-PST I don't think anyone is maintaining or wants to maintain Twenex LEDIT. Sources are in , relevant files are LEDIT and SUBFORK. Oh, and JSYS-TBL, but I'm not sure which dir it's in. -sjk -------  Date: 23 November 1980 15:23-EST From: Kent M. Pitman Subject: (ARRAYDIMS ...) => (NIL ...) To: JONL at MIT-MC cc: ALAN at MIT-MC, BUG-LISP at MIT-MC I have no code which would be broken by such a change. I have always assumed it would return NIL in the car anyway ... All manuals I know of (including Touretzky's poket guide) are ambiguous on the issue -- they say it returns the "type" of the array and give only a "T" type array as an example. -kmp  Date: 23 November 1980 15:13-EST From: Kent M. Pitman Subject: LEDIT To: BUG-LISP at MIT-MC It should use IOTA to open the file ...  Date: 23 NOV 1980 0323-EST From: ALAN at MIT-MC (Alan Bawden) Subject: How about... To: (BUG LISP) at MIT-MC MacLisp still lacks a way to get array dimension information without consing. Why not adopt the LispMachine function array-dimension-n? (array-dimension-n ) (Look at the manual first, the damned thing is 1 based since it returns the leader length for dimension 0, and it returns nil for non-existant dimensions.)  Date: 23 Nov 1980 0223-EST From: JIS at MIT-EECS Subject: LEDIT on MIT-EE To: Bug-Lisp at MIT-MC Is broken as follows: If you get an error while lisp is reading from the _LEDIT file, the file object is never closed (even if you ^G out of the error break). So the next time you try to read something from the ledit buffer into lisp, emacs blows out trying to expunge the old _LEDIT file, because the lisp still has it open. Apparently someone isn't unwind-protecting the file object so it gets closed. A temporary (kludge^2) solution is for the user (me) to GC before going back to the EMACS if I have errored out in the previous reading. -Jeff -------  Date: 23 NOV 1980 0141-EST From: JONL at MIT-MC (Jon L White) Subject: Inadvertent loading of MLMAC file To: WJL at MIT-MC CC: GJC at MIT-MC, (BUG LISP) at MIT-MC WJL@MIT-ML 11/18/80 13:12:37 To: (BUG LISP) at MIT-ML I am getting very frustrated with the function name conflicts resulting from all of the new stuff that gets autoloaded into Lisp. I spent five hours figuring out what was going on when a probef of a backquoted list caused backquote to be loaded which called pairp, got mine, returned t, messed up the interrupts, tried to load the tty, and went deaf. . . . On the 12'th of this month, GJC and I discovered that BACKQ had been compiled with a compiler which failed to open-code PAIRP (this is fixed now through the loading of a "fix" file when the XCOMPLR is loaded). But there should be no function call to PAIRP in compiled code, for that would, in older LISPs, cause the autoloading of MLMAC. I'm not sure when the recompiled BACKQ made it over to ML, but since GJC did the compilation on MC, he may have forgotten to :INSTALL it to AI and ML (GSB probably did it later?).  Date: 22 NOV 1980 2354-EST From: JONL at MIT-MC (Jon L White) Subject: (ARRAYDIMS (array () () 8)) ==> (T 8) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC If this is a misfeature, its certainly been around since time immemorial. "T" means s-expression, as opposed to FIXNUM or FLONUM, but indeed that leaves no way to find out the state of the "GC-marks-thru-me" bit. Should it be changed?  Date: 22 NOV 1980 2004-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC In XLISP 2054: (arraydims (array nil nil 8)) (T 10) ... shouldn't that be (NIL 10) ??  Date: 22 NOV 1980 0449-EST From: JONL at MIT-MC (Jon L White) Subject: Uh, addendum To: (BUG LISP) at MIT-MC Try out MC:JONL;TS FOO for an XLISP dumped with new stuff in it. FASL's are currently on NILCOM;  Date: 22 NOV 1980 0448-EST From: JONL at MIT-MC (Jon L White) Subject: Try out new DEFMAX and DEFVST To: (BUG LISP) at MIT-MC I think most of the bugs are out of the DEFMAX/DEFMAC/DEFVST scheme described in LISP;NEW RECENT; there is a dumped XLISP with most of the out-of-core files loaded, including the soon-to-be releasd D/D/D stuff. Try it out, for bugs and misfeatures.  Date: 21 NOV 1980 1837-EST From: JONL at MIT-MC (Jon L White) Subject: Request for comments To: (BUG LISP) at MIT-MC I'm about to add another LISP RECENT describing things in the current XLISP, and out-of-core software -- I'd appreciate your comments on the upcoming LISP RECENT which is presently the file LISP;NEW RECENT.  Date: 21 NOV 1980 1352-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC The following problem which you noted is fixed in the current XLISP -- version 2054. Date: 16 OCT 1980 1657-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: This still happens in XLISP (defun foo () '(expr definition)) (macro foo (nil) ''(macro definition)) (foo) => (macro definition) (funcall 'foo) => (expr definition) (apply 'foo ()) => ;IMPROPER USE OF MACRO - EVAL  Date: 21 Nov 1980 1242-EST From: DCP at MIT-EECS Subject: correction to ^G lossage To: bug-lisp at MIT-MC On closer inspection it does a HOME DOWN then prints QUIT, which causes the next line at the top, which is aht I noticed. -------  Date: 21 Nov 1980 1240-EST From: DCP at MIT-EECS Subject: TWENEX lossage To: bug-lisp at MIT-MC I don't remember seeing this but, When in MacLisp, when I type a control/G it seems to do a (cursorpos 0 0) somewhere along the way. This is a screw, especially to those who aren't use to it. I'm confident I can reproduce it. (I also ran a LEDIT beforehand, if that is part of the screw). -------  Date: 20 November 1980 1520-EST From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: Re: STATUS, and the first n characters In-Reply-To: JONL@MIT-MC's message of 20 Nov 80 08:32-EST Past acceptance is no excuse for continuing a crock. However, there are so many other things that need working on that I would not seriously suggest that you drop everything just to fix this one. I was just really taken aback to see truncation being done in LISP. Why was it ever implemented that way in the first place? (Let me guess: table lookup of STATUS functions by snarfing the first 5 chars of the pname, right? Bletch.) -- Dave  Date: 20 NOV 1980 1444-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Twenex Maclisp display lossage. To: (BUG LISP) at MIT-MC CC: (BUG TWENEX) at MIT-MC, JWalker at BBNA If one starts a Lisp and then detaches on Twenex (eg, Break-Q without logging out), then reattaches (using ATTACH uname ...) and even sets their terminal specs back to what they were, Lisp does not do tty io correctly any more. Rubouts echo ^PB^PL and ^L echos as ^L^PC, etc. I TERM says that the system knows my correct terminal type (VT52), which is the same terminal type as I was before I got detached. Lisp is not getting its communication path to VTS correctly restored (whatever that means). Can someone please look into this? Thanks -kmp  Date: 20 NOV 1980 0832-EST From: JONL at MIT-MC (Jon L White) Subject: STATUS, and the first n characters To: Touretzky at CMU-10A CC: (BUG LISP) at MIT-MC I rather agree with GLS Date: 19 November 1980 1350-EST (Wednesday) From: Guy.Steele at CMU-10A To: Dave Touretzky at CMU-10A Subject: Re: cutting corners in STATUS ? . . . Actually, STATUS is a moderately non-LISPish thing to do. which is not to say that non-LISPish things must be bad; just that even LISP has to "accommodate" once in a while, and the STATUS accommodation reflects the "realities" of 12 years ago. Is it really worth changing now?  Date: 19 November 1980 1350-EST (Wednesday) From: Guy.Steele at CMU-10A To: Dave Touretzky at CMU-10A Subject: Re: cutting corners in STATUS ? CC: bug-lisp at MIT-MC In-Reply-To: Dave Touretzky's message of 18 Nov 80 22:55-EST Message-Id: <19Nov80 135033 GS70@CMU-10A> STATUS is explicitly permitted to look at only the first N characters of a status name, and (STATUS STATUS) is permitted to truncate names to N characters. This may be a loss, but it *is* documented in the 1978 version, at least, of the MacLISP manual (chapter 3). Actually, STATUS is a moderately non-LISPish thing to do.  Date: 19 November 1980 1348-EST (Wednesday) From: Guy.Steele at CMU-10A To: JPG at MIT-MC (Jeffrey P. Golden) CC: bug-lisp at MIT-MC In-Reply-To: JPG@MIT-MC's message of 19 Nov 80 02:58-EST Message-Id: <19Nov80 134848 GS70@CMU-10A> Regarding your message about (*RSET NIL) (setq x '(1 2 3)) (SORTCAR (CDR X)) giving ;**MISSING-ARG** UNDEFINED FUNCTION IN UUO CALL: I think it's a fine error message: a function got called, and it lost because it was a "missing argument" -- therefore someone forgot to pass a functional argument to somebody. Serves you right for turning off error-checking. Had you left *RSET T, you would have gotten a better message.  WJL@MIT-ML 11/19/80 09:56:56 To: (BUG LISP) at MIT-ML An extension of my complaints of yesterday: I think I understand the problem a little better now, about where the name conflicts are coming from. I can see that maybe these things are generally useful in NIL. However, my problem is that I am not using NIL, nor can I afford to have a NIL simulator sharing my address space. Besides the problems of naming conflicts in code written by five different people over five years time and now maintained as little as possible by me, the full system runs out of address space on a reasonably complicated case. That's without lsb, loop, format, %format, any debuggers, any editors, or a lot of other stuff I'd like to have in there. Thus it is necessary that I keep out the NIL support stuff that I don't even want. The problem would be easy if I could just refrain from using the NIL support stuff that I don't want anyway. However, you have dumped in my environment two kinds of obstacles that I keep tripping over. First, these names that have autoload properties on them. That hasn't proved to be a problem yet. The real problem is innocent looking stuff (like backquote) that causes NIL support stuff to be loaded without me knowing it (or worse, assuming it's there and using some function of mine with the same name). When the compiler assumes the existence of NIL support stuff in the user's environment that's really bad. It seems to me that an effort has to be made to keep a NIL-less environment available for those who need it. That means labeling stuff that requires NIL as such and further not to require NIL for things that really don't need it. -Bill Long  Date: 19 NOV 1980 0258-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC In a fresh LISP: (*RSET NIL) (SETQ X '(1 2 3)) (SORTCAR (CDR X)) gives ;**MISSING-ARG** UNDEFINED FUNCTION IN UUO CALL. Not a very winning error message.  Date: 18 November 1980 2255-EST From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: cutting corners in STATUS ? (status featurexxxxxxxx) => (BIBOP BIGNUM ... etc. ) Hmmm. STATUS seems to look only at the first five letters of a feature name. This seems like a truly non-Lispish thing to do. One would expect such of Pascal or some other heathen tounge, but Lisp should have more class. Also, (STATUS STATUS) returns symbols that have obviously been truncated after the 5th letter. What gives?  WJL@MIT-ML 11/18/80 13:12:37 To: (BUG LISP) at MIT-ML I am getting very frustrated with the function name conflicts resulting from all of the new stuff that gets autoloaded into Lisp. I spent five hours figuring out what was going on when a probef of a backquoted list caused backquote to be loaded which called pairp, got mine, returned t, messed up the interrupts, tried to load the tty, and went deaf. Looking through the list of stuff that gets loaded, I have known conflicts with pairp, find-method, and describe. I have a lot of code inherited from other folks so there are probably more. If any of this stuff is directly useful to the community at large, I would be glad to listen to the arguments, and maybe they should be incorporated in Lisp in the standard way. However, from the way they are casually mentioned in Lisp Recent, I take it they are useful for NIL implementation stuff only. If that is the case, they should have appropriately obscure names. One thing that would help a little is if someone would provide a function that check for name conflicts between existing lisp environments and new lisps.  Date: 17 November 1980 18:23-EST From: Alan Bawden Subject: LOOP iteration macro To: JONL at MIT-MC cc: GSB at MIT-MC, BUG-LISP at MIT-MC, levitt at MIT-AI, dlw at MIT-AI Fine, give LOOP an autoload property. (It's a good word to "use up", but I can live with it as an autoload.) I hope that the point of mentioning the FOR problem, is to inspire someone to cause LOOP to check when it loads that it isn't REdefining some other good words like FOR. (It should check for MACRO, SUBR, LSUBR etc. properties.) I, for one, happen to have a FOR macro! (Isn't it the case that there is some other word LOOP redefines besides FOR?)  Date: 17 NOV 1980 1333-EST From: JONL at MIT-MC (Jon L White) Subject: LOOP iteration macro To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, levitt at MIT-AI, dlw at MIT-AI About a month ago we talked about the possibility of making LOOP be autoloadable -- the one hitch being the state of controversy over the "FOR" keyword (whether it should defaultly initiate a LOOP too). Just saw WAM and PSZ now, and it seems that the safe and right thing to do now is to install an autoload property for LOOP, have the symbol FOR around so that later we can later patch an autoload in for it. And at least in the forthcoming LISP RECENT we can announce LOOP and its documentation.  Date: 16 Nov 1980 1010-EST From: Mark L. Miller To: KMP at MIT-MC cc: RWK at MIT-MC, BUG-LISP at MIT-MC, DEVON at MIT-MC, EAK at MIT-MC In-Reply-To: Your message of 15-Nov-80 1822-EST Yes, please build in some cursor stuff for 20x! -------  Date: 16 NOV 1980 0036-EST From: JONL at MIT-MC (Jon L White) Subject: Incredible STRING band! To: SOLEY at MIT-MC CC: (BUG LISP) at MIT-MC, NILE at MIT-MC I've just installed a new STRING (and STRAUX) package, which corrects a coulple of serious bugs, and utilizes the new error checking facilities; if "latent" features defelop, there is a STRING.OFASL and STRAUX.OFASL on MC's LISP directory. 1) STRAUX makes certain that there are four functions +INTERNAL-CHAR-N, +INTERNAL-RPLACHAR-N, +INTERNAL-STRING-WORD-N, and +INTERNAL-SET-STRING-WORD-N. These are non-checking versions, in in XLISP they are coded in the system in order to insure correct interruptibility. This has made it possible to rewrite a lot of string functions which used to lambda-bind *RSET so as not to bind now. (still, there are a few functions which will bind *RSET to stop checking on sub-recursive calls -- primarily STRING-SEARCH and STRING-APPEND). 2) The backwards versions of POSQ (like, STRING-BPOSQ-N) were buggy! This probably schrod a bunch of other backwards functions -- like maybe backwards searching. This is now fixed. Hopefully, within a few days I'll have the new MACROEXPANDED scheme in DEFMAX, and will build a new NILAID. In the meantime, I'd appreciate feedback from you regarding possible bugs mentioned in 2.  Date: 15 NOV 1980 1920-EST From: JONL at MIT-MC (Jon L White) Subject: 3-way versions of <= and >= To: (BUG LISP) at MIT-MC I just fixed a bug in UMLMAC whereby the 3-arg versions of these guys sometimes failed to preserve order of evaluation. Also, added an optimizing clause in the expander to look for cases when the arguments have no side-effects.  Date: 15 November 1980 18:22-EST From: Kent M. Pitman To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, DEVON at MIT-MC, EAK at MIT-MC Date: 15 November 1980 15:20-EST From: Robert W. Kerns ... he should do (SYSCALL 2 'SCPOS HPOS VPOS -1), which will return a list of the old HPOS and VPOS. Note that this merely tells ITS where the cursor is, and doesn't move it ... ----- We probably ought to abstract this and offer a primitive for it since it's different on Twenex with VTS etc. (SYSCALL 2 'SCPOS ...) is not notably transportable, after all. How about a SETCURSORPOS function? (not macro as that'll kill site->site transportability) ...  Date: 15 November 1980 15:20-EST From: Robert W. Kerns To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, DEVON at MIT-MC, EAK at MIT-MC Date: 15 November 1980 14:34-EST From: Kent M. Pitman To: DEVON cc: BUG-LISP, EAK Date: 15 November 1980 01:38-EST From: Earl A. Killian Date: 13 November 1980 21:44-EST From: Devon S. McCullough To: BUG-CRTSTY Would someone tell me how to use SCPOS from Lisp? You're asking us?? See .INFO.;LISP NEWIO and .INFO.;LISP CURSOR for descriptions of cursor position control in Maclisp. -kmp SCPOS is not cursor position control. If DEVON really wants to use SCPOS (and he should read the documentation produced by doing :CALL SCPOS if he hasn't already), he should do (SYSCALL 2 'SCPOS HPOS VPOS -1), which will return a list of the old HPOS and VPOS. Note that this merely tells ITS where the cursor is, and doesn't move it. DEVON may well be wanting exactly this.  Date: 15 November 1980 14:34-EST From: Kent M. Pitman To: DEVON at MIT-MC cc: BUG-LISP at MIT-MC, EAK at MIT-MC Date: 15 November 1980 01:38-EST From: Earl A. Killian Date: 13 November 1980 21:44-EST From: Devon S. McCullough To: BUG-CRTSTY Would someone tell me how to use SCPOS from Lisp? You're asking us?? See .INFO.;LISP NEWIO and .INFO.;LISP CURSOR for descriptions of cursor position control in Maclisp. -kmp  Date: 15 November 1980 03:22-EST From: Robert W. Kerns To: KRONJ at MIT-MC cc: BUG-LISP at MIT-MC Date: 15 November 1980 01:04-EST From: David Eppstein To: BUG-LISP How do I flush the ;Caution! FUNC, a User SUBR at... cruft? I know about (status noldmsg), but that only stops messages about autoloads of files. (SETQ FASLOAD () ) FASLOAD is a list of properties to complain about when redefinition occurs.  Date: 15 November 1980 01:38-EST From: Earl A. Killian To: DEVON at MIT-MC cc: BUG-CRTSTY at MIT-MC, BUG-LISP at MIT-MC Date: 13 November 1980 21:44-EST From: Devon S. McCullough To: BUG-CRTSTY WOULD SOMEONE TELL ME HOW TO USE SCPOS FROM LISP? You're asking us??  Date: 15 NOV 1980 0104-EST From: KRONJ at MIT-MC (David Eppstein) To: (BUG LISP) at MIT-MC How do I flush the ;Caution! FUNC, a User SUBR at... cruft? I know about (status noldmsg), but that only stops messages about autoloads of files.  GSB@MIT-ML 11/14/80 01:39:23 Re: format To: (BUG LISP) at MIT-ML I have installed the new format on ML, where it is easy for me to handle any problems that arise. Just give the word, and i will make it call +INTERNAL-CHAR-N rather than CHAR-N. That won't work in older lisps unless STRING defines it.  GSB@MIT-ML 11/13/80 23:29:37 Re: xlisp 2052 To: (BUG LISP) at MIT-ML The array property on STR:ARRAY seems to get reclaimed unless i have something else pointing to it. I don't understand why, shouldn't it be protected by being on the plist of an interned symbol?  Date: 13 NOV 1980 1714-EST From: JONL at MIT-MC (Jon L White) Subject: DEFVAR To: batali at MIT-AI CC: (BUG LISP) at MIT-MC Date: 13 November 1980 15:13-EST From: John Batali On a completely clean MacLISP 1997 (on AI) the command (DEFVAR FOO) gets the error: ;SPECIAL UNDEFINED FUNCTION OBJECT Bug in MLMAC has been fixed, and a "fix" file for XCOMPLR is installed.  Date: 13 November 1980 15:13-EST From: John Batali Subject: Defvar is broken To: BUG-LISP at MIT-AI On a completely clean MacLISP 1997 (on AI) the command (DEFVAR FOO) gets the error: ;SPECIAL UNDEFINED FUNCTION OBJECT I've gotta feeling I know what's wrong.  Date: 13 NOV 1980 0200-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (cond ((null chnl) (error '|-- Unknown or un-proceedable condition| condition)) ((or proceedable (not restartable)) (error blurb cruft chnl)) ('T (*throw 'ERROR-RESTART () ))))) This code (from CERROR) is bogus: Note that if the error is not proceedable, but is restartable, it does the (*throw 'ERROR-RESTART () ) without ever going into any form of error break. Probably the best thing to do is to insert (error blurb cruft chnl) before the *THROW.  Date: 12 NOV 1980 2000-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, GJC at MIT-MC, SRF at MIT-MC, SJK at MIT-MC CC: daniel at MIT-AI Date: 12 NOV 1980 1359-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: PAIRP UNDEFINED AFTER AUTOLOAD . . . I've moved an emmended version of MLMAC to EE, which tries to be fully compatible with the new XLISP (only exists on ITS systems right now), and all previous LISPs.  Date: 12 NOV 1980 1931-EST From: RWK at MIT-MC (Robert W. Kerns) To: DUFTY at MIT-MC CC: (BUG LISP) at MIT-MC The problems with DEFVST and FORMAT, etc., were all caused by a bad PTR-TYPEP. The problem has been fixed.  Date: 12 November 1980 18:23-EST From: Robert W. Kerns Subject: (SETF (CDR X) Y) To: GZ at MIT-MC cc: BUG-LISP at MIT-MC Date: 11 November 1980 02:58-EST From: Gail Zacharias To: BUG-LISP at MIT-MC (setf (cdr x) y) returns x. I thought the value of a setf was its second arg? You must be using the current LISP. This is fixed in XLISP.  Date: 12 NOV 1980 1633-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: DUFTY at MIT-MC The SEQUENCEP function appears to have vanished off the face of the earth!  Date: 12 November 1980 16:24-EST From: Robert W. Kerns Subject: PAIRP UNDEFINED AFTER AUTOLOAD To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, GJC at MIT-MC, SRF at MIT-MC, DANIEL at MIT-AI The problem is that in XLISP, PAIRP is defined in LISP, rather than autoloaded. You're MLMAC file is too new for your LISP.  Date: 12 NOV 1980 1359-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: PAIRP UNDEFINED AFTER AUTOLOAD To: (BUG LISP) at MIT-MC CC: GJC at MIT-MC, SRF at MIT-MC, DANIEL at MIT-AI The PAIRP bug extends to EE. This broke ULisp rather badly. Please be aware that there are many students depending on Maclisp and Maclisp-based systems working on EE. I have patched ULisp to define PAIRP itself but please import a new version of whatever package had been broken as soon as possible. Thanks. -kmp  Date: 12 November 1980 12:21-EST From: Kent M. Pitman Subject: DO-WITH-ECHO-DEFERED To: FH at MIT-MC cc: BUG-LISP at MIT-MC Date: 12 November 1980 01:45-EST From: Fred W. Helenius Re: DO-WITH-ECHO-DEFERED Webster's says DEFERRED, and doesn't permit any variations. Unfortunately, fixing this may well break somebody's code. It's still a winning macro, despite the spelling... ----- It's RWK's contribution to the TTY package. I have renamed the macro. It won't break running code -- it'll only screw up when people recompile their stuff. If they heed the "DO-WITH-ECHO-DEFERED" not defined in this file message from Maclisp, they won't get screwed much there either... It is now DO-WITH-ECHO-DEFERRED. -kmp  Date: 12 NOV 1980 1148-EST From: GJC at MIT-MC (George J. Carrette) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC Problem with BACKQ fixed by recompiling it. sigh...  Date: 12 NOV 1980 1131-EST From: GJC at MIT-MC (George J. Carrette) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC Backquote is broken by PAIRP getting moved to the wrong file or something???? Help.  Date: 11 November 1980 18:27-EST From: Kent M. Pitman Subject: Just for Fun ... To: BUG-LISP at MIT-MC cc: JAR at MIT-MC, RICH at MIT-AI, DANIEL at MIT-AI Here's a couple of cute Maclisp toys to play with ... [1] Fun with Shadowing. (DEFMACRO FOO (X) `(CAR ,X)) (MAPCAR #'FOO '((A B) (C D) (E F))) Do you know why it loses? (DEFUN FOO (X) (FOO X)) (DEFMACRO FOO (X) `(CAR ,X)) (MAPCAR #'FOO (X) '((A B) (C D) (E F))) Do you know why it wins? [2] Fun with Interpreted Macros. (DEFMACRO MMAPCAR (FN L) (LET ((VAR (GENSYM)) (CALL (IF (AND (LISTP FN) (MEMQ (CAR FN) '(QUOTE FUNCTION))) `(,(CADR FN)) `(FUNCALL ,FN)))) `((LAMBDA (,VAR) (COND (,VAR (CONS (,@CALL (CAR ,VAR)) (MMAPCAR ,FN (CDR ,VAR)))))) ,L))) (SETQ GRIND-MACROEXPANDED T) (DEFMACRO F (X) `(CAR ,X)) (MMAPCAR #'F '((A B) (C D) (E F))) (SPRINTER +) (DEFUN G (X) (MMAPCAR #'F X)) (G '((A B) (C D))) (GRINDEF G) (G '((A B))) (GRINDEF G) (G '((A B) (C D) (E F))) [3] Fun with Compiled Macros. (Extra Credit) Why doesn't the definition of G from [2] compile?  Date: 11 NOV 1980 1737-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: SETF To: (BUG LISP) at MIT-MC Shouldn't (SETF #'ADD3 #'(LAMBDA (X) (PLUS X 3))) work? It says that (FUNCTION ADD3) is an obscure format...  Date: 11 NOV 1980 0258-EST From: GZ at MIT-MC (Gail Zacharias) To: (BUG LISP) at MIT-MC (setf (cdr x) y) returns x. I thought the value of a setf was its second arg?  Date: 10 November 1980 17:04-EST From: Charles Rich Sender: GLR at MIT-AI Subject: Using macros in Mapping functions To: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI, LISP-FORUM at MIT-AI cc: KMP at MIT-AI, RICH at MIT-AI I just finished reading Ken Pitman's Lisp Conference article on macros and Fexpr's in which he points out that a difference between macros and Fexpr's is that you can apply Fexpr's, which you cannot do so with macros. This is indeed a significant point. I have been irritated for a long time by having to write forms like the following (MAPCAR #'(LAMBDA (X) (SECOND X)) L) when I would much rather write (MAPCAR #'SECOND L) I would like to ask now why the second form above cannot be taken as a shorthand for the first (using a gensym for the variables)? It seems unreasonable to force the user to write the first form or, even worse, (MAPCAR #'CADR L) if the interpreter and compiler could systematically accept the shorter form as a valid abbreviation for the longer form. If I am not missing some obvious (or subtle) reason why Lisp can't support macros used in this way, may I propose this as an innovation for future Lisp's. yt, Chuck Rich.  GSB@MIT-ML 11/10/80 11:42:16 Re: sharable To: (BUG LISP) at MIT-ML should die more graciously if a dump it needs is missing, like perhaps doing a (quit), maybe giving an indication that this should be considered a bug.  GSB@MIT-ML 11/08/80 19:26:35 Re: bleagh! To: (BUG LISP) at MIT-ML BACKQ contains a call to PAIRP which is not macroexpanded and thus forces in MLMAC... I suppose it should be recompiled with XCOMPLR?  Date: 8 NOV 1980 0811-EST From: JONL at MIT-MC (Jon L White) Subject: Meaningless error msg in CASEQ To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 8 November 1980 04:32-EST From: Alan Bawden (caseq '(foo) (t t)) ;(FOO) MATCHING EXPRESSION NOT FIXNUM OR SYMBOL . . . Couldn't this error message mention the function CASEQ??? . . . This certainly looks like a loser of a msg -- I've changed it in the curren source, which will show up in XLISP version 2051 shortly. Here's my version of a msg for here, about which you should complain quickly if you don't like it either: ;(FOO) -- ARGUMENT TO CASEQ IS NEITHER A FIXNUM NOR A SYMBOL  Date: 8 November 1980 04:32-EST From: Alan Bawden To: BUG-LISP at MIT-MC (caseq '(foo) (t t)) ;(FOO) MATCHING EXPRESSION NOT FIXNUM OR SYMBOL ;BKPT WRNG-TYPE-ARG Couldn't this error message mention the function CASEQ??? It's rather hard to figure out what is wrong if you don't mention just what it is that you are doing that requires a fixnum or a symbol. (Just why is it an "EXPRESSION" anyway???)  Date: 7 NOV 1980 1748-EST From: JONL at MIT-MC (Jon L White) Subject: FORMAT.AUX on XX To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC GSB is making up a new FORMAT today, so some changes are in the wind, but I FTP'd the current one anyway. By the bye, MacLISP on XX is in a pretty desolate state, since AV flushed all the files three weeks ago, and not all the new stuff has been fully restored there.  Date: 7 Nov 1980 1735-EST From: MOON at MIT-XX Subject: Absurd security paranoia To: bug-lisp at MIT-MC The file LISP;FORMAT AUX is missing from the XX: directory. I don't have access to put it there myself. Lack of this file prevents FORMAT from working (except for certain easy cases) -------  GSB@MIT-ML 11/07/80 06:33:49 Re: xlisp 2049 To: (BUG LISP) at MIT-ML User hunks still get OUTFILES only when one is printing to NIL and OUTFILES and ^R are not nil.  Date: 7 NOV 1980 0314-EST From: LSH at MIT-MC (Lars S. Hornfeldt) Subject: The TRACE function, used with the kwrd "ENTRY",prints all.. To: (BUG LISP) at MIT-MC, LSH at MIT-MC (TRACE (FN ENTRY (x))) should cause FN at entry to print out ONLY the value of x, but in addition it ALSO prints out ALL THE ARGS of FN.  Date: 6 NOV 1980 1845-EST From: JONL at MIT-MC (Jon L White) Subject: Structures in MacLISP To: TFT at MIT-MC CC: (BUG LISP) at MIT-MC Date: 6 November 1980 01:25-EST From: Tom Trobaugh How do I get defstructs in MACLISP? MACLISP used to understand LISPM2;NSTRUC, but seems to have lost some of the relevant vocabulary. The autoloading MacLISP feature DEFVST (documented in LISP:DEFVST DOC) is the MacLISP/NIL way to get structures; by making two "switch setting" adjustments you can cause it to behave pretty much they way the LISPM documented DEFSTRUCT works (LISPM manual P. 147); just do (SETQ CONSTRUCTOR-NAMESTRING-PREFIX '|MAKE-| SELECTOR-NAMESTRING-STYLE () ) The "LDB"-style fields, as in item "(3)", Page 147 of LISPM Manual, are not yet implemented, but will be sooner or later. Of course, some of the many LISPM options are inherently non-NIL/non-MacLISP, such as :GROUPED-ARRAY, but otherwise the syntax is the same. DEFVST produces hunk-type objects, which fit into the CLASS system if that is loaded (see LISP;LISP RECENT), but if not loaded they just remain MacLISP hunks. Since DEFVST isn't intended to be totally 100% compatible with DEFSTRUCT, it isn't named that, but you could conditionally do the switch settings mentioned above and macro-define DEFSTRUCT just to turn into DEFVST, and probably win in most cases.  Date: 6 NOV 1980 1622-EST From: JONL at MIT-MC (Jon L White) Subject: # ("O" or otherwise) To: GLS at MIT-MC, RWK at MIT-MC, (BUG LISP) at MIT-MC Just for the record, I fixed the SHARPM package so that 1) #*...* works correctly now, e.g. #*400000000000* is 'SETZ' 2) #(...) will work whenever the VECTOR package is loaded (no need to do (SSTATUS FEATURE NIL) now) 3) #T works when EXTEND package is loaded, which it will be if you load in any of the NIL-data-type packages.  Date: 6 November 1980 1350-EST (Thursday) From: Guy.Steele at CMU-10A To: RWK at MIT-MC (Robert W. Kerns) Subject: Re: #o, picky picky CC: bug-lisp at MIT-MC In-Reply-To: RWK@MIT-MC's message of 5 Nov 80 12:34-EST Message-Id: <06Nov80 135015 GS70@CMU-10A> Your answer to my question about the VAX indicates your confusion about my confusion about your ambiguity. My point is that unless you are worrying about fitting some bits into a finite box of definite size (i.e., a fixnum) then the distinction between signed and unsigned numbers is unimportant. After all, the difference between them is merely that a certain bit at a fixed distance from bit 0 gets interpreted differently (as a sign bit or just another data bit). The problem is that you have underspecified your notion of the semantics of the proposed "unsigned number syntax". Supposing fixnums are 28 bits long, and all larger numbers are bignums, then as I understand your proposal: #o*777777777 (nine sevens) is the same as #o777777777 (uninteresting case) #o*1777777777 internally becomes the same as -1, but you don't care because the 28 bits of interest are all there. Two points: (a) if the above descriptions are substantially correct, then would you care whether #o*7777777777 (ten sevens) read in as -1 (low 30 bits are still all ones)? How about #o*7000000000 reading as #o-1000000000 ? (b) on the other hand, the second point of understanding above is *not consistent*. I claim that it is incorrect to convert the syntax #o*1777777777 to an internal fixnum -1, because there is nothing whatsoever in the syntax that says that only 28 bits are significant. Perhaps I intend there to be 30 significant bits there, of which the two high-order bits happen to be zero.  Date: 6 November 1980 02:18-EST From: Alan Bawden Subject: defstruct in MacLisp To: TFT at MIT-AI cc: BUG-LISP at MIT-AI ALAN;STRUCT FASL on AI or MC is a still experimental defstruct that we plan on installing on the LispMachine sometime soon. It tries to be 99% compatable with the old (current) LispMachine defstruct but it also has new features, and it works (and will continue to work) in MacLisp. (It grew out of my private defstruct for MacLisp.) It lacks one major feature that the current LispMachine defstruct has, it doesn't do "components", that is, slots of the form (( ) ( )). This it what is keeping us from installing it, I have to get around to putting this feature in. But if you don't use this feature, then you can start using it now. You can find fairly complete documentation for it in ALAN;STRUCT DOC. There is also a QFASL, but it is not necessarily in phase with the current FASL. It's also not a good idea to use it unless you have to, since it will break your LispMachine world in several small (not fatal, just annoying) ways. Let me know if you are going to use this so I can add you to my mailing list of people to inform when I break the thing!  Date: 6 November 1980 01:25-EST From: Tom Trobaugh To: BUG-LISP at MIT-AI How do I get defstructs in MACLISP? MACLISP used to understand LISPM2;NSTRUC, but seems to have lost some of the relevant vocabulary.  Date: 5 November 1980 21:49-EST From: Glenn S. Burke Subject: you have seen this before and ignored it To: BUG-LISP at MIT-ML When a user-hunk is sent the print message and the original stream was nil (the default) but there are outfiles, it just gets passed outfiles, making the terminal feel lonely. It should be passed NIL instead. Isn't there a bit which can be checked somewhere for this before it is passed outfiles? This screws up dribble and log files in XLMS and brand-x, and is not fixed in lisp 2032.  Date: 5 NOV 1980 1250-EST From: RWK at MIT-MC (Robert W. Kerns) Sent-by: RWK at CADR5 at MIT-MC Subject: Using * in names To: CATCH-THROW at MIT-MC, Guy.Steele at CMU-10A Of course, your proposal re: using * wouldn't have helped in the case of CATCH and THROW, which were stable a lot longer than two years. Also lots of losers are replaced by losers which are replaced by losers.... Maybe everything should start out with 150 *'s, and once a month, if it hasn't been changed incompatibily, a * is removed from the name? Then when a name runs out of stars, it is considered to have tenure. CAR, CDR, and CONS have tenure, for example. (Remember LSUBR CONS?)  Date: 5 NOV 1980 1154-EST From: JONL at MIT-MC (Jon L White) Subject: |frobboz/||, and preferential names To: GUY.STEELE at MIT-MC CC: (BUG LISP) at MIT-MC Well, the reason for the note by KMP and RWK was that they objected to documenting what I thought were verrrry internal names -- the objections stems from differing opinions as to the utility of these functionalities. RWK's proposal -- what I called the "amazingly simple solution" -- that we just put EXPR properties on the desirable names, and worry (maybe) someday about a name changeover; that way we needn't grovel over all possible FASL files just in order to recycle a name like |frobboz/||. This "groveling" is the problem I referred to, and which you found puzzling -- namely that just fixing up a few source files won't help. I certainly hope that not all those functionalities are deemed truly worthy (i.e., worthy enough to have new names); even when they aren't externally worthy, it would still seem useful to document even the most obscurely-named piece of system code, simply because a coherent overall explanation in english is more useful even to a wizard than similar words obscurely hidden in the source code.  Date: 5 NOV 1980 1146-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Naming To: Guy.Steele at CMU-10A CC: JONL at MIT-MC, (BUG LISP) at MIT-MC Well, it turns out that |constantp/||, etc., while internal, do also show up in FASL files. I believe JONL's putting them in LISP RECENT was a reaction to my statement that I was planning to document them (in my Maclisp manual) whether anyone wanted it or not ... In particular, I feel that Lisp is a well- abstracted set of Assembly-Language routines (sometimes not so well...). But the ones that have Lisp-symbol entrypoints represent functions with calling conventions that can be used by users and might as well be documented so that users with those same applications can take advantage of them rather than having them duplicate effort to write something truly obscure (as I have written to identify C...R forms in the past -- there are two builtins which deal with this and neither is advertised) ... So RWK and I propose to name these reasonably and leave the funny names with EXPR indirection properties of the good names (and maybe at some far future date, flush the funny names). When/if this happens, the COMPLR will be made to diagnose and rewrite code involving the funny names to code involving the pretty names ... -kmp  Date: 5 November 1980 1142-EST (Wednesday) From: Guy.Steele at CMU-10A To: catch-throw at MIT-MC Subject: Using * in names CC: lisp-forum at MIT-MC Message-Id: <05Nov80 114228 GS70@CMU-10A> I must agree with Dick Waters and others, that code should use *CATCH/*THROW from now on, but the old names CATCH and THROW should not go away or be recycled, and *CATCH/*THROW also should not go away. But to prevent such glitches in the future, I have a suggestion: when a feature is first implemented (say a function GLOTZ), it should from the outset be called *GLOTZ. Then when someone eventually points out what a loser it is, one can invent the better version and call that one just plain GLOTZ. If *GLOTZ turns out to be okay, then after two years the name GLOTZ can be phased in as a synonym for *GLOTZ.  Date: 5 November 1980 1134-EST (Wednesday) From: Guy.Steele at CMU-10A To: jonl at MIT-MC Subject: Naming CC: bug-lisp at MIT-MC Message-Id: <05Nov80 113458 GS70@CMU-10A> From: JONL at MIT-MC (Jon L White) Subject: Your personal feelings about names From: rwk,kmp at MIT-MC . . . (2) We disagree violently with releasing functions named +INTERNAL..., |constantp/|| etc. These functions want reasonable names. So just go ahead and remove them from the documentation. Who cares, since nobody will use them anyhow. In defense of documentation, though, I would say that the several system packages are interrelated; e.g., several places call |constantp/||, which would have the same functionality regardless of what you rename it to. Furthermore, because of the interrelations, you can't fix the name argument just by renaming them in the source. You (RWK) invented some of them, and must have had good reason for such functionality in the higher-level functions (like SETF). So why not flush the documentation and let every loser re-invent the functionality? I agree with the point which I think KMP and RWK were trying to make. As I perceive it, they were arguing not that functions which have been endowed with funny names should not be advertised, but rather that if a function is useful enough to the user to be worth advertising in LISP RECENT, then one ought to provide such a function with a reasonable name. After all, names like +INTERNAL-FROBBOZ and |frobboz/|| are purposely used to keep certain functions out of the user's hair; they were chosen precisely because they are weird and hard to type. This is okay for system types, but users shouldn't have to put up with it. (Actually, it hurts my eyes just to look at a name like |frobboz/|| -- which means it is *excellent* for its original purpose. I certainly don't want to use such a name in *my* code!) I don't understand the remark, "because of the interrelations, you can't fix the name argument just by renaming them in the source." Well, certainly you have to rename something everywhere it is used, but since such a function is by hypothesis a "system function" before it gets advertised, presumably you system wizards can get together and find all such places. I think it would be worth it.  Date: 5 November 1980 1123-EST (Wednesday) From: Guy.Steele at CMU-10A To: Robert W. Kerns Subject: Re: Another thought on #o CC: bug-lisp at MIT-MC In-Reply-To: Robert W. Kerns's message of 1 Nov 80 12:41-EST Message-Id: <05Nov80 112308 GS70@CMU-10A> You said, "Under my proposal, the only truncation is that if you want to type in a 32-bit number, you type in 32 bits." How, pray tell, does one type precisely 32 bits in octal? (Okay, so the VAX uses hex, but...) But if you type in a 36-bit number (on the PDP-10), you said that you wanted to get a fixnum, not a bignum. In order to do this, you have to *know* that 36 bits is what you wanted. By "truncation", I don't mean that any bits you typed are lost; instead I mean that an arbitrary word length is somehow chosen, which can cause odd things such as negative numbers to appear if a large "unsigned" number is typed. By the way, on the VAX should an unsigned number be 28 bits or 32 bits? (Sorry, I meant 30 or 32.) In the one case you can't specify a full word unsignedly; in the other you get a bignum.  Date: 5 November 1980 1114-EST (Wednesday) From: Guy.Steele at CMU-10A To: GSB at MIT-ML Subject: Re: Format's C (kicking a live horse) CC: dlw at MIT-AI, alan at MIT-AI, bug-lisp at MIT-MC In-Reply-To: GSB@MIT-ML's message of 4 Nov 80 18:11-EST Message-Id: <05Nov80 111459 GS70@CMU-10A> Well, it seems to me that the problem is that ITS has a split personality wrt characters: it can't make up its mind as to what code 003 means, so how can LISP? Well, maybe MacLISP should adopt an internal 9-bit standard (SIGH! shades of SAIL) and declare codes 0-37 to be SAIL graphics after all (except format effectors). But that sounds like a lot of work.  Date: 4 November 1980 16:16-EST From: Kent M. Pitman Subject: Forwarded mail... To: BUG-LISP at MIT-MC Date: 11/04/80 05:13:13 From: CSTACY at MIT-AI To: kmp cc: JIS at MIT-AI Re: IOCERROR I copied ai:lisp;mlmac fasl from MC, becuz I got five irrecoverable disk data errors on the old version. Works OK now. Chris  Date: 4 November 1980 00:41-EST From: Edward Barton To: BUG-LISP at MIT-AI Regarding the reader weirdness that RLB reported, it also happens with some other characters -- 1.0A is illegal, but 1.0%A and 1.0!A read as 10%A and 10!A respectively.  Date: 3 NOV 1980 2320-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: reader wierdity To: (BUG LISP) at MIT-MC 123.45$P12423 where "$"=alt reads as if the "." were absent, instead of "illegal object somewhere or other".  DDM@MIT-AI 11/03/80 19:08:49 To: catch-throw at MIT-MC Fine by me -- I've (finally) cleaned up all my existing code and put in *catch form so an eventual shift from that would just be a teco subst away (is the LISPM going to go to just "catch / throw" in the near future or are they keeping the stars indefinately ??)  Date: 3 NOV 1980 1425-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 3 November 1980 00:37-EST From: Kent M. Pitman Subject: LSUBRS/SUBRS without ARGS info in Lisp.2033 XLisp doesn't have ARGS info for the following forms on ITS. I would really like to see this fixed... *, *$, +, +$, -, -$, //, //$, +INTERNAL-AUTOLOAD, TTSR/|, APPEND, DIFFERENCE, HUNK, LIST, NCONC, PLUS, PROGN, QUOTIENT, TIMES Not all of these are LSUBRS -- +INTERNAL-AUTOLOAD and TTSR/| are subrs, and I"ve just edited the source to install the correct args "property"; as for the others, well, they sort of claim to accept anything, right?  Date: 3 November 1980 11:50-EST From: GSB,KMP at MIT-MC Sender: KMP at MIT-MC Subject: Age-old rubout bug To: BUG-LISP at MIT-MC On return, Lisp loses when doing rubout just after a line overflow. It thinks the operating system isn't going to move upward, so it does it. It is, however, wrong. ITS and Twenex both move upward automatically and one ends up rubbing into the line above the one he wants to be rubbing into ...  DICK@MIT-ML 11/03/80 11:29:12 To: catch-throw at MIT-MC I am certainly in favor of the original change that introduced *CATCH & *THROW instead of CATCH & THROW. I am also in favor of getting rid of the old meaning of CATCH & THROW permanently. There is no reason for the confusion of having both. I suggest picking an exact date for the total demise of CATCH & THROW, and putting this date in the compiler error message in order to encourage people to change. There is a second question however, of then going back to the original names CATCH & THROW, with the new meaning. I STRONGLY object to this for three reasons: 1. Why bother? Who cares what the names are? I don't want to go edit all my files again for such a trivial thing as that. 2. there is an advantage to just keeping the new names. you get to keep giving people reasonable error messages for ever. Particularly since we have a million old lisp manuals around that will be giving wrong information for ever, it should save a lot of grief for the new people that are always arriving. 3. The lisp machine still uses the names *CATCH & *THROW as far as I know. Is it going to change? If not, we would be introducing another incompatability. I do not think we should make the change unless the lispm does too. I do not think we should introduce unnecessary incompatabilities. In summary, I do not think we should make the second step of the change because it definitely has a cost, and I do not think it is worth anything significant. Richard Waters  Date: 3 NOV 1980 1000-EST From: JONL at MIT-MC (Jon L White) Subject: Defmacro-For-Compiling/Defmacro-Dispalce-Call To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 11/01/80 04:55:30 with defmacro-for-compiling set to nil, the forget-macromemos of the name being defmacroed still gets put into the fasl file. Although these are independent switches, it would seem generally superflous to have the macromemos cache serviced for macros which likely wont be in the runtime environment. SO I've edited into the source of DEFMAC the code to stop it -- will appear in version 130 or greater.  Date: 3 NOV 1980 0818-EST From: JONL at MIT-MC (Jon L White) Subject: PSETQ To: CWH at MIT-MC, FNT at MIT-MC CC: (BUG LISP) at MIT-MC Actually it never had an autoload property -- the docuemntation just got a step ahead of the code. But there should be a new XLISP today with PSETQ autoloadable in it.  Date: 3 NOV 1980 0814-EST From: CWH at MIT-MC (Carl W. Hoffman) To: FNT at MIT-MC, (BUG LISP) at MIT-MC FNT@MIT-MC 11/02/80 23:12:46 Has there been any recent changes in your lisp environment? "psetq" is no longer defined. PSETQ is defined by LISP;MLMAC FASL. It appears to have lost its autoload property.  Date: 3 NOV 1980 0725-EST From: JONL at MIT-MC (Jon L White) Subject: PSETQ To: RWK at MIT-MC, KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 1 November 1980 17:24-EST From: rwk,kmp at MIT-MC Subject: LISP;LISP RECENT . . . (1) PSETQ is not autoloading in XMaclisp.2033 on MIT-MC. I've just edited this into the source. What with all the little changes accreting, its time for a new XLISP. Just to remind everyone, if you want any of the XLISP dumps to stay on line (on the DISK), please make an entry into LISP;LOCK >  Date: 3 NOV 1980 0648-EST From: JONL at MIT-MC (Jon L White) Subject: /#-MACRO-DATALIST To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 3 November 1980 03:12-EST From: Kent M. Pitman . . . This symbol is still initially unbound. Could someone please fix this? Done.  Date: 3 NOV 1980 0639-EST From: JONL at MIT-MC (Jon L White) Subject: &WHOLE with other args... To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC You may have misinterpreted the semantics of &WHOLE Date: 3 November 1980 06:01-EST From: Kent M. Pitman . . . I should hope you don't make this work! Asking for it to work is like (DEFUN FOO (&REST BAR &OPTIONAL BAZ) (LIST BAR BAZ)) (FOO 3 4) to return ((3 4) 3) ... yuk! You should have to do (DEFUN FOO (&WHOLE FORM) (LET ((W (CDR FORM))) ...)) in order to win. -kmp Whereas &optional and &rest (and all the "&requireds") are necessarily sequentially parsed, &whole is totally independent of all of them.  Date: 3 November 1980 06:01-EST From: Kent M. Pitman Subject: &WHOLE with other args... To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 28 October 1980 09:32-EDT From: Jon L White To: BUG-LISP Re: &WHOLE Apparently the &REST interferes with the &WHOLE in (DEFMACRO FOO (&WHOLE FORM &REST W) ...) but other cases work. ----- I should hope you don't make this work! Asking for it to work is like asking (DEFUN FOO (&REST BAR &OPTIONAL BAZ) (LIST BAR BAZ)) (FOO 3 4) to return ((3 4) 3) ... yuk! You should have to do (DEFUN FOO (&WHOLE FORM) (LET ((W (CDR FORM))) ...)) in order to win. -kmp  Date: 3 November 1980 05:59-EST From: Scott J. Kramer Subject: Losing Maclisp.2034 To: KMP at MIT-EECS cc: BUG-LISP at MIT-MC Date: 2 Nov 1980 2318-EST From: KMP at MIT-EE To: SJK at MIT-EE cc: BUG-LISP Re: Losing Maclisp.2034 XX, Speech, and EE are all losing by having SETF try to AUTOLOAD it rather than having it primitively defined to be an FSUBR. This causes a SETF undefined after autoload message when you try somethgin like (SETF x 3) ... I don't understand why this should be different on tweneces than on its. or maybe it is broken in all lisps and we haven:'t seen the effect yet (sorry about the typos -- this is a losing ai tv i am on) ... can you please look into fixing this? thanks muchly. -kmp Fixed on EE, the SETF there was ancient and thus incompatable with the newer Lisp. -sjk  Date: 3 November 1980 05:23-EST From: Robert W. Kerns Subject: FUNCALL BUGS FIXED To: KMP at MIT-MC cc: ALAN at MIT-MC, BUG-LISP at MIT-MC Date: 3 November 1980 00:51-EST From: Kent M. Pitman To: BUG-LISP cc: ALAN (SETQ A (ARRAY NIL T 100.)) (LEXPR-FUNCALL A '(10.)) dies on a too many args error, too! This and its friends, including the wrong messages with FUNCALL, have been fixed. A number of small bugs, only one of which belonged to LEXPR-FUNCALL. The rest were all between FUNCALL and WNAERR ....  Date: 3 November 1980 03:12-EST From: Kent M. Pitman Subject: /#-MACRO-DATALIST To: BUG-LISP at MIT-MC Date: 22 July 1980 06:22-EDT From: Jon L White Date: 20 July 1980 03:44-EDT From: Kent M. Pitman (STATUS SYSTEM '/#-MACRO-DATALIST) => (VALUE SYMBOL) but /#-MACRO-DATALIST is initially unbound. I am uncomfortable with this. Is there some reason it can't be () by default? In fact, why does it have privileged status as a system symbol when |#-C-M-bits| and some of the other variables used by SHARPM do not? -kmp It could be initially set to () with no harm -- was probably left this way during some experimentation as to how much should be assembled in and how much should be autoloaded. This symbol is still initially unbound. Could someone please fix this? -kmp  Date: 3 NOV 1980 0305-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC The non-existent function HUMBLE still autoloads in XLisp.2033  Date: 3 NOV 1980 0051-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC (SETQ A (ARRAY NIL T 100.)) (LEXPR-FUNCALL A '(10.)) dies on a too many args error, too!  Date: 3 NOV 1980 0037-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: LSUBRS/SUBRS without ARGS info in Lisp.2033 To: (BUG LISP) at MIT-MC XLisp doesn't have ARGS info for the following forms on ITS. I would really like to see this fixed... *, *$, +, +$, -, -$, //, //$, +INTERNAL-AUTOLOAD, TTSR/|, APPEND, DIFFERENCE, HUNK, LIST, NCONC, PLUS, PROGN, QUOTIENT, TIMES -kmp  Date: 3 NOV 1980 0017-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC In lisp 2033: The error messages I get for FUNCALLing or LEXPR-FUNCALLing an array on too few arguments is "TOO MANY ARGUMENTS SUPPLIED - APPLY". Also the other stuff printed out in WNA error messages for FUNCALLing or LEXPR-FUNCALLing an array varies from partly to completely bogus. (The cases are too many to list them all, try them and see.) Finally: (LEXPR-FUNCALL (ARRAY NIL T 2 3) '(1 1 1)) gets an MPV.  Date: 2 NOV 1980 2349-EST From: ALAN at MIT-MC (Alan Bawden) Subject: (SETF (FIXNUM-IDENTITY X) Y) again To: (BUG LISP) at MIT-MC The reason this should expand into: (SETF X (FIXNUM-IDENTITY Y)) and NOT: (FIXNUM-IDENTITY (SETF X Y)) (as it does now) is to check the fixnumitude of Y BEFORE storing it into the fixnum variable X! Please?  Date: 2 Nov 1980 2318-EST From: KMP at MIT-EE Subject: Losing Maclisp.2034 To: SJK at MIT-EE cc: BUG-LISP at MIT-MC XX, Speech, and EE are all losing by having SETF try to AUTOLOAD it rather than having it primitively defined to be an FSUBR. This causes a SETF undefined after autoload message when you try somethgin like (SETF x 3) ... I don't understand why this should be different on tweneces than on its. or maybe it is broken in all lisps and we haven:'t seen the effect yet (sorry about the typos -- this is a losing ai tv i am on) ... can you please look into fixing this? thanks muchly. -kmp -------  Date: 2 NOV 1980 1810-EST From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (DEFMACRO FOO (&REST BAR) (DECLARE (SPECIAL BAR)) (FUNCALL BAR)) gets the following error from the COMPLR: (COMMENT **ERROR** (DECLARE (SPECIAL BAR)) Local declaration at wrong place in function |FOO MACRO|)  Date: 2 NOV 1980 0745-EST From: JONL at MIT-MC (Jon L White) Subject: VTS interactions with MacLISP To: (BUG TWENEX) at MIT-MC CC: (BUG LISP) at MIT-MC 1) the TM%SCR bit of a subsystem is not inherited from the setting at exec (say, @TERM WRAP), consequently MacLISP is just forcibly setting it to some state now -- the (STATUS TTY) function will have an option for reading the Terminal Mode Word, and (SSTATUS TTY ...) will set it, so MacLISP users can tailor these bits to their own needs. 2) ITS standard for outputting a control-P while in display mode is to output control-P followed by P, which will print out as "^P"; but VTS apparently just prints nothing here.  Date: 2 NOV 1980 0546-EST From: JONL at MIT-MC (Jon L White) Subject: Your personal feelings about names To: RWK at MIT-MC, KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 1 November 1980 17:24-EST From: rwk,kmp at MIT-MC . . . (2) We disagree violently with releasing functions named +INTERNAL..., |constantp/|| etc. These functions want reasonable names. So just go ahead and remove them from the documentation. Who cares, since nobody will use them anyhow. In defense of documentation, though, I would say that the several system packages are interrelated; e.g., several places call |constantp/||, which would have the same functionality regardless of what you rename it to. Furthermore, because of the interrelations, you can't fix the name argument just by renaming them in the source. You (RWK) invented some of them, and must have had good reason for such functionality in the higher-level functions (like SETF). So why not flush the documentation and let every loser re-invent the functionality?  Date: 1 NOV 1980 1932-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Feature LISP To: (BUG LISP) at MIT-MC I see LISP does precisely the right thing with IBASE=1 !! Now, if it would only understand BASE=1 ....  Date: 1 November 1980 18:49-EST From: George J. Carrette To: KMP at MIT-MC cc: CATCH-THROW at MIT-MC, MILLER at MIT-MC, PSZ at MIT-MC Kent, I think PSZ suggestion of some kind of 1980 release of Maclisp is something to consider too. To tell the truth, I hate to imagine students being introduced to lisp, and a course taught in an standard maclisp environment. When I introduce people to lisp, mostly when I see they need an expressive power they can't get in Macsyma, I always start them off in the most up to date macro environment; and most importantly make sure they read good new code to see how things are done, before I let them read old macsyma system code. The regularization of the language can be done in a burst for the people who are starting fresh. I think the courses which use a practical lisp system, (i.e. one with a compiler, 6.001 doesn't count), need to have a least one thoughtful and expert maclisp programmer go over the environment with a fine comb, making sure the good stuff and defaults are in, and the bad stuff is out. This takes experience of course, but shouldn't take too much time. Most of documented maclisp is simply very low-level stuff. *ARRAY, HUNK, ARRAYCALL, STORE, even RPLACA, RPLACD, are things that just aren't seen in new maclisp code. I would say none of the STATUS and SSTATUS stuff are directly applicable. DECLARE is also low-level because subtle misuse can cause unpredictable effects. One could go on and on ... -gjc  Date: 1 NOV 1980 1724-EST From: rwk,kmp at MIT-MC Sent-by: KMP at MIT-MC Subject: LISP;LISP RECENT To: (BUG LISP) at MIT-MC (1) PSETQ is not autoloading in XMaclisp.2033 on MIT-MC. (2) We disagree violently with releasing functions named +INTERNAL..., |constantp/|| etc. These functions want reasonable names. -kmp,rwk  Date: 1 NOV 1980 1559-EST From: JONL at MIT-MC (Jon L White) Subject: Last Breath Horse To: KMP at MIT-MC, (BUG LISP) at MIT-MC The point about (DEPOSIT #O... #*...*) or any such hac, such as JLK;LISPT PATCH is that you dont export them. ever. so you dont even need #+MULTICS or anything else.  Date: 1 NOV 1980 1556-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: ...cont'd To: (BUG LISP) at MIT-MC, JONL at MIT-MC Except that #+PDP10 (DEPOSIT #o124000 #o*...) would be more appropriate since it's meaningless on Multics and LispM and such ... Outside the whole form is where the #+condition belongs ...  Date: 1 NOV 1980 1554-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Jonl's note To: JONL at MIT-MC, (BUG LISP) at MIT-MC Grak, (DEPOSIT #o124000 #+PDP10 #o...) would read as (DEPOSIT #o124000) on non-PDP10's. Glag ... It would probably put **MISSING-ARG** in that location for all I know. ALAN's comments just prior to this note sum up my view correctly.  Date: 1 November 1980 15:49-EST From: Alan Bawden Subject: Very dead horses. To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, KMP at MIT-MC Date: 1 November 1980 15:21-EST From: Jon L White Uh, re your remark Date: 1 November 1980 15:01-EST From: Kent M. Pitman Subject: #O truncation, and #* there's a certain "patch" doable to maklisp which involves (DEPOSIT #O124000 #*265500013613*) If I didn't misunderstand your last comment on this dead horse, you seem to think that it would be much clearer if it were written (DEPOSIT #O124000 #+PDP10 #O265500013613) ?? (DEPOSIT #O124000 #O*265500013613) Would be the way to make the patch. The point is that the number in a #*...* IS in SOME base, so why not make it explicit? Unless you have some hack that works by interpreting the same digits in different bases on different machines (ugh!), how can it hurt you to write the base down?  Date: 1 Nov 1980 1548-EST From: Scott J. Kramer Subject: Re: Calling EXEC from MacLisp To: IC.Mark at MIT-EE cc: Bug-Lisp at MIT-MC On EE: (LOAD '((MACLISP) SUBFORK)) then (EXEC). Subsequent calls of this function will return you to the same "pushed" EXEC. -sjk -------  Date: 1 NOV 1980 1547-EST From: JONL at MIT-MC (Jon L White) Subject: Subjobs on Twenex To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, IC.MARK at MIT-EECS Date: 1 Nov 1980 1431-EST From: KMP at MIT-EE Subject: [IC.MARK: calling EXEC from MACLISP] Does anyone have any good ideas about how to call Twenex from Maclisp? I think maybe Twenex Maclisp should offer something like Multics' CLINE or at least like the PUSH command offered in many of the other Twenex systems. In addition to VALRET, which at leas will permit you to do a monitor command and return (but it seems, not return from a subsystem), you could use the SUBFORK facility. see the source file [EE]SUBFORK.LSP which has enough comments to be readable to a non-novice lisp programmer. I helps you set up sub forks, and operate on them, and well as running random JSYS's. For some sample usage, see the source for the LEDIT interface [EE]LEDIT.LSP  Date: 1 NOV 1980 1521-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Uh, re your remark Date: 1 November 1980 15:01-EST From: Kent M. Pitman Subject: #O truncation, and #* there's a certain "patch" doable to maklisp which involves (DEPOSIT #O124000 #*265500013613*) If I didn't misunderstand your last comment on this dead horse, you seem to think that it would be much clearer if it were written (DEPOSIT #O124000 #+PDP10 #O265500013613) ?? Of course, nobody hacks machine language from lisp right? And all LAP code is portable, right? (see JLK;LISPT PATCH) At any rate, when "hacking with the bits", something like #* would help separate out such things; or maybe one would do (SETQ JSP-INSN #*265500013613*) (DEPOSIT PATCH-ADDRESS JSP-INSN) ;; see how much cleaner this is with a comment and a mnemonic name?  Date: 1 November 1980 15:15-EST From: Robert W. Kerns Subject: [IC.MARK: calling EXEC from MACLISP] To: KMP at MIT-EECS cc: BUG-LISP at MIT-MC (VALRET "TERM VT52 CONT ") works just fine.  Date: 1 NOV 1980 1513-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: #O* vs. #*O To: (BUG LISP) at MIT-MC The only reason for not doing #O* is that then you can't do #O( Subject: Forwarded mail... To: CATCH-THROW at MIT-MC Date: 11/01/80 12:15:22 From: MILLER at MIT-AI To: KMP Re: Query for Lisp users My own opinion falls somewhere between that if Pete Solovitz' (gather all such cleanups together, do them all at once, and publish a definitive 1980 manual, or else don't do it at all -- and to his list I'd add flushing old-style DO) and that of BEE (go for it). I only use the new forms of each thing, but the "software rot" problem is far more severe in MacLisp than any other language. If you take a 1-week vacation, it is likely that a new distribution tape has arrived (we're not on the net at TI, yet anyway) and that your programs won't work till you edit X, Y, and Z. If you have a very busy schedule that includes things besides hacking (giving talks, selling management on AI, selling other parts of the company on "doing the winning thing", managing a project or three, teaching a class), it is easy to find your programs and lectures falling months behind what the system actually does. This is very painful. Thanks for listening to our views. Regards, Mark  Date: 1 November 1980 15:01-EST From: Kent M. Pitman Subject: #O truncation, and #* To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, JONL at MIT-MC, RLB at MIT-MC Date: 1 November 1980 13:41-EST From: Robert W. Kerns To: JONL cc: BUG-LISP, RLB Re: #O truncation, and #* The current definition of #* is not the right thing for machine dependent code. There is such a thing as gratuitous dependency. ----- I agree completely. I tink that the existing definition of #* just gives people license to write code which is never going to be transportable. Worse, it does not keep the stuff from being run on another system. Consider the alternatives: Either you can do something like: #+PDP37 (SETQ FOO #o777777000000) (or some such) or you can do something like #+PDP37 (SETQ FOO #*777777000000*) In the former case, you are providing the guy with info that the number is octal. If he's never heard of PDP37's, he may still be able to read your code. In the latter case, you provide him with 0 info if he doesn't know what word size and natural base are for the PDP37. Heck, it could be HEX on a 48bit machine and just happen to be that no lettered digits were needed for this application ... The programmer always knows. Further, if he's playing with bits, he's doing something very intricate. I think we have an obligation to provide constructs that lend structure to his program rather than allowing him to hide in obscure idioms. Is there anyone currently opposed to the flushing of the #* convention? RWK: #O being already locked down, there is an advantage to #O* over #*O which is that it leaves #* free for some other application. As to the concept of truncation, I guess I agree with RWK that we need to think up a place where truncation could be used successfully in some real application before we offer auto-truncation..  Date: 1 NOV 1980 1500-EST From: KMP at MIT-MC (Kent M. Pitman) To: PSZ at MIT-MC CC: CATCH-THROW at MIT-MC, GJC at MIT-MC, MILLER at MIT-MC The change will only drastically affect people using CATCH/THROW in the old semantics. I am less interested in making *CATCH/*THROW go away than I would be in getting CATCH/THROW to do the right thing. I am not opposed to leaving *CATCH/*THROW for a year or so to give you time to change over ... also the definition (MACRO *CATCH (X) (RPLACA X 'CATCH)) (MACRO *THROW (X) (RPLACA X 'THROW)) would be the only change you needed in order to make your incidences of CATCH/THROW compile. Since all of *CATCH, CATCH, THROW, and *THROW open code, this should not break any FASL files, only EXPR code. I suspect that regularization of the language in a burst as you describe would offend more people. Whole packages would just fail to run and people would be unable or unwilling to fix them. This kind of change involves a very mechanical set of instructions which will convert old forms to new ones. I can even provide you with Teco macros that let you do this with a minimum of effort. Can you be persuaded yet?  Date: 1 Nov 1980 1431-EST From: KMP at MIT-EE Subject: [IC.MARK: calling EXEC from MACLISP] To: BUG-LISP at MIT-MC Does anyone have any good ideas about how to call Twenex from Maclisp? I think maybe Twenex Maclisp should offer something like Multics' CLINE or at least like the PUSH command offered in many of the other Twenex systems. --------------- Date: 1 Nov 1980 0600-EST From: IC.MARK Subject: calling EXEC from MACLISP To: kmp How can I, in the process of loading a Malcisp file, e.g. FINAL2.LSP, run a TERMINAL command in EXEC? I'm trying to set TE RAISE before the running of FINAL2. Thanx. ------- --------------- -------  Date: 1 NOV 1980 1415-EST From: GJC at MIT-MC (George J. Carrette) To: CATCH-THROW at MIT-MC CC: PSZ at MIT-MC Go for it! I have no CATCH/THROW in my code, and the *CATCH=> CATCH transformation will take only a couple minutes to cover the hundreds of pages of code in macsyma and my own stuff, via tags-query-replace. The way to win in a changing language is to keep the changes of the meta-language manageable. -gjc  Date: 1 November 1980 13:41-EST From: Robert W. Kerns Subject: #O truncation, and #* To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, RLB at MIT-MC The current definition of #* is not the right thing for machine dependent code. There is such a thing as gratuitous dependency.  Date: 1 November 1980 12:41-EST From: Robert W. Kerns Subject: Another thought on #o To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 31 October 1980 17:25-EST From: Kent M. Pitman Subject: Another thought on #o To: BUG-LISP at MIT-MC ... Note also that if we hair up #o it should be made clear that #8r is what people want to read normal numbers in base 8 and that #o is especially for dealing with single-machine-word bits. Currently there is no emphasized difference between #8r and #o. What hairing up of #o do you refer to? I think that under both RLB's and my proposal, #o by itself does NOT truncate to single-machine-word integers. Under my proposal, the only truncation is that if you want to type in a 32-bit number, you type in 32 bits.  Date: 1 November 1980 12:30-EST From: Robert W. Kerns Subject: Re: #o and unsignedness To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC Date: 31 October 1980 1722-EST (Friday) From: Guy.Steele at CMU-10A To: RWK at MIT-MC (Robert W. Kerns) Subject: Re: #o and unsignedness CC: bug-lisp at MIT-MC In-Reply-To: RWK@MIT-MC's message of 31 Oct 80 16:13-EST Message-Id: <31Oct80 172251 SL5P@CMU-10A> The truncation I referred to was chopping off the poor "integer" and forcing it to fit into a fixnum (thereby causing some bits possibly to be lost, but in any case suddenly altering the weight of one of its bits, from 2^25 to -2^35!!!). Ah, but this altering of the weight of one of it's bits only occurs when you stop thinking of it as an unsigned integer. One wouldn't use #*O when one meant anything other than an unsigned integer, so this altering in meaning wouldn't occur. This is no different than packing two nubers into a single integer, representing a character by a fixnum, etc. If I'm representing something like 2 18-bit positive numbers, and consider the combination as a combination of 2 18-bit numbers consistantly, it doesn't matter at all to me that occasionally one of these combininations would be considered to be negative if considered as a single fixnum on a machine of 36 bits or less; I never consider them as a single fixnum! There is a problem with #*O..., which is that if #B means binary then #*B is ambiguous on a machine where just plain #* means hexadecimal. Not if #* by itself never means hexadecimal, which was my proposal. Letting #* vary in radix from machine to machine isn't all that much of a problem -- the machines may have different word lengths as well, after all. They also may have a different number of disk drives. So what? So my code shouldn't read in even aproximately, because when I wrote #*ABC, now it tries to read it as octal? Tell me what GOOD it does to have the base varying and unspecified, as opposed to specified. Indeed, there is a nice symmetry between *, +, and - -- that's why I originally proposed to use *nnnn* (the stars actually being independent -- the treailing star was the "machine-radix point", and the leading one meant "unsigned fixnum" -- so that -nnn* and *ddd. actually made sense. But reason prevailed, and we got #*, which actually is rather nice to me now.)  Date: 1 NOV 1980 1218-EST From: JONL at MIT-MC (Jon L White) Subject: #O truncation, and #* To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, RLB at MIT-MC 1) how about truncating disussion of this trivial topic 2) #* is for machine-dependent code. Do people ever write machine-dependent code in LISP?  Date: 1 November 1980 12:15-EST From: Robert W. Kerns Subject: Re: #O, an alternate view, yet again. To: RLB at MIT-MC cc: BUG-LISP at MIT-MC Date: 31 October 1980 16:16-EST From: Richard L. Bryan Subject: Re: #O, an alternate view To: RWK at MIT-MC cc: BUG-LISP at MIT-MC If you don't want your input radix migrating machine-dependently, combine the #o and #* notations: type the PDP10 fixnum <-1,,0> as #o*777777000000 where the "*", rather than meaning "read in machine-dependent input radix", means "read in and truncate to machine-dependent number of bits". Implementation Note: the reader code for #x and #b, at least, currently needs to peek at the following char for '"'-ness, and could check for "*"-ness as well. -------- Sigh, why do people persist in thinking I want truncation? I don't, I want unsignedness! If I'm into truncation I can simply truncate my input. There is no truncation involved in specifying the sequence of bits represented by the unsigned octal number 777777000000 in a 36 bit word. In fact, I'd not have complained about it being a BIGNUM if it weren't for BOOLE or somebody not likeing it. But I specified 36 bits; it makes sense to give me 36 bits. If I give a 37-bit number I'd expect it to give me a bignum; truncation would be a bug! There might be use for truncation, but I doubt it's important enough to provide a reader syntax for it (besides #.). There IS reason to want to specify unsignedness. Now if we take RLB's proposal, substitute 'unsigned' for 'truncated to a machine-dependent number of bits', and reverse the '*' and 'o', we have my proposal. Now, I don't care about the order of the '*' and the 'o'. But I don't think BOTH proposals should exist; it would be too confusing. How about if we just don't offer truncation, and do offer unsigned reading? Does anybody REALLY believe there is ANY use or justification for having your input radix vary with implementation, ala #*? Why?  PSZ@MIT-ML 11/01/80 09:09:01 Re: Objecting to the proposed changes To: catch-throw at MIT-MC CC: PSZ at MIT-ML, GSB at MIT-ML Although I fully concur in the desire to "clean up" lisp by fixing CATCH and THROW to what they "should have done anyway", I find myself revolted by the thought of having to spend several days groveling through old code just to fix up a bunch of not-very-important stylistic differences which yield me no real gain. I have been happily writing *CATCH and *THROW recently, but of course now I will have to fix those too. If MACLISP were at one stroke to become a relatively static (i.e., SLOWLY changing) language which was well documented and easily accessible to new users, I would be less reluctant to take the effort to go fix old programs, but as it is, I am likely to fix CATCHes today and something else next month. (Some functionally unchanged code I use in 6.871 absolutely requires yearly maintenance.) Perhaps we could strike a deal: I will accept the burden of "modernizing" a lot of old code once, if: 1. All foreseeable incompatible changes to MACLISP are gathered together at one time, announced together, and made together, with the good will intent that no other such changes should come along for a significantly long while without very good reason. 2. A new (complete) MACLISP manual is simultaneously issued so that it becomes possible to teach the language to new users. The idea would be to have a "1980" release of MACLISP which then becomes the standard for the next few years. (I have been teaching MACLISP to 6.871 students -- after a fashion -- out of the 1974 manual, scraps of the 1978 manual, and random system notes. It is a very unsatisfactory experience.) Note that if the hackers agreed to this deal, then it would also be reasonable to sift through current Lisp and find other things to clean up. Discussions with JONL come to mind concerning: 1. Flushing the HUNK variable and its effects on EQUAL, etc. by publishing the USERHUNK or EXTEND facility. 2. Settling on some consistent set of function and macro definition and memoizing facilities. 3. Standardizing various macro packages and deciding the status of all the NIL extensions to MACLISP. 4. Implementing a sheme of physical/logical character mappings which would permit various packages to be written with syntax using logical character sets independent of each other and several to be used together by mapping their characters into the physical alphabet. This would be a generalization to the various #(, #< etc. crocks. 5. Standardizing the inclusion and "x-time eval" mechanisms of MACLISP (I prefer LSB). Maybe adding some on-line documentation aids. etc. I am a reasonable man, ready to bargain. But I do think that something along the above lines, including a renewed commitment to current, coherent, and consistent documentation, is essential. --Pete Szolovits  GSB@MIT-ML 11/01/80 04:55:30 To: (BUG LISP) at MIT-ML with defmacro-for-compiling set to nil, the forget-macromemos of the name being defmacroed still gets put into the fasl file.  Date: 1 NOV 1980 0407-EST From: JONL at MIT-MC (Jon L White) To: REM at MIT-MC CC: CATCH-THROW at MIT-MC Date: 31 October 1980 19:09-EST From: Robert Elton Maas . . . Persons running NIL code can write macros that map CATCH and THROW to *CATCH and *THROW while experienced NIL users will be careful not to load faulty code in with their NIL stuff. Just like to point out that the NIL syntax for CATCH is primitive, and it is *CATCH which is made a macro (which conveniently enough just changes its name into CATCH)  Date: 31 October 1980 20:46-EST From: Neal Feinberg Subject: *CATCH/*THROW -- CATCH/THROW To: CATCH-THROW at MIT-MC I like catch/throw as they are, thankyou. I see know REAL reason to change this and muck up all my programs. Neal  Date: 31 October 1980 19:35-EST From: Kent M. Pitman Subject: Forwarding failed mail... To: CATCH-THROW at MIT-MC MOON@MIT-MC 10/31/80 17:29:33 This sounds reasonable (if not very important). The disruption to users could be serious--we'll have to see.  Date: 31 OCT 1980 1909-EST From: REM at MIT-MC (Robert Elton Maas) To: CATCH-THROW at MIT-MC I vote for immediately changing CATCH and THROW to generate an error |Use *CATCH and *THROW instead, see MC:LSPMAI;CATCH QUERY for info.| or something like that. CATCH QUERY should indicate how to emulate all forms of old CATCH/THROW code using the new *CATCH/*THROW/CATCHALL. Persons running NIL code can write macros that map CATCH and THROW to *CATCH and *THROW, thus there is no reason to install CATCH and THROW as built-in synonyms for *CATCH and *THROW for several months. Lusers running old code during this time will thus be pointed to needed info for easily upgrading the code, while experienced NIL users will be careful not to load faulty code in with their NIL stuff.  Date: 31 OCT 1980 1845-EST From: BEE at MIT-MC (Bruce E. Edwards) To: CATCH-THROW at MIT-MC Right on!! Go for it.  Date: 31 OCT 1980 1813-EST From: ALAN at MIT-MC (Alan Bawden) To: CATCH-THROW at MIT-MC Sure. Go ahead. The sooner you do it the better.  Date: 31 OCT 1980 1725-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Another thought on #o To: (BUG LISP) at MIT-MC #o and friends could also peek for a trailing "," to help in system system programming. for DDT compatibility, an extra "," would be eaten as well. Hence, the following sorts of things would work: #o-1,,0 #o1,,0 or even #o1,, I would recommend that leading spaces be allowed after the "o" but not after the comma. So that (SYSCALL 3. 'FOO #o -1,,0 #o 3,,) would be a valid form. The sign convention "*" might want to work for both halves so that you could say #o -1,,*2222222222222222222222222222 in order to mean 777... in the left half and the pattern 010 010 010 ... in the right half ... Note also that if we hair up #o it should be made clear that #8r is what people want to read normal numbers in base 8 and that #o is especially for dealing with single-machine-word bits. Currently there is no emphasized difference between #8r and #o.  Date: 31 October 1980 1722-EST (Friday) From: Guy.Steele at CMU-10A To: RWK at MIT-MC (Robert W. Kerns) Subject: Re: #o and unsignedness CC: bug-lisp at MIT-MC In-Reply-To: RWK@MIT-MC's message of 31 Oct 80 16:13-EST Message-Id: <31Oct80 172251 SL5P@CMU-10A> The truncation I referred to was chopping off the poor "integer" and forcing it to fit into a fixnum (thereby causing some bits possibly to be lost, but in any case suddenly altering the weight of one of its bits, from 2^25 to -2^35!!!). There is a problem with #*O..., which is that if #B means binary then #*B is ambiguous on a machine where just plain #* means hexadecimal. Letting #* vary in radix from machine to machine isn't all that much of a problem -- the machines may have different word lengths as well, after all. Indeed, there is a nice symmetry between *, +, and - -- that's why I originally proposed to use *nnnn* (the stars actually being independent -- the treailing star was the "machine-radix point", and the leading one meant "unsigned fixnum" -- so that -nnn* and *ddd. actually made sense. But reason prevailed, and we got #*, which actually is rather nice to me now.)  Date: 31 October 1980 1714-EST (Friday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: Re: #O, an alternate view In-Reply-To: Richard L. Bryan's message of 31 Oct 80 16:16-EST Message-Id: <31Oct80 171400 SL5P@CMU-10A> Actually, I wasn't going to mention it, but now that RLB has come close... If you're really paranoid, why not write #8*777777000000*, or #16*FFFF0000*, or whatever? Then I guess #o* and #x* suggest themselves after all. While we're at it, I still, think my idea of using "[n]" as a radix-n point had some merit. 7307[8] => #o7307, FF00A3BC[16] => #xFF00A3BC. Who cares if it's harder to parse? You get floating-point in exchange! (Pi = 3[8]11037552, approximately.) --Quux  Date: 31 OCT 1980 1627-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: RLB's #o* suggestion To: (BUG LISP) at MIT-MC I agree. That would free up #*, which I think is a good idea. #o*, etc. could just repeatedly TYIPEEK for digits, add them to LSH of the previous result, and finally return when a non-digit was peeked at. Note that the thing should signal an error on #o*12345ABC, where a break char did not follow immediately after the last digit. -kmp  Date: 31 October 1980 16:16-EST From: Richard L. Bryan Subject: Re: #O, an alternate view To: RWK at MIT-MC cc: BUG-LISP at MIT-MC If you don't want your input radix migrating machine-dependently, combine the #o and #* notations: type the PDP10 fixnum <-1,,0> as #o*777777000000 where the "*", rather than meaning "read in machine-dependent input radix", means "read in and truncate to machine-dependent number of bits". Implementation Note: the reader code for #x and #b, at least, currently needs to peek at the following char for '"'-ness, and could check for "*"-ness as well.  Date: 31 OCT 1980 1613-EST From: RWK at MIT-MC (Robert W. Kerns) Sent-by: ___045 at MIT-MC Subject: #o and unsignedness To: Guy.Steele at CMU-10A CC: (BUG LISP) at MIT-MC Indeed, I never suggested that it should truncate. I gave it a bit pattern that would fit in a FIXNUM and it didn't fit it in a fixnum. But on reflection I think my other proposal is superior: Replacing #*nnnn with #*O (or #*X or #*D or #nn*R ...) to be unsigned. There's even mnemonic value in the * being neither - nor +. This could even be made compatible with it's current behaviour in that I don't know of any non-octal uses, so #*nnn could be the same as #*Onnnn  Date: 31 October 1980 1512-EST (Friday) From: Guy.Steele at CMU-10A To: MACRAKIS at USC-ISIE Subject: Re: Namelist of Twenex subdirectories CC: bug-lisp at MIT-MC In-Reply-To: MACRAKIS@USC-ISIE's message of 31 Oct 80 13:08-EST Message-Id: <31Oct80 151242 GS70@CMU-10A> I agree with Stavros' observation.  Date: 31 October 1980 1507-EST (Friday) From: Guy.Steele at CMU-10A To: Robert W. Kerns Subject: Re: #O, an alternate view CC: bug-lisp at MIT-MC In-Reply-To: Robert W. Kerns's message of 31 Oct 80 11:47-EST Message-Id: <31Oct80 150725 GS70@CMU-10A> Fine, let #o be only unsigned. But that is a different issue from deciding at what point to truncate it (word size). There are some applications where you want to use a bignum as a bit string (especially on the PDP-10, which unlike NIL doesn't have a BITS), on which to use bignum BOOLE or HAIPART, etc. (I think Pratt does some of this kind of thing.) Think of it this way: #o is the *portable* way to get bit patterns, and #* is the way to get *machine-dependent* bit patterns. The fact that you can use one to get the other (sometimes) is no more excuse for confusing them than is using CDR when you mean PLIST, even though that also works (sometimes).  Date: 31 October 1980 14:53-EST From: Robert W. Kerns Subject: #O, #X, #R etc To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 31 October 1980 11:56-EST From: Jon L White To: RWK cc: BUG-LISP Re: #O, #X, #R etc Uh, you did see about #* also didn't you? (also my request that someone may want to fix the #*400000000000* bug in MacLISP's SHARPM) Yes. Note that I didn't say anything about wanting my INPUT RADIX to vary depending on what machine I was on! In fact, this has always struck me as singularly useless. The text following it doesn't change when you port from machine to machine, after all! If the syntax were #*O or #*D or #*X and meant 'UNSIGNED', then I'd have no objections.  Date: Friday, 31 October 1980 10:08-PST From: MACRAKIS at USC-ISIE To: Bug-Lisp at MC CC: Macrakis at USC-ISIE Subject: Namelist of Twenex subdirectories Since the Car part of Namelist is supposed to represent the device/directory hierarchy, I should think that a Twenex filename of the form a:d.e should correspond to a namelist of ((a b c) d e) and not ((a |b.c|) d e). Currently, namelists like ((a b c) d e) are neither accepted as legal nor produced. Note that Twenex allows arbitrarily many levels of subdirectories in general.  Date: 31 Oct 1980 1202-EST From: KMP at MIT-EE Subject: Linefeed To: bug-lisp at MIT-MC cc: mt at MIT-XX When maclisp types blank lines in wraparound mode on Twenex, text from the previous screenful often is left sitting there. Isn't it doing the ^PA equivalent for Twenex? Doesn't this ask Twenex to clear the screen? This is not trivial to reproduce, I will watch for it and try to send you an example. But I have seen it happen enough times to warrant mentioning it. (MT -- this is the same effect as the bug I mentioned awhile back in HAUNT where when it got to the bottom of the screen, it would wrap but not blank out lines it wasn't going to type on) ... -kmp -------  Date: 31 OCT 1980 1156-EST From: JONL at MIT-MC (Jon L White) Subject: #O, #X, #R etc To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Uh, you did see about #* also didn't you? (also my request that someone may want to fix the #*400000000000* bug in MacLISP's SHARPM)  Date: 31 October 1980 11:47-EST From: Robert W. Kerns Subject: #O, an alternate view To: JONL at MIT-MC cc: BUG-LISP at MIT-MC The reason I don't agree that #o777777000000 should be a BIGNUM is that I think it should be an UNSIGNED OCTAL read. I have yet to want to represent a bit pattern by specifying its two's complement and preceeding it with a - sign in LISP, and only very rarely in MIDAS. I'd rather do #.(- #o250). Thus #o777777000000 should be read in as -262144., while #o1777777000000 would be read in as 137438691328. as it is now. This corresponds with the belief that the reason 2^n bases are used most frequently is to produce a specific bit pattern rather than an integer.  Date: 31 Oct 1980 1128-EST From: KMP at MIT-EE Subject: Display bug in Maclisp on EE To: BUG-LISP at MIT-MC (PRINC "^PCFOO... If I type a ^L when typing this form (before typing the matching doublequote and close paren), the Control-P C is taken as a display code. Since it echos as ^P when I type it in the first time, I think it should continue to echo that way when I redisplay ... -kmp -------  Date: 31 OCT 1980 0442-EST From: JONL at MIT-MC (Jon L White) Subject: Finally flushing old names To: RLB at MIT-MC CC: (BUG LISP) at MIT-MC Re: Date: 30 October 1980 19:14-EST From: Richard L. Bryan Subject: Correcting CATCH/THROW in Maclisp Isn't it about time we prepare to recycle the non-* names? I suggest that CATCH,THROW exist but be errors in the about-to-be-released Maclisp version, and that they be identical to *CATCH,*THROW in the next one. RMS has gone on record as opposed to *ever* flushing these names. Could you, Rich, take on responsibility for polling the community and ascertaining that there will be no major "revolutions" if this where to happen? Minimal test would be mailing ti *ITS.  GSB@MIT-ML 10/31/80 02:37:58 Re: sxhash To: (BUG LISPM) at MIT-ML, (BUG LISP) at MIT-ML, JERRYB at MIT-ML There is nothing in the "definition" of sxhash which says that it should be insensitive to order in a list. This has in fact been considered a bug in Maclisp. The constraint however is that the hash should remain constant in a given lisp implementation for "all time". Maybe it's not too late to change it on the Lispm, but it has been decided that it is for Maclisp. There is no reason to perpetuate this crock for compatibility, it is not supposed to be depended on. Probably most people only know about it because it has been complained about. (Of course, i can't give an Official Declaration of what sxhash is supposed to do, but i believe you can find something to this effect in old bug-lisp mail archives.)  Date: 31 October 1980 02:29-EST From: Alan Bawden To: JerryB at MIT-AI cc: BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC Date: 31 October 1980 02:16-EST From: Gerald R. Barber In system 46.8, with microcode 692, on LISP Machine Four: SXHASH seems to have the property that (SXHASH '(a b c)) = (SXHASH '(b c a)) or, it is insensitive to the ordering of things in a list. If I am not mistaken, the MacLisp sxhash has this property too (insensitivity to the order of a list). Are we perhaps keeping this around for compatibility? I have never thought that this was a very "nice" property for a hashing function to have. Is it too late to change it in MacLisp? (I'll bet the answer to that one is "yes".)  Date: 30 OCT 1980 1914-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: Correcting CATCH/THROW in Maclisp To: (BUG LISP) at MIT-MC Isn't it about time we prepare to recycle the non-* names? I suggest that CATCH,THROW exist but be errors in the about-to-be-released Maclisp version, and that they be identical to *CATCH,*THROW in the next one. I reproduce the 2-year-old warning below. Sunday Sept 17,1978 FM+11H.57M.58S. LISP 1742 -HIC, JONL- Changes affecting all LISPs: [3] *THROW, *CATCH, CATCHALL, CATCH-BARRIER, and UNWIND-PROTECT. For compatibility with the new format of CATCH and THROW in the LISP Machine, and in NIL, we are introducing *THROW and *CATCH. Please use these, and sometime in the future, CATCH and THROW in PDP10 MACLISP may be changed also. It is recommended that old code be converted to *CATCH and *THROW.  Date: 30 Oct 1980 1805-EST From: KMP at MIT-EE To: LS.GOLDFARB at MIT-EE cc: BUG-LISP at MIT-MC (1) The repositioning of the cursor at the top of the screen instead of scrolling is called wraparound. It's not really a bug, just a misfeature that it happens by default. They will change that in some version of Maclisp soon. It's not ULisp's fault. (2) The (CVTA 16) problem is a severe Maclisp failing which ULisp inherits. I am glad you pointed it out. (CVTA 16) returns the character Control-P. This is a very magic character to Twenex display and Maclisp should be taking care to display it as "^P" rather than sending the character to Twenex for display as a raw control-P. I'm sure the implementors will look into fixing that. (To the Maclisp maintainers: (PRINC "^PC" TYO) in XMACLISP on EE demonstrates this lossage -- TYO is open in OUT ASCII SINGLE TTY mode and should not be displaying that ^P ... I assume the problem is that on ITS, the opsys takes care of this ...) -------  Date: 30 OCT 1980 0909-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: LEXPR-FUNCALL To: batali at MIT-AI CC: ALAN at MIT-MC, RWK at MIT-MC, JONL at MIT-MC, (BUG LISP) at MIT-MC CC: JIS at MIT-MC Maclisp.2018 is totally losing. Your suggestion that LEXPR-FUNCALL doesn't work seems reasonable. I had troubles with what was probably LEXPR-FUNCALL in that lisp and lost badly in my ULisp interpreter. Maclisp.2009, and Maclisp.2031 on up do not exhibit these problems. So you should try the problem you have in another Lisp and re-report the bug if it persists.  Date: 30 OCT 1980 0743-EST From: JONL at MIT-MC (Jon L White) Subject: #* To: RWK at MIT-MC, (BUG LISP) at MIT-MC #*400000000000 is even more dramatic. sigh, who'll fix SHARPM?  Date: 30 OCT 1980 0739-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC #*777777000000 ==> 377777000000 ==> WRONG BIT PATTERN!  Date: 30 OCT 1980 0652-EST From: KMP at MIT-MC (Kent M. Pitman) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC #o means octal read. After all, (SETQ IBASE 8.) followed by 777777000000 is certainly going to read as a bignum. Imagine on a BCD machine complaining that "1000000000." read as a bignum when you really wanted to set a high bit in the 9th half-byte ... Would you have us screw all the non-BCD users just for you? Now aren't you ashamed of yourself? Seriously, though, i do agree w/ the motivation cited in Jonl's reply. -kmp  Date: 30 OCT 1980 0644-EST From: JONL at MIT-MC (Jon L White) Subject: #O To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 30 OCT 1980 0641-EST From: RWK at MIT-MC (Robert W. Kerns) #o777777000000 ==> BIGNUM!!!!!! Yes, this is quite right. From NIL;RP > (the reader-printer syntax) " 1.1.5) Unsigned machine word: #*C4BD96AC* #*777777* The "#*" prefix indicates this mode, and * serves as a kind of delimiter for the numeric string. " whereas #O is merely an abbreviation for #8R... which is radix 8.  Date: 30 OCT 1980 0641-EST From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC #o777777000000 ==> BIGNUM!!!!!!  Date: 29 October 1980 20:42-EST From: Robert W. Kerns Subject: Infamous TYIPEEK bug To: EB at MIT-ML cc: BUG-LISP at MIT-ML Has now been fixed and patched into 2033 and 1997 on AIMLMC.  Date: 29 October 1980 19:07-EST From: Robert W. Kerns Subject: MACROEXPANDED not working with SETF (??) To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, GJC at MIT-MC Another solution would be for SETF to be less persistant with it's MACROEXPANDEDness. Basically, introduce a MACROEXPANDED-SETF form. (MACROEXPANDED-SETF ) is taken from DEFMACRO-COUNTER, which is incremented whenever a DEFMACRO or DEFSETF is done. When MACROEXPANDED-SETF is EVAL'd, it compares with the global DEFMACRO-COUNTER, and if anything has been redefined, it re-expands. Redefinitions are rare enough to make this an acceptable cost.  Date: 29 October 1980 18:23-EST From: Glenn S. Burke Subject: Knee-jerk response To: Guy.Steele at CMU-10A, JONL at MIT-MC cc: BUG-lisp at MIT-MC is approximately the best thing proposed so far. It is extremely inconvenient that even when one understands why you are getting screwed it is difficult to do anything about it. |forget-macromemos/|| should be renamed more conveniently (or another entry should be made) and there should be something you can call to do the mapatoms if you are super-paranoid and/or lazy. (Note that you don't want to mapatoms just |forget-macromemos/||, and remproping the macroexpanded property is wrong; you want to increment it.) The other thing to do is to memoize the expansion on all the dependencies, so a particular SETF expansion would "know" that it depended on both SETF and FROBNICATE being redefined... But in general it probably is not possible to back up as far as is necessary, given the case of macros evaluated for a value which makes up some part of a memoized macro expansion.  Date: 29 October 1980 1457-EST (Wednesday) From: Guy.Steele at CMU-10A To: JONL at MIT-MC (Jon L White) Subject: Re: Poor SETF, revisited ["yea, me worry"] CC: bug-lisp at MIT-MC In-Reply-To: JONL@MIT-MC's message of 29 Oct 80 14:01-EST Message-Id: <29Oct80 145720 GS70@CMU-10A> Maybe there should be a simple facility, analogous to (SSTATUS UUOLINKS), as you noted, for "flushing the cache". Call it something like MACROFLUSH, or MACRODANGER, or MACROCHAOS, or something. Then people who do weird things can call that function and "the right thing" will happen? This is a knee-jerk response -- maybe a better-thought-out system can be invented.  Date: 29 OCT 1980 1438-EST From: JONL at MIT-MC (Jon L White) To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Date: 29 October 1980 14:20-EST From: George J. Carrette Subject: Poor SETF, revisited ["yea, me worry"] . . . Hey, I said you might as well just DISPLACE. Which costs even less than memoizing, and takes a lot less crufty code in your defmacro's. WRONG! if you memoize in any form, then you can recuperate (by "cache" invalidation) but if you DISPLACE, you lose. period. I'm not laying them at the feet of SETF, I am laying them at the feet of JONL! The provided system facilities are not sufficient to handle SETF. George, did you even read my comment about the mechanization possible for defmacro (when it redefines an existing macro)? Did you even acknowledge that some cases are not at all easily detectable? Can you honestly say that a mapatoms of |forget-macromemos/|| is "not sufficient to handle SETF"?  Date: 29 OCT 1980 1427-EST From: JONL at MIT-MC (Jon L White) To: eak at BBNA CC: (BUG LISP) at MIT-MC, mmcm at MIT-AI, (BUG twenex) at MIT-XX Date: Tuesday, 28 October 1980 12:37-EST From: EKILLIAN at BBNA Subject: new LISP rubout processing . . . LISP is looking at TC%CLR and using that to set %TOERS in one of its internal capability words. It does not appear to be looking at TC%SCL for that. . . . Are you suggesting that this is buggy. I think maybe it is, only in that LISP might try to rubout on a terminal where it can't (the TC%SCL bit implies the TC%CLR bit so it would never miss an opportunity)  Date: 29 October 1980 14:20-EST From: George J. Carrette Subject: Poor SETF, revisited ["yea, me worry"] To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 29 OCT 1980 1401-EST From: JONL at MIT-MC (Jon L White) To: GJC cc: (BUG LISP) Re: Poor SETF, revisited ["yea, me worry"] Uh, George, the problem just can't be laid at the feet of SETF, no matter what system facilities it uses. I'm not laying them at the feet of SETF, I am laying them at the feet of JONL! The provided system facilities are not sufficient to handle SETF. That the problem is still more general should have been evident from the FIND-PROJECTION example, but to help visualize it again, just imagine redefining the function LAST. Redefine LAST? Are you feeling O.K. today? Your proposal re SETF -- that of never memoizing -- would be a narrow (and very costly!) solution. Hey, I said you might as well just DISPLACE. Which costs even less than memoizing, and takes a lot less crufty code in your defmacro's. But you didn't comment on my two suggestions, which would work for a rather wide variety of environment changes; did you understand them? I did comment, I said "why should you have to do stuff like that by HAND?" The comparison with UUOLINKS was a real win too. I never did understand why DEFUN didn't take care of UUOLINKS for you either!!! Why reset the UUOLINKS for the world when you only want to do it for a single function? gjc p.s. I think it goes without saying that the "GENERAL PROBLEM" deals with what files/functions need to be recompiled when macros are changed etc. Already dealt with quite well on the lisp machine. My main comment is that this MACROMEMO stuff is an ill-working special case of that.  Date: 29 OCT 1980 1401-EST From: JONL at MIT-MC (Jon L White) Subject: Poor SETF, revisited ["yea, me worry"] To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Uh, George, the problem just can't be laid at the feet of SETF, no matter what system facilities it uses. Date: 29 October 1980 13:25-EST From: George J. Carrette Subject: MACROEXPANDED not working with SETF (??) . . . In fact, it is exactly the correct characterization of THE PROBLEM. . . . SETF is not a user defined macro, therefore, why should it be his responsiblity to make up for its deficiencies with respect to the attempt at memoization? That the problem is still more general should have been evident from the FIND-PROJECTION example, but to help visualize it again, just imagine redefining the function LAST. How does one know which of his many macros might have used such a thing? Your proposal re SETF -- that of never memoizing -- would be a narrow (and very costly!) solution. But you didn't comment on my two suggestions, which would work for a rather wide variety of environment changes; did you understand them? Basically they would have the user specify a general "cache" invalidation whenever something "dangerous" is done (1) set MACRO-EXPANSION-USE to MACROMEMO, and invalidate via RPLACD (2) (MAPTAOMS ) Some of the "dangerous" operations can even be mechanically detected, such as the case of a defmacro which redefines an existing macro.  Date: 29 October 1980 13:25-EST From: George J. Carrette Subject: MACROEXPANDED not working with SETF (??) To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 29 OCT 1980 1004-EST From: JONL at MIT-MC (Jon L White) To: GJC cc: (BUG LISP) Re: MACROEXPANDED not working with SETF (??) The subject line of this note is not the right characterization of the problem -- what's going wrong here is that any macro-expansion which has been "memoized" one way or other may need to be invalidated by operations other than that of merely redefining the macro. ..... (DEFMACRO PROJECT-IT (X) `(FIND-PROJECTION ,x MAIN-AXIS)) ; ? I think you mean `(FIND-PROJECTION ,X ,MAIN-AXIS) ? In fact, it is exactly the correct characterization of THE PROBLEM. If the user defines a macro such as PROJECT-IT, then he is well aware of the fact that the expansion depends on the value of a global variable which may change. SETF is not a user defined macro, therefore, why should it be his responsiblity to make up for its deficiencies with respect to the attempt at memoization? But as Alfred E. Neuman used to say, "Not to worry . . ." Sure, whatever you say. -gjc  EB@MIT-ML 10/29/80 12:58:46 To: (BUG LISP) at MIT-ML From .INFO.;LISP SFA: C) TYIPEEK The SFA should return a fixnum (as in TYI) but should not remove the character from the input flow. Therefore, subsequent TYIPEEK's will read the same character. If the SFA cannot handle TYIPEEK, it will be simulated by a TYI/UNTYI pair of operations. In LISP 2033: (setq sfa (sfa-create '(lambda (sfa op val) (caseq op (which-operations '(tyi untyi)) (tyi 0) (untyi 0) (t (error)))) 0 'sfa)) #SFA-... (tyi sfa) 0 ; so far so good (tyipeek nil sfa) ; (NIL TYI NIL) ATTEMPT TO INVOKE SFA ON UNSUPPORTED OPERATION ; -- or some such error  Date: 29 OCT 1980 1004-EST From: JONL at MIT-MC (Jon L White) Subject: MACROEXPANDED not working with SETF (??) To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC The subject line of this note is not the right characterization of the problem -- what's going wrong here is that any macro-expansion which has been "memoized" one way or other may need to be invalidated by operations other than that of merely redefining the macro. Thus I think, George, your sense of despair needn't be taken so badly: Date: 28 October 1980 18:25-EDT From: George J. Carrette . . . ; Might as well not bother with the MACROMEMO scheme and just have ; all macros displace if it isn't going to work in the one of ; the most common cases, SETF. If you had, in fact, been using the MACROMEMO scheme instead of the MACROEXPANDED scheme, then there would have been a trivial way to win. But more importantly, one has to be able to recognize when a condition has occurred which *may concievably* invalidate some macor expansion. For example, consider (DEFMACRO PROJECT-IT (X) `(FIND-PROJECTION ,x MAIN-AXIS)) What happens if the value of the global-variable MAIN-AXIS is changed? Well, one could just say (|forget-macromemos/|| 'PROJECT-IT), but in general he may not know what all macros will be affected. If MACRO-EXPANSION-USE is set to MACROMEMO, then on can easily and simply invalidate all "memoized" expansions of all macros by merely doing (RPLACD MACROMEMO () ). The problem is more complex when one is using the MACROEXPANDED scheme and doesn't wish to change over to the MACROMEMO scheme; but still he could do (MAPATOMS '(LAMBDA (X) (REMPROP X 'MACROEXPANDED))) Both of these tactics are somewhat akin to doing (SSTATUS UUOLI), and I'm sure that if someone wanted to spend a few weeks researching how to be more selecitve in the unsnapping, it could be done. But as Alfred E. Neuman used to say, "Not to worry . . ."  Date: 29 OCT 1980 0412-EST From: JONL at MIT-MC (Jon L White) To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC Tnx for your perceptive perusing of LISP.RECENT -- I've fixed up the comment about ASH Date: 28 October 1980 20:03-EST From: David A. Moon lisp recent claims ASH takes one argument. It takes two, of course. Date: 28 October 1980 20:10-EST The example of open coding of DPB in LISP;LISP RECENT is incorrect. I use hope the compiler does not actually do what the documentation says. and for DPB, the documentation example should have been "(DPB 0 #o0304 X) ==> (BOOLE 4 X #o170)" rather than "(DPB -1 #o0304 X) ...". However (cough, cough) , there is in fact a bug with the open-expansion of "(DPB -1 ...)" for constant , and I'll get it fixed within the hour.  Date: 28 October 1980 20:21-EST From: Mike McMahon Sender: MMcM at CADR6 at MIT-AI Subject: new LISP rubout processing To: EKILLIAN at BBNA, JONL at MIT-MC cc: BUG-TWENEX at MIT-XX, MT at MIT-XX, BUG-LISP at MIT-MC I have modified the SUPDUP server so that %TOERS implies both TC%SCL and TC%CLR. This seems to make rubout processing work right from SUPDUP in the new LISP.  Date: 28 OCT 1980 2003-EST From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC lisp recent claims ASH takes one argument. It takes two, of course.  Date: 28 October 1980 20:10-EST From: David A. Moon To: BUG-LISP at MIT-AI The example of open coding of DPB in LISP;LISP RECENT is incorrect. I use hope the compiler does not actually do what the documentation says.  Date: 28 OCT 1980 2003-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC lisp recent claims ASH takes one argument. It takes two, of course.  Date: 28 OCT 1980 1825-EDT From: GJC at MIT-MC (George J. Carrette) Subject: MACROEXPANDED not working with SETF To: (BUG LISP) at MIT-MC ; I suppose you know about this already, but here it is ; anway. (setq x '(nil nil)) (NIL NIL) (defmacro foo (m) `(car ,m)) FOO (defun c-b (l v) (setf (foo l) v)) C-B (c-b x 9) 11 x (11 NIL) (defmacro foo (m) `(cadr ,m)) FOO (c-b x 99) 121 x (121 NIL) ; It is evident from the SETF MACROEXPANDED form that it doesn't ; remember the "versions" of all the macros it had to forcebly ; expand in order to do its own expansion. ; Might as well not bother with the MACROMEMO scheme and just have ; all macros displace if it isn't going to work in the one of ; the most common cases, SETF. ; By the way, I think its a win that SETF is a macro anyway. -gjc  Date: 28 October 1980 1338-EST (Tuesday) From: Guy.Steele at CMU-10A To: JONL at MIT-MC (Jon L White) Subject: Re: Shifted-0, Modular arithmetic CC: bug-lisp at MIT-MC, Dave.Touretzky at CMU-10A, David.Goldberg at CMU-10A In-Reply-To: JONL@MIT-MC's message of 28 Oct 80 06:25-EST Message-Id: <28Oct80 133814 GS70@CMU-10A> Of course, part of the complaint is that the PDP-10 instruction set doesn't even implement the ring you described, but only an approximation to it. If it were a true ring then indeed (* x 2) would be the same as (+ x x). However, the PDP-10 IMUL instruction does not store the 36 low-order bits, but the 35 low-order bits plus the correct sign. That's why (* 2 2_34.) => 0 instead of -2_35.  Date: Tuesday, 28 October 1980 12:37-EST From: EKILLIAN at BBNA To: JONL at MIT-MC (Jon L White) Cc: BUG-LISP at MIT-MC, BUG-TWENEX at MIT-XX, MT at MIT-XX, MMCM at MIT-AI Subject: new LISP rubout processing Date: Tuesday, 28 October 1980 07:08-EST From: JONL at MIT-MC (Jon L White) Date: Monday, 27 October 1980 17:08-EST From: EKILLIAN at BBNA Doesn't seem to work when using SUPDUP to get to XX as opposed to TELNET. Perhaps 20X is not setting the bit saying you can move the cursor backward on a SUPDUP terminal (because there is no %TD code for doing it -- you only have %TDMV0 and %TDFS)? LISP only copies what VTS can do, and it seems likely that your analysis is right (i.e., no TC%MOV capability) which would mean no CURSORPOS capability of any note. Also, no TC%SCL (or TC%CLR) would mean that the terminal can't selectively erase, so LISP wouldn't try the rubout processing. As for the echoing of ^L as a sail char, I'm not sure I understand what is happing wrong. Rather than speculate further, I decided to find out what was going on. LISP is looking at TC%CLR and using that to set %TOERS in one of its internal capability words. It does not appear to be looking at TC%SCL for that. Also, 20X is not setting TC%CLR on a SUPDUP TTY. Why? SUPDUP TTYs certainly use %TDCLR. Anyway, it seems like both LISP and 20X are in error.