Date: 28 OCT 1980 0932-EDT From: JONL at MIT-MC (Jon L White) Subject: &WHOLE To: (BUG LISP) at MIT-MC Apparently the &REST interferes with the &WHOLE in (DEFMACRO FOO (&WHOLE FORM &REST W) ...) but other cases work.  Date: 28 OCT 1980 0808-EDT From: JONL at MIT-MC (Jon L White) To: Ekillian at BBND CC: (BUG LISP) at MIT-MC, mmcm at MIT-AI, (BUG twenex) at MIT-XX CC: mt at MIT-XX Date: Monday, 27 October 1980 17:08-EST From: EKILLIAN at BBNA Subject: new LISP rubout processing 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.  Date: 28 OCT 1980 0725-EDT From: JONL at MIT-MC (Jon L White) Subject: Shifted-0, Modular arithmetic To: TOURETZKY at CMU-10A CC: (BUG LISP) at MIT-MC, GOLDBERG at CMU-10A Date: 28 October 1980 0556-EST From: Dave Touretzky at CMU-10A Subject: is it SUPPOSED to do this? (setq a (^ 2 34.)) => 17179869184. (+ a a) => -34359738368. ;arithmetic overflow (* 2 a) => 0 ;huh??? doesn't 2*a = a+a? (times 2 a) => 34359738368. ;correct answer, as a bignum The intended compiled-code target for the "+" function is the PDP-10 ADD instruction, and for "*" it is the MUL instruction; this isn't nearly as bad as it seems, since there are interesting theoretical properties of 36.-bit, 2's-complement, mid-point zero arithmetic. The pratical application of this weirdo "ring" is that except near the "endpoints", it is almost like integer arithmetic; when the endpoints are disturbing, then you must use PLUS and TIMES in order to insure faithfulness to the standard mathematical arithmetic. You'll only take two orders of magnitude longer time, but sometimes the price is worth it.  Date: 28 October 1980 0556-EST From: Dave Touretzky at CMU-10A To: bug-lisp at MIT-MC Subject: is it SUPPOSED to do this? CC: David Goldberg at CMU-10A Reply-To: Dave Touretzky at CMU-10A In MacLisp with *RSET set to T, BASE and IBASE set to 10.: (setq a (^ 2 34)) => 17179869184 (+ a a) => -34359738368 ;arithmetic overflow (* 2 a) => 0 ;huh??? doesn't 2*a = a+a? (times 2 a) => 34359738368 ;correct answer, as a bignum I'm kind of surprised at the disparity in answers. Doesn't *RSET checking involve tests for bogus arithmetic operations? Is there any other way to get such testing?  Date: Monday, 27 October 1980 17:08-EST From: EKILLIAN at BBNA To: BUG-LISP at MIT-MC, BUG-TWENEX at MIT-XX Subject: new LISP rubout processing 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)? If so, which of LISP or 20X should be changed? Oh, also, when I type ^L to LISP on a SUPDUP terminal, I get the ^L echoed (as the sail character) before it clears the screen. Either the character should be uparrowed (I haven't asked for sail character output), or it shouldn't be output at all.  Date: Monday, 27 October 1980 16:50-EST From: EKILLIAN at BBNA To: BUG-LISP at MIT-MC Subject: assembling LISP should use more modern MIDAS features Why does assembling LISP on 20X produce a .REL file instead of a .EXE file? You should probably use the .DECSAV pseudo. Also, it uses .FNAM2 to find its version number; it should use .FVERS instead.  Date: 26 October 1980 19:44-EST From: George J. Carrette Sender: TFT at MIT-AI To: MOON at MIT-AI cc: BUG-LISP at MIT-AI That last note was from GJC.  Date: 26 OCT 1980 0646-EDT From: JONL at MIT-MC (Jon L White) Subject: (STATUS FEATURES) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, CWH at MIT-MC Date: 26 October 1980 03:48-EDT From: Kent M. Pitman Could we please have a PDP10 on the default features list for ITS? Done. (In the sources -- will be in the XLISP to be announced this week) Could you please remove one of the two ITS's from the FEATURES list? It's not really important to have them both there... Two ITS's appear because of an archaic compatibility question -- the last thing in the features list is guaranteed to be the same as (STATUS FILESYSTEM-TYPE) and the next-to-last is (STATUS SITE) or (STATUS OPSYSTEM-TYPE). As long as no one objects, I thing we can remove the second "guarantee", and that will remove the double "ITS" feature. Any objectors?  Date: 26 OCT 1980 0540-EDT From: JONL at MIT-MC (Jon L White) Subject: Dumped out NIL's To: RWK at MIT-MC CC: SOLEY at MIT-MC, (BUG LISP) at MIT-MC Date: 26 October 1980 01:21-EDT From: Robert W. Kerns Subject: STRING bug Well, JONL has just made n^n small changes to the source, so it's kinda hard for me to figure out if he's changed anything relevant. In case you've forgotten, NIL is a dumped-out system, with the version of STRING current at the time of dumping. Should a person of moderate intelligence be handicapped by any changes to the source since that dumpout time? Original sources sill available. Maybe NILE should be tried out in an environment with all those "n^n small changes" (whatever that means), in case any of them serendipitously fixed the problem.  Date: 26 October 1980 03:48-EDT From: Kent M. Pitman Subject: (STATUS FEATURES) To: BUG-LISP at MIT-MC cc: CWH at MIT-MC Could we please have a PDP10 on the default features list for ITS? Macsyma does #+PDP10 in several places. This would be a generally useful feature for others, too, I suspect. Could you please remove one of the two ITS's from the FEATURES list? It's not really important to have them both there... -kmp  Date: 26 OCT 1980 0121-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: STRING bug To: SOLEY at MIT-MC CC: (BUG LISP) at MIT-MC Well, JONL has just made n^n small changes to the source, so it's kinda hard for me to figure out if he's changed anything relevant. It is possible that you're causing it by clobbering a string. This is one problem the MACLISP STRING implementation has. The internal symptoms are that STR/:NO.STRINGS is getting to be larger than STR/:GCMARRAY. I'm not sure why. Just SETQing it down to 1- the size of STR/:GCMARRAY doesn't make the problem go away, it gets upped the next time a GC is run. I suspect a fencepost, but I'm not sure where.  Date: 25 October 1980 22:48-EDT From: Kent M. Pitman Subject: While you're hacking SUSPEND-time I/O... To: "(FILE [JONL;JONL MAIL])" at MIT-MC cc: BUG-LISP at MIT-MC This was reported once before but continues to cause problems. If there is a tty channel other than TYI/TYO open at SUSPEND time, SUSPEND fails on an open-channels error. Could you please make it close these channels and re- open them in the same mode automatically? It's a real screw for this not to happen because I don't always have control over the actual suspension process (someone else's code may be doing the dumping and may not realize I've opened an extra tty channel ... and I don't necessarily have a hook which allows me to get this channel re-opened after dump time ...) If the problem is not clear, I can elaborate, but I don't see any reason not to do it. Eg, try suspending a Macsyma sometime and you'll see the problem ... -kmp  Date: 25 OCT 1980 2019-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: (RENAMEF ...) To: (BUG LISP) at MIT-MC CC: HIC at MIT-MC Now works. Patched into the current LISP and XLISP. (this was a simple oversight; the code was just missing, although RENAMEF was in the table of system messages).  Date: 24 OCT 1980 1620-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: CPR at MIT-EECS, ERIC at MIT-EECS, JIS at MIT-AI We really need a primitive in Maclisp for doing the Twenex 'abort'-flavor close on files from Maclisp. Eg, if I am writing to a directory that I don't have access to and do a (DELETE fileobj) I lose badly but if I close the fileobj first, I can't DELETE it due to file protection problems. Maybe (DELETE openfileobj) on Twenex could arrange to do this flavor of close on the file object? Would that do the right thing? Alternatively, an optional arg to CLOSE (default T) which if () said to do this kind of close would be fine also ... Also, GC if reclaiming dead file objects should use this kind of close if available. -kmp  Date: 24 October 1980 10:53-EDT From: Robert W. Kerns Subject: LEXPR-FUNCALL BITES MAN To: NLM at MIT-MC, "(FILE [JONL;JONL MAIL])" at MIT-MC, batali at MIT-AI cc: ALAN at MIT-AI, BUG-LISP at MIT-AI Date: 23 October 1980 19:31-EDT From: nlm,batali at MIT-AI Sender: GJS at MIT-AI Subject: LEXPR-FUNCALL BITES MAN To: ALAN at MIT-AI, JONL at MIT-MC cc: BUG-LISP at MIT-AI We moved a compiled version of "mc:alan;nstruct fasl" over to Speech (carefully patching the word length on word count (losing ftp!)). ... CHAOSnet FTP has more problems than just the word length problem. It also has a bad tendency to swap bytes. Since it doesn't happen on ITS, I'd suggest you transfer the SOURCE file and recompile it there. LEXPR-FUNCALL is not conditionalized on operating system! Another possibility is that the LISP there is ancient. If so, the solution is a magtape. I don't have an account on SPEECH, nor do I know the password to the MacLisp directory, so I can't investigate any of this firsthand.  Date: 24 October 1980 00:37-EDT From: Alan Bawden Subject: LEXPR-FUNCALL BITES MAN To: NLM at MIT-MC, BATALI at MIT-MC, "(FILE [JONL;JONL MAIL])" at MIT-MC cc: BUG-LISP at MIT-AI Sounds like a lisp bug, not a defstruct bug. I will be happy to poke around in a lisp that is having this problem, except I can't use SPEECH myself.  Date: 23 October 1980 19:31-EDT From: nlm,batali at MIT-AI Sender: GJS at MIT-AI Subject: LEXPR-FUNCALL BITES MAN To: ALAN at MIT-AI, JONL at MIT-MC cc: BUG-LISP at MIT-AI We moved a compiled version of "mc:alan;nstruct fasl" over to Speech (carefully patching the word length on word count (losing ftp!)). Wfhen attempting to place a value in a structure we had created we got the error that |HUNK DEFSTRUCT-REF| got too many arguments. After carefully studying the situation we found that this error occured when *rset was t but not when it was nil (really!). The error seems to have something to do with the way lexpr-funcall does its thing. The error may be reproduced on speech by loading "nstruct" into a fresh lisp and doing: (defstruct eep () gleep) (setq feep (make-eep)) (gleep eep)  GSB@MIT-ML 10/23/80 19:10:45 To: (BUG LISP) at MIT-ML LWNACK is defined without symbols, but FWNACK isn't...  Date: 23 OCT 1980 0551-EDT From: JONL at MIT-MC (Jon L White) Subject: .FASL hackers, ATTENTION! To: (BUG LISP) at MIT-MC In order to add the VTS stuff of MT into twenex MacLISP, I had to extend the format of a part of TTY file arrays. If you think you have ever used symbols like ATO.LC, AT.CHS, AT.LNN, AT.PGN, FO.LNL, or FO.PGL, then pls let me know asap.  Date: 23 OCT 1980 0534-EDT From: JONL at MIT-MC (Jon L White) Subject: SUBST into hunks To: (BUG LISP) at MIT-MC (SUBST () () '(1 . 1 .)) ==> ;0 CAN'T CREATE A HUNK OF THIS SIZE  Date: 22 OCT 1980 1752-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC NOTE: That's :FASLIST {esc}{dot} if you want to see the options. The dot -- you guessed it -- gets parens put around it and readlist is called and so that's why it's illegal ... fun, huh? Yes, :FASLIST #.(PRINT 'HI) will do fun things, too ... sigh.  Date: 22 OCT 1980 1742-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: FASLIS trivia To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC By the way, you can also do interesting filters on the FASLIS information, by providing switches. The format for the command line is: filename {esc}{switch1} {switch2} ... An illegal syntax in the switch area will show you the valid switches. eg, :FALIS {esc}. is a good way to get it. RLB can probably explain each does. -kmp  Date: 21 OCT 1980 1222-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC, LISP-FORUM at MIT-MC, NIL at MIT-MC You know what I could use many times? LABELS, ala SCHEME, however, what would suit me most of those times would be a simple extension to PROG, a GOSUB ala BASIC. (prog (common-variable-environment) (COND possibly complicated with (GOSUB FROB-1) and (GOSUB FROB-2)) FROB-1 ...stuff... (RETURN NIL) FROB-2 ...stuff... (RETURN NIL)) The value of the GOSUB will would be the value of the RETURN next executed. Question: How easy is it to add a GOSUB feature to existing lisp compilers? Note: I have various pattern matchers and finite state machines which would love to be able to macroexpand into this type of thing. There is no other way to get this functionality in present lisps without the use of special variables or variables in structures, both of which forego the efficiency of register or number-pdl allocation. (Computed GO's are out of the question of course). Question: Is this a reasonable feature to have? -gjc  Date: 21 October 1980 1113-EDT (Tuesday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC, bug-lispm at MIT-AI, nil at MIT-MC Subject: Re: comaptibility in STRING usage In-Reply-To: JONL@MIT-MC's message of 20 Oct 80 17:11-EST Message-Id: <21Oct80 111353 GS70@CMU-10A> It seems to me that the rule generally stated by naive users, while not always correct, is a good guide to intuition when extending EQUAL: "two things are EQUAL if they print the same". Inasmuch as "Foo" and "fOO" do *not* print the same, I would therefore argue that they not be EQUAL.  Date: 21 October 1980 11:19-EDT From: Richard L. Bryan Subject: Is this the right place to send bug reports about :FASLIS ?? To: ALAN at MIT-MC, BUG-LISP at MIT-MC Date: 20 OCT 1980 0313-EDT From: ALAN at MIT-MC (Alan Bawden) 1) I notice that FASLIS doesn't know about STRT7, someone should teach it. 2) It seems that if FASLIS doesn't know an opcode it just prints NIL. This is a loss since you cannot tell what is really there. It should print the opcode as a number in that case. Close enough. It reached me and KMP, who've fixed this.  GSB@MIT-ML 10/20/80 23:35:44 Re: i almost forgot about this To: (BUG LISP) at MIT-ML ML:CRASH;LISP SPWIN is a pdumped lisp which got a purpg at SPWIN. A ^B had just been typed at it. Someone should perhaps look at it as it may be a rare chance to find what could be a timing screw in the interrupt code.  Date: 20 OCT 1980 1811-EDT From: JONL at MIT-MC (Jon L White) Subject: comaptibility in STRING usage To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, NIL at MIT-MC Date: 20 October 1980 04:54-EDT From: Alan Bawden If the MacLisp string package is trying to be LispMachine-like, then (equal "Foo" "fOO") should return T. In fact, the NIL-I group had rather decided that EQUAL should not call STRING-EQUAL, which is the LISPM-compatible function, but rather do a more strict equivalence; this is reflected in the code for the method EQUAL->STRING-CLASS, and could be easily changed, but I suppose we'd lobby for LISPM making the change instead (i.e., making a distinction between the two kinds of string-equality, and letting EQUAL call thhe more strict one rather than STRING-EQUAL as currently defined.)  Date: 20 OCT 1980 0454-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: MacLisp strings To: (BUG LISP) at MIT-MC If the MacLisp string package is trying to be LispMachine-like, then (equal "Foo" "fOO") should return T.  Date: 20 OCT 1980 0313-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: Is this the right place to send bug reports about :FASLIS ?? To: (BUG LISP) at MIT-MC 1) I notice that FASLIS doesn't know about STRT7, someone should teach it. 2) It seems that if FASLIS doesn't know an opcode it just prints NIL. This is a loss since you cannot tell what is really there. It should print the opcode as a number in that case.  Date: 20 October 1980 00:49-EDT From: Robert W. Kerns Subject: Initial /" macro setting in XLisp in question To: KMP at MIT-MC cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, GSB at MIT-ML, PSZ at MIT-ML Having read KMP's arguments, I agree that we should not make real strings the default.  Date: 19 October 1980 15:36-EDT From: Kent M. Pitman Subject: For the record To: BUG-LISP at MIT-MC Date: 10/19/80 12:53:05 From: PSZ at MIT-ML To: KMP Re: Initial /" macro setting in XLisp in question Thank you for your comments. Of course, I agree. --Pete  Date: 19 OCT 1980 0722-EDT From: JONL at MIT-MC (Jon L White) Subject: SUSPEND hanging on spurious I/O channel To: GJS at MIT-MC CC: (BUG LISP) at MIT-MC Remember that Random lossage we saw once about 5 months ago? Well it struck me last nite, and I had to dig in and finally track it down before bringing up a new XLISP. Problem seems that at one place in the code for OPEN, a file-array has been created, and channel number allocated, but when something goes wrong after that, not all paths exit from there remember to de-allocate the channel. In particular, the code just after OPEN3: doesn't! Subject to all sorts of timing screws then, that SAR cell might be re-used just as the channel table still had the worthless assignment in it. I've patched this in the current lisp, and edited the sources; also checked out a few other paths for similar lossage.  Date: 18 OCT 1980 1754-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC There are now three lists on MC. BUG-LISP (add yourself here to just be on BUG-LISP) BUG-COMPLR (add yourself here to just be on BUG-COMPLR) LISP-AND-COMPLR-PEOPLE (add yourself here to be on both) I don't think the two lists should get merged, but those of you interested in complr bugs should realize there is a list you can put yourself on. If you were on bug-lisp and bug-complr already, you have been moved to LISP-AND-COMPLR-PEOPLE. -kmp  Date: 18 October 1980 17:23-EDT From: Kent M. Pitman Subject: Initial /" macro setting in XLisp in question To: "(FILE [JONL;JONL MAIL])" at MIT-MC cc: BUG-LISP at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC, GSB at MIT-ML, PSZ at MIT-ML Although it may be useful for certain applications to have strings in Maclisp, I don't think they should be the default. XLisp seems to have a different default for /" than previous lisps have had. The following reasons come to mind: [1] Practical constraints. The STRING package is large. Many simple stringlike applications don't require that much hair. (ERROR "...") or (PRINC "...") are some of the more common cases. Picking apart strings is not the only reason for having them. [2] Philosophical constraints. Things which are the default should be assumed to be available by default in a Lisp. Take an analagous situation: It didn't used to be that LET existed. When it was introduced, people assumed they could use it whereever they wanted. This was fine because it was generally agreed what functionality it needed. Now if anyone has a package, FOO, which uses LET and someone tries to use the FOO package who has redefined LET, then we say it is not the FOO-package maintainer's fault that his code doesn't run in this person's environ because a system function has been redefined. If then, making real strings the default means that people will start to write code for Maclisp which depends on having strings, then I don't want it to be the default. It's fine for NIL and it's fine for LispM and even fine for Multics lisp because these have the address space to spare, but it's not fine for Maclisp because it doesn't. If I am running short of space in my Maclisp and I still need the support of some random package and it's going to in turn want STRINGs loaded. [3] Serving a user community. I think the default should serve the user community in the most useful way. It's easy to make real strings be your default if you want -- it's harder to undo the default (because shared packages will depend on the most powerful feature defaultly available). I have just gone through and deleted the (SSTATUS MACRO /" '+INTERNAL-/"-MACRO) all over my packages because I thought that was going to be the default. I don't now want to have to go through and re-enable them. I think the argument is actually most akin to the Lisp Machine people's argument about destructuring LET. People recognize the usefulness of destructuring let, but they don't want it the default because their applications don't happen to call for it. This means I have to load it when I need it, but I don't really mind that. I'd rather have to do that than have people have to be turning it off if they didn't want it. I know ALAN, GSB, and PSZ at least support me in not wanting real strings to be the default for Maclisp. We need to consider this carefully before attempting to release XLisp. -kmp  Date: 18 OCT 1980 1059-EDT From: JONL at MIT-MC (Jon L White) Subject: (DEFUN ( FOO BAR) ...) To: ALAN at MIT-MC CC: (BUG COMPLR) at MIT-MC, (BUG LISP) at MIT-MC Date: 18 October 1980 06:39-EDT From: Alan Bawden I complained a long time ago that something of the form (defun (let foo bar) ...) caused the following nasty error message: (COMMENT **** (LET FROM USER FILE #FILE-IN-|DSK:LIL;KERNEL 262|-70722) Redefining system function in function LET) Now I am being screwed because the presence of this message in the unfasl file makes it impossible to READ back in again. (I guess I am lucky that there wasn't a #F macro defined.) Well the random appearance of a useless error comment doesn't seem nearly as bad as the inablility to read in the unfasl file -- so I've fixed both; this fix only appears in XCOMPLR now, but within shortly a new XLISP (and XCOMPLR) will be announced, and after a few weeks they will replace the current LISP (and COMPLR). (By the bye, is there some special reason that this plaint should go to BUG-LISP too? or should BUG-COMPLR forward all comments to BUG-LISP?)  Date: 18 October 1980 06:39-EDT From: Alan Bawden Subject: Double Screw To: BUG-COMPLR at MIT-MC cc: BUG-LISP at MIT-MC I complained a long time ago that something of the form (defun (let foo bar) ...) caused the following nasty error message: (COMMENT **** (LET FROM USER FILE #FILE-IN-|DSK:LIL;KERNEL 262|-70722) Redefining system function in function LET) Now I am being screwed because the presence of this message in the unfasl file makes it impossible to READ back in again. (I guess I am lucky that there wasn't a #F macro defined.) Could someone fix the original bug or perhaps just fix the place where file objects are PRINTed into unfasl files?  Date: 18 OCT 1980 0007-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Just for fun To: (BUG LISP) at MIT-MC Guess what (A . B .........) reads as. Kinda cute. -kmp  Date: 17 OCT 1980 1327-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Maclisp reader seems consistently inconsistent... To: (BUG LISP) at MIT-MC Why is "READ END OF FILE WITHIN READ" (not enough ")"'s) a FAIL-ACT while "GOT TO TTY INSIDE S-EXP" (no cr after last ";") and "DOT CONTEXT ERROR" have no associated error handlers. Suppose I was writing a rubout handler that wanted to trap errors generated by the Maclisp default read -- how could I reasonably be expected to do so? Couldn't all of these types of errors use the same error handler and couldn't there be some way to tell that it was the reader which is signalling the error... Right now I have to know what all possible READ error messages are if I am to be able to sort out random errors that occur during the READ (^X Quits, Alarmclock functions dying, etc) ...  Date: 17 OCT 1980 0847-EDT From: JONL at MIT-MC (Jon L White) Subject: KL-10 (especially TOPS-10) incompatibilities for MacLISP To: MMiller at BBNA, KEN at MIT-AI, BEN at MIT-ML To: Cjohnson at SUMEX-AIM CC: (BUG LISP) at MIT-MC, Broberts at BBNG, TBlocker at BBNA CC: GJS at MIT-AI, PHW at MIT-AI I think I've finally fixed that old "snag", the lack of compatible double-precision floating-point instructions on most KL-10's. I've CC'd this note to several people, since Mark Miller made a rather long comment about this problem last month: Date: 23 September 1980 23:27-EDT From: Mark L. Miller Subject: MacLISP's Floating point cc: KEN at MIT-AI, GJS at MIT-AI, PHW at MIT-AI, TBlocker at BBNA, MMiller at BBNA, ben at MIT-ML, BUG-LISP at MIT-MC, BRoberts at BBNC . . . So in reply to Bob Meacham's note: Date: 16 Oct 1980 0542-PDT From: Cjohnson at SUMEX-AIM Subject: MAClisp installation at ORNL . . . I almost immediately got the message "?KA10 floating point instruction at user PC 441351" DDT examination revealed the command "FADL 7,10". Our 3 CPUs are KL-10s, and we are currently running version 7.01 of the TOP-10 monitor. Under this version, the monitor command "set float on" will translate the FADL instruction to something acceptable, but under the 7.02 monitor whose pre-release version we will receive in January even this temporary fix will disappear. So that's snag #1, I guess - I need to get the FADL (which I guess MIDAS puts in there?) replaced by something legal. . . . Finally! This is just the information I needed to find out what was wrong -- its only the lack of a true FADL, FDVL, etc on most KL-10s which cause thhe problem. So I've just assembled a new lisp here at MIT-MC which has a run-time test for being on a KL-10, and uses appropriate versions of double-precision instructions. Likely, by tomorrow this time, I'll have the TOPS-10 and TOPS-20 versions updated, and hoopefully some redistribution can begin. As for your other complaint: Now snag #2 is more mysterious to me. When I did "set float on" and then . . . ?Illegal UUO at user PC 436207 DDT revealed 436206 was HRRZ 12,0(12) and 436207 was just 0,,436211 . . . Cordially, Robert Meacham Most likely this is due to an administrative limit on the maximum size of "core" (really, "address space") used by a job on your TOPS-10 system -- many system managers set a ridiculously low limit, which makes it impossible to load up any significant application into MacLISP; but it shouldn't matter since you are no doubt running the VM system. True, it is a bug that MacLISP doesn't die more gracefully, but there are so many more important things to work on first ....  Date: 16 OCT 1980 1657-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: This still happens in XLISP To: (FILE [JONL;JONL MAIL]) at MIT-MC CC: (BUG LISP) at MIT-MC (defun foo () '(expr definition)) (macro foo (nil) ''(macro definition)) (foo) => (macro definition) (funcall 'foo) => (expr definition) (apply 'foo ()) => ;IMPROPER USE OF MACRO - EVAL  Date: 16 OCT 1980 0924-EDT From: BATALI at MIT-AI (John Batali) Subject: DEFSUBST To: INFO-LISP at MIT-AI I need it in MacLISP. Where is it? Is it? Etc?  Date: 16 October 1980 02:31-EDT From: Henry Lieberman To: BUG-LISP at MIT-AI I got a CALL JONL error - Atomindex screw in function STEP-FORWARD in ACTOR;DEBUG >. Needs my init file, reads in lots of macros to compile. I'll help narrow it down if you need to.  Date: 14 OCT 1980 1820-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CC: LISP-FORUM at MIT-MC (setq Y '(1 2 3)) (setf (setq x (CAR y)) 100) ; Obscure format - SETF I don't want to give anyone the idea that I sit around thinking up these wierd things, this was created by a macro. (setf (progn (hprint "Howdy hacker") x) 99) seems to work. So I would think the same value-propagation code should work for SETQ. (****) (****) (Sort-of-value). What do people think about SETF through COND, DO, etc. Obviously these have to be dealt with if an RMS-style destructuring binder is going to be all it could be. -gjc  Date: 13 October 1980 16:50-EDT From: Kent M. Pitman Subject: +INTERNAL-STRING-MARKER lossage To: BUG-LISP at MIT-MC, BUG-COMPLR at MIT-MC cc: KMP at MIT-MC, RWK at MIT-MC, GJC at MIT-MC, GSB at MIT-ML ;; Intern the ``string'' MY-BUG ... (EVAL-WHEN (EVAL COMPILE) (INTERN "MY-BUG")) ;; Define an ordinary function ... (DEFUN MY-BUG (X) X) ----- This works niftily in the interpreter. This doesn't work if you try to compile and fasload it into a lisp. I wonder why? Could it have anything to do with the +INTERNAL-STRING-MARKER that is still on the *interned* symbol in the compiler after the (INTERN "MY-BUG") is executed? Probably. I think that probably the compiler should also redefine INTERN to do a normal intern only if that property is absent. Presumably if the property is present, you should treat the symbol as a string. What does that mean? Well, how about... (DEFUN REDEFINED-INTERN (X) (COND ((AND (SYMBOLP X) (GET X '+INTERNAL-STRING-MARKER)) (STANDARD-INTERN (COPYSYMBOL X ()))) ; Don't copy plist!! (T (STANDARD-INTERN X)))) ie, if the thing has such a marker, it's a string. strings cannot live on the obarray, so get a symbol which looks like the string and put *that* on the obarray... if you don't do something like this, the result is confusing. it lost me about 2 hours last night trying to find out why my function ran interpreted but lost compiled ... disappeared. the UNFASL file even claims that the function is getting defined... -kmp  Date: 13 October 1980 1054-EDT (Monday) From: Guy.Steele at CMU-10A To: CWH at MIT-MC Subject: Side effects and SETF CC: bug-lisp at MIT-MC Message-Id: <13Oct80 105433 GS70@CMU-10A> From: Carl W. Hoffman From: Guy.Steele at CMU-10A I must agree with GJC that the tradition of left-to-right evaluation be maintained in MacLISP/LISP Machine LISP for consistency. The SETF machinery ought to be gone over with a fine-toothed comb, as well as the destructuring machinery and anything else vaguely related, to make sure things are being kept consistent. SETF is a special form, not a subr. I consider the fact that GJC's example worked interpreted to be a bug. His example only makes sense if we view SETF as a subr and CAR as returning a locative. But Lisp doesn't work that way. Hmm... you seem to be suffering from "Aunt Agatha syndrome": "Why, I can't imagine it working any other way... so it must be this way!" To me, his example makes sense under a model other than the locative model: SETF is a special form that effectively turns any function call as its first argument into a special form--but arguments of that call are NOT special forms. Thus, (SETF (CAR (get y x)) (hack z)) treats the upper-case part as special forms, so to speak. Now note too that the "special function call" ti to CAR, a function with no side effects, and in general the selector operation fed to a SETF is supposed to have no side effects. The computations of the argument to thast selector may have side effects, however, and so such computations should be done left-to-right. Thus in (SETF (GET x y) z), GET is a selector (side-effect-less), and the forms x, y, and z should be executed once each and in that order. By the same token, (PUSH x (GET y z)) treats the GET as special, but x, y, and z are ordinary forms and should be executed once each and in that order. In these examples CAR and GET are not being treated as returning locatives (though that is also a helpful metaphor); instead, they may be considered "keywords" for PUSH and SETF--part of the template for the total special form. Any ordinary forms within that template should be executed left-to-right.  Date: 11 October 1980 18:44-EDT From: Kent M. Pitman Subject: #+(NOT x y z) To: CWH at MIT-MC cc: BUG-LISP at MIT-MC Yes, this is clearly a case of a typo -- I didn't mean it should work. I just want Lisp to signal an error when it occurs.  Date: 10 October 1980 21:35-EDT From: Glenn S. Burke Subject: Re: side effects and a complr bug. To: Guy.Steele at CMU-10A, CWH at MIT-MC, GJC at MIT-MC, BUG-LISP at MIT-MC I think it is poor practice to have macros/special forms which have unpredictable results with respect to side effects, order of evaluation, and repeated evaluation. Having to assume that it is unsafe to have any sigificant evaluation inside of SETF or any of its derivatives significantly screws the power normally provided by Lisp. The obvious convention to follow is that things get evaluated exactly once, and in left to right order. It is possible to design a relatively simple protocol for making SETF constructs, which can then be used to define things like PUSH and POP, complete with typing and common subexpression optimization. To make it easier to define these constructs, they can just bind whatever they think is necessary, and that can be optimized away later. Much of the support necessary to do this exists already, and i have been employing a lambda-optimizer for other purposes for some time now.  Date: 10 October 1980 19:25-EDT From: Carl W. Hoffman Subject: Re: side effects and a complr bug. To: GJC at MIT-MC, BUG-LISP at MIT-MC, Guy.Steele at CMU-10A Date: 9 October 1980 1028-EDT (Thursday) From: Guy.Steele at CMU-10A In-Reply-To: GJC@MIT-MC's message of 8 Oct 80 16:46-EST I must agree with GJC that the tradition of left-to-right evaluation be maintained in MacLISP/LISP Machine LISP for consistency. The SETF machinery ought to be gone over with a fine-toothed comb, as well as the destructuring machinery and anything else vaguely related, to make sure things are being kept consistent. SETF is a special form, not a subr. I consider the fact that GJC's example worked interpreted to be a bug. His example only makes sense if we view SETF as a subr and CAR as returning a locative. But Lisp doesn't work that way.  Date: 10 October 1980 19:19-EDT From: Carl W. Hoffman To: BUG-LISP at MIT-MC Date: 9 OCT 1980 1924-EDT From: KMP at MIT-MC (Kent M. Pitman) On ITS Maclisp, #+(NOT LISPM MACLISP) 3 reads as 3 #+(NOT MACLISP LISPM) 3 4 reads as 4 It just ignores the 2nd element. Syntax checking would be nice. Who knows but that someone might not think that #+(NOT a b c ...) means the same as #-(AND a b c ...) and lose ... -kmp NOT should only work for one argument. Anything else is probably a typo.  Date: Friday, 10 October 1980 15:23-EDT From: EAK at MIT-XX To: BUG-LISP at MIT-MC cc: MT at MIT-XX Subject: MACLISP's reader Now that XX has VTS, MACLISP should support reasonable rubout processing. It should determine at runtime if VTS is running, and use ^P codes if so.  Date: 10 October 1980 00:45-EDT From: Robert W. Kerns To: GSB at MIT-MC, JONL at MIT-ML cc: BUG-LISP at MIT-ML Date: 10/09/80 17:18:57 From: JONL at MIT-ML To: (BUG LISP) at MIT-ML (describe "abc") loses -- msg is ;FORMAT RAN OUT OF ARGS. This is a FORMAT bug. Try, for example: (FORMAT 'T "~:[~vT~;~S~]" t 'foo) ;Runs out of arguments (FORMAT 'T "~:[~S~;~S~]" t 'foo) ;Works fine It would appear that the argument calculation in ~vT isn't skipped in failing conditionals.  Date: 9 OCT 1980 1924-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC On ITS Maclisp, #+(NOT LISPM MACLISP) 3 reads as 3 #+(NOT MACLISP LISPM) 3 4 reads as 4 It just ignores the 2nd element. Syntax checking would be nice. Who knows but that someone might not think that #+(NOT a b c ...) means the same as #-(AND a b c ...) and lose ... -kmp  JONL@MIT-ML 10/09/80 18:04:46 Re: Default Allocations of PDLs To: GLS at MIT-ML CC: (BUG LISP) at MIT-ML Your'e probably right that we should just install some large specific number, rather than depend upon the stability of either SEGSIZ or PAGSIZ. The current setup for ITS MacLISP is "4*PAGSIZ", which would be 4096.(decimal). As a side point, we might note that SEGSIZ hasn't changed since the initial perturbation of the BIBOP scheme (and likely can't change!), but PAGSIZ changes moment-by-moment as one goes from an ITS system to a TOPS-10/20.  JONL@MIT-ML 10/09/80 17:18:57 To: (BUG LISP) at MIT-ML (describe "abc") loses -- msg is ;FORMAT RAN OUT OF ARGS.  Date: 9 October 1980 1028-EDT (Thursday) From: Guy.Steele at CMU-10A To: gjc at MIT-MC, bug-lisp at MIT-MC Subject: Re: side effects and a complr bug. In-Reply-To: GJC@MIT-MC's message of 8 Oct 80 16:46-EST Message-Id: <09Oct80 102856 GS70@CMU-10A> I must agree with GJC that the tradition of left-to-right evaluation be maintained in MacLISP/LISP Machine LISP for consistency. The SETF machinery ought to be gone over with a fine-toothed comb, as well as the destructuring machinery and anything else vaguely related, to make sure things are being kept consistent.  Date: 9 October 1980 1014-EDT (Thursday) From: Guy.Steele at CMU-10A To: JONL at MIT-MC (Jon L White) Subject: Re: Default PDL allocations CC: bug-lisp at MIT-MC In-Reply-To: JONL@MIT-MC's message of 8 Oct 80 16:35-EST Message-Id: <09Oct80 101431 GS70@CMU-10A> No, you don't want PDL sizes to go all haywire just because you change SEGSIZ; SEGSIZ is meant to affect the granularity of allocation for expandible spaces, not the size of fixed things. No doubt this is an ancient spazz on my part. I suggest that some fixed large number be chosen instead (i.e. replace PAGSIZ by 2000 octal).  Date: 8 OCT 1980 1750-EDT From: GJC at MIT-MC (George J. Carrette) Subject: DEFUN-KEYED. To: LISP-FORUM at MIT-MC, (BUG LISP) at MIT-MC, BAK at MIT-MC A maclisp FASL file for BAK's DEFUN-KEYED is in GJC;DEFKEY FASL (All ya had to do was define DEL and give a *LEXPR declaration. Although I can image the frustration of trying to run COMPLR a few times on AI is enough to make you swear off.)  Date: 8 OCT 1980 1746-EDT From: GJC at MIT-MC (George J. Carrette) Subject: side effects and a complr bug. To: LISP-FORUM at MIT-MC, (BUG LISP) at MIT-MC There is a possible incompatiblity between lisp machine lisp and maclisp and NIL with respect to the handling of side effects. Here is a wallpaper file with an example: ((DSK GJC) LWALL /1) (defun mapcc (f v) (do ((l v)) ((null l) v) (setf (car l) (funcall f (pop l))))) MAPCC (setq a '(1 2 3 4 5) b '(1 2 3 4 5) f '(lambda (u) (list 'f u))) (LAMBDA (U) (LIST (QUOTE F) U)) ; test1 (mapcc f a) ((F 1) (F 2) (F 3) (F 4) (F 5)) ; neat (chomp mapcc) (MAPCC) ; test2 (mapcc f b) ;((F (F (F (F (F 1)))))) NIL CLOBBERED ;BKPT FAIL-ACT QUITQUIT b (1 (F 1) (F (F 1)) (F (F (F 1))) (F (F (F (F 1))))) ; ah, so thats what its doing! (walend) The maclisp expanders for SETF/PUSH/POP try very hard to guarantee the order of evaluatation as the lexicaly apparent order of evaluation, and to also keep the number of evaluations to 1. The macros themselves also try to avoid creating extra temporary locations, which is hard to do sometimes without error, I guess thats what causes the bug once MAPCC above is compiled. The DEFUN-KEYED macro of BAK is another example. The order of evaluation of the arguments is given by the macro definiton, not by the apparent calling of the function. Its easy enough to make sure the evaluation is as apparent in the call, although arguments for not doing this can be made in terms of efficiency of the run-time or the compiler. Question: What do you think we should do about all this? -gjc p.s. I just HAD to come up with something to get people off of DIGIT-WEIGHT!  Date: 8 OCT 1980 1735-EDT From: JONL at MIT-MC (Jon L White) Subject: Default PDL allocations To: (BUG LISP) at MIT-MC In the *LISP file, there are settings for labels like "ALPDL" etc. which are conditionalized on the PAGING flag. Problem is, they then set values dependent upon PAGSIZ -- they probably should use SEGSIZ instead so that Twenex versions don't have their allocations halved. (A twenex page is half the size of an ITS page.)  Date: 7 October 1980 04:07-EDT From: Robert W. Kerns Subject: Certain random cases of internal APPLY To: "(FILE [JONL;JONL MAIL])" at MIT-MC cc: BUG-LISP at MIT-MC Date: 2 October 1980 17:26-EDT From: Jon L White To: RWK cc: BUG-LISP Re: Certain random cases of internal APPLY I believe you may have added the line at ILP1+1: ILP1: HRRZ A,(C) ; NEXT PDL SLOT HAS FUNCTION IN RH, HRLZM A,(C) ; Save FN in left half in case it's not there This is most certainly buggy, to zero out the RH (I may be responsible and just can't remember, but since I seldom use lower-case comments ...) Anyway, regardless of how/why it was added, I had to change it to: ILP1: MOVE A,(C) ; NEXT PDL SLOT HAS FUNCTION IN RH, TLZN A,-1 HRLM A,(C) ; Save FN in left half in case it's not there SKOTT A,LS This lossage shows up when funcalling or applying FUNARGs (yes, Virginia, there is a FUNARG-claus in MacLISP, and the poooor COMPLR even uses one!). If anyone has seen spurious WRNG-NO-ARGS errors in XLISP (especially with FUNCALL or LEXPR-FUNCALL) I'd appreciate some more feedback on this change. I was responsible, the 'Z' in the 'HRLZM' was a typo. My change was in the line of a quick fix (except I blew it in typing it into the source). Your fix looks like sort of the right thing, except it didn't make sense to me why this was the place to fill in the slot conditionally rather than filling it in unconditionally somewhere else.  Date: 4 OCT 1980 2351-EDT From: GJC at MIT-MC (George J. Carrette) To: DDM at MIT-MC CC: (BUG LISP) at MIT-MC (DEFAULTF 'filename) will set up the file defaults for LOAD and OPEN. However, LOAD and OPEN are considered primitives now, only ONE person in a evironment can be fooling with DEFAULTF of course, so it can lead to problems in shared programs. Global side effects of that nature are not now considered a good way to save typing of filenames. (Ah, but you should see some of the new features.)  Date: 4 October 1980 14:47-EDT From: David D. McDonald To: BUG-LISP at MIT-AI After a year's hiatus to write my thesis I'm now back trying to make my programs work again... I find that now runing (LOAD "FOO;BAR") does not change one's CRUNIT to FOO; - I think that's a mistake !! Have you given up sticky defaults ?? Is there some variation on the call that IS sticky ??  Date: 2 OCT 1980 1824-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: DEFUN doesn't check enough To: (BUG LISP) at MIT-MC 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. -kmp  Date: 2 OCT 1980 1741-EDT From: JONL at MIT-MC (Jon L White) Subject: TYI and TYIPEEK on SFA's To: (BUG LISP) at MIT-MC CC: JLK at MIT-MC, GJC at MIT-MC I just found and fixed a bug in the SFA code which could account for TYI and TYIPEEK acting strange (ocasionally) on SFA's -- basically, if the call to TYI or TYIPEEK had been compiled, then it probably was set up as an NCALL (expecting a numerical result in accumulator TT), but thte SFA code was only putting a result in accumulator A. Anyone other than KMP and myself ever see this?  Date: 2 OCT 1980 1726-EDT From: JONL at MIT-MC (Jon L White) Subject: Certain random cases of internal APPLY To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC I believe you may have added the line at ILP1+1: ILP1: HRRZ A,(C) ; NEXT PDL SLOT HAS FUNCTION IN RH, HRLZM A,(C) ; Save FN in left half in case it's not there This is most certainly buggy, to zero out the RH (I may be responsible and just can't remember, but since I seldom use lower-case comments ...) Anyway, regardless of how/why it was added, I had to change it to: ILP1: MOVE A,(C) ; NEXT PDL SLOT HAS FUNCTION IN RH, TLZN A,-1 HRLM A,(C) ; Save FN in left half in case it's not there SKOTT A,LS This lossage shows up when funcalling or applying FUNARGs (yes, Virginia, there is a FUNARG-claus in MacLISP, and the poooor COMPLR even uses one!). If anyone has seen spurious WRNG-NO-ARGS errors in XLISP (especially with FUNCALL or LEXPR-FUNCALL) I'd appreciate some more feedback on this change.  Date: 2 October 1980 04:32-EDT From: Robert W. Kerns Subject: (EQUAL "a" "a") -> () To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, miller at MIT-AI Date: 1 October 1980 1110-EDT (Wednesday) From: Guy.Steele at CMU-10A To: bug-lisp cc: miller at MIT-AI Re: (EQUAL "a" "a") -> () I might suggest that there be a separate obarray for interning strings--this would prevent the possibility of SETQ conflicts, while allowing EQUAL to work on them. This requires an entire obarray, plus buckets, plus inhibiting GC of them unless you invoke the great GCTWA. If you've got the space, why not do (LOAD '((LISP) STRING)) and get REAL strings?  Date: 2 October 1980 04:16-EDT From: Robert W. Kerns Subject: #| ... |# = /* ... */ To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 1 October 1980 04:50-EDT From: Alan Bawden To: BUG-LISP, BUG-LISPM Re: #| ... |# = /* ... */ So, how about this #| ... |# thing? Are you people convinced that it is acceptable? Nobody objected when I suggested the idea to lisp-forum, so if I hear from the MacLisp/NIL people that they are willing to put it in their sharpsign macro I will go ahead and add it to the LispMachine reader. It's acceptable to me, but I still think it's gross. Of course, I've wanted such a thing bad enough to implement one on occasion, but I STILL think it's gross.  Date: 2 October 1980 03:13-EDT From: Robert W. Kerns Subject: (equal "a" "a") ==> () To: BARMAR at MIT-MC cc: ALAN at MIT-MC, BUG-LISP at MIT-MC If you do (LOAD '((LISP) STRING)) you will get a package which implements strings in MACLISP. (equal "a" "a") will then return T. The disadvantage is that this takes up space, and many applications, such as MACSYMA, are strapped for space and will take what they can get. For most applications symbols are adaquate, and this is what MacLisp defaultly provides.  Date: 2 October 1980 00:58-EDT From: Robert W. Kerns Subject: DESCRIBE To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 23 September 1980 17:51-EDT From: Jon L White To: BUG-LISP Re: DESCRIBE in the EXTEND stuff, the function DESCRIBE fails to put spaces between the applicable methods, resulting in a not-so-readable printout. FORMAT change. Hmm, I thought I'd already fixed it. Anyway, it's fixed on ITS now.  Date: 2 OCT 1980 0025-EDT From: BARMAR at MIT-MC (Barry Margolin) Subject: MacLisp strings To: (BUG LISP) at MIT-MC, LISP-FORUM at MIT-MC Thanks for all the replies. I did not mean to start a controversy, but I'm sort of glad I did, because of the incompatibilities between the various dialects of MacLisp. Also, just for your information, what started this flamage was an EECS MacLisp user who called to ask why it didn't work. I figured out that "samepnamep" was the right function, but I was just wondering why that was necessary. I had also gotten into the habit of thinking that "equal" was the general function to use if one wanted to know if wo objects looked alike. I am also glad I sent this in, as I now know the true story of how ITS MacLisp groks strings. -Barmar  Date: 1 OCT 1980 2305-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: While you are in that neighborhood! To: (BUG LISP) at MIT-MC GSB@MIT-ML 10/01/80 23:02:07 Re: apply & user hunks APPLYing a user-hunk still doesn't work... Nor does APPLYing a macro that also has a subr property...  GSB@MIT-ML 10/01/80 23:02:07 Re: apply & user hunks To: (BUG LISP) at MIT-ML APPLYing a user-hunk still doesn't work...  Date: 1 OCT 1980 1703-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: #| ... |# To: LISP-FORUM at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC (SHIT! This damned keyboard just doubled a ^C and sent you all some more trash to delete! Most of you get TWO copies!) 1) Yes, I prefer ";" as the way to write a comment too. But there are things that you cannot do with it that you can do with "#|". If MIDAS programmers prefer the ";" comment and tend to use it when they can, then I suspect the same thing will remain true of Lisp programmers. 2) Yes, It is intended that the things should nest. I agree that editors won't be able to deal with this correctly, but that is a poor reason to screw ourselves. People who use "/*" in PL1 have complained bitterly for years that the damn things don't nest correctly. 3) About slashification. I didn't think it was necessary since you can always comment out a "|#" by typing "|/#" instead, but "/|#" is better parsed by editors. So OK, slashification is now part of the definition. 4) Anyone who uses #| | |# has just thrown away all the advantages of "#|". He might as well be typing ";;;" at the front of every line. Editors will also get confused by all the "|"s. For these reasons I expect that this will not be done. (BTW, M-Q does understand ";;;" if you set the fill prefix, but that is not always enough.) 5) How come nobody voted no the first time I brought this up?  Date: 1 OCT 1980 1640-EDT From: JONL at MIT-MC (Jon L White) Subject: Use of strings in PDP10 MACLISP To: BARMAR at MIT-MC, ALAN at MIT-MC, KMP at MIT-MC To: LISP-FORUM at MIT-MC, (BUG LISP) at MIT-MC, Miller at MIT-AI To: Guy.Steele at CMU-10A CC: JHendler at BBNA, JShelton at BBNA, TBlocker at BBNA CC: Pattermann at BBNA, Kehler at BBNA There has been a lot of commentary on the two notes reproduced below and I've copied it to a file MC:LSPMAI;STRING BARMAR for reference. Date: 28 September 1980 20:22-EDT From: Barry Margolin Subject: "strings" To: BUG-LISP at MIT-MC Why does (equal "a" "a") return NIL? Date: 29 SEP 1980 0910-EDT From: KMP at MIT-MC (Kent M. Pitman) The primary use of "..." is to get an object which prints a certain way... "..." is defined on non-Multics Maclisp to return an UNINTERNED SYMBOL which has been SETQ'd to itself (so that it self-evaluates). Sad to say, no one seems to have thought of telling BARMAR to use the macLISP STRING package. The initial setting of the " macro in PDP10 MacLISP is indeed for a minimal kind of compatibility, but for a real STRING implementation, one should load in the out-of-core package (LOAD '((LISP) STRING FASL)) Some minimal documentation can be found in the source files MC:NILCOM;STRING >, MC:LSPSRC;EXTEND >, and MC:LSPSRC;EXTMAC >. Similar files exist on the MacLISP distribution to TOPS-10/20 sites.  Date: 1 OCT 1980 1626-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: #| ... |# To: LISP-FORUM at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC 1) Yes, I prefer ";" as the way to write a comment too. But there are things that you cannot do with it that you can do with "#|".  Date: 1 October 1980 15:15-EDT From: Kent M. Pitman Subject: [Re: [Re: [Re: (EQUAL "a" "a") -> ()]]] To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, miller at MIT-AI Date: 1 October 1980 1252-EDT (Wednesday) From: Guy.Steele at CMU-10A ... I meant for the obarray to be an unadvertised internal implementation technique. People are only supposed to depend on advertised properties of data types and functions, and strings being EQ is most certainly not advertised! ... So if the obarray hack is put in, don't annouce that an obarray is used. Announbce only that EQUAL now works on strings. ----- I'm still worried about the naive user from some other lisp who does assignments to hard-to-print tokens and finds that he breaks other code by so doing. Making strings interned (anywhere) and then letting them be SETQ-able bothers me. I'd agree to this only if you could keep SETQ from winning. I still think (SETQ "(" 'OPEN-PAREN) ... (MAPC #'PRIN1 (LIST "(" A " " ")")) is going to really cramp debugging... Can someone suggest an out here. Does purifying pseudo-strings' value cells work and is it feasible? I'm not up on those details. -kmp  Date: 1 October 1980 1252-EDT (Wednesday) From: Guy.Steele at CMU-10A To: KMP at MIT-MC (Kent M. Pitman) Subject: Re: [Re: [Re: (EQUAL "a" "a") -> ()]] CC: bug-lisp at MIT-MC, miller at MIT-AI In-Reply-To: KMP@MIT-MC's message of 1 Oct 80 10:39-EST Message-Id: <01Oct80 125246 GS70@CMU-10A> I think I didn't make myself clear: I meant for the obarray to be an unadvertised internal implementation technique. People are only supposed to depend on advertised properties of data types and functions, and strings being EQ is most certainly not advertised! Using an obarray internally will solve the EQUAL problem, and I don't think it breaks any correct programs. It will just cause incorrect programsd to be incorrect in a different way. Small fixnums are "interned" too, by FXCONS, for different implementational reasons, and this has occasionally misled people into using EQ on fixnums because they empirically determined that EQ "worked"; but when this screwed them we just said to use =, rather than flushing the "interning" feature. So if the obarray hack is put in, don't annouce that an obarray is used. Announbce only that EQUAL now works on strings.  Date: 1 October 1980 12:55-EDT From: Kent M. Pitman Subject: (EQUAL "a" "a") -> () To: MILLER at MIT-AI cc: BARMAR at MIT-MC, BUG-LISP at MIT-MC, JHendler at BBNA, JShelton at BBNA, Kehler at BBNA, Pattermann at BBNA, TBlocker at BBNA Date: 30 September 1980 23:49-EDT From: Mark L. Miller To: KMP, BARMAR cc: JHendler at BBNA, JShelton at BBNA, TBlocker at BBNA, Pattermann at BBNA, Kehler at BBNA, BUG-LISP Re: (EQUAL "a" "a") -> () Date: 29 SEP 1980 0910-EDT From: KMP at MIT-MC (Kent M. Pitman) The primary use of "..." is to get an object which prints a certain way... "..." is defined on non-Multics Maclisp to return an UNINTERNED SYMBOL which has been SETQ'd to itself (so that it self-evaluates). ... let's not criticize the complaint -- it is a legitimtate gripe -- i.e., the semantic rule of thumb that "if two things LOOK THE SAME they are almost always EQUAL" has been violated, and thus this behavior can reasonably be called a "bug". ----- This doesn't follow at all. Bugs are when things don't behave as documented or as carefully thought out. Funarg problems arise from evaluators behaving according to rules of thumb, yet it is the evaluator, not the programmer which is defficient when the funarg is not correctly resolved. The reason is that there are more deep-rooted (admittedly hard to model as `rules of thumb') reasons for wanting the more complex behavior. GENSYM's already violate the rule and for good reason. If it were going to be a bug to have things that look alike, then we wouldn't have different obarrays and gensyms and all that -- we'd have a `definition' of EQUAL that said this was to be true. Personally, I think that EQUAL ought NOT to do the gratuitous string-equal for you -- even in a real lisp. I think it's operation should be to determine if you have a collection of objects which are EQ at the atomic level. Strings being atoms, I don't see "abc" as equal to "abc". If you want a string comparison of things, you should ask for it explicitly -- that's going to the subatomic level and should require a different observation. That's just my opinion, though, and I think people would resent my suggesting it be changed, so I'll pass on that point for now. -kmp  Date: 1 October 1980 12:05-EDT From: George J. Carrette Subject: Macros and destructuring and functions, oh my! To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC, dlw at MIT-AI This comment is more of a bug note, but to tell you the truth I have even found the destructuring provided by DEFMACRO on the lispm and in maclisp to be poor in the "syntax-checking" and error message features they provide to the user of a macro which happened to be written using destructuring. Say I write (defmacro foo ( ( a b) C) ...), but you call it as (foo X Y). In JONL's complr this would cause A and B to be bound to random bad pointers (well I guess B would be the CAR of the PLIST of X), the COMPLR does strange things when given such strange input! even in the maclisp interpreter you would get a strange looking error. On the lispm you get an error when taking the CAR of X, which is nice, and you can use the error handler to find out that you are macro-expanding (FOO X Y), but its still not as nice as a "Bad syntax to macro FOO, the second argument was intended to match against: (A B)" In maclisp especialy I think we need a destucturing mechanism which has error checking which is context informative (in terms of error messages). In defmacros this is more important to me than the optimal code in terms of least number of CAR's and CDR's and stack space used which JONL's destructuring LET now provides. [However, that technology of optimaly picking apart data is useful for other things.] -gjc  Date: 1 OCT 1980 1139-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: [Re: [Re: (EQUAL "a" "a") -> ()]] To: Guy.Steele at CMU-10A CC: (BUG LISP) at MIT-MC, MILLER at MIT-AI The only problem about putting strings on another obarray is that it makes EQ work also. I think this is a poor idea. This will allow people to say things like (SETQ "(" 3) when they way (SETQ |(| 3) and then later when someone else does a (PRINC "(") they will get a *big* surprise. Additionally, (EQ "a" "a") would mean that people might start relying again on EQness of strings. I find it useful to know for sure that "..." is not really useful for much more than its printname (unless severely maligned) ... And think of the great debugging statistics you can get from being able to do (DEFUN DEBUGPRINT (X) (COND ((SYMBOLP X) (PUSH (STATUS DAYTIME) (GET X 'WHEN-USED-LAST)))) (PRINT X)) and then knowing for sure that if you did (DEBUGPRINT ".") in many places, you could tell *which* call to DEBUGPRINT was actually outputting that dot where you didn't want it .... This last issue is all in fun, but the other issues I think are serious. I'd rather not see a string obarray. -kmp  Date: 1 October 1980 1113-EDT (Wednesday) From: Guy.Steele at CMU-10A To: Alan Bawden Subject: Re: #| ... |# = /* ... */ CC: bug-lisp at MIT-MC, bug-lispm at MIT-MC In-Reply-To: Alan Bawden's message of 1 Oct 80 03:50-EST Message-Id: <01Oct80 111317 GS70@CMU-10A> I vote yes. Seems harmless enough.  Date: 1 October 1980 1110-EDT (Wednesday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: Re: (EQUAL "a" "a") -> () CC: miller at MIT-AI In-Reply-To: Mark L. Miller's message of 30 Sep 80 22:49-EST Message-Id: <01Oct80 111052 GS70@CMU-10A> I might suggest that there be a separate obarray for interning strings--this would prevent the possibility of SETQ conflicts, while allowing EQUAL to work on them.  Date: 1 October 1980 1106-EDT (Wednesday) From: Guy.Steele at CMU-10A To: alan at MIT-MC Subject: Defmacros and &... CC: dlw at MIT-AI, bug-lisp at MIT-MC, bug-lispm at MIT-MC Message-Id: <01Oct80 110654 GS70@CMU-10A> Well, I didn't exactly claim that the current thing is elegant. However, your FRUITY example is indeed an example of the kind of thing I would like to do, if we could come up with a reasonable way to express it (actually, I didn't think what you wrote was so bad). Oh, well...  Date: 1 October 1980 04:50-EDT From: Alan Bawden Subject: #| ... |# = /* ... */ To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC So, how about this #| ... |# thing? Are you people convinced that it is acceptable? Nobody objected when I suggested the idea to lisp-forum, so if I hear from the MacLisp/NIL people that they are willing to put it in their sharpsign macro I will go ahead and add it to the LispMachine reader.  Date: 1 October 1980 04:02-EDT From: Daniel L. Weinreb Sender: DLW at CADR2 at MIT-AI Subject: Re: Macros and destructuring... To: Dave Touretzky at CMU-10A cc: BUG-lisp at MIT-MC, BUG-lispm at MIT-MC, BUG-macsymai at MIT-MC This discussion should be moved to LISP-FORUM. Dave, if you are not on it, you probably should be. I'll send further messages to LISP-FORUM instead of these BUG- lists. What does a LEXPR take if not an argument vector? It does not take an argument vector. The ARG function never returns any such vector. ARG lets you get at your N arguments via an ugly mechanism (numbers instead of names) because Maclisp hasn't had &mumbles. What FEXPRs do is even more irrelevant; FEXPRs are basically a loss and do not fit into what I consider reasonable philosophy of Lisp. I think it is absurd to base a discussion of what Lisp ought to be on the basis of what FEXPRs do now. As for your second paragraph, I have already explained this in previous messages. A macro is a function to the meta-lenguage, but it is a macro to the language. To say that "A macro is still a function, just like a FEXPR is" is quite wrong; FEXPRs aren't functions either. Saying that destructuring in DEFUN "is a natural thing to do, because at least one class of function really needs it" is exactly what I have been disagreeing with; you should *not* add something just because one application needs it, you can get destructuring with a DESTRUCTURE special form quite easily without building it in, and macros are NOT functions. Read my previous mail.  Date: 30 September 1980 23:49-EDT From: Mark L. Miller Subject: (EQUAL "a" "a") -> () To: KMP at MIT-MC, BARMAR at MIT-MC cc: JHendler at BBNA, JShelton at BBNA, TBlocker at BBNA, Pattermann at BBNA, Kehler at BBNA, BUG-LISP at MIT-MC Regarding this discussion: Date: 29 SEP 1980 0910-EDT From: KMP at MIT-MC (Kent M. Pitman) The primary use of "..." is to get an object which prints a certain way... "..." is defined on non-Multics Maclisp to return an UNINTERNED SYMBOL which has been SETQ'd to itself (so that it self-evaluates). While I understand the reason for this situation and am capable of using SAMEPNAMEP (sigh) instead of EQUAL to get around it, let's not criticize the complaint -- it is a legitimtate gripe -- i.e., the semantic rule of thumb that "if two things LOOK THE SAME they are almost always EQUAL" has been violated, and thus this behavior can reasonably be called a "bug". Off- hand I can't think of an efficient approach to solving it, but perhaps intern-ing "strings" on MacLisps that implement them as symbols should be considered? I have had several bug-messages come to me (at TI) on this subject in the last month. Users of other dialects such as Yale/UCI LISP are used to having "real" strings, i.e., "foo" works and (EQUAL "a" "a") returns T -- so this is seen as a deficiency of MacLISP. (But then the SETQ introduces at least a small possibility of name clash lossage -- so perhaps we should all stick to '|foo|, which is a true QUOTEd interned symbol -- or plead for true strings as a new datatype in those implementations that lack them. Regards, Mark  Date: 30 September 1980 2135-EDT From: Dave Touretzky at CMU-10A To: Daniel L. Weinreb Subject: Re: Macros and destructuring and functions, oh my! CC: bug-lisp at MIT-MC, bug-lispm at MIT-MC, bug-macsymai at MIT-MC In-Reply-To: Daniel L. Weinreb's message of 29 Sep 80 11:20-EST If Lisp had EXPRs and nothing else, you could perhaps make a more convincing argument to the effect that functions take multiple separate arguments and not an argument vector. But that is not the case. What does a LEXPR take if not an argument vector? What does a FEXPR take as input that makes it fundamentally different from a macro? Given that there are all these ways for a function to accept arguments, it doesn't seem reasonable to rule out destructuring as another useful variation. Second, let's re-examine the notion of macro as part of the metalanguage. This is a carryover from assembly language, where macros used an entirely different set of operations than the source language (e.g. simple string manipulation operations as opposed to machine instructions) and were only used to generate compileable source lines more efficiently. I claim a Lisp macro is just another kind of function, like a FEXPR. The difference is that a macro is a function that returns a form to be evaluated. Now, in the compiler the form is compiled for later evaluation, but in the interpreter it is evaluated immediately. But this is a just a feature of the way compilation works. A macro is still a function, just like a FEXPR is. Therefore, adding destructuring to DEFUN is a natural thing to do, because at least one class of function (the macro) really needs it, and it is logically consistent with the other classes as well. -- Dave  Date: 29 September 1980 19:18-EDT From: Daniel L. Weinreb Subject: Macros and destructuring and... To: Guy.Steele at CMU-10A cc: BUG-lisp at MIT-MC, BUG-lispm at MIT-MC, macsyma-i at MIT-MC I know that Lisp is its own meta-language. Just because one of the things you do with Lisp is to write macros is no reason to specialize DEFUN for that application. There are lots of other things you could specialize it for; macros are not that special. Well, I still don't think that functions are pased a vector of arguments. They are passed several arguments. This "vector" is an implementation detail which you seem to be elevating to the level of a philosophically desirable entity, merely to make your point.  Date: 29 September 1980 12:20-EDT From: Daniel L. Weinreb Subject: Macros and destructuring and functions, oh my! To: Guy.Steele at CMU-10A cc: BUG-lisp at MIT-MC, BUG-lispm at MIT-MC, macsyma-i at MIT-MC Sorry, Dan, I beg to differ with you on the philosophical nature of macros. Macros certainly are functions, of one argument. No, I still don't agree. A macro is implemented as a function of one argument in the meta-language. From the point of view of the meta-language it is a function of one argument. But functions in the meta-language have nothing to do with functions in the language; from the point of view of the language, a macro is a translator and not a function. Now, the fact that macros and functions are invoked by means of the "same syntax" is sort of a coincidence, and not at all essential. Yes. That's what I said, too. I don't see why you are debating this. I went on to say that this coincidence should not fool you into thinking that lambda lists and defmacro patterns are "the same thing". Now, it is true that in practice up until now destructuring has been the most useful for macros, which commonly parse apart their arguments into known fixed pieces. There is also the fact that ordinary functions in effect already get one level of destructuring by the fact that they are considered to get many named arguments rather than a single one (which is usually a "vector" of some sort); but after all, what are &OPTIONAL and &REST but destructuring mechanisms? There is something to be said for unifying that mechanism with the one used by DEFMACRO and the NIL LET, provided it can be done without undue clutter. No, I do not buy this argument at all. &OPTIONAL and &REST are not "destructuring an argument vector". Functions are not passed an argument vector; they are passed several arguments. &OPTIONAL has absolutely nothing to do with destructuring; you might think &REST does, but I don't; the only reason that list is there is because it is the easiest way to let you deal with an unanticipatable number of arguments. That list got CONSed; it did n't "fail to get destructured".  Date: 30 September 1980 01:10-EDT From: Mark L. Miller Subject: Your long note of last week To: MILLER at MIT-AI, JONL at MIT-MC cc: TBlocker at BBNA, ben at MIT-ML, KEN at MIT-MC, GJS at MIT-MC, PHW at MIT-MC, BUG-LISP at MIT-MC, BRoberts at BBNC Jonl, Those two points are VERY encouraging! Please sign TI up for an order of 2 dozen manuals (tell me where to send the check!) and please tell me how to get a Tops-20 Dumper tape of Mike Travers' 20X CRT support goody. Meanwhile, I'm still a "fan" you know and the last shot has not been fired. Regards, Mark  Date: 27 September 1980 13:32-EDT From: Daniel L. Weinreb Sender: dlw at CADR6 at MIT-AI To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC Well, what you have here is a special case; the functions you happen to be writing are doing something like translation. Why must DEFUN be modified just for one particular application? Use destructuring LET or something.  Date: 27 September 1980 13:12-EDT From: Mark L. Miller Subject: Learning LISP To: ALAN at MIT-MC cc: PHW at MIT-AI, BKPH at MIT-AI, CFFK at MIT-MC, BUG-LISP at MIT-MC In Reply To: Date: 8 AUG 1980 1638-EDT From: ALAN at MIT-MC (Alan Bawden) Date: 8 AUG 1980 1622-EDT From: CFFK at MIT-MC (Charles F. F. Karney) A guy here at Princeton would like to learn Lisp. Asides from the Maclisp Manual is there any easy introductory information he could use. (E.g. an on-line primer, a TEACHLISP program, or a decent book on Lisp.) I have been using the new Winston& Horn text, LISP (Addison-Wesley '81) in my Survey of AI course (80 graduate students in CS) at UT Dallas. It is excellent. Regards, Mark  Date: 27 September 1980 11:34-EDT From: Mark L. Miller Subject: Non-ITS Maclisp Maintenance To: MILLER at MIT-AI, Scott.Fahlman at CMU-10A cc: Dave.Touretzky at CMU-10A, jonl at MIT-MC, BUG-lisp at MIT-MC I basically agree that finishing NIL is a better goal than fixing up MACLISP-20. I think 20's will be around longer than you think, however; I guess I can't really see a major place for the VAX in AI -- by the time it has the 10 years of well-funded software development that 10's/20's have going for them, personal computing will be the only real choice for the future. We plan to hack on the 2060 till we have enough personal engines to turn it into a file computer. WIth any luck, I'll never even learn to use SOS or the other crufty DEC software on VMS. However, the portability goal of NIL makes it a better long term hope than LISPM LISP per se. I think NIL on a personal machine, though, is more viable than on the VAX. (Of course if it worked well enough and included something like ZWEI I suppose our VAX might come in handy...) Meanwhile, It is starting to look like TI may write THE NEW MACLISP MANUAL (modelled after THE NEW UCILISP MANUAL). The more tapes of machine readable headstarts we can get, the more likely we are to win. I was going to try hacking a chapter over the net, but working that way is just a lose. Our 2060 has typically 10 people on it (never more than 20) with 768Kwords, and so THAT's where I can get good enough response to face the task. We still have to explain to management why we are going to devote 2-3 manyears/year to writing a manual for MACLISP instead of just using INTERLISP, sigh! Regards, Mark  Date: 29 September 1980 22:02-EDT From: Alan Bawden Subject: GRINDEF and old-style DO To: Guy.Steele at CMU-10A cc: KMP at MIT-MC, BUG-GRINDEF at MIT-MC Date: 29 September 1980 1115-EDT (Monday) From: Guy.Steele at CMU-10A Recall that one can always convert old-style DO to new-style simply by inserting six parentheses: (DO X INIT STEP TEST BODY) => (DO ((X INIT STEP)) (TEST) BODY) SO a quick way out is just to grind every old-style DO as a new-style one, by this conversion (this amounts to an implicit declaration of war against old-style DO as being obsolete). I'm not sure I really advocate this -- just pointing out the possibility. barf  Date: 29 September 1980 1151-EDT (Monday) From: Guy.Steele at CMU-10A To: dlw at MIT-AI, gjc at MIT-AI Subject: Macros and destructuring and functions, oh my! CC: bug-lisp at MIT-MC, bug-lispm at MIT-MC, macsyma-i at MIT-MC Message-Id: <29Sep80 115129 GS70@CMU-10A> Sorry, Dan, I beg to differ with you on the philosophical nature of macros. Macros certainly are functions, of one argument. They map a piece of program (a macro call) into another piece of program. Now, the fact that macros and functions are invoked by means of the "same syntax" is sort of a coincidence, and not at all essential. There is no reason why lists whose *second* element was an atom beginning with an upper-case Q could not be reserved to mean macro calls and detected as such by the evaluator. Then, in the evaluator, one would have not ((AND (ATOM (CAR EXP)) (MACROP (FSYMEVAL (CAR EXP)))) (EVAL (MACROCALL (FSYMEVAL (CAR EXP)) EXP))) but instead ((AND (ATOM (CADR EXP)) (CHAR= #/Q (GETCHAR (CADR EXP) 1)) (EVAL (MACROCALL (GET (CADR EXP) 'MACRO) EXP))) and one could write a quadratic polynomial as (C Q+ (X Q* (B Q+ (X Q* A)))) for example. Sure, it's not "LISPy", but it's perfectly consistent. Another, simpler way to detect macro calls would be to require a keyword like CALL, so instead of (PUSH X Y) we would write (CALL PUSH X Y). One of the great things about LISP, though, is that the subset of lists it chooses to reserve to represent macro calls manage to look like function calls. This in turn allows the incredibly punnish and gross, but very efficient, implementation trick of allowing macro definitions to be stored in the function cell, taking advantage of the fact that the *particular syntax chosen for macro calls, which confuses them with function calls*, guarantees that a symbol cannot represent both a function and a macro simultaneously anyway. All this flamage is to point out that the only difference between a function and a macro is when it is invoked, the algorithm for deciding whether a form is a function call or a macro, and so on. Once you have decided to feed arguments to one or the other, it is a simple function. Now, it is true that in practice up until now destructuring has been the most useful for macros, which commonly parse apart their arguments into known fixed pieces. There is also the fact that ordinary functions in effect already get one level of destructuring by the fact that they are considered to get many named arguments rather than a single one (which is usually a "vector" of some sort); but after all, what are &OPTIONAL and &REST but destructuring mechanisms? There is something to be said for unifying that mechanism with the one used by DEFMACRO and the NIL LET, provided it can be done without undue clutter.  Date: 29 September 1980 1115-EDT (Monday) From: Guy.Steele at CMU-10A To: kmp at MIT-MC, alan at MIT-MC Subject: GRINDEF and old-style DO CC: bug-grindef at MIT-MC Message-Id: <29Sep80 111539 GS70@CMU-10A> Recall that one can always convert old-style DO to new-style simply by inserting six parentheses: (DO X INIT STEP TEST BODY) => (DO ((X INIT STEP)) (TEST) BODY) SO a quick way out is just to grind every old-style DO as a new-style one, by this conversion (this amounts to an implicit declaration of war against old-style DO as being obsolete). I'm not sure I really advocate this -- just pointing out the possibility.  Date: 29 SEP 1980 1430-EDT From: ALAN at MIT-MC (Alan Bawden) To: BARMAR at MIT-MC CC: (BUG LISP) at MIT-MC Date: 29 SEP 1980 0910-EDT From: KMP at MIT-MC (Kent M. Pitman) The primary use of "..." is to get an object which prints a certain way. Things like EQ are something you shouldn't depend on any more than EQ-ness of lists. "..." is defined on non-Multics Maclisp to return an uninterned symbol which has been SETQ'd to itself (so that it self-evaluates). You should normally check .INFO.;LISP NEWS for descriptions like this as almost all recent ITS features are documented there in some form or another. -kmp This doesn't completely answer your question. You asked why (EQUAL_"foo" "foo") returned nil not (EQ "foo" "foo"). EQUAL compairs things in all kinds of ways, numbers for numeric equality, conses for EQUALness of cars and cdrs, and strings (in lisps that have them) for same-name-ness, but for symbols it uses EQ, and that is what you are stuck with. Thus since ITS MacLisp doesn't really have strings but makes symbols instead (as KMP explained), the function EQUAL won't behave "correctly" with respect to these fake strings. This is OK, because we put the /" macro into ITS MacLisp primarily so that we could write (princ "Fatal Error!!!") and have it work on ITS and in places that really do have strings. The function SAMEPNAMEP can be used to compare these fake strings to see if they have the same name, and will also work for that purpose in lisps that have real strings. If you are doing something simple, this may be what you are looking for.  Date: 29 September 1980 11:33-EDT From: Richard Mark Soley Subject: GRINDEF in lower case To: KMP at MIT-MC cc: BUG-GRINDEF at MIT-MC Date: 26 SEP 1980 2118-EDT From: KMP at MIT-MC (Kent M. Pitman) Sender: BIL at MIT-MC To: SOLEY cc: (BUG GRINDEF) Re: GRINDEF in lower case Well, I don't agree that lower case code is more readable .... Okay, fine, no lower case. What about the bug in grinding MC:NILE;DOC > (function DOCUMENTOR) ?? -- richard  Date: 29 SEP 1980 0910-EDT From: KMP at MIT-MC (Kent M. Pitman) To: BARMAR at MIT-MC CC: (BUG LISP) at MIT-MC The primary use of "..." is to get an object which prints a certain way. Things like EQ are something you shouldn't depend on any more than EQ-ness of lists. "..." is defined on non-Multics Maclisp to return an uninterned symbol which has been SETQ'd to itself (so that it self-evaluates). You should normally check .INFO.;LISP NEWS for descriptions like this as almost all recent ITS features are documented there in some form or another. -kmp  Date: 28 SEP 1980 2022-EDT From: BARMAR at MIT-MC (Barry Margolin) Subject: "strings" To: (BUG LISP) at MIT-MC Why does (equal "a" "a") return NIL? barmar@mc  Date: 27 SEP 1980 0905-EDT From: JONL at MIT-MC (Jon L White) Subject: Your long note of last week To: miller at MIT-AI CC: KEN at MIT-MC, GJS at MIT-MC, PHW at MIT-MC, (BUG LISP) at MIT-MC CC: TBlocker at BBNA, ben at MIT-ML, BRoberts at BBNC Date: 23 September 1980 23:27-EDT From: Mark L. Miller Subject: MacLISP's Floating point To: JONL at MIT-MC cc: KEN at MIT-AI, GJS at MIT-AI, PHW at MIT-AI, TBlocker at BBNA, MMiller at BBNA, ben at MIT-ML, BUG-LISP at MIT-MC, BRoberts at BBNC I was hoping to reply more to your note, Mark, but Scott Fahlman's reply (which is still in my mail file) makes essentially the main point -- that maintaining Maclisp, while useful, is not a forward-looking project (as NIL is). However, two things are on the horizon which may help you and other non-MIT Maclisp users: 1) Kent Pitman has been working on a full Maclisp manual, to be done in TEX, and there is some hope that this will be done "shortly". 2) Mike Travers has done a virtual-terminal service for TOPS-20 (on the XX machine) which essentially implements the ITS-style control-P codes -- thus it should be possible to use the ITS-specific code for Maclisp's CURSORPOS (written in MIDAS), and thus achieve on TOPS-20 the same level of "rubout-ability" and CRT-usabililty as on ITS.  Date: 26 September 1980 21:35-EDT From: Alan Bawden Subject: GRINDEF in lower case To: KMP at MIT-MC cc: BUG-GRINDEF at MIT-MC Given that you won't be kept busy making GRINDEF hack lower case why don't you make it understand old-style DO?  Date: 26 SEP 1980 2118-EDT From: KMP at MIT-MC (Kent M. Pitman) Sent-by: BIL at MIT-MC Subject: GRINDEF in lower case To: SOLEY at MIT-MC CC: (BUG GRINDEF) at MIT-MC Well, I don't agree that lower case code is more readable than uppercase code. Fortunately, my reason for not implementing that needn't be dependent on this dislike: We had some discussion a while back in which I and others pointed out that you cannot correctly decide what to downcase and what to leave upcased. There is no way to distinguish between code that was typed in by |...| from stuff that was not. Eg, (+ |X| X) would print out as (+ x x) under your scheme since after reading there is no way to detect the input syntax that was used. This would break code, so we can't do it. Besides that, it would be slow, but that's a lesser issue and not the criterial one. -kmp  Date: 26 SEP 1980 1910-EDT From: SOLEY at MIT-MC (Richard Mark Soley) Subject: Lowercase and bugs. To: (BUG GRINDEF) at MIT-MC CC: NILE at MIT-MC Two things: the function DOCUMENTOR in MC:NILE;DOC > ALWAYS grinds incorrectly, quite consistently, overflowing the line length regardless of the terminal's linel. Is there any way to have grindef output LOWER CASE? I THINK WE ALL AGREE THAT LOWERCASE CAN BE easier to read than uppercase. -- richard  Date: 26 September 1980 19:08-EDT From: Richard L. Bryan To: JGA at MIT-MC, BUG-LISP at MIT-MC Extracted from the file MRG;TRIGI > : (DEFUN ATAN2 (YY X) (LET ((Y (ATAN YY X))) (IF (MINUSP YY) (-$ Y 6.28318531) Y)))  Date: 26 SEP 1980 1834-EDT From: JGA at MIT-MC (John G. Aspinall) To: (BUG LISP) at MIT-MC CC: JGA at MIT-MC In Lisp (atan y x) returns answers in the range 0 to 2*pi. But in Macsyma atan2(y,x); returns answers in the range -pi to pi. I think that (a) the two should be consistent, and (b) Macsyma is doing the right thing since it includes the entire principal branch of the function. I realize that a change like this might break some code, so can I get the Macsyma-Lisp version from anywhere, so I can load it with my code? (I'm writing a function for use in Macsyma so there won't be any extra space taken up anyway.)  Date: 26 September 1980 13:46-EDT From: George J. Carrette To: dlw at MIT-AI cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC Date: 26 September 1980 12:17-EDT From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI To: GJC cc: BUG-LISP, BUG-LISPM, MACSYMA-I Date: 26 September 1980 09:40-EDT From: George J. Carrette To: JPG at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC I think its a bit of a crock that destructuring is supported in Defmacro but not in Defun, for the following reason: many times one writes auxiliary functions which are also syntactic in the way they take their arguments. If somebody writes (defun foo ((a b)) ...) it doesn't mean they are violating data-abstractions. Of course, they MIGHT be violating data abstractions. So, when are we going to see a more general destructuring and binding mechanism, one that can handle more than just lists? -gjc It is not a crock. It is intentional. You seem to not understand the philosophical basis of what is going on here. The thing after the macro name in a "defmacro" form is NOT an argument list. The thing after the function name in a "defun" form IS an argument list. The two are totally different and have nothing to do with each other. Functions take arguments; macros don't take arguments. Functions compute; macros translate. A translator's job usually is to take the structure apart and put it back together with some new stuff in a different way. A computer's job is to take several objects, compute upon them, and produce side effects and a result. If the computation done by the computer just happens to include taking CARs and CDRs of the objects it is passed, that just happens to be what one function is doing, and has nothing to do with functions in general. That is why LispM defuns do not have "destructuring lambda lists", and why I belive they should not. Come come now. "you seem to not understand the philosphical basis". I know this is a sore spot, but such attacks! The case in point happens to be the functions which do macsyma->lisp translation, and in fact they do translation, and take input in a syntactic manner just like DEFMACRO. O.K. It may be a crock that one even needs to do macsyma->lisp translation, but thats another story. -gjc  Date: 26 September 1980 12:17-EDT From: Daniel L. Weinreb Sender: dlw at CADR2 at MIT-AI To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC Date: 26 September 1980 09:40-EDT From: George J. Carrette To: JPG at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC I think its a bit of a crock that destructuring is supported in Defmacro but not in Defun, for the following reason: many times one writes auxiliary functions which are also syntactic in the way they take their arguments. If somebody writes (defun foo ((a b)) ...) it doesn't mean they are violating data-abstractions. Of course, they MIGHT be violating data abstractions. So, when are we going to see a more general destructuring and binding mechanism, one that can handle more than just lists? -gjc It is not a crock. It is intentional. You seem to not understand the philosophical basis of what is going on here. The thing after the macro name in a "defmacro" form is NOT an argument list. The thing after the function name in a "defun" form IS an argument list. The two are totally different and have nothing to do with each other. Functions take arguments; macros don't take arguments. Functions compute; macros translate. A translator's job usually is to take the structure apart and put it back together with some new stuff in a different way. A computer's job is to take several objects, compute upon them, and produce side effects and a result. If the computation done by the computer just happens to include taking CARs and CDRs of the objects it is passed, that just happens to be what one function is doing, and has nothing to do with functions in general. That is why LispM defuns do not have "destructuring lambda lists", and why I belive they should not.  Date: 26 September 1980 09:40-EDT From: George J. Carrette To: JPG at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, MACSYMA-I at MIT-MC Date: 26 SEP 1980 0517-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: GJC cc: (BUG LISPM), (BUG LISP), MACSYMA-I I distinctly remember CWH saying it was ok to use this sort of argument destructuring a few months back when BMT first used it. Now you say not to use it. What gives? The compile-time environment was messed up in some way. The extra stuff to allow destructuring in defun's was not loaded. I think its a bit of a crock that destructuring is supported in Defmacro but not in Defun, for the following reason: many times one writes auxiliary functions which are also syntactic in the way they take their arguments. If somebody writes (defun foo ((a b)) ...) it doesn't mean they are violating data-abstractions. Of course, they MIGHT be violating data abstractions. So, when are we going to see a more general destructuring and binding mechanism, one that can handle more than just lists? -gjc  Date: 26 SEP 1980 0517-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: GJC at MIT-MC CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, MACSYMA-I at MIT-MC MACSYM@MIT-MC 09/25/80 19:29:40 To: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, MACSYMA-I at MIT-MC In system 44.2, with microcode 692, on LISP Machine Ten: The lisp machine compiler error's out on functions which have argument destructuring. e.g. (DEFUN RATDERIVATIVE ((NUM . DENOM) VAR) (COND ((EQN 1 DENOM) (CONS (PDERIVATIVE NUM VAR) 1)) (T (SETQ DENOM (PGCDCOFACTS DENOM (PDERIVATIVE DENOM VAR))) (SETQ NUM (RATREDUCE (PDIFFERENCE (PTIMES (CADR DENOM) (PDERIVATIVE NUM VAR)) (PTIMES NUM (CADDR DENOM))) ;RATREDUCE ONLY NEEDS TO BE DONE WITH CONTENT OF GCD WRT VAR. (CAR DENOM))) (COND ((PZEROP (CAR NUM)) NUM) (T (RPLACD NUM (PTIMES (CDR NUM) (PEXPT (CADR DENOM) 2))))))))) ; pardon the example. Macsyma implementors: argument destructuring is not supported on all systems, and should probably not be used. I distinctly remember CWH saying it was ok to use this sort of argument destructuring a few months back when BMT first used it. Now you say not to use it. What gives?  Date: 25 SEP 1980 2119-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC Anybody know any reasons why using LEDIT should cause DDT breakpoints in a lisp job to act funny? I can try and duplicate the lossage if this is unknown to everybody, but I would rather not untangle the mess if it is a known screw.  Date: 25 SEP 1980 1929-EDT From: MACSYM at MIT-MC To: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, MACSYMA-I at MIT-MC In system 44.2, with microcode 692, on LISP Machine Ten: The lisp machine compiler error's out on functions which have argument destructuring. e.g. (DEFUN RATDERIVATIVE ((NUM . DENOM) VAR) (COND ((EQN 1 DENOM) (CONS (PDERIVATIVE NUM VAR) 1)) (T (SETQ DENOM (PGCDCOFACTS DENOM (PDERIVATIVE DENOM VAR))) (SETQ NUM (RATREDUCE (PDIFFERENCE (PTIMES (CADR DENOM) (PDERIVATIVE NUM VAR)) (PTIMES NUM (CADDR DENOM))) ;RATREDUCE ONLY NEEDS TO BE DONE WITH CONTENT OF GCD WRT VAR. (CAR DENOM))) (COND ((PZEROP (CAR NUM)) NUM) (T (RPLACD NUM (PTIMES (CDR NUM) (PEXPT (CADR DENOM) 2))))))))) ; pardon the example. Macsyma implementors: argument destructuring is not supported on all systems, and should probably not be used. -GJC  Date: 25 September 1980 16:53-EDT From: Alan Bawden Subject: For the record? To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, GJC at MIT-MC, GSB at MIT-MC, JONL at MIT-MC Date: 25 September 1980 13:40-EDT From: Kent M. Pitman Date: 24 September 1980 18:23-EDT From: Alan Bawden Date: 23 SEP 1980 1500-EDT From: KMP at MIT-MC (Kent M. Pitman) The behavior of *FUNCTION with a second arg seems to be ... ----- If the alternative is to document it. Why don't we just flush it? ----- Any seconds on ALAN's motion for flushing 2nd arg to *FUNCTION? Any discussion? ----- Well actually I was talking about flushing the entire funny-funarg feature.  Date: 25 September 1980 13:40-EDT From: Kent M. Pitman Subject: For the record? To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, GJC at MIT-MC, GSB at MIT-MC, JONL at MIT-MC Date: 24 September 1980 18:23-EDT From: Alan Bawden Date: 23 SEP 1980 1500-EDT From: KMP at MIT-MC (Kent M. Pitman) The behavior of *FUNCTION with a second arg seems to be ... ----- If the alternative is to document it. Why don't we just flush it? ----- Ahh, what a novel thought. I don't really mind anyone doing that either. I just want it made clear that I am going to try to document anything that is around in Lisp by default. So if it's going to happen, I plan to try documenting it. We simply can't have these obscure features that work like magic and which are passed by word of mouth ... Any seconds on ALAN's motion for flushing 2nd arg to *FUNCTION? Any discussion? -kmp  Date: 25 September 1980 12:07-EDT From: George J. Carrette Subject: For the record. To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, GSB at MIT-MC, JONL at MIT-MC, ALAN at MIT-MC If anyone wants to use something which has the functionality of *FUNCTION, yet compiles into good code, there is LIBMAX;CLOSE > I'll give a short example, (defclosure stack (com arg) ((sp 0) (array (*array nil t 50)) (dim 50) (undeflow (make-undeflow)) (overflow (make-overflow))) (caseq com (null (= sp 0)) (pop (setq sp (1- sp)) (if (= sp 0) (call underflow self)) (arraycall t array sp)) (push (setq sp (1+ sp)) (if (= sp dim) (call overflow self)) (setf (arraycall t array sp) arg) SELF))) (defclosure overflow (master) ((more-inc 10) (more-limit 5)) (if (= more-limit 0) (barf)) (setq more-limit (1- more-limit)) (IN-ENV-OF-STACK MASTER ; lexical scoping of variables of course! ; so if we want the variables of somebody we have ; to be explicit. (setq dim (+ dim more-inc)) (*rearray array dim))) (setq s (make-stack)) I use a macro CALL, so that calling these guys can be open compiled, (subrcall). That way I can use them for clipping-streams, 3d-transformation-streams, and other graphics applications. If you want to go through FUNCALL you can, just by setting up the USERHUNK things. However, I found FUNCALL to be too slow, changing the whole Programming Style. (Actually this was using the general CLASS stuff to do the dispatching, I don't know how much faster you can make it by writing your own hunk-dispatcher in midas). -gjc  Date: 24 September 1980 18:23-EDT From: Alan Bawden Subject: For the record? To: KMP at MIT-MC, BUG-LISP at MIT-MC cc: GJC at MIT-MC, GSB at MIT-MC, JONL at MIT-MC Date: 23 SEP 1980 1500-EDT From: KMP at MIT-MC (Kent M. Pitman) The behavior of *FUNCTION with a second arg seems to be compatible with an upward funarg type of behavior -- in XLISP, of course, where things are working. Note that SETQ'ing a variable that is in the closure affects only that copy of the closure, and not the variable on the stack of which it is a copy -- this is IFF a second arg was given. If the second arg is given, the funarg is downward only and SETQ's will assign to the variable in the actual environ in which the closure was created. I don't know if this is how things ought to be, but this is how I will document it until/- unless I get word that someone is changing this behavior. If the alternative is to document it. Why don't we just flush it?  BEN@MIT-ML 09/24/80 15:27:14 Re: GRIND mangles end-of-line comments To: (BUG LISP) at MIT-ML In TOPS-10 MACLISP at Tufts (though I suspect elsewhere, too), GRINDing a file that includes end-of-line comments frequently puts the comments on the following line, unprotected by semi-colons. When this is loaded into LISP, we get lots of undefined value errors. (At installations that could run EMACS, no one would have to run GRIND, but . . .) Ben  Date: 23 September 1980 23:27-EDT From: Mark L. Miller Subject: MacLISP's Floating point To: JONL at MIT-MC cc: KEN at MIT-AI, GJS at MIT-AI, PHW at MIT-AI, TBlocker at BBNA, MMiller at BBNA, ben at MIT-ML, BUG-LISP at MIT-MC, BRoberts at BBNC Please see my comments on the **'d item below ... Date: 9 SEP 1980 0225-EDT From: JONL at MIT-MC (Jon L White) Date: 8 September 1980 14:03-EDT From: Benjamin Kuipers TOPS-10 MACLISP still has the problem of using KA-10 floating point instructions, which must be software simulated on the Tufts KL-10. Are there any plans to fix this? Not that I know of. Several other people have complained about this -- especially Ken Kahn who is trying to use MacLISP on a Swedish TOPS-10 that apparently doesn't support much in hte way of ** compatibility -- but there's just not a lot of "steam" here on our ** side to maintain the TOPS-10 version. Hopefully, some combination ** of TOPS-10 MacLISP users could delve into these things? (the CMUA crew, and maybe someone from Tufts?). I hate to criticize, since I know everyone there as friends and know that they do the best that they can, given human time limitations. Moreover, the result of years of software development work has been freely distributed, and for this we should all be grateful. But this situation, which I will describe as "The Inferiority of MacLisp Support on non-I.T.S. Systems" is a very serious problem for MacLisp AND THUS (if you believe, as I do, that it represents the future whereas InterLisp represents the past) FOR THE AI COMMUNITY AT LARGE. The documentation situation is equally embarrassing for MacLisp advocates. Byron and I, here at TI, have tried hard to "sell" MacLisp, but due to better documentation and 20X support, INTERLISP may win here in the end. ("Hopefully you users will do it" is, unrealistic outside of the university setting -- although we ARE TRYING to bootleg some Tops-20 improvements to MacLisp, like cursorpos and such.) This is particularly sad since we are trying to buy (indeed may be within days of ordering) LISPM's. Those of you who have only lived in the I.T.S. world cannot appreciate just how inferior MacLisp is on other operating systems, relative to its state on I.T.S. Given the number of sites running I.T.S. (!) this seems a bit parochial, even if understandable from the MIT point of view. I don't know what the right answer is, or how to improve the situation. But ignoring it doesn't help. One possible solution might be to propagate I.T.S. along with Emacs and MacLisp. What is the legal status of this? Can any site with a 10/20 choose to run that instead (not just universities or just MIT)? Who would I ask, to get a tape? What special hardware configurations, if any, would be required? What about updates? Would it mean no further support from either DEC or maintenance houses when things crash? SUPPOSE WE BOUGHT ALL FUTURE 10/20-class MACHINES FROM FOONLY, INC., INSTEAD OF DEC? Could THEY supply I.T.S., and will they help out when an I.T.S.-based machine crashes? Or, is there any chance that M.I.T. will move over to Tops-20 release N, after most of the good features of I.T.S. get stolen by DEC? The version from CMU, with multi-forking and PCL commands, release 4, is pretty nice; in some ways nicer (certainly friendlier to learn) than I.T.S. Mostly what it lacks is operating system level display support -- each application (like Emacs) must reinvent the wheel. Please accept these comments as constructive feedback. For now, we will continue to try to improve the Tops-20 user environment; we may even attempt a manual on the scale of the recent UCI document. On the other hand, this task seems so ominous for a new group that we may well have to go over to INTERLISP in order to get some things running to show off to management. At the end of the year, we can't just say "we wrote a manual for LISP and fixed some bugs specific to the Tops-20 version of our favorite dialect". If you have other suggestions, they'd be welcome. Regards, Mark  Date: 24 SEP 1980 0017-EDT From: MOON at MIT-MC (David A. Moon) Subject: Cursorpos on XX Losing To: KMP at MIT-MC, MILLER at MIT-AI, VINOD at MIT-XX CC: (BUG LISP) at MIT-MC I should point out that the experimental monitor currently running on XX has display terminal support in it. I believe this isn't ready for users to try yet, Mike Travers is working on finishing it.  Date: 23 September 1980 23:35-EDT From: Mark L. Miller Subject: Cursorpos on XX Losing To: VINOD at MIT-XX, KMP at MIT-MC cc: MOON at MIT-MC, BUG-LISP at MIT-MC Date: 8 September 1980 23:48-EDT From: Kent M. Pitman Maclisp on XX does not assume your terminal to be printing. It simply does not support the multiplicity of different possible terminal types. The Twenex operating system in its current form does not support a virtual terminal display protocol, and as such will not support CURSORPOS. The only alternative, that taken by Teco and other programs, is for Maclisp to understand how to CURSORPOS on whatever type terminal you have. No one has been willing to spend the time coding this up, so you pretty much lose. -kmp We now have MacLisp cursorpos support for C100's, H19's (I think), Teleray's, and VT100's. It is really still too crufty to distribute, but with a little patience you can probably get that from us (TI) or from Jonl as soon as wee send him a tape (order of weeks or less till someone finds time to clean it up but it basically works). In fact we have some nice window-like hacks for the C100's, ala ATLO/LISPM/etc. Meanwhile, how about working on a generalized JSYS function, or ALLFILES, which we haven't gotten to yet? Regards, Mark  Date: 23 September 1980 22:28-EDT From: Daniel L. Weinreb Sender: DLW at CADR8 at MIT-AI Subject: DIGITP again, and again and again To: GSB at MIT-ML, nil at MIT-MC, BUG-lisp at MIT-MC I agree completely with Glenn.  Date: 23 SEP 1980 1834-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JM at MIT-MC, ERIC at MIT-EECS, LICK at MIT-XX (DEFUN FACTORIAL (X) (COND ((ZEROP X) 1) (T (* X (FACTORIAL (1- X)))))) This will behave like the description of the bug report we received from JM. The bug just stems from the fact that "*" is the fixnum-only multiplication operator for Maclisp. It is defined to do whatever the machine hardware integer multiply does and to not err if overflow occurs. As a result, you experience wrap-around as your number goes out of bounds. The solution is to use TIMES, which will be careful about overflow and help you into the bignum range. -kmp  Date: 23 SEP 1980 1751-EDT From: JONL at MIT-MC (Jon L White) Subject: DESCRIBE To: (BUG LISP) at MIT-MC in the EXTEND stuff, the function DESCRIBE fails to put spaces between the applicable methods, resulting in a not-so-readable printout.  Date: 23 SEP 1980 1500-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: For the record To: (BUG LISP) at MIT-MC CC: GJC at MIT-MC, KMP at MIT-MC, GSB at MIT-MC, JONL at MIT-MC The behavior of *FUNCTION with a second arg seems to be compatible with an upward funarg type of behavior -- in XLISP, of course, where things are working. Note that SETQ'ing a variable that is in the closure affects only that copy of the closure, and not the variable on the stack of which it is a copy -- this is IFF a second arg was given. If the second arg is given, the funarg is downward only and SETQ's will assign to the variable in the actual environ in which the closure was created. I don't know if this is how things ought to be, but this is how I will document it until/- unless I get word that someone is changing this behavior.  GSB@MIT-ML 09/23/80 14:47:24 To: (BUG LISP) at MIT-ML CC: RAMESH at MIT-ML It would be nice if i didn't have to tell people who want split-screen to work to have to xfile the following: :sl tyoflf/  camge d,fo.pgl(t) jrst tyof4 setzm at.lnn(t) aos at.pgn(t) jrst tyofff+3  Date: 23 September 1980 14:38-EDT From: Glenn S. Burke Subject: DIGITP again, and again and again To: Guy.Steele at CMU-10A, jonl at MIT-MC, nil at MIT-MC, BUG-lisp at MIT-MC Just to lend some balance to the pros, cons, and utilities of various definitions, i feel i should point out that the usage i have consistently wanted was whether the character in question was one of the characters 0-9. (For what it's worth, that fits the first definition given in my Webster's.) On the other hand, i have not been writing a general token reader, but i also doubt that most users will spend their time doing that. Looks to me like an optional second arg of the base, default 10., is the best choice. If nothing else, one should have powerful primitives for doing class tests on the character set, (alphabeticp, alphanumericp, digitp, etc; forgive me for not reviewing CHPROP), and these primitives should be independent of the parameters used by Lisp itself (ibase, readtable) so that they can be generally used in contexts where those parameters have no meaning.  Date: 23 SEP 1980 1439-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: GRINDEF To: (BUG LISP) at MIT-MC The variable GRINDEF should be SETQ-IF-UNBOUND'd or something like that rather than just SETQ'd when the GRIND package loads.  Date: 23 SEP 1980 1437-EDT From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, NIL at MIT-MC Date: 23 September 1980 14:21-EDT From: Kent M. Pitman I guess I don't see this possible-digitness as being interesting. . . . Just because you artificially cut things off at 26 or 36 doesn't really change anything. I hope you're not serious. Just in case youve missed it 1) DIGITP as currently construed is not just a predicate, but extracts the digits "weight" (in GLS's terminology); 2) "weight" extraction is a non-trivial operation (i.e., not just one or two machine instructions on your typical machine) because "A" and "a" are generally identified, and because the 36. digits are not necessarily in numerical order; 3) the VAX's natural machine base is 16 and the usual presentation of numbers in this base is a simple range-restriction of the 36-digit notion. Do you think you have a better character standard?  Date: 23 SEP 1980 1421-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC, GLS at MIT-MC, JAR at MIT-MC I guess I don't see this possible-digitness as being interesting. "[" is a possible digit in Base-37. Eg, in teco, doing 37u..E37= will display a '[' ... If you pick a large enuf base, you have to increase your range of characters to represent digits. Something that just tells you what digit a character would represent is no more a predicate than the ever-controversial TYPEP 'predicate'. Just because you artificially cut things off at 26 or 36 doesn't really change anything.  Date: 23 SEP 1980 1410-EDT From: JONL at MIT-MC (Jon L White) Subject: Character set division into "digits" To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC, NIL at MIT-MC Date: 22 September 1980 1525-EDT (Monday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: DIGITP Message-Id: <22Sep80 152518 GS70@CMU-10A> . . . [I have been considering changing CHPROP so that DIGITP would take an optional argument (default 10.) specifying the radix. Are there any objections to this --GLS] I've argued for a reader-independent notion of DIGITP, returning the digit's "weight" as you suggest, so that a *character set* standard can be proffered. Whether or not that predicate for "digitability" is called DIGITP is not much concern to me, but I would like to point out that that has been the definition in NIL;NEWFUN > for almost two years; furthermore, I'd sure hate to see that two-line, reader-useful function (DEFMACRO BASE-DIGITP (D &optional (B 10.) &aux (VAL (GENSYM))) `(LET ((,VAL (DIGITP ,D))) (AND ,VAL (< ,VAL ,B) ,VAL) fully displace the current DIGITP and thus wipe out all semblance of program-independence in the character standard.  Date: 23 September 1980 1057-EDT (Tuesday) From: Guy.Steele at CMU-10A To: jonl at MIT-MC, nil at MIT-MC, bug-lisp at MIT-MC Subject: DIGITP again, already Message-Id: <23Sep80 105729 GS70@CMU-10A> From: JONL at MIT-MC (Jon L White) ... It looks as if you are still confusing the (static) division of the alphabet with the (dynamic) action of the reader; the major point that you've apparently missed is that a typical reader has to do something like the following piece of code anyhow (at least if its input radix is variable): (AND (SETQ VAL (DIGITP CHAR)) (< VAL )) [It is for this very reason that I wanted to give DIGITP an optional argument defaulting to 10. Then (DIGITP x) corresponds to the "naive" notion of x being a digit--namely one of the characters in the set {0,1,2,3,4,5,6,7,8,9}--making it very easy for the novice to use this extremely common case; while (DIGITP x IBASE) is precisely what the reader needs. (Actually, it would cause 8 not to be a digit in octal radix, which is actually "a right thing" if not "the right thing", but we are all used to abusing that--sigh.) I don't think anyone is ever really interested in whether a given character can EVER be a digit, under any conceivable circumstances--but perhaps (DIGIT x ()) could serve that purpose. Finally, ought (DIGITP x 'ROMAN) do anything useful?? --GLS]  Date: 22 September 1980 23:27-EDT From: Kent M. Pitman Subject: [Forwarded mail] To: BUG-LISP at MIT-MC Date: 22 Sep 1980 1811-EDT From: ERIC at MIT-EE To: jonl, kmp Re: our maclisp seems to be broken Guys: Moses and Lick were in today, and while hacking around found what seems to be a gross fixnum=>bignum conversion error...just write a garden variety factorial routine and see...note that this is maclisp not ulisp. love eric  Date: 22 September 1980 1525-EDT (Monday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: DIGITP Message-Id: <22Sep80 152518 GS70@CMU-10A> From:RWK Bletch, (DIGITP #/q) claims 'q' is a digit. I have commented out the two offending lines of code. I note in CHPROP that JAR has objected to this behaviour as well. I did not make it take a radix argument, as JAR suggests, but I would assert that it should NOT assume the radix is 26, and that it did so was a bug. [I have been considering changing CHPROP so that DIGITP would take an optional argument (default 10.) specifying the radix. Are there any objections to this --GLS]  Date: 22 SEP 1980 1655-EDT From: moon at MIT-MC (David A. Moon) Sent-by: ___024 at MIT-MC Subject: DIGITP To: (BUG LISP) at MIT-MC So make it look at the special variable IBASE.  Date: 22 SEP 1980 1640-EDT From: JONL at MIT-MC (Jon L White) Subject: Usage of DIGITP To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, NIL at MIT-MC Date: 22 September 1980 16:21-EDT From: Kent M. Pitman I find (DIGITP #/q) => T extremely unaesthetic. . . . So do I, since NIL^K seems to think that (DIGITP #/q) and (DIGITP ~q) evaluate to the same thing -- namely 26. It's easier to understand the purpose of this function when you know what its action is.  Date: 22 SEP 1980 1634-EDT From: JONL at MIT-MC (Jon L White) Subject: DIGITP To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, NIL at MIT-MC Date: 22 September 1980 16:21-EDT From: Kent M. Pitman Subject: DIGITP I find (DIGITP #/q) => T extremely unaesthetic. . . . The previous comment on DIGITP wasn't just a call for votes on aesthetics; also, it wasn't addressed to NIL, but since you've replied to NIL, then this not also is going there. It looks as if you are still confusing the (static) division of the alphabet with the (dynamic) action of the reader; the major point that you've apparently missed is that a typical reader has to do something like the following piece of code anyhow (at least if its input radix is variable): (AND (SETQ VAL (DIGITP CHAR)) (< VAL ))  Date: 22 September 1980 16:21-EDT From: Kent M. Pitman Subject: DIGITP To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, NIL at MIT-MC, GLS at MIT-MC, JAR at MIT-MC, RWK at MIT-MC I find (DIGITP #/q) => T extremely unaesthetic. The most commonly useful things should be the most accessible. If you make the most useful things the hardest to get at, then people will shy from the feature. Why can't (DIGITP #/A) return () and (DIGITP #/A 16.) return non-()? This could compile optimally for both, but it makes the most useful case the most accessible one. I have *never* wanted q to be a digit. I have rarely wanted A to be a digit (in fact only once in the last 3 years). Typing a 10. in the second arg position or having a DECIMAL-DIGITP (both of which involve *more* typing than the 1 arg case) is ridiculous. -kmp  Date: 22 SEP 1980 1344-EDT From: JONL at MIT-MC (Jon L White) Subject: DIGITP To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, GLS at MIT-MC, JAR at MIT-MC Date: 21 September 1980 05:58-EDT From: Robert W. Kerns Subject: DIGITP in NILCOM;STRING Bletch, (DIGITP #/q) claims 'q' is a digit. I have commented out the two offending lines of code. I note in CHPROP that JAR has objected to this behaviour as well. I did not make it take a radix argument, as JAR suggests, but I would assert that it should NOT assume the radix is 26, and that it did so was a bug. Note that CHPROP had two differing definitions of DIGITP (hence you can't refer to that as a standard), but no requirement that DIGITP be defined only to accept decimal digits. More importantly, the former notion of DIGITP (which I've restored) permits one to ignore the question of whether or not supra-decimal digits follow "9" in the ascii collating sequence. Thus, the correct definition of DIGITP permits one then to write DECIMAL-DIGITP as a simple variant, but your more-limiting definition is of no help in writing the general DIGITP. The question of radix is quite misplaced here -- DIGITP only identifies the portion of the alphabet which **can be** used as digits, not those which are within the bounds of the current (dynamically changing) input base. By the bye, the NIL syntax provides for input radices up to 36., not just up to 26.  Date: 22 September 1980 13:23-EDT From: Richard L. Bryan Subject: SFA reading gets stale data To: KMP at MIT-MC, GJC at MIT-MC, BUG-LISP at MIT-MC Of course, READ and GENSYM share the same PNBUF. The GENSYM done by the macro-expansion of the POP clobbers READ's buffer with each char tyi'ed. Date: 22 SEP 1980 1258-EDT From: KMP,GJC at MIT-MC Sent-by: GJC at MIT-MC (DEFUN MY-SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYI UNTYI)) ((TYI) (POP (SFA-GET SELF 0.))) ((UNTYI) (COMMENT I DON/'T REALLY CARE)) ((INIT) (SETF (SFA-GET SELF 0.) DATA)) (T (ERROR "Unsupported call" (LIST 'SFA-CALL SELF OP DATA))))) (DEFUN MAKE-AN-SFA (DATA) (LET ((SFA (SFA-CREATE 'MY-SFA-HANDLER 1. "My SFA"))) (SFA-CALL SFA 'INIT (EXPLODEN DATA)) SFA)) (SETQ A (MAKE-AN-SFA "ABC ")) (READ A) => G00 (GENSYM (ASCII 2.)) (SETQ A (MAKE-AN-SFA "ABC ")) (READ A) => /^B00 (SETQ A (MAKE-AN-SFA "ABCDEFGHIJKLMNOPQRSTUVWXYZ ")) (READ A) => /^B0043FGHIJKLMNOPQRSTUVWXYZ Where is this coming from? Naturally it does manifest itself in 'real' programs as well. -kmp ps GJC says there is a similar effect with READLINE.  Date: 22 SEP 1980 1322-EDT From: JONL at MIT-MC (Jon L White) Subject: Bignum bug? To: FH at MIT-MC CC: (BUG LISP) at MIT-MC Date: 21 September 1980 20:44-EDT From: Fred W. Helenius If you compile the following function (which is intended to add two . . . (defun add-rats (a b) (let (((c . d) a) ((e . f) b)) (let ((hcf (gcd d f))) (cons (plus (times c (quotient f hcf)) (times e (quotient d hcf))) (times (quotient d hcf) f))))) (setq exp '(apply 'add-rats '((716087101460491 . 1041496283283456) (103334765625 . 197568495616)))) . . . I suppose this is a bug. The function works fine in the interpreter, and compiled for most arguments. For your convenience, the function definition, the result of its compilation, and the definition of exp may be found in FH;BUG DEFN, BUG FASL, and BUG EXP, respectively. I took the liberty of changing your BUG EXP file so that the bug would be visible in LISP as well as MACSYMA (i.e., I added the necessary decimal point after the numbers). This result is actually due to a bug in LISP, and I've just patched it (GCD was clobbering a random register).  Date: 22 SEP 1980 1301-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: Bignum bug? To: (BUG LISP) at MIT-MC Either COMPLR needs to know that GCD can cause C to be altered, or else the routine at BNLWFL shouldn't alter C. BNLWFL gets called from GCDBG4+12 ---- Date: 21 SEP 1980 2044-EDT From: FH at MIT-MC (Fred W. Helenius) If you compile the following function (which is intended to add two rational numbers given in the form (numerator . denominator)), load it into LISP, and do (eval exp) where exp is given below, LISP produces the error still further below: (defun add-rats (a b) (let (((c . d) a) ((e . f) b)) (let ((hcf (gcd d f))) (cons (plus (times c (quotient f hcf)) (times e (quotient d hcf))) (times (quotient d hcf) f))))) (setq exp '(apply 'add-rats '((716087101460491 . 1041496283283456) (103334765625 . 197568495616)))) ;(7577) NON-NUMERIC VALUE ;BKPT WRNG-TYPE-ARG I suppose this is a bug. The function works fine in the interpreter, and compiled for most arguments. For your convenience, the function definition, the result of its compilation, and the definition of exp may be found in FH;BUG DEFN, BUG FASL, and BUG EXP, respectively.  Date: 22 SEP 1980 1258-EDT From: KMP,GJC at MIT-MC Sent-by: GJC at MIT-MC Subject: SFA reading gets stale data To: (BUG LISP) at MIT-MC (DEFUN MY-SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYI UNTYI)) ((TYI) (POP (SFA-GET SELF 0.))) ((UNTYI) (COMMENT I DON/'T REALLY CARE)) ((INIT) (SETF (SFA-GET SELF 0.) DATA)) (T (ERROR "Unsupported call" (LIST 'SFA-CALL SELF OP DATA))))) (DEFUN MAKE-AN-SFA (DATA) (LET ((SFA (SFA-CREATE 'MY-SFA-HANDLER 1. "My SFA"))) (SFA-CALL SFA 'INIT (EXPLODEN DATA)) SFA)) (SETQ A (MAKE-AN-SFA "ABC ")) (READ A) => G00 (GENSYM (ASCII 2.)) (SETQ A (MAKE-AN-SFA "ABC ")) (READ A) => /^B00 (SETQ A (MAKE-AN-SFA "ABCDEFGHIJKLMNOPQRSTUVWXYZ ")) (READ A) => /^B0043FGHIJKLMNOPQRSTUVWXYZ Where is this coming from? Naturally it does manifest itself in 'real' programs as well. -kmp ps GJC says there is a similar effect with READLINE.  Date: 21 SEP 1980 2044-EDT From: FH at MIT-MC (Fred W. Helenius) Subject: Bignum bug? To: (BUG LISP) at MIT-MC If you compile the following function (which is intended to add two rational numbers given in the form (numerator . denominator)), load it into LISP, and do (eval exp) where exp is given below, LISP produces the error still further below: (defun add-rats (a b) (let (((c . d) a) ((e . f) b)) (let ((hcf (gcd d f))) (cons (plus (times c (quotient f hcf)) (times e (quotient d hcf))) (times (quotient d hcf) f))))) (setq exp '(apply 'add-rats '((716087101460491 . 1041496283283456) (103334765625 . 197568495616)))) ;(7577) NON-NUMERIC VALUE ;BKPT WRNG-TYPE-ARG I suppose this is a bug. The function works fine in the interpreter, and compiled for most arguments. For your convenience, the function definition, the result of its compilation, and the definition of exp may be found in FH;BUG DEFN, BUG FASL, and BUG EXP, respectively.  Date: 21 SEP 1980 0558-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: DIGITP in NILCOM;STRING To: (BUG LISP) at MIT-MC, GLS at MIT-MC, JAR at MIT-MC Bletch, (DIGITP #/q) claims 'q' is a digit. I have commented out the two offending lines of code. I note in CHPROP that JAR has objected to this behaviour as well. I did not make it take a radix argument, as JAR suggests, but I would assert that it should NOT assume the radix is 26, and that it did so was a bug.  Date: 20 SEP 1980 1441-EDT From: JONL at MIT-MC (Jon L White) Subject: +INTERNAL-/'-MACRO To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 09/19/80 22:46:16 Re: fixing things It seems that +INTERNAL-/'-MACRO now calls a read entry which calls the read hook. . . . The read hook has semantics of being a "toplevel" call and is allowed to do things like flush the character trailing a character. This isn't right for a recursive read. It's not entirely clear what the purpose of this read "hook" is -- the toplevel hook is another feature (READ-*-EVAL-PRINT and *-READ-EVAL-PRINT) -- and furthermore, its not clear that we've resolved the READ-PRESERVE-DELIMITERS problem for maclisp; but your comment seems right, that READ rather than (LAMBDA (X) (COND (READ (FUNCALL READ X)) ((READ X)))) is what is desired. So I've again patched it accordingly.  GSB@MIT-ML 09/19/80 22:47:39 Re: correction To: (BUG LISP) at MIT-ML that should have read "flush the character trailing an atom"  GSB@MIT-ML 09/19/80 22:46:16 Re: fixing things To: (BUG LISP) at MIT-ML It seems that +INTERNAL-/'-MACRO now calls a read entry which calls the read hook. As i remember it, it was requested that it call the read function (ie *READ). The read hook has semantics of being a "toplevel" call and is allowed to do things like flush the character trailing a character. This isn't right for a recursive read.  Date: 19 September 1980 16:59-EDT From: Kent M. Pitman Subject: Bad GRINDEF/TRACE interaction To: BUG-LISP at MIT-MC cc: SRF at MIT-MC, DANIEL at MIT-MC (DEFUN F (X) X) ; Define a function (GRINDEF F) ; Grinds just fine (TRACE F) ; Traces just fine (GRINDEF F) ; Grinds just fine with note that it's traced (DEFUN F (Y) Y) ; Redefine without untracing (GRINDEF) ; Claims traced. Doesn't grind (UNTRACE F) ; Untrace doesn't break the F(y) definition (GRINDEF F) ; Grinds just fine as F(y) ----- If there is a more recent definition than the traced definition, GRINDEF should allow that definition to supersede the trace information. -kmp  Date: 18 September 1980 17:54-EDT From: Glenn S. Burke Subject: LDB To: ALAN at MIT-MC, BUG-LISP at MIT-MC ; The following goes into the autoloadable LODBYT file, or in Lisp itself. (lap-a-list '((lap ldb subr) (push p (% 0 0 fix1)) (jsp t fxnv1) (jsp t fxnv2) (caia) (entry +internal-ldb subr) (push p (% 0 0 fix1)) (hrlz d 0 a) (lsh d 6) (tlo d b) (ldb tt d) (popj p) nil)) ; You might note that +INTERNAL-LDB has the same number of instructions as ; *LDB. If it were lisp-internal, it could have an ACS property of 2. ; The following goes into a file which gets loaded into the compiler ; (presumably it would be pre-loaded): (defun ldb-hacker (form) (let* (((ppss n) (cdr form)) (foo (lsb:constantp ppss))) (cond ((or (null foo) (not (fixp foo))) `(+internal-ldb ,ppss ,n)) (t `(boole 1 (lsh n ,(- (lsh foo -6.))) ,(ldb-make-mask foo)))))) (push '(ldb . ldb-hacker) macrolist) (defun ldb-make-mask (ppss) (lsh -1 (- (boole 1 ppss #o77) 36.))) This division keeps the interpreter from bloating (after all, all it needs is a subr, not code which knows how to compile LDB) and lets one have easy LDBs hacked nicely by the compiler. If the compiler were ever to hack LDB then you just flush the compile-time file. P.s: LSB:CONSTANTP returns the constant if the thing is a constant, with (QUOTE number) being canonicalized to the number. As a side comment, it is fine to have things be macros, but if there are lots of them they cause the size of interpreted code to blow up badly, increasing paging and gc time, and maybe making one run out of core.  Date: 18 September 1980 16:56-EDT From: Alan Bawden To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 SEP 1980 1641-EDT From: JONL at MIT-MC (Jon L White) So your questions re *LDB are just wasting time and space in the BUG-LISP channel? And you still don't understand how trivial *LDB is now? Look, If we had all read and understood my original message then there wouldn't need to be all this flaming. Serious points: 1) Does the existence of your LDB subr mean that you don't get the efficiency of the BOOLE which the macro generates for constant ? Well I am willing to give that up for the moment, given that the compiler will open-code it someday. 2) Will your LDB be schrod when the compiler open-codes LDB? When the compiler open-codes LDB, then I won't need one of my own!  Date: 18 SEP 1980 1641-EDT From: JONL at MIT-MC (Jon L White) Subject: Academic questions on *LDB and *DBP To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 16:30-EDT From: Alan Bawden . . . I don't have to worry about it. I LAPed up a LDB and a DPB of my own a long time ago and I still don't have any reason to flush them. What I am amazed by is the totally hairy "stop gap" measures that don't gain anything! So your questions re *LDB are just wasting time and space in the BUG-LISP channel? And you still don't understand how trivial *LDB is now? Serious points: 1) Does the existence of your LDB subr mean that you don't get the efficiency of the BOOLE which the macro generates for constant ? 2) Will your LDB be schrod when the compiler open-codes LDB?  Date: 18 September 1980 16:30-EDT From: Alan Bawden Subject: Talking to a rock. To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 SEP 1980 1618-EDT From: JONL at MIT-MC (Jon L White) Date: 18 September 1980 16:02-EDT From: Alan Bawden Subject: (LDB 0203 Y) versus (LDB X Y) . . . (ldb 0203 y) expands into (boole 1 (lsh y -2) 7) (ldb x y) expands into (*ldb (lsh x 30) y) I don't see anything that looks like (*ldb ppss_30 ...) so I don't see how anything has been saved. Are you asleep today! How do you think the "7" got generated in the line "(ldb 0203 y) expands into (boole 1 (lsh y -2) 7)" What difference does it make where the 7 comes from?? *LDB is not a user-available function -- it exists only as a stop-gap until the compiler open-codes LDB. (Although it is true now that *LDB is never handed a "constant" arg, that's not how it was when *LDB was first coded -- the conversion to BOOLE is a recent innovation -- but the whole existence of *LDB depends on whether or not the compiler knows how to open-code LDB). Anyway, why are you worrying about this -- is it slowing your program down by 0.25%? I don't have to worry about it. I LAPed up a LDB and a DPB of my own a long time ago and I still don't have any reason to flush them. What I am amazed by is the totally hairy "stop gap" measures that don't gain anything!  Date: 18 SEP 1980 1618-EDT From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 16:02-EDT From: Alan Bawden Subject: (LDB 0203 Y) versus (LDB X Y) . . . (ldb 0203 y) expands into (boole 1 (lsh y -2) 7) (ldb x y) expands into (*ldb (lsh x 30) y) I don't see anything that looks like (*ldb ppss_30 ...) so I don't see how anything has been saved. Are you asleep today! How do you think the "7" got generated in the line "(ldb 0203 y) expands into (boole 1 (lsh y -2) 7)" *LDB is not a user-available function -- it exists only as a stop-gap until the compiler open-codes LDB. (Although it is true now that *LDB is never handed a "constant" arg, that's not how it was when *LDB was first coded -- the conversion to BOOLE is a recent innovation -- but the whole existence of *LDB depends on whether or not the compiler knows how to open-code LDB). Anyway, why are you worrying about this -- is it slowing your program down by 0.25%?  Date: 18 September 1980 16:02-EDT From: Alan Bawden Subject: (LDB 0203 Y) versus (LDB X Y) To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 SEP 1980 1543-EDT From: JONL at MIT-MC (Jon L White) Date: 18 September 1980 13:54-EDT From: Alan Bawden Subject: *LDB, *DBP In fact when X is a constant (LDB X Y) expands into (BOOLE 1 (LSH Y ...) ...) So where is the gain? In fact I would argue that the right solution You must have missed my comment about the case worth optimizing -- namely one like (LDB 0203 Y) as opposed to (LDB X Y). If you did examine the former case, then I suggest you also expand the latter and compare the differences. (ldb 0203 y) expands into (boole 1 (lsh y -2) 7) (ldb x y) expands into (*ldb (lsh x 30) y) I don't see anything that looks like (*ldb ppss_30 ...) so I don't see how anything has been saved. If you are going to turn constants into lsh and boole so that the compiler can code them, then you will NEVER be handing a pre-shifted constant into *ldb, you will ALWAYS be doing a lsh before calling *ldb. Come to think of it, if we are going to do things this way why doesn't dpb with a constant ppss also expand into some booles and lshes?  Date: 18 SEP 1980 1545-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: (setf (fixnum-identity ...) ...) To: (BUG LISP) at MIT-MC you made (setf (fixnum-identity x) y) expand into (fixnum-identity (setf x y)). why not (setf x (fixnum-identity y))???  Date: 18 SEP 1980 1543-EDT From: JONL at MIT-MC (Jon L White) Subject: (LDB 0203 Y) versus (LDB X Y) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 13:54-EDT From: Alan Bawden Subject: *LDB, *DBP In fact when X is a constant (LDB X Y) expands into (BOOLE 1 (LSH Y ...) ...) So where is the gain? In fact I would argue that the right solution You must have missed my comment about the case worth optimizing -- namely one like (LDB 0203 Y) as opposed to (LDB X Y). If you did examine the former case, then I suggest you also expand the latter and compare the differences.  Date: 18 SEP 1980 1538-EDT From: JONL at MIT-MC (Jon L White) Subject: SUBLIS To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 15:28-EDT From: Alan Bawden . . . The "feature" isn't much of a feature since: 1) SUBLIS isn't careful to not remove SUBLIS properties that it didn't put there. 2) It only works to put a SUBLIS property on the front of the property list. 3) It doesn't work to say (sublis nil ...). (It doesn't look at ANY properties in that case.) I think you misread my previous reply - I mentioned only that at one time (i.e. prior to about 1972) this had been intended to be a feature; that intention was never carried out.  Date: 18 September 1980 15:28-EDT From: Alan Bawden To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 SEP 1980 0951-EDT From: JONL at MIT-MC (Jon L White) Date: 18 September 1980 02:35-EDT From: Alan Bawden I was looking at how SUBLIS worked... . . . Suppose I went nuts trying to figure out why the SUBLIS returned the wrong answer, and why my property lists were being REMPROPed behind my back. I suppose this comment has an element of truth in it (e.g., "went nuts ..."); but the "clever" version of SUBLIS dates back to LISP 1.5 days, and at one time was a "feature" that you could put your own SUBLIS properties. When the Moonual was written these features didn't get documented, so I suppose it would be good to use some other property name now. The "feature" isn't much of a feature since: 1) SUBLIS isn't careful to not remove SUBLIS properties that it didn't put there. 2) It only works to put a SUBLIS property on the front of the property list. 3) It doesn't work to say (sublis nil ...). (It doesn't look at ANY properties in that case.) If you are going to go to the trouble to use some other property, why not go all the way and rewrite it to not use property lists at all! (More efficient in the common, small-alist case.)  Date: 18 September 1980 13:54-EDT From: Alan Bawden Subject: *LDB, *DBP To: JONL at MIT-MC cc: BUG-LISP at MIT-MC Date: 18 SEP 1980 0947-EDT From: JONL at MIT-MC (Jon L White) Date: 18 September 1980 04:06-EDT BTW I notice that the functions *ldb and *dpb take the byte specifcation shifted left by 30 (octal). This causes (ldb x y) to expand into (*ldb (lsh x 30) y). This seems pretty gratuitous to me since it only takes one instruction to have *ldb and *dpb do the lsh themselves. (*ldb contains an unnecessary move anyway!) *LDB and *DPB take a pre-shifted argument so that when, for example, "x" is a constant, the call becomes (*ldb _30 y), and the executable sequence then doesn't include the LSH; this in fact is the case worth optimizing. In fact when X is a constant (LDB X Y) expands into (BOOLE 1 (LSH Y ...) ...) So where is the gain? In fact I would argue that the right solution is to make LDB and DPB be subrs (you remember them? You can funcall them?) and have the compiler understand them (there is a LDB instruction...). This would be compatable as we could keep *ldb and *dpb araound.  Date: 18 September 1980 13:00-EDT From: Robert W. Kerns Subject: SETF of PROGN To: Guy.Steele at CMU-10A cc: BUG-LISP at MIT-MC Date: 18 September 1980 1232-EDT (Thursday) From: Guy.Steele at CMU-10A To: bug-lisp Re: SETF of PROGN While we are fixing bugs in SETF why not add the setf-x properties for fixnum and flonum-identity? And while you are at it you might also want to do PROGN: (setf (progn x) 12) = (setf x 12) [More generally, (setf (progn x1 x2 ... xn) 12) = (progn x1 x2 ... (setf xn 12)) -- Guy] My fix does handle (SETF (PROGN x1 x2 ... xn) v1), although it doesn't turn it into (PROGN x1 x2 ... (SETF xn 12)). There are severe modularity problems with performing this transformation, but instead turns it into a LAMBDA with the x1 ... xn-1 being passed in as arguments and ignored. It is not only SETF that is affected, but PUSH and POP and any user routines (like INCREMENT) which use +INTERNAL-SETF-X-1 and friends to generate access and inversion with correct order and no duplication of side-effects. I have an idea for a way to do it, but it requires a lot more work and recompilation of everything in the world that does a DEFSETF. Fortunately, I think I can make SETF complain if an old DEFSETF is used. Also, I don't think anyone has written anything like INCREMENT that uses +INTERNAL-SETF-X-1, if so, they'll get a suprise. I don't know when I'll find the time to do this, however.  Date: 18 SEP 1980 1254-EDT From: JONL at MIT-MC (Jon L White) Subject: Why *LDB etc. To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 1244-EDT (Thursday) From: Guy.Steele at CMU-10A . . . Well, actually I don't see why this matters. In the interpreter you don't care, and the compiler is perfectly capable of figuring out that there is a constant there and pre-shifting it--indeed, it can optimize even better. I don't know exactly what code is produced for *LDB, but for (*LDB 0304 X) one might imagine the code (LDB TT (% 0 0 @ (SPECIAL X) 030400)) being generated. No shifts, and indeed 0304_30 doesn't exactly appear either. As it happens, the compiler knows absolutely nothing about LDB, *LDB etc. The only reason why this whole question came up is that ALAN was looking into the internals of things, and apparently didn't realize that *LDB was a stop-gap measure until the compiler open-codes LDB. Yea, someday.  Date: 18 September 1980 1244-EDT (Thursday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: *LDB, *DPB Message-Id: <18Sep80 124404 GS70@CMU-10A> From: JONL at MIT-MC (Jon L White) Date: 18 September 1980 04:06-EDT BTW I notice that the functions *ldb and *dpb take the byte specifcation shifted left by 30 (octal). This causes (ldb x y) to expand into (*ldb (lsh x 30) y). This seems pretty gratuitous to me since it only takes one instruction to have *ldb and *dpb do the lsh themselves. (*ldb contains an unnecessary move anyway!) *LDB and *DPB take a pre-shifted argument so that when, for example, "x" is a constant, the call becomes (*ldb _30 y), and the executable sequence then doesn't include the LSH; this in fact is the case worth optimizing. Well, actually I don't see why this matters. In the interpreter you don't care, and the compiler is perfectly capable of figuring out that there is a constant there and pre-shifting it--indeed, it can optimize even better. I don't know exactly what code is produced for *LDB, but for (*LDB 0304 X) one might imagine the code (LDB TT (% 0 0 @ (SPECIAL X) 030400)) being generated. No shifts, and indeed 0304_30 doesn't exactly appear either.  Date: 18 September 1980 1232-EDT (Thursday) From: Guy.Steele at CMU-10A To: bug-lisp at MIT-MC Subject: SETF of PROGN Message-Id: <18Sep80 123249 GS70@CMU-10A> While we are fixing bugs in SETF why not add the setf-x properties for fixnum and flonum-identity? And while you are at it you might also want to do PROGN: (setf (progn x) 12) = (setf x 12) [More generally, (setf (progn x1 x2 ... xn) 12) = (progn x1 x2 ... (setf xn 12)) -- Guy]  Date: 18 SEP 1980 0951-EDT From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 02:35-EDT From: Alan Bawden I was looking at how SUBLIS worked... . . . Suppose I went nuts trying to figure out why the SUBLIS returned the wrong answer, and why my property lists were being REMPROPed behind my back. I suppose this comment has an element of truth in it (e.g., "went nuts ..."); but the "clever" version of SUBLIS dates back to LISP 1.5 days, and at one time was a "feature" that you could put your own SUBLIS properties. When the Moonual was written these features didn't get documented, so I suppose it would be good to use some other property name now.  Date: 18 SEP 1980 0947-EDT From: JONL at MIT-MC (Jon L White) Subject: *LDB, *DBP To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 September 1980 04:06-EDT BTW I notice that the functions *ldb and *dpb take the byte specifcation shifted left by 30 (octal). This causes (ldb x y) to expand into (*ldb (lsh x 30) y). This seems pretty gratuitous to me since it only takes one instruction to have *ldb and *dpb do the lsh themselves. (*ldb contains an unnecessary move anyway!) *LDB and *DPB take a pre-shifted argument so that when, for example, "x" is a constant, the call becomes (*ldb _30 y), and the executable sequence then doesn't include the LSH; this in fact is the case worth optimizing.  Date: 18 September 1980 06:43-EDT From: Robert W. Kerns To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, GSB at MIT-MC Date: 18 September 1980 04:10-EDT From: Alan Bawden To: BUG-LISP While we are fixing bugs in SETF why not add the setf-x properties for fixnum and flonum-identity? And while you are at it you might also want to do PROGN: (setf (progn x) 12) = (setf x 12) -------- PROGN now works, although non-optimally. (SETF (progn (foo) (bar) (car (baz))) 'val) ==> ((LAMBDA (G0001 G0002 G0003 G0004) (PROGN G0001 G0002 (RPLACA G0003 G0004)) G0004) (FOO) (BAR) (BAZ) 'VAL) which produces 3 PUSHes and a combined POP. Tough shit. The case of a 1-argument PROGN is not hurt. FIXNUM-IDENTITY and FLONUM-IDENTITY are treated the same as PROGN, with FLONUM- or FIXNUM-IDENTITY taking the place of the PROGN above. Is it going to be a screw that the FIXNUM-IDENTITY guys are not moved outside the LAMBDAs? It's not easy to change.  Date: 18 SEP 1980 0410-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC While we are fixing bugs in SETF why not add the setf-x properties for fixnum and flonum-identity? And while you are at it you might also want to do PROGN: (setf (progn x) 12) = (setf x 12)  Date: 18 SEP 1980 0406-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC BTW I notice that the functions *ldb and *dpb take the byte specifcation shifted left by 30 (octal). This causes (ldb x y) to expand into (*ldb (lsh x 30) y). This seems pretty gratuitous to me since it only takes one instruction to have *ldb and *dpb do the lsh themselves. (*ldb contains an unnecessary move anyway!) Ah well, too late now! (snicker)  Date: 18 September 1980 03:16-EDT From: Robert W. Kerns Subject: SETF To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC I have moved the DEFSETFs for LDB and LOAD-BYTE back to LODBYT where they belong. There is nothing unsafe or hairy about this. I also fixed the bug in the DEFSETFS where it tried to do stuff by hand rather than using the functions provided for the purpose, and did it wrong. I am NOT amazed that it requires that you CONS up a 12-hunk. It needs an intermediate datastructure, and that's what DEFVST uses. The reason you end up with a (lambda (()) 'x) is simply that (setf (ldb 0603 (foo (bar))) y) has to turn into ((LAMBDA (G0259) (SETF (FOO G0259) (DPB 0603 (FOO G0259)))) (BAR)) and the (lambda (()) 'x) is just a piece of code that returns the way to access the frob being SETF'd. Normally it's just a piece of constant code, but for LDB it is consed on the fly.  Date: 18 SEP 1980 0235-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: ... To: (BUG LISP) at MIT-MC I was looking at how SUBLIS worked... Suppose I was using the SUBLIS property myself. Suppose I happend to also use the SUBLIS function. Suppose that I tried to substitute for some symbol that had one of MY SUBLIS properties (at the front of the property list, by chance). Suppose I went nuts trying to figure out why the SUBLIS returned the wrong answer, and why my property lists were being REMPROPed behind my back. amazing  Date: 18 SEP 1980 0212-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC Is anybody EVER going to fix grindef to understand old-style do?  Date: 18 September 1980 02:03-EDT From: Alan Bawden Subject: AAIIEEE!!!!!! shit for brains! To: BUG-LISP at MIT-MC ;;; In a fresh lisp (version 1997) (setq x 222222) 222222 (ldb 0603 x) ;Loading LODBYT 24 ;Loading DEFMAX 44 ;Loading MACAID 87 2 ;;; Let's see just what that expanded into: + (MACROEXPANDED LDB 1 (LDB 603 X) (BOOLE 1 (LSH X -6) 7)) ;;; Knowing that, observe the following: (setf (ldb 0603 x) 5) ;Loading SETF 250 ;(BOOLE 1 (LSH X -6) 7) Obscure format - SETF ;BKPT WRNG-TYPE-ARG ;;; Hmmm... doesn't ldb have a SETF-X property? (plist'ldb) ;;; The property list of LDB goes here. You cannot see it because ;;; there is a bug in DRIBBLE, but I could and it DOES have a SETF-X ;;; property. The bug is that SETF cannot expand ANY macros until it ;;; has loaded the rest of the SETF package, because there might be ;;; SETF-X properties hidden there. You might fix this by: ;;; 1) Loading the rest of SETF whenever you might do a macro expansion. ;;; This is a safe solution, but it blows away your autoloading ;;; scheme, since the most common use of setf is with a macro, ;;; and thus SETF would almost never be usefull in its half-loaded ;;; form. ;;; 2) Move all the SETF-X properties on macros out of the autoloading ;;; part of setf and put them elsewhere. The one on LDB can be made ;;; part of LODBYT. This is the unsafe, hairy, bug-prone solution, ;;; but it does preserve the silly autoloading scheme, so I bet this ;;; is the one you will opt for. ;;; 3) Make setf be an autoloading macro, and when it autoloads ;;; it should bring ALL of setf in. I would do this. ;;; ;;; Now I bet you think that once this stuff is all loaded, it will work! QUIT * (setf (ldb 0603 x) 5) ;((?) (NIL)) TOO FEW ARGUMENTS SUPPLIED - APPLY ;BKPT WRNG-NO-ARGS ;;; Well that was a helpfull error message! (errframe nil)(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *))(evalframe (cadr *)) ;;; (Damned DRIBBLE! And I'll bet that in stone-age MacLisp newio this is even ;;; a hard bug to track down!) ;;; If you could see what was in those evalframes you would be amazed that the ;;; task of groking (setf (ldb 0603 x) 5) requires that you cons up a 12-hunk! ;;; The actual error is caused by applying (lambda (()) 'x) to NIL. Where did ;;; it get the x from I wondered? The second argument to LDB of course! ;;; But I still cannot imagine the algorithm that makes something like this ;;; the right thing to do!  Date: 17 SEP 1980 1710-EDT From: kmp at MIT-MC (Kent M. Pitman) Sent-by: BIL at MIT-MC Subject: ;UNRECOVERABLE REG PDL OVERFLOW To: (BUG LISP) at MIT-MC (EVAL -) done repeatedly in Lisp without ^G'ing or P'ing the resulting error breaks eventually dies to the monitor on its with a PURPG; error. Is there some reason that this couldn't be handled more winningly, perhaps if some switch were turned on, by maybe zero'ing out the stack and then running some clean-up handler or even just zero'ing out the stack and transferring control to whatever (STATUS TOPLE) designates...?  GSB@MIT-ML 09/17/80 14:54:20 To: (BUG LISP) at MIT-ML TYOFLF, if it hits the pagel, falls through to TYOFFF which does not trigger the endpagefn if the file is a tty. This is reasonable for formfeed (at least on ITS), but it breaks more processing with splitscreen stuff.  Date: 16 Sep 1980 1738-EDT From: BRoberts at BBNG (Bruce Roberts) Subject: SLEEP To: bug-lisp at MIT-MC SLEEP on tops-20 Lisp appears to do a FIX on the argument. It only sleeps in integer units, and will not sleep for less than a second. -------  Date: 15 September 1980 11:21-EDT From: Glenn S. Burke Subject: * To: JONL at MIT-MC, GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 15 SEP 1980 0741-EDT From: JONL at MIT-MC (Jon L White) Date: 14 September 1980 19:51-EDT From: George J. Carrette When I do (lap * foo-bar) () I get the caution about *, A SYSTEM LSUBR, IS BEING REDEFINED. Just a reminder that "*" is the fixnum-only version of TIMES. Just a reminder that giving "*" a FOO-BAR property does not redefine it.  Date: 15 SEP 1980 0741-EDT From: JONL at MIT-MC (Jon L White) Subject: * To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Date: 14 September 1980 19:51-EDT From: George J. Carrette When I do (lap * foo-bar) () I get the caution about *, A SYSTEM LSUBR, IS BEING REDEFINED. Just a reminder that "*" is the fixnum-only version of TIMES.  Date: 14 SEP 1980 1951-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC When I do (lap * foo-bar) () I get the caution about *, A SYSTEM LSUBR, IS BEING REDEFINED. -gjc  Date: 14 SEP 1980 0345-EDT From: JONL at MIT-MC (Jon L White) To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Date: 13 September 1980 21:19-EDT From: George J. Carrette Subject: Infinite loop in Complr? (defun gen-name () (funcall '#,((lambda (obarray) (intern 'p1pfx)) sobarray))) Causes Complr to wegde itself for an indefinite amount of time. . . . Fixed now -- poor interaction between #, and funcall understander.  Date: 13 SEP 1980 2119-EDT From: GJC at MIT-MC (George J. Carrette) Subject: Infinite loop in Complr? To: (BUG LISP) at MIT-MC, JONL at MIT-MC (defun gen-name () (funcall '#,((lambda (obarray) (intern 'p1pfx)) sobarray))) Causes Complr to wegde itself for an indefinite amount of time. Apply seems to work fine: (defun gen-name () (apply '#,((lambda (obarray) (intern 'p1pfx)) sobarray) nil)) (putprop 'gen-name (get (let ((obarray sobarray) (intern 'p1pfx))) 'subr) 'subr) works even better, but is much to simple.  Date: 13 SEP 1980 0333-EDT From: JONL at MIT-MC (Jon L White) Subject: *FUNCTION with two args To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 09/10/80 01:04:50 Re: (*function foo ) Anyone know what this thinks it's doing? . . . there should be a MOVEI C,(A) after .FUNC2+10 .FUNC3+4 should XCONS rather than CONS .FUNC2+5 should be HRRZ rather than HLRZ I think your observations are right - I've edited in the code, and after the next reassembly we can try out conjectures as to what its supposed to do!  Date: 13 SEP 1980 0307-EDT From: JONL at MIT-MC (Jon L White) Subject: READing from SFAs To: KMP at MIT-MC, RLB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 12 September 1980 16:05-EDT From: KMP,RLB at MIT-MC +INTERNAL-/'-MACRO (Midas Symbol RDQTE) makes an internal call to read rather than a toplevel call, so bypasses checking for READ call supported by an SFA. . . . -kmp This code predates even newio, and apparently was never appropriately updated; I believe the correct fix is pushj'ing to IREAD instead of READ. Will try to make the patch, and source edit.  Date: 12 SEP 1980 1605-EDT From: KMP,RLB at MIT-MC Sent-by: KMP at MIT-MC To: (BUG LISP) at MIT-MC +INTERNAL-/'-MACRO (Midas Symbol RDQTE) makes an internal call to read rather than a toplevel call, so bypasses checking for READ call supported by an SFA. Hence, (READ my-sfa)'(A B) will get the list (A B) read by TYI'ing from the SFA instead of by READ'ing from it. Redefining it as (DEFUN +INTERNAL-/'-MACRO () (LIST 'QUOTE (READ))) corrects the defect. Can the Lisp source be updated to do this functionality? Just jumping to OREAD instead of READ seems to be wrong since arguments are not set up right at that point to do that. -kmp  Date: 11 September 1980 16:28-EDT From: Kent M. Pitman Subject: how to type in LISP? To: BUG-LISP at MIT-MC I answered MJA's query about (TYO 27.) -kmp  Date: 11 SEP 1980 1302-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC ignore my previous note. i was looking at evalframe, not errframe. instead substitute the following bug: When the PDL overflow handler runs, it doesn't set up an errframe. Why is this? Does it conserve so much stack space that it's not worth it? I wish ERRSET would trap PDL-OVERFLOW and I wish that an ERRFRAME would exist when the PDL-OVERFLOW handler is called. -kmp  Date: 11 SEP 1980 1253-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC According to .INFO.;LISP NEWS, the third element of an ERRFRAME is supposed to be (message [ losing-item [ handler ]]). However, a PDL overflow gives (+INTERNAL-PDL-BREAK (REGPDL)) ... Am I to assume that +INTERNAL-PDL-BREAK is the message? That's pretty silly. Could this be fixed? Thanks. -kmp  GSB@MIT-ML 09/10/80 02:07:15 Re: lexpr-funcall, evalframe, etc. To: rwk at MIT-MC CC: (BUG lisp) at MIT-MC Having the (defprop foo car expr) case tell you car was given wna is more like what the rest of lisp does (ie, lose information). What is of more interest to me is to not have evalframe return arguments which are random crap.  Date: 10 September 1980 01:57-EDT From: Robert W. Kerns Subject: LEXPR-FUNCALL and the function being called To: GSB at MIT-ML cc: BUG-LISP at MIT-ML I changed IAPPLY to copy the function to the left half of the PDL slot. The UUO handlers all put it there, but FUNCALL and LEXPR-FUNCALL don't. (You never see the problem with FUNCALL because it uses JCALL unless *RSET is (), and IAPPLY doesn't check the no of arguments if *RSET is (). Set *RSET to T at interrupt level at the right time and you can generate the bug via FUNCALL too.) This however has the side-effect of changing the function refered to in EVALFRAME and ERRFRAME in the case of (DEFPROP FOO CAR EXPR). Currently FOO is reported as the function with the wrong no of arguments. With the change to IAPPLY, it gives CAR instead. I don't know why one is better than the other, so I've made the change in the source. If you disagree, you can fix it some other way.  GSB@MIT-ML 09/10/80 01:04:50 Re: (*function foo ) To: (BUG LISP) at MIT-ML Anyone know what this thinks it's doing? It's not documented (that i know of). It looks like (*function foo list-of-symbols) is a poor attempt at (closure 'list-of-symbols 'foo), except: there should be a MOVEI C,(A) after .FUNC2+10 .FUNC3+4 should XCONS rather than CONS .FUNC2+5 should be HRRZ rather than HLRZ  Date: 9 September 1980 05:32-EDT From: Alan Bawden To: PGS at MIT-AI cc: JONL at MIT-MC, BUG-LISP at MIT-AI Date: 9 September 1980 04:45-EDT From: Patrick G. Sobalvarro Perhaps the MLMAC definition of defvar should be made standard in the Lisp environment? It is in the standard Lisp environment. Your init file loads LIBLSP;AUTODF which supplies autoload properties for all sortsa things on the LIBLSP directory, including DEFVAR.  Date: 9 September 1980 04:45-EDT From: Patrick G. Sobalvarro To: jonl at MIT-MC cc: BUG-LISP at MIT-AI The reason I asked you where the source for MLMAC was was because I was trying to figure out why defvar as Lisp Machine hackers know and love it doesn't work in the default MacLisp environment. The defvar in the default MacLisp environment is some propagative variable assignment hack done by a J.T. Galkowski, formerly JAN@AI in 1975; I can't imagine why anyone would want to use it, although Macsyma users probably do. It lives on LIBLSP; PPAK FSL. I always put a herald at the beginning of my files, which autoloads MLMAC, where the more useful definition of defvar lives. Perhaps the MLMAC definition of defvar should be made standard in the Lisp environment?  Date: 9 SEP 1980 0225-EDT From: JONL at MIT-MC (Jon L White) Subject: MacLISP's Floating point To: ben at MIT-ML CC: (BUG LISP) at MIT-MC Date: 8 September 1980 14:03-EDT From: Benjamin Kuipers TOPS-10 MACLISP still has the problem of using KA-10 floating point instructions, which must be software simulated on the Tufts KL-10. Are there any plans to fix this? Not that I know of. Several other people have complained about this -- especially Ken Kahn who is trying to use MacLISP on a Swedish TOPS-10 that apparently doesn't support much in hte way of compatibility -- but there's just not a lot of "steam" here on our side to maintain the TOPS-10 version. Hopefully, some combination of TOPS-10 MacLISP users could delve into these things? (the CMUA crew, and maybe someone from Tufts?).  GSB@MIT-ML 09/09/80 01:15:51 To: (BUG LISP) at MIT-ML (lexpr-funcall 'car nil nil nil) => ; ((NIL NIL NIL) (NIL . 1)) TOO MANY ARGUMENTS SUPPLIED It would be rather convenient if the function didn't get lost.  Date: 8 September 1980 23:48-EDT From: Kent M. Pitman To: VINOD at MIT-XX cc: MOON at MIT-MC, BUG-LISP at MIT-MC Maclisp on XX does not assume your terminal to be printing. It simply does not support the multiplicity of different possible terminal types. The Twenex operating system in its current form does not support a virtual terminal display protocol, and as such will not support CURSORPOS. The only alternative, that taken by Teco and other programs, is for Maclisp to understand how to CURSORPOS on whatever type terminal you have. No one has been willing to spend the time coding this up, so you pretty much lose. -kmp  GSB@MIT-ML 09/07/80 01:51:15 Re: +tyo loses on sfas in *rset T To: (BUG LISP) at MIT-ML ptyo2/movei ar1,(b) ptyo2+1/jsp tt,xfosp ptyo2+2/jfcl ptyo2+3/skipa ptyo2+4/jrst ptyo3 ptyo2+5/jsp t,fxnv1  Date: 5 SEP 1980 0032-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC Date: 3 Sep 1980 1532-EDT From: VINOD at MIT-XX Subject: Maclisp on XX To: Moon at MIT-MC cc: vinod at MIT-XX Maclisp on XX currently assumes the terminal to be a printing type terminal. Is there any way to set the terminal to be display type so that it does rubout and cursorpos nicely ? Thanks. Vinod -------  Date: 4 SEP 1980 1858-EDT From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, BILL at MIT-ML GSB@MIT-ML 08/26/80 07:37:09 Re: (equal (hunk 'a 'b 'c 'd) (hunk 'a 'd 'd 'd)) When EQLHN4 finds the first hunk is not a user-hunk and jumps back to EQLHN3, TT has been clobbered. Patched, and edited in source.  Date: 4 SEP 1980 1754-EDT From: JONL at MIT-MC (Jon L White) Subject: names for multiple SETQ/RETURN To: MOON at MIT-MC, RMS at MIT-MC CC: GJC at MIT-MC, MACSYMA-I at MIT-MC, NIL at MIT-MC CC: (BUG LISP) at MIT-MC Date: 24 August 1980 20:40-EDT From: David A. Moon Subject: Multiple-value SETQ/RETURN I don't understand why these "MSETQ" special-forms don't have the standard names. Well, there were several problems with the multiple-setq/multiple-return protocol that haven't been fully resolved, but RMS's note seems to say that the LISPM people are less worried about them. GLS had a more extensive scheme for the S1, so if there is going to be a NIL version which is incompatible with LISPM, the MSETQ-CALL etc are needed; but if not, then they can merely be macroified to produce MULTIPLE-VALUE etc. Date: 24 August 1980 01:04-EDT From: Richard M. Stallman Subject: Multiple-value SETQ/RETURN There may not be any need to worry about what to do about multiple values and PROG1. When Moon and I made multiple values work consistently on the Lisp machine, we decided that it was reasonable for PROG1 not to return multiple values, interpreted or compiled. . . . Mostly the fear about lack of generality was voiced by GJC Date: 23 August 1980 11:22-EDT From: George J. Carrette Subject: Multiple-value SETQ/RETURN . . . You mention in NIL;NEWFUN > that the following will not work correctly in NIL: (MSETQ-CALL (X Y) (PROG1 (FIND-POLAR-POSITION SHIP) (FROB))) This may make MSETQ-CALL dangerous to use in code which undergoes macro expansion. The poor luser writes (MSETQ-CALL (X Y) (FOO)) and (FOO) expands. Resticting what (FOO) can expand into is a gross violation of the lisp semantic contract. Do you seriously want to introduce a language construct for which you are unable to generate correct code? . . . Also, without micro-code, it may be too costly to have *assured* match up between caller and calle as to number of items returned; if both cooperate, there is no problem, but it not? Since VAX/NIL functions in general do not signal the number of returned values, it may be more difficult to get an *assured* version of MULTIPLE-VALUE-LIST.  Date: 3 September 1980 1336-EDT (Wednesday) From: Guy.Steele at CMU-10A To: KESHAV at MIT-XX Subject: Re: Maclisp on XX CC: bug-lisp at MIT-MC In-Reply-To: KESHAV@MIT-XX's message of 3 Sep 80 10:24-EST Message-Id: <03Sep80 133641 GS70@CMU-10A> I suggest that you send mail to BUG-LISP@MC (that's where this note is CC'd to) for problems with MacLISP. (By the way, I am no longer at MIT, but at CMU.) [BUG-LISP: the problem is that KESHAV wants MacLISP by default to provide nice rubout processing for those terminals on XX that can support it.]  Date: 2 September 1980 19:34-EDT From: Eric J. Swenson Subject: Suggestion for commenting brackets like /*...*/ To: Guy.Steele at CMU-10A cc: "ALAN (ALAN BAWDEN)ALAN (ALAN BAWDEN)" at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC, BUG-lispm at MIT-AI How about just /* .... */? It looks nice.  Date: 2 September 1980 1047-EDT (Tuesday) From: Guy.Steele at CMU-10A To: ALAN at MIT-MC (Alan Bawden) Subject: Suggestion for commenting brackets like /*...*/ CC: bug-lisp at MIT-MC, nil at MIT-MC, bug-lispm at MIT-AI In-Reply-To: ALAN@MIT-MC's message of 1 Sep 80 05:37-EST Message-Id: <02Sep80 104708 GS70@CMU-10A> I'm not sure that I am entirely thrilled by the suggestion, but let me suggest that #|...|# would cause the least trouble, because editors and things already understand |...|. #| Don't you think this looks like a nice multi-line comment? |#  Date: 1 September 1980 18:48-EDT From: Robert W. Kerns Subject: SETF of an array To: Guy.Steele at CMU-10A cc: "GJC (GEORGE J. CARRETTE)GJC (GEORGE J. CARRETTE)" at MIT-MC, BUG-LISP at MIT-MC (SETF (ARRAYCALL ...) ...) does indeed already work.  Date: 1 SEP 1980 0018-EDT From: KMP at MIT-MC (Kent M. Pitman) To: SJK at MIT-MC, EGK at MIT-MC, (BUG LISP) at MIT-MC Yes, there is a reason for complaining. The discrepancy between STATUS JNAME and STATUS SUBSY can be used as evidence that the guy has more than one job by that name. Additionally, and most importantly, STATUS JNAME is a unique ID for the job, while STATUS SUBSY is not defined to be. I care less if STATUS SUBSY returns something 6 chars, though I do think it's obnoxious and less useful, but I resent muchly having STATUS JNAME return something that can't be put in a file for some emacs to valret "cont " and expect to win. If you have a MACLISP0 and MACLISP and you valret "cont MACLIS", what does it mean? -kmp  Date: 1 SEP 1980 0012-EDT From: EGK at MIT-MC (Ed Kochanowski) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 31 August 1980 22:06-EDT From: Kent M. Pitman On EE, (STATUS JNAME) and (STATUS SUBSY) both return MACLIS for jobs named MACLISP and MACLISP0 ... I suspect it's just blindly truncating to 6 chars. Is there any reason to truncate at all? I don't see any. -kmp In TOPS-20, The subsystem name of system programs is defined to be the filename, truncated to six letters and converted to sixbit. This I suspect is the reason why. -- EGK --  Date: 31 August 1980 22:50-EDT From: Kent M. Pitman Subject: LEXPR-FUNCALL To: BUG-LISP at MIT-MC cc: ALAN at MIT-MC Date: 25 August 1980 01:23-EDT From: Alan Bawden To: BUG-LISP lexpr-funcall allows you to call it with just one argument. This is a meaningless case and should be flushed for consistency. ----- Just to disambiguate, he means flush the case of (lexpr-funcall fn) -- *not* (lexpr-funcall fn arglist) ... the word 'argument' plays a dual role here. To the naive eye [not you, alan] (lexpr-funcall fn arglist) might seem flushable, but since it pushes stack frames differently than apply, etc. it *is* useful. -kmp  Date: 31 AUG 1980 2206-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC On EE, (STATUS JNAME) and (STATUS SUBSY) both return MACLIS for jobs named MACLISP and MACLISP0 ... I suspect it's just blindly truncating to 6 chars. Is there any reason to truncate at all? I don't see any. -kmp  Date: 29 August 1980 1633-EDT (Friday) From: Guy.Steele at CMU-10A Subject: SETF of an array To: GJC at MIT-MC (George J. Carrette) CC: bug-lisp at MIT-MC Message-ID: <29Aug80 163311 GS70@CMU-10A> In-Reply-To: GJC@MIT-MC's message of 22 Aug 80 13:37-EST I sympathize somewhat with GJC's complaint, but note that if instead of ARRAY you use *ARRAY (or (ARRAY NIL ...)) to create a true array object instead of a named array, then (SETF (ARRAYCALL ...) ...) is easily made to work (I think SETF does already work for this case?).  Date: 29 August 1980 14:00-EDT From: Glenn S. Burke Subject: Getting file attributes To: Guy.Steele at CMU-10A, gjc at MIT-MC cc: BUG-lisp at MIT-MC Date: 29 August 1980 1319-EDT (Friday) From: Guy.Steele at CMU-10A The function DIRECTORY in the ALLFILES package is supposed to let you get at all the file attributes of interest. Except that it doesn't allow you to get the most recent version except by having to sort and choose out of the result. What i have been using for years now is some midas code which returns a DIRECTORY style disembodied plist, eg: (get-file-info '((dsk gsb) tea fasl)) => (((DSK GSB) TEA FASL) FASL T CREATOR (LISP /1997) CRETIME (22. 46. 56.) CREDATE (80. 7. 27.) REFDATE (80. 8. 18.) BYTES 953. BYTESIZE 36.) Admittedly some of this is gratuitous, but it is more in line with what is wanted -- no version choosing, and one call gets everything of interest (including faslp).  Date: 29 August 1980 1319-EDT (Friday) From: Guy.Steele at CMU-10A Subject: Getting file attributes To: gjc at MIT-MC CC: bug-lisp at MIT-MC Message-ID: <29Aug80 131938 GS70@CMU-10A> In-Reply-To: Scott J. Kramer's message of 22 Aug 80 04:34-EST The function DIRECTORY in the ALLFILES package is supposed to let you get at all the file attributes of interest.  Date: 29 AUG 1980 1312-EDT From: JGA at MIT-MC (John G. Aspinall) To: (BUG LISP) at MIT-MC CC: JGA at MIT-MC With respect to my previous bug message - Date: 24 AUG 1980 1721-EDT From: JGA at MIT-MC (John G. Aspinall) In lisp 1997 I got the following bomb-out to ddt MPV; 12326>>HRLM 1,@1(10) 1/ 105745 276142/ ?? when I did - (load '((jga) tekplt)) ;some plotting functions (setup-graphics) ;initialization (file-out-graphics '((jga) yogi tek)) ;an output file (setq infile (open '((jga) yogi ltext) '(in ascii dsk))) (setq yogi (read infile)) (close infile) ;it read yogi (which is a list of function calls) ok ;then it bombed out on (mapc 'eval yogi) The file JGA;YOGI LTEXT is still around if you want to try it. I found an out-of-bounds array reference from a compiled function, which almost certainly caused the problem. So don't waste effort on it. John  Date: 29 AUG 1980 0732-EDT From: GSB at MIT-ML (Glenn S. Burke) Subject: bug in GC To: Dave Touretzky at CMU-10A CC: (BUG LISP) at MIT-ML In case no one responded to this (if they did they didn't cc to bug-lisp), the problem is that the arrays should be created as T type, not NIL type; eg, (array size t 5). NIL types don't get marked through, so after the first gc the stuff which was in them, if not protected by something else, is now on the freelist. I have seen this "bug" before, and even encountered it myself; it isn't immediately obvious that NIL isn't just an ordinary notype array.  Date: 28 August 1980 2303-EDT From: Dave Touretzky at CMU-10A Subject: bug in GC To: bug-lisp at MIT-MC CC: Glenn Iba at CMU-10A The following bug appears in the Tops-10, Tops-20, and ITS versions of MacLisp. A rather simple user program is having its arrays munged immediately after the first garbage collection takes place. To demonstrate the bug, retrieve file MOVEIT.MCL[C410DT50] from CMUA, and also file BUG.INI[C410DT50]. Start up a lisp, feed it BUG.INI as the init file, and let the program run for 1-2 minutes. It eventually prints some asterisks and the message "Something is rotten in <...>" and goes into a break loop. The message is triggered when the program notices that its arrays have been set to strange lists of NIL's. On some implementations, depending on when the GC is triggered, the program may instead get a PDL overflow because one of its functions is attempting to recurse down a bogus 150 element list (a the garbage array element) before it discovers that the arrays have been munged. If this happens, simply change the size of list space by +/- 1000 or so and try again. The garbage collection will then occur at a different time, and the program's array-testing code will probably win. The arrays in question are called SIZE, PEG, TOP, and NEXT-TO-TOP. Their indices run from 0 to 4. These arrays are supposed to contain numbers or lists, but after the garbage collector runs, some elements contain long lists of NIL, from 20 to 150 elements. Moreover, these bogus lists seem to share structure, e.g. the 20 element list is a tail of the 150 element list. We get essentially the same results running on CMU-10A, CMU-20C, and MIT-MC. The program also lost the same way in compiled form (on CMUA.) -- Dave Touretzky (on the BUG-LISP mailing list) Glenn Iba (Iba @ CMUA)  GSB@MIT-ML 08/26/80 16:29:03 Re: this really isn't very helpful To: (BUG LISP) at MIT-ML (APPLY -8938 (ERROR (|-- OBJECT arg to CUE was not a TRIPLE| #12570 #10112)) -4028) This garbage coming from evalframe has been around for years. Isn't it ever going to get fixed?  GSB@MIT-ML 08/26/80 07:37:09 Re: (equal (hunk 'a 'b 'c 'd) (hunk 'a 'd 'd 'd)) To: (BUG LISP) at MIT-ML CC: BILL at MIT-ML When EQLHN4 finds the first hunk is not a user-hunk and jumps back to EQLHN3, TT has been clobbered.  GSB@MIT-ML 08/26/80 05:36:30 Re: EQUAL lossage To: (BUG LISP) at MIT-ML CC: BILL at MIT-ML (setq a (hunk 'a 'b 'c 'd) b (hunk 'a 'd 'd 'd) hunkp t) With (status usrhunk), for example in a NXLMS, (EQUAL A B) => T I bet it switches things around and ends up comparing B with B.  Date: 26 August 1980 0155-EDT From: Dave Touretzky at CMU-10A Subject: Re: bug in OPEN To: Scott J. Kramer CC: bug-lisp at MIT-MC In-Reply-To: Scott J. Kramer's message of 24 Aug 80 23:41-EST Thanks, I was running 1984 exactly. I snarfed version 2009 from XX and it works fine. I notice that in this version it checks for a LISP.INI automagically so you don't have to type ^A to an "alloc?" message. Good. Is there a way to specify an alternate init file yet? -- Dave  Date: 25 AUG 1980 0123-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC lexpr-funcall allows you to call it with just one argument. This is a meaningless case and should be flushed for consistency.  Date: 24 Aug 1980 2141-PDT From: Scott J. Kramer Subject: Re: bug in OPEN To: Dave Touretzky at CMU-10A, bug-lisp at MIT-MC In-Reply-To: Your message of 24-Aug-80 0031-PDT Try assembling a new Lisp; the most recent Lisp I checked which produced a similar error was 1984, but versions 1998 and above worked okay. Which version are you running that caused this problem? -sjk -------  Date: 24 AUG 1980 2040-EDT From: MOON at MIT-MC (David A. Moon) Subject: Multiple-value SETQ/RETURN To: JONL at MIT-MC CC: NIL at MIT-MC, (BUG LISP) at MIT-MC I don't understand why these "MSETQ" special-forms don't have the standard names.  Date: 24 AUG 1980 1721-EDT From: JGA at MIT-MC (John G. Aspinall) To: (BUG LISP) at MIT-MC CC: JGA at MIT-MC In lisp 1997 I got the following bomb-out to ddt MPV; 12326>>HRLM 1,@1(10) 1/ 105745 276142/ ?? when I did - (load '((jga) tekplt)) ;some plotting functions (setup-graphics) ;initialization (file-out-graphics '((jga) yogi tek)) ;an output file (setq infile (open '((jga) yogi ltext) '(in ascii dsk))) (setq yogi (read infile)) (close infile) ;it read yogi (which is a list of function calls) ok ;then it bombed out on (mapc 'eval yogi) The file JGA;YOGI LTEXT is still around if you want to try it. John.  GSB@MIT-ML 08/24/80 07:00:38 Re: pdl-overflow (continued) To: (BUG LISP) at MIT-ML The problem we have been having is that the amount (mainly of regpdl) allocated is primarily determined by the amount needed by the GC. In order to allow a GC from inside a pdl-overflow break, it is preferable to set the PDLMAX down low in comparison to the PDLROOM, so that infinite recursion still leaves lots of room for the GC to operate in. This has the unfortunate effect of causing a GC to queue lots and lots of pdl-overflow interrupts. When the pdl-overflow gets run, it is capable of detecting that it was in the gc if it is not already in a pdl-overflow (by virtue of the fact that the pdlsize is no longer greater than the pdlmax by the time it gets run). If it is already in a pdl-overflow break, however, this heuristic does not work. If nothing else, i would like to have the space-between-recursive-pdlovs upped from the about 200 words it is now to 400 or so. This is not extremely important since i have a pdl-overflow handler which can take care of this situation. But it would be nice if either i could have different parameters for when the pdlov user interrupt gets run for the GC and for user code, or i could have some way of knowing that the pdlov occured during the gc AND not have the gc queue multiple pdlov interrupts. Suggestions?  Date: 24 August 1980 0331-EDT From: Dave Touretzky at CMU-10A Subject: bug in OPEN To: bug-lisp at MIT-MC On TWENEX, trying to open a file that is read-protected results in half an error message followed by a memory protection violation. If you ^G out of the break loop and try the operation again, Lisp prints half the error message again and then goes into an infinite loop, printing spaces.  Date: 24 August 1980 01:04-EDT From: Richard M. Stallman Subject: Multiple-value SETQ/RETURN To: GJC at MIT-MC, JONL at MIT-MC cc: MACSMA-I at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC There may not be any need to worry about what to do about multiple values and PROG1. When Moon and I made multiple values work consistently on the Lisp machine, we decided that it was reasonable for PROG1 not to return multiple values, interpreted or compiled. Only the last subform in a construct ever passes back multiple values on the Lisp machine. So we have a consistent scheme for what things return multiple values, and as part of this scheme, PROG1 does not. Because this does fit into a consistent scheme, it shouldn't be called "incorrect implementation" or "failing to work" I'm not trying to say this is the ONLY consistent design. It might be possible to design another consistent scheme in which PROG1 would return multiple values, and that scheme might or might not be preferable, but if it were preferable it would be at most a minor improvement. You might choose to implement such a scheme if it were easy to do, but it would not be worth working hard for.  Date: 23 August 1980 11:22-EDT From: George J. Carrette Subject: Multiple-value SETQ/RETURN To: JONL at MIT-MC cc: MACSMA-I at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC Actually, I am not all that thrilled with multiple value returns. Chuck Linton needed to run some of HIC's lispm code in maclisp, so instead of changing the multiple value returns into "(PROGN (SETQ *RETURN1* ) (SETQ *RETURN2* ))" by hand I made up a little macro to hide the SETQ's. The reason I am not too thrilled is that multiple value return complicates the compiler, and cannot be done correctly with a macro, (remember that I impose a condition, that macros are not allowed to call macro-expand). You mention in NIL;NEWFUN > that the following will not work correctly in NIL: (MSETQ-CALL (X Y) (PROG1 (FIND-POLAR-POSITION SHIP) (FROB))) This may make MSETQ-CALL dangerous to use in code which undergoes macro expansion. The poor luser writes (MSETQ-CALL (X Y) (FOO)) and (FOO) expands. Resticting what (FOO) can expand into is a gross violation of the lisp semantic contract. Do you seriously want to introduce a language construct for which you are unable to generate correct code? Right now I am thinking about working on a maclisp macro which works in the above case, (it violates my condition of course), using the same META EVALUATOR code that I suggested JKF use for lambda-binding optimization (remember &PROTECT). That suggestion met with such positive response of course! The way it works is to generate temporaries for X and Y. GENSYMS. And then target these to recieve the return values of the PROG1. The PROG1 the targets these to recieve the return values of its first argument, and so on. It is incredibly simple to do if you are not worried about the efficiency of the number of needless LAMBDA BINDs or SETQ's that you generate. Look what might be generated: (MSETQ-CALL (X Y) (SOME-SUBR)) ; SOME-SUBR is not a macro. (PROGN (SETQ G0001 (SOME-SUBR) G0002 *RETURN-REGISTER-2* X G0001 Y G0002) G0001) Of course, the over-caution lets you generate CORRECT code for the PROG1. (PROGN (SETQ G0001 (FIND-POLAR-POSITION SHIP) G0002 *RETURN-REGISTER-2*) ; now we can evaluate the rest of the PROG1 without worry. (FROB) ; now take care of the MSETQ (SETQ X G0001 Y G0002) ; lastly, the return value of prog1 and the MSETQ G0001) I have left out the details of where the temporaries get allocated. Wrapping a (LET (G0001 G0002) ...) around things suggests that they get pushed onto some stack as needed. So JONL, do you think you can get this to work correctly and efficiently in NIL?  Date: 23 AUG 1980 1028-EDT From: JONL at MIT-MC (Jon L White) Subject: Multiple-value SETQ/RETURN To: GJC at MIT-MC CC: MACSMA-I at MIT-MC, NIL at MIT-MC, (BUG LISP) at MIT-MC Somewhat inobtrusively, we've added MSETQ-CALL and MSETQ-RETURN to NIL for the obvious purpose; one reason that we've avioded merely giving multiple arguments to RETURN is possible confusion with RETURN-FROM, but this is not really important. At any rate, I'd like to suggest that whatever you contemplate for MACLISP be fully compatible with whatever we make as the final decision for NIL. It's super important that this not linger too long snce we dont' like the idea of re-changeing NIL's special forms too much (witness KMP's paper in LISP Conference). Also I have a lot of NIL code using MSETQ-CALL and MSETQ-RETURN -- not that the names are important, but the fnctionality is definitely needed. For a quick view of the syntax/semantics, see NIL;NEWFUN > ( I think they are basically the same as the LISPM facility, or trivial variants, except for the ambiguous meaning of RETURN). For the MACLIP compiler, rather than hair up RETURN, wy not let usintroduce these guys for real -- it wuld take only about an hour to add the compoler code for the, andmaybe another smilar amount of time to add FSUBRs to theinterpreter. I'd propose using accumulators 1 - 5 for the return values, postponing the inevitable question of what to do when you want moe than 5 return values. Finally, apologies for the dropped letters in thisnote - am on a verrry unfamiliar terminal here in Palo Alto.  Date: 23 AUG 1980 1013-EDT From: JONL at MIT-MC (Jon L White) Subject: i/o channel of LOAD To: JPG at MIT-MC, GJC at MIT-MC CC: MACSYMA-I at MIT-MC, (BUG LISP) at MIT-MC JPG is right in that this is totally a LISP misfeature -- that the i/o channel is no closed upon error exit. We ought to look at the pprroblem smetime, holding the proper estmation of the importance of tis proble. (tertiary, maybe?)  Date: 22 AUG 1980 1924-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC fixnum-identity and flonum-identity should be understood by setf. Perhaps the correct behavior is: (setf (fixnum-identity foo) bar) => (setf foo (fixnum-identity bar))  Date: 22 AUG 1980 1437-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC (array bar t 10) (store (bar 3) t) ; works but (setf (bar 3) t) ; gives obscure format setf error. In the interpreter SETF should check for an array property, and in the compiler ARRAY should put a SETF-X property. That is, if you want to be compatible with maclisp's crufty array syntax. -gjc  Date: 22 Aug 1980 0234-PDT From: Scott J. Kramer To: GJC at MIT-MC, (BUG LISP) at MIT-MC cc: NIL at MIT-MC In-Reply-To: Your message of 21-Aug-80 1427-PDT Mail-from: ARPAnet host MIT-MC rcvd at 21-Aug-80 1427-PDT Date: 21 AUG 1980 1727-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC, GJC at MIT-MC Is there a way to get the file creation date and time of a file? Can I suggest an extension of PROBEF: (PROBEF "FOOFILE" 'CREATION) (PROBEF "FOOFILE" '(TRUENAME CREATION LAST-REF)). Try: (DIRECTORY '("FOOFILE") '(CREDATE CRETIME)) Even though the information about a file is incredibly system dependant, I think all reasonable systems support the subset of messages '(TRUENAME CREATION LAST-REF) and maybe some others. True, Twenex could stand ALLFILES and DIRECTORY. I wrote something to look at the FDB word, but it's not in ITS-like format. This is usefull information to have for systems programming. Again, on Twenex peeking/poking at the File Descriptor Block from Lisp is handy, I'll have to find my old program... -sjk -------  Date: 21 AUG 1980 1727-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC, GJC at MIT-MC Is there a way to get the file creation date and time of a file? Can I suggest an extension of PROBEF: (PROBEF "FOOFILE" 'CREATION) (PROBEF "FOOFILE" '(TRUENAME CREATION LAST-REF)). Even though the information about a file is incredibly system dependant, I think all reasonable systems support the subset of messages '(TRUENAME CREATION LAST-REF) and maybe some others. This is usefull information to have for systems programming.  GSB@MIT-ML 08/21/80 08:11:21 Re: pdl-overflow To: (BUG LISP) at MIT-ML CC: WAM at MIT-ML The amount of pdl you are given to play with when a pdl-overflow is triggered seems to be insufficient to do anything reasonable. The situation i have encountered is that i was running in a lisp which had a special (status breaklevel) [used to rebind user variables and perform various actions], the hairy tty prescan, and i was testing interpreted read code. With some of this interpreted, it used enough pdl to recursively trigger pdl-overflows until it went and broke the lisp. (It printed ";bkpt pdl-overflow" 4 or 5 times.) (The original pdl-overflow was unrelated to the ones which followed.) The problem is that as more environment support code gets used, this small amount of pdl is going to cause recursive pdl-overflows more and more frequently, needlessly. My experience has been that pdl-overflows, in virtually all cases, happen for two reasons: infinite recursion (in which case one needs to be able to poke around and find out what went wrong), and the gc losing in marking hunks in large hairy databases (in which case there is little one can do other than start off with more). It seems to me that it would be preferable for the space between the first and the unrecoverable pdlov to be divided into only one or two pdlov interrupts, rather than 4. I also consider it a bug that the unrecoverable regpdl overflow doesn't just error out to toplevel, but rather gets a memory error forcing the lisp to be g'ed, thus not unwinding the stack properly. And the pdl-overflow interrupt should heed the value of ERROR-BREAK-ENVIRONMENT!  Date: 19 AUG 1980 1400-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC How abot adding <$ and >$ for NIL compatibility? It was a crock that these were combined in with < and > in the first place...  Date: 16 AUG 1980 1548-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: broken magic To: (BUG LISP) at MIT-MC (defun foo (x) (print (list 'foo-expr x)) (car x)) FOO (defmacro foo (x) (print (list 'foo-macro x)) `(car ,x)) FOO (foo '(a . b)) (FOO-MACRO (QUOTE (A . B))) A (funcall 'foo '(a . b)) (FOO-EXPR (A . B)) ;Excellent! Just what I wanted! A (apply 'foo '((a . b))) ;IMPROPER USE OF MACRO - EVAL ;OOPS! ;BKPT *RSET-TRAP I find that APPLY is the the ONLY function that won't cooperate with me here. FUNCALL, LEXPR-FUNCALL, all the MAPping functions and the uuolinker all know to ignore a MACRO property if they can find something better. Could someone twist APPLY's arm a little and get him to agree? thanx.  Date: 15 August 1980 1719-EDT (Friday) From: Guy.Steele at CMU-10A Subject: Re: SETF To: JONL at MIT-MC (Jon L White) CC: bug-lisp at mit-ai, bmt at mit-mc Message-ID: <15Aug80 171924 GS70@CMU-10A> In-Reply-To: JONL@MIT-MC's message of 13 Aug 80 22:41-EST Anyone who uses the value of SETF deserves to lose. However, for consistency it would be best if is returned the "second argument" by analogy with SETQ, I believe.  Date: 14 August 1980 23:49-EDT From: Robert W. Kerns Subject: SETF To: JONL at MIT-MC cc: BMT at MIT-MC, MACSYMA-I at MIT-MC, RZ at MIT-MC, WGD at MIT-MC, BUG-LISP at MIT-MC Date: 13 August 1980 23:41-EDT From: Jon L White To: BMT cc: MACSYMA-I, RZ, WGD, BUG-LISP Re: SETF Unfortunately, the currentf SETF expander turns (SETF (CAR L) X) into (PROGN (RPLACA L X) X), which isn't what the built in version does -- it acts as if the expansion should be (RPLACA L X). This difference in return value makes it impossible to use the value of SETF. Any preferences for what the "return value" of SETF should be? This is a bug resulting from your turning SETF into a special form. One of us should fix it.  Date: 14 August 1980 23:45-EDT From: Robert W. Kerns Subject: SETF clarification To: JONL at MIT-MC cc: KMP at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC As the leading advocate of returning the value like SETQ, I have written much code assuming that it returns the value like SETQ. I don't know exactly how much of it actually DOES use it, I don't use it any more than I use the return value from SETQ. But I'd rather be able to write (PRINT (SETF foo bar)) than (LET ((BAR bar)) (SETF foo BAR) (PRINT BAR)), just like I'd rather do the same with SETQ. I believe it to be more readable; brevity can HELP readability!  GSB@MIT-ML 08/14/80 20:13:16 Re: gcprotect To: (BUG LISP) at MIT-ML This time, i found a bug because i didn't get screwed when in theory i should have. (No, i won't explain.) Anyway, it appears that gcprotect is expecting accumulator AR1 to be saved around the PUSHJ P,SXHSH0 it does to compute the hash key. In the case i encountered (the object being gcprotected was a user-hunk), AR1 went from 1 to 0 turning a protect into a release.  Date: 14 August 1980 12:28-EDT From: George J. Carrette Subject: SETF To: CWH at MIT-MC cc: JONL at MIT-MC, BMT at MIT-MC, MACSYMA-I at MIT-MC, RZ at MIT-MC, WGD at MIT-MC, BUG-LISP at MIT-MC, HIC at MIT-MC Carl, I really don't like the idea of having forms which return "undefined" values unless that can be enforced by the compiler and the interpreter. If you can convince everyone to have SETQ, SETF, ney, all side-effecting primitives to return SI:+INTERNAL-**UNDEFINED-FOOBAR** then I think you would have better grounds for having SETF's return value be undefined. I know that mixing side effect producing expressions with expressions which are evaluated for value can lead to some *REALLY* grotesque and difficult to read programs, , *but*, it doesn't have to. As HIC pointed out, even the maclisp compiler optimizes away the lambda needed to save the value to return just in case it is needed. -gjc  Date: 14 August 1980 09:10-EDT From: Howard I. Cannon Subject: SETF To: CWH at MIT-MC cc: JONL at MIT-MC, BMT at MIT-MC, MACSYMA-I at MIT-MC, RZ at MIT-MC, WGD at MIT-MC, BUG-LISP at MIT-MC Date: 14 August 1980 02:12-EDT From: Carl W. Hoffman To: JONL, BMT cc: MACSYMA-I, RZ, WGD, BUG-LISP Re: SETF Date: 13 AUG 1980 2341-EDT From: JONL at MIT-MC (Jon L White) Any preferences for what the "return value" of SETF should be? Undefined! I think it would be great if SETF returned the value, just like SETQ. You don't know HOW many times I've wanted that. It turns out that in MacLISP, if you just do it in the straightforward fashion (with a lambda), the compiler optimizes it away if you don't use the returned value (ALAN and I tried that for exactly this reason: to see if we could change SETF reasonably).  Date: 14 AUG 1980 0405-EDT From: JW at MIT-MC (John C. Wenn) To: (BUG LISP) at MIT-MC IT WORKS!!!! THANK YOU JW  Date: 14 AUG 1980 0352-EDT From: JW at MIT-MC (John C. Wenn) To: (BUG LISP) at MIT-MC Thanx, where exactly would I declare J1, N, K, and Next-base??  Date: 14 AUG 1980 0345-EDT From: JONL at MIT-MC (Jon L White) To: JW at MIT-MC CC: (BUG LISP) at MIT-MC Your function BITREV simply should have a lot more number declarations (admittedly it shouldn't be necessary, but ...) I believe the problem will go away if you merely declare the rest of the variables shown to be FIXNUM.  Date: 14 AUG 1980 0343-EDT From: JW at MIT-MC (John C. Wenn) To: (BUG LISP) at MIT-MC There seems to be a bug in the complr. I try to run the simple function: (defun bitrev (j nu) (declare (fixnum j nu)) (do ((j1 j nextbase) (n nu (// n 2)) (next-base (// j 2) (// next-base 2)) (k 0 (+ (* k 2) (- j1 (* 2 next-base))))) ((= 1 n) k))) This runs fine when interpreted. When it is complied, on the second and subsequent iterations, j1 and next-base are set to the same value!!! J1 should equal (* 2 next-base). What is going wrong, and how can I fix it?? Now I am using the function written as a prog (GROAN!!). thanx-- JW  Date: 14 August 1980 02:12-EDT From: Carl W. Hoffman Subject: SETF To: JONL at MIT-MC, BMT at MIT-MC cc: MACSYMA-I at MIT-MC, RZ at MIT-MC, WGD at MIT-MC, BUG-LISP at MIT-MC Date: 13 AUG 1980 2341-EDT From: JONL at MIT-MC (Jon L White) Any preferences for what the "return value" of SETF should be? Undefined!  Date: 14 August 1980 00:21-EDT From: Alan Bawden Subject: SETF clarification To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 14 AUG 1980 0004-EDT From: JONL at MIT-MC (Jon L White) I believe the first LISPM implementations of SETF were explicitly described to have "undefined" value ... This is still true on the LispMachine. There is no plan to change the way SETF works as far as I know.  Date: 14 AUG 1980 0004-EDT From: JONL at MIT-MC (Jon L White) Subject: SETF clarification To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC I believe the first LISPM implementations of SETF were explicitly described to have "undefined" value -- mostly because of the random nature of the code produced by the SETF expanders. While it might be desirable to standardize someday on a useful value, I'd be curious to hear of anyone who has much code written depending on the return value from SETF. The BMT incident shows that likely he would get varying results when running such code.  Date: 13 August 1980 2355-EDT From: Dave Touretzky at CMU-10A Subject: Re: SETF To: JONL at MIT-MC (Jon L White) CC: bug-lisp at MIT-MC In-Reply-To: JONL@MIT-MC's message of 13 Aug 80 22:41-EST Clearly the return value of SETF should be X. Returning whatever random piece of structure was returned by the operation SETF expanded to is not very esthetic. What happens if, for some SETF cases, SETF is changed or improved in some way? Then the result of some SETF expansions might change, and this wouldn't be very pleasant. If SETF always returned its second argument its behavior would be guaranteed consistent, and also simpler.  Date: 13 AUG 1980 2348-EDT From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC, MACSYMA-I at MIT-MC, RZ at MIT-MC, WGD at MIT-MC To: (BUG LISP) at MIT-MC CC: JAR at MIT-MC The value of SETF must be its second arg. There is a ton of code by now that depends on this, I'm sure. We want to be able to do something similar to: (SUBST '(CAR X) 'A (SUBST 'SETF 'SETQ random-expression)) This is perhaps an oversimplification, but it shows a situation where it's more useful to rely on a value related to the meta-notion of setting rather than a value related to the operation-specific notion of RPLACA.  Date: 13 AUG 1980 2341-EDT From: JONL at MIT-MC (Jon L White) Subject: SETF To: BMT at MIT-MC CC: MACSYMA-I at MIT-MC, RZ at MIT-MC, WGD at MIT-MC CC: (BUG LISP) at MIT-MC Unfortunately, the currentf SETF expander turns (SETF (CAR L) X) into (PROGN (RPLACA L X) X), which isn't what the built in version does -- it acts as if the expansion should be (RPLACA L X). This difference in return value makes it impossible to use the value of SETF. Any preferences for what the "return value" of SETF should be?  Date: 13 AUG 1980 1413-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: BMT at MIT-MC Subject: (POP FOO) with (SETQ CAR T) To: (BUG LISP) at MIT-MC :SRCCOM L;*LISP 009,L;*LISP 010 The PUSHJ P,CADR that was there bombs if you do (SETQ CAR 'LIST CDR 'LIST). I made it a little more careful about what it CARCDR'd by simply reversing the order in which it checked for no second arg and for NIL/T second arg. I think this is the logical order besides. However, I am burned out enough that I may have blown it away totally.  Date: 13 August 1980 01:44-EDT From: Robert W. Kerns To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-MAIL at MIT-MC This is LISP's bug. LISP stops parsing JCL at the first carriage return. It also limits the total size of the JCL by giving you an error if the JCL is too long for it. It doesn't truncate even, just errors out. You'd do better to communicate by filename, using the (R-HEADER-FORCE QUOTE) bit.  Date: 13 AUG 1980 0044-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CC: (BUG MAIL) at MIT-MC I have been using a suspended maclisp as a job started up by COMSATs PGM option. Things work fine except that JCL is truncated at about 90 characters or less, which is not enough to parse most mail headers. I know that JCL isn't exactly the most efficient way to pass information from one program to another, but is this a realistic limitation on the JCL size, or is this a lisp bug? Its easy to reproduce using :LJCL in DDT.  GSB@MIT-ML 08/12/80 19:49:38 Re: SLEEP on XX To: (BUG LISP) at MIT-ML apparently fixifies a flonum before multiplying by 1000, so a flonum arg < 1.0 doesn't sleep.  Date: 12 August 1980 12:18-EDT From: "Guy L. Steele, Jr." Subject: Ignored Variables To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI Presumably the only reason for explicitly mentioning that a variable is ignored is for error-checking, so that the compiler will not print the warning message if you're sure that the variable is supposed to be ignored. Why not extend this error-checking to the interpreter? The use of () (or IGNORE, for that matter, though IGNORE is mroe readable in my opinion) as a LAMBDA-variable I find unacceptable as a general mechanism, because it doesn't let me assign my own name to the ignored thing. Often ignored variables arise in a situation where a function is called by some dispatching mechanism (e.g., fetching from a property list), and so I want all the LAMBDA-lists of the possible functions to look the same, because they are conventionally passed a standard set of arguments which have a standard set of names, but not all the dispatch possbilities use all the arguments. (As an example of this, consider the command- handlers for FORMAT.) I want to retain the names as standard, and separately note that some are ignored. On the other hand, just mentioning ignored variables at the front of the function body is also unacceptable. I want a way to say EXPLICITLY thast a variable is ignored, and get a warning message from the compiler if the variable is in fact used! Also, if I depend on the front-of- lambda-body technique to suppress unused-variable warnings, then I invite "unused value" warnings (which the compiler ought also to generate for situations such as (PROGN FOO (SETQ X Y)) and (PROGN (CONS A B) ...)). I think there is much to be sadi for some kind of explicit declaration of ignoring. IOt allows better error-checking in the compiler, makes more clear what is going on, and even allows for error-checking in the interpreter, which could recognize the declarations (either (DECLARE (IGNORE ...)) or &IGNORE or whatever) and bind the variable in question to the unbound value.  Date: 11 August 1980 13:28-EDT From: "Guy L. Steele, Jr." Subject: "Above-cited property" To: BUG-LISP at MIT-AI The above-cited property was not associativity, but merely LEFT-associativity. I admit that this is a much less interesting property than full associativity. Projectivity is also an interesting property, but observe that the applicability of the projectivity property cannot be determined unless the value of the Boole "function argument" is known, whereas the property of left-associativity currently alw2ays works even if the function is unknown. I believe, however, that left-associativity will still work even if the propoased projectivity definitions are included provided that at least two arguments are always associated. This should be verified. Thus only the one-argument case would change, and the useful cases (for symbolic code transformation) would remain for left-associativity.  Date: 10 AUG 1980 2238-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Would anyone object to making #\EOF return -1, since TYIPEEK always returns -1 for end of file if given any 3rd arg and users of TYI often use -1 as the optional 2nd arg...? Naturally on systems that had real eof values, such a value could be preferred. -kmp  Date: 10 AUG 1980 2140-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (DEFUN MY-SFA-HANDLER (SELF OP DATA) (CASEQ OP ((WHICH-OPERATIONS) '(TYI TYIPEEK)) ((TYI) (TYI TYI)) ((TYIPEEK) (TYIPEEK () TYI)) (T (ERROR "Illegal SFA operation" `(SFA-CALL ,SELF ,OP ,DATA))))) (SETQ MY-SFA (SFA-CREATE 'MY-SFA-HANDLER 0. "My SFA")) (READ MY-SFA)`(TYO = ,TYO) ;(#SFA-|My SFA|-70676 UNTYI 41.) ATTEMPT TO INVOKE SFA ON AN UNSUPPORTED OPERATION -- +INTERNAL-SFA-CALL Why does Lisp need to do the UNTYI here? Can't it be using my builtin TYIPEEK operation? If you're going to insist that I handle an UNTYI call, I think I ought to be given an UNTYI primitive to push things back on to the TYI input stream. It's not at all fair to demand this handler to hold onto the untyi'd character, as if a read occurs later on another SFA trying to indirect through TYI as well, it will lose. -kmp  Date: 10 AUG 1980 2135-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Age old bug To: (BUG LISP) at MIT-MC This also is getting in the way of reasonable rubout processing for Macsyma. I mention this to encourage those who do such things to consider this sort of bug to be something that is worth it to the group to look into ... (PROGN (TYIPEEK) (PRINT 'FOO))* FOO T Now, you *CAN'T* rub out the *. you *CAN'T* control-k the *. you *CAN'T* get the * to evaluate ... until either TYI it or another form gets read and that forces the prescan to push off to the evaluator. typing lots of spaces doesn't help. it sits there until you type a ")" or a real expression. I know this is an old bug, but it's one I'd like to see fixed. -kmp  Date: 10 AUG 1980 0315-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: CWH at MIT-MC, KMP at MIT-MC (TYIPEEK () (SFA-CREATE #'(LAMBDA N ()) 0. "Loss")) gives ;(NIL TYI NIL) ATTEMPT TO INVOKE SFA ON AN UNSUPPORTED OPERATION -- +INTERNAL-SFA-CALL (1) Could this message be made short enough to fit on a line. (2) Could the message be made to include TYIPEEK as the problem, rather than TYI? I had a bit of trouble tracking down this problem on a real SFA since the SFA *DID* support TYI and I couldn't figure out what the error referred to. (3) RUBOUT *STILL* doesn't dispatch to SFA handlers. It complains of non-tty file object. We need this to win to work with SFA handlers for Macsyma exportation. -kmp  Date: 8 AUG 1980 1736-EDT From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC CC: MOON at MIT-MC, GLS at MIT-MC, (BUG LISP) at MIT-MC, JAR at MIT-MC I think that (DEFMACRO BOOLE (OP &REST X) (COND ((NULL X) (ERROR "Too few args to BOOLE" (CONS 'BOOLE X))) ((NULL (CDR X)) (CAR X)) (T `(+INTERNAL-BOOLE ,OP ,(CAR X) (BOOLE ,OP ,@(CDR X)))))) should be the proper recursion description. Such a definition makes an elegant case for (BOOLE op val) => val.  Date: 8 AUG 1980 1638-EDT From: ALAN at MIT-MC (Alan Bawden) To: CFFK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 8 AUG 1980 1622-EDT From: CFFK at MIT-MC (Charles F. F. Karney) A guy here at Princeton would like to learn Lisp. Asides from the Maclisp Manual is there any easy introductory information he could use. (E.g. an on-line primer, a TEACHLISP program, or a decent book on Lisp.) "Notes on the Programming Language Lisp" by Bernie Greenberg is an excellent introduction to Lisp. Copies can be obtained by sending $3.50 ($2.50 to cover duplication costs and $1.00 to cover postage and handling) to: Student Information Processing Board MIT Room 39-200 Cambridge Mass 02139  Date: 8 AUG 1980 1624-EDT From: KMP at MIT-MC (Kent M. Pitman) Sent-by: JONL at MIT-MC To: CFFK at MIT-MC CC: (BUG LISP) at MIT-MC On MC only, :TEACH;LISP will run an automated Lisp Teacher. The program is not currently in an exportable state. -kmp  Date: 8 AUG 1980 1622-EDT From: CFFK at MIT-MC (Charles F. F. Karney) To: (BUG LISP) at MIT-MC A guy here at Princeton would like to learn Lisp. Asides from the Maclisp Manual is there any easy introductory information he could use. (E.g. an on-line primer, a TEACHLISP program, or a decent book on Lisp.)  GSB@MIT-ML 08/08/80 03:53:33 Re: usrhunk & printing To: (BUG LISP) at MIT-ML CC: ALAN at MIT-ML If outfiles is not nil and ^r is t and ^w is nil, when output is sent to "nil", the user-hunk handler (ie (status sendi)) gets called with a stream arg of outfiles, rather than nil, making the tty feel rather lonely.  GSB@MIT-ML 08/07/80 16:00:47 Re: fformat To: (BUG LISP) at MIT-ML doesn't print it's herald to msgfiles  Date: 7 AUG 1980 0556-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: MACSYM at MIT-MC, RWG at MIT-MC If you type to a fresh MACSYMA: LOADFILE(FMULT,3,RWG); LIMIT(BUSTER,N,INF); , and as soon as you see the "Loading done" message for MATRUN FASL, you hit control-G, you will exit to DDT with MPV; 67277>>MOVE 12,(17) or perhaps a PURPG error.  Date: 5 AUG 1980 2228-EDT From: JONL at MIT-MC (Jon L White) Subject: Deja-vu To: (BUG LISP) at MIT-MC CC: GJC at MIT-MC, JPG at MIT-MC, GSB at MIT-MC Just to remind us of why so much extra stuff is getting pushed onto the internal list LDEVPRO by fasload: JONL@MIT-ML 09/02/79 16:24:30 Re: GC and symbols To: (BUG LISP) at MIT-ML Although the GC will balk at reclaiming any symbol header which has either ccn bit one (Compiled-Code-Needs-me), it fails to mark from the plist and pname-list of such symbols unless they are marked from other pathes (like, thru the obarray, etc.) This certainly makes it harder to deal with un-interned symbols referenced by compiled code.  Date: 5 AUG 1980 2209-EDT From: JONL at MIT-MC (Jon L White) Subject: Broken squidified strings To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG MACSYMA) at MIT-MC GSB and I apparently broke fasload this morning, while trying to stop the over-consification of squid-quotified stuff onto a second gc-protection array. I've taken back the modification, and we'll rethink the problem. This should fix TRANSL's problems.  Date: 5 AUG 1980 2123-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CC: (BUG MACSYMA) at MIT-MC I swear, the default double quote in maclisp seems to be busted in some strange way. One example is the file MAXSRC;TRANSL > which uses many "strings". If you call the function TRANSLATE_FILE in macsyma you will note that in the function PRINT-TRANSL-HEADER that many (PRINC "FOOO" STREAM) things seem to output randomness into the file. I don't expect you to be able to track this down from example, but I suspect you have some idea of possible causes of this bug. This bug also shows up in the I/O done by the macsyma PRELUDE file. Presently no macsyma source files can be installed because of this bug.  GSB@MIT-ML 08/04/80 23:59:21 Re: hard times are a way of life To: (BUG LISP) at MIT-ML purcopying an array sets the AS.FL bit in the asar rather than the TTS.CN bit in the ttsar. I thought this had been fixed long ago.  GSB@MIT-ML 08/04/80 23:43:43 Re: purification To: (BUG LISP) at MIT-ML CC: (BUG BRAND-X) at MIT-ML My lossage earlier this evening got me poking around at what happens in lisp when stuff is referenced from compiled code. I discovered that fully 1/2 of the things stored on the list LDEVPRO in an XLMS were duplicates. (XLMS turns on the GCPROTECT flag so as not to blow gcprotect out of the water by looking at circular structures.) In addition, there were a slew of inums in there. This is a primitive xlms. A system built on xlms (XABEL) has 5 times as much stuff stashed here, again 1/2 of it duplications. XABEL was not made pure, so that list also contains lots of symbols. Couldn't these have been hacked by setting SY.CCN in the symbol header? Along the same line, it is probably a wise idea for the documentation of the PURCOPY message of user-hunks to point out that if the object is NOT going to be purified it must be gc-protected.  GSB@MIT-ML 08/04/80 22:24:58 Re: ferocious user code To: (BUG LISP) at MIT-ML LDQLS+24 should contain POP FXP,F rather than POP FXP,R This can blow away fasload by allowing some aobjn pointer to get clobbered.  Date: 4 AUG 1980 1840-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC APPEND and NCONC have no args information associated with them in the interpreter. Should be (0 . inf) rather than NIL. -kmp  Date: 4 AUG 1980 1830-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (*RSET ()) (SETQ CAR T CDR T) (SETQ B (HUNK 'B)) (RPLACD B (CAR B)) => (#777777 .) ; WHAT A SILLY PRINTNAME. WHY NOT (.)? (HUNKSIZE B) .VAL 0; HUNKP>>LSH A,-11 A/ 702777 Could this .VAL 0 object be made to print more like 0? It seems to affect the read-eval-print-loop so that it types ?U? at me for some reason, too.  Date: 4 AUG 1980 1650-EDT From: MOON at MIT-MC (David A. Moon) Subject: BOOLE of one (i.e. two) argument To: GLS at MIT-AI CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-AI Date: 4 AUG 1980 1457-EDT From: GLS at MIT-AI (Guy L. Steele, Jr.) Subject: BOOLE of one (i.e. two) argument To: (BUG lisp) at MIT-MC CC: (BUG LISPM) at MIT-AI, GLS at MIT-AI I argue that (BOOLE 10 X) should in fact return X, not (LOGNOT X). It already does, in both Lisp machine and Maclisp. Does this mean there is some incorrect documentation somewhere?  Date: 4 AUG 1980 1457-EDT From: GLS at MIT-AI (Guy L. Steele, Jr.) Subject: BOOLE of one (i.e. two) argument To: (BUG lisp) at MIT-MC CC: (BUG LISPM) at MIT-AI, GLS at MIT-AI I argue that (BOOLE 10 X) should in fact return X, not (LOGNOT X). The reasoning is that for these multiple-argument operators like BOOLE, PLUS, TIMES, MAX, and so on, we want the following property to hold: (OP (OP x1 x2 ... xj) xj+1 ... xn) = (OP x1 x2 ... xj xj+1 ... xn) for as many j and n as possible. Indeed, for j=2 this is how these operations are implemented. Now if you let j=1 you can see that the result of (OP x) should be x, and for j=0 the result of (OP) should be the identity operation for OP if it has one (this is why (PLUS)=0 and (TIMES)=1). To avoid problems BOOLE requires at least one real argument (in addition to the opreator number), because some operator numbers have identities and others do not. Now I suppose that one could argue that (BOOLE 10 X) = (LOGNOT X) by analogy with (- x) = (MINUS x), but that is after all a crock special case allowed because the single-argument case is otherwise "useless". However, I think the above-cited property is useful enough to warrant the (BOOLE 10 X)=X.  Date: 4 AUG 1980 1503-EDT From: JONL at MIT-MC (Jon L White) Subject: IGNORE To: dick at MIT-ML CC: (BUG LISP) at MIT-MC Sounds like a good idea: COMPLR will merely not print out any warning msg about unused variable if the variable's pname begins with "IGNORE". This fails catch certain bugs which the NIL feature of (DECLARE (IGNORE MUMBLE)) does, but at least it makes a happy medium between MACLISP/LISPM . Any one else have ideas/objections?  Date: 4 AUG 1980 1135-EDT From: JONL at MIT-MC (Jon L White) Subject: SHARAB and depurify first arg to suspend To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 08/03/80 21:23:12 Re: pure-suspend (in sharable) apparently doesn't unpurify a symbol given it as its first arg. If i make a sharable dump, giving pure-suspend '|:kill | as a first arg, and make another one from that, giving it the same first arg, it mpv's before dumping. An another bug bites the dust, at the behest of the GSB bullet! new SHARAB installed, and new compiler dump slowly being :INSTALL'd  GSB@MIT-ML 08/03/80 21:23:12 Re: pure-suspend (in sharable) To: (BUG LISP) at MIT-ML apparently doesn't unpurify a symbol given it as its first arg. If i make a sharable dump, giving pure-suspend '|:kill | as a first arg, and make another one from that, giving it the same first arg, it mpv's before dumping.  GSB@MIT-ML 08/02/80 20:34:45 To: (BUG LISP) at MIT-ML (setsyntax nil) should have the brains to realize that if was previously a macro of some type the chtran should be reset even though a third arg of NIL was given. Currently it leaves it alone, leaving the macro function or somesuch garbage there.  Date: 2 AUG 1980 1047-EDT From: JONL at MIT-MC (Jon L White) Subject: BOOLE To: (BUG LISP) at MIT-MC BOOLE isn't consistently projected into the 1-argument case; (BOOLE 10 X) should return the complement of X, and (BOOLE 5 X) should return X [at least, by projecting the bitwise definition of the boole operation number]. but (BOOLE 10 X) returns X, and (BOOLE 10 X Y) returns the complement of X.  Date: 1 AUG 1980 0051-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (SETQ A (*ARRAY () T 100.)) (LEXPR-FUNCALL A '(10.)) gives ;((NIL 12) (NIL . 0)) TOO MANY ARGUMENTS SUPPLIED - APPLY This hardly seems fair. (APPLY A '(10.)) and (FUNCALL A 10.) work fine. Hence, we're losing on arrays' consistency as funcallable.  Date: 31 JUL 1980 1641-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: Sillyness To: (BUG LISP) at MIT-MC (funcall readtable) ;((#READTABLE-0-70006) (NIL . 777776)) TOO MANY ARGUMENTS SUPPLIED - APPLY ;BKPT WRNG-NO-ARGS In general the error message for funcalling ANY array with too few arguments is TOO MANY ARGUMENTS SUPPLIED . While we are on the subject of arrays, why are readtables and filearrays 0 length? SFA's, obarrays and jobarrays all have positive lengths.  Date: 30 JUL 1980 1618-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC In the interpreter \ works if you give it bignums but in the compiler it open-codes as an IDIV instruction in the absence of declarations. The interpreter is at fault I presume.  GSB@MIT-ML 07/30/80 16:13:51 Re: sharable To: (BUG LISP) at MIT-ML announce-&-load-init-file has kind of a deficiency in that it assumes that the name of the init file to be loaded can be represented as (maybe a truncation of) the name of the subsystem. I would like to be able to have the two be different since it is going to announce anyway; eg, "BRAND-X 259 (in SHARABLE 25, LISP 1997)" is supposed to load an init file with fn2 of "BRANDX", not "BRAND-".  Date: 30 July 1980 13:42-EDT From: Robert W. Kerns To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 28 July 1980 19:13-EDT From: George J. Carrette To: BUG-LISP at MIT-MC (DEFUN (FOO BAR) (X) X) in compiled code causes FOO to get a BAR property of |FOO BAR| and |FOO BAR| to get a SUBR property. How can I get FOO to have a BAR property which is the SUBR property in question without the generation of the symbol |FOO BAR| which is useless for my purpose. Look at the documentation for DEFUN in LISP NEWS! Basically, what you want is the 3-list form: (DEFUN (FOO BAR BAZ) (X) X) which will give FOO a BAR property of (LABMDA (X) X) when loaded into the interpreter, and a BAZ property with the SUBR pointer when compiled.  Date: 29 JUL 1980 1307-EDT From: JONL at MIT-MC (Jon L White) Subject: "How sad"? To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 28 July 1980 18:12-EDT From: Kent M. Pitman (DELETE 'A '(A B C) 1.5) in a fresh lisp does a ILOPR; A>>SYALC+17 0/ (not surprisingly) 0 SYALC+17/ SY2ALC+2,,0 How sad. Enough to be fixed. Currently patched into dump, and edited into source.  Date: 29 JUL 1980 0145-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC GRINDEF, SPRIN1 and friends don't seem to understand about (SSTATUS USRHU ...) etc.  Date: 28 JUL 1980 2131-EDT From: KMP at MIT-MC (Kent M. Pitman) To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC You want (DEFUN (FOO exprname subrname) (...) ...). Eg, (DEFUN F (X) X) <=> (DEFUN (F EXPR SUBR) (X) X) -kmp  Date: 28 JUL 1980 1913-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC (DEFUN (FOO BAR) (X) X) in compiled code causes FOO to get a BAR property of |FOO BAR| and |FOO BAR| to get a SUBR property. How can I get FOO to have a BAR property which is the SUBR property in question without the generation of the symbol |FOO BAR| which is useless for my purpose.  Date: 28 JUL 1980 1812-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (DELETE 'A '(A B C) 1.5) in a fresh lisp does a ILOPR; A>>SYALC+17 0/ (not surprisingly) 0 SYALC+17/ SY2ALC+2,,0 How sad.  GSB@MIT-ML 07/27/80 23:16:48 Re: goddamn fucking cretinism To: (BUG LISP) at MIT-ML (valret) => .logout 1, How novel. Having a lisp in use do this to me does nasty things to my disposition however.  GSB@MIT-ML 07/27/80 07:12:21 To: (BUG LISP) at MIT-ML If BASE is ROMAN, then when the gc goes to print its statistics, when it goes to print a number which would not be printed in roman (too large), someone somewhere is doing a JSP T,FXNV1 on something which ain't a fixnum and the lisp gets blown away.  Date: 24 JUL 1980 1934-EDT From: JAR at MIT-MC (Jonathan A. Rees) Subject: Maclisp quiz To: KMP at MIT-MC, DANIEL at MIT-MC, GENSYM at MIT-MC To: (BUG LISP) at MIT-MC, SANTA at MIT-MC ;;; What does TEST return when run interpreted? ;;; What does TEST return when run compiled? (DEFUN F (()) 'BEFORE) (DEFUN G (()) 'AFTER) (DEFUN TEST () (LET ((F (GETL 'F '(SUBR EXPR))) (G (GETL 'G '(SUBR EXPR)))) (UNWIND-PROTECT (F (PUTPROP 'F (CADR G) (CAR G))) (PUTPROP 'F (CADR F) (CAR F)))))  PSZ@MIT-ML 07/23/80 22:58:35 To: (BUG LISP) at MIT-ML Timing bug in ledit tty return With the normal setup of ledit, if one types ^E interrupt while inside the tty return action of a previous ledit, the emacs is again entered, and subsequent returns get nested (I tried only two deep). Perhaps the interrupt could be locked out?  PSZ@MIT-ML 07/23/80 15:57:37 Re: GCDEMN To: (BUG LISP) at MIT-ML In response to an absence of screams in reply to the previously-announced upcoming change to GC-DAEMON, it has now been installed on LIBDOC and LIBLSP.  Date: 23 JUL 1980 1550-EDT From: PSZ at MIT-MC (Peter Szolovits) Subject: LEDIT To: (BUG LISP) at MIT-MC I have installed LEDIT's paying attention to the read hook. I note for the record that I have also inadvertantly installed some anonymous change made in the LEDIT source by RWK in February which has never been reflected in previously-installed versions.  PSZ@MIT-ML 07/23/80 15:34:55 To: (BUG LISP) at MIT-ML Ledit has a bug in that it does not look at the READ hook when reading stuff in LEDIT-TTY-RETURN. GSB and I are about to fix it.  Date: 22 JUL 1980 0622-EDT From: JONL at MIT-MC (Jon L White) Subject: SHARPM oddities To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 20 July 1980 03:39-EDT From: Kent M. Pitman Subject: Typo in SHARPM . . . I note that /#-CNTRL-META-IFY has a bug in it. The line that claims to extract the C-M- bits actually only extracts M-bits. You probably want CADDR instead of CADR. -kmp Fixed. tnx muchly. Date: 20 July 1980 03:47-EDT From: Kent M. Pitman From "NILCOM;SHARPM >" ... (comment NIL-type defsharps for maclisp) #-NIL (progn 'COMPILE ----- Shouldn't that be #+NIL ...? NIL-/#-MACRO-DATALIST seems to get set up even in non-NIL environments currently -- that seems like a waste ... Definetly not. The idea is that general maclisp code has to be able to support a minimal abount of NIL-type defsharps so that things like '(a #-NIL frob #N #B"101011" c) can even be read in. ALAN's suggestion was used here - namely the code for these defshaprs will live, but is activated (thru the use of the varialbe NIL-/#-MACRO-DATALIST) only when under a #N conditinal; in a pseudo-NIL environment (like the NIL simulator, or NILAID), more serious defsharping takes place. The extra burden for maclisp to be able to pass over #N code is only about a 10% increast to the SHARPM package. 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.  Date: 20 JUL 1980 0843-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC TTSR/| is a SUBR but has no args information in the initial environment.  Date: 20 JUL 1980 0819-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Spurious AUTOLOAD property on sym HUMBLE ...? To: (BUG LISP) at MIT-MC The symbol HUMBLE has an autoload property of ((LISP) HUMBLE FASL) but that file does not define any function called HUMBLE. I suspect the autoload property is just an error? -kmp  Date: 20 JUL 1980 0442-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC +INTERNAL-AUTOLOAD has no args information associated with it, even though it is a SUBR. -kmp  Date: 20 JUL 1980 0347-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: More SHARPM oddities To: (BUG LISP) at MIT-MC CC: NIL-I at MIT-MC From "NILCOM;SHARPM >" ... (comment NIL-type defsharps for maclisp) #-NIL (progn 'COMPILE ----- Shouldn't that be #+NIL ...? NIL-/#-MACRO-DATALIST seems to get set up even in non-NIL environments currently -- that seems like a waste ...  Date: 20 JUL 1980 0344-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (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  Date: 20 JUL 1980 0339-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Typo in SHARPM To: (BUG LISP) at MIT-MC Looking over the source to SHARPM, I note that /#-CNTRL-META-IFY has a bug in it. The line that claims to extract the C-M- bits actually only extracts M- bits. You probably want CADDR instead of CADR. -kmp  Date: 19 July 1980 21:15-EDT From: Robert W. Kerns Subject: For Your Amusement? To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 19 July 1980 07:38-EDT From: Kent M. Pitman To: BUG-LISP Re: For Your Amusement? ... While I'm thinking about it, the ^B function seems to not be defined in break loops. Typing ^B at toplevel in a fresh lisp works fine, but for some reason once in a break loop, it doesn't work any more. -kmp Huh? Typing ^B once in a break loop works just fine for me, it gives me a recursiev break loop. Perhaps something funny in your environment?  Date: 19 JUL 1980 0755-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: ERR errs out badly ... To: (BUG LISP) at MIT-MC (ERRSET (PROGN (ERRSET (ERR ) NIL) T) NIL) ; => (T) (ERRSET (PROGN (ERRSET (ERR (ERR) T ) NIL) T) NIL) ; => (T) (ERRSET (PROGN (ERRSET (ERR (ERR) ) NIL) T) NIL) ; => (T) (ERRSET (PROGN (ERRSET (ERR (ERR) NIL) NIL) T) NIL) ; loses with: PURPG; ERR1+3>>HRRES -2(P) ERR3A+3/ EXCH T,-14(P) Aren't (ERR (ERR)) and (ERR (ERR) NIL) supposed to be the same? The old lisp manual documents them as being the same. Even just doing (ERR (ERR)) and (ERR (ERR) NIL) at toplevel differ -- (ERR (ERR)) gives a *RSET- type breakpoint where (ERR (ERR) NIL) does not. I find no documentation in .INFO.;LISP NEWS about any changes to the ERR function. -kmp  Date: 19 JUL 1980 0738-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: For Your Amusement? To: (BUG LISP) at MIT-MC (ERR 'a 'b 'c 'd) generates an error. That's what err with the right number of args would have done. I think (ERR 'a 'b 'c 'd) should *not* err out, so that I can tell something is the matter. While I'm thinking about it, the ^B function seems to not be defined in break loops. Typing ^B at toplevel in a fresh lisp works fine, but for some reason once in a break loop, it doesn't work any more. -kmp  Date: 19 JUL 1980 0535-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Just for the record ... To: (BUG LISP) at MIT-MC (DEFUN&) => NIL (PLIST 'NIL) => (EXPR (LAMBDA NIL (COMMENT ARGLIST = NIL))) (NIL) ;NIL UNDEFINED FUNCTION OBJECT Yes, I realize this is hard to get NIL to do correctly -- presumably EVAL is looking at NIL's other CDR ... Mostly just noting this oddity for the record. (DEFUN NIL NIL NIL) gives the same bug. Perhaps these guys should complain about bad format to DEFUN or something, for the case where some macro (eg, DEFUN&) produces them without realizing it ... -kmp  Date: 19 July 1980 0223-EDT From: Dave Touretzky at CMU-10A Subject: LINEREAD broken To: bug-lisp at MIT-MC LINEREAD under Tops-10 MacLisp generates ?ill mem refs. Both the compiled and the interpreted versions die. Single stepping through the interpreted version, it tried to do (RETURN (NREVERSE LIST-OF-FORMS)), but when RETURN tried to return NIL I got blown out to the monitor by the ill mem ref. I tried this both in normal CMU MacLisp (with LINMODE set to T, and setsyntaxed to act like ) and in a bare MacLisp with no init file. Nothing helped.  Date: 18 JUL 1980 2237-EDT From: MOON at MIT-MC (David A. Moon) Subject: Iterated SETF To: RICH at MIT-AI CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC Since the field definitions can be completely arbitrary, there can be no possible elegant way of doing this with run-time variable structure field references. If you only want a constant set of field definitions you can use a macro such as the one GLS suggested, although for clarity you probably don't want to use a MAPCAR-like syntax; maybe something more like SETQ, e.g. (MULTI-SETF field-name value-expression field-name value-expression ...) => (LET ((.TEMP. )) (SETF (field-name .TEMP.) value-expression) ...)  Date: 18 JUL 1980 1731-EDT From: JONL at MIT-MC (Jon L White) Subject: MAPF To: GLS at MIT-MC, RICH at MIT-MC CC: GJS at MIT-MC, DANNY at MIT-MC, (BUG LISP) at MIT-MC CC: (BUG LISPM) at MIT-MC Say, just a reminder that NIL has snarfed the name MAPF as a kind of generalized mapper (see MC:NIL;NEWFUN >, and search for MAPF). Date: 18 July 1980 16:59-EDT From: "Guy L. Steele, Jr." . . . (DEFMACRO MAPF (STRUCT FIELDS LIST) (DO ((F FIELDS (CDR F)) . . . . . . (MAPF A-FOO (FOO-REG FOO-VAL FOO-INDEX) (HACK-UP-A-3-LIST)) Also, is there any intention for this suggestion to take non-constant lists of fields? Date: 18 July 1980 15:58-EDT From: Charles Rich . . . (MAPC #'(LAMBDA (F) (SETF (F STRUC) NIL)) '(FIELD1 FIELD2 FIELD3 ...)) For examply, would you want to do (MAPC #'(LAMBDA (F) (SETF (F STRUC) NIL)) (MUMBLIFY)) ?  Date: 18 July 1980 16:59-EDT From: "Guy L. Steele, Jr." To: RICH at MIT-AI cc: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI, DANNY at MIT-AI, GJS at MIT-AI How about (DEFMACRO MAPF (STRUCT FIELDS LIST) (DO ((F FIELDS (CDR F)) (J 0 (+ J 1)) (SETS '() (CONS `(SETF (,(CAR F) %%STRUCT%%) (NTH ,J %%LIST%%)) SETS))) ((NULL F) `(LET ((%%STRUCT%% ,STRUCT) (%%LIST%% ,LIST)) ,@SETS)))) (MAPF A-FOO (FOO-REG FOO-VAL FOO-INDEX) (HACK-UP-A-3-LIST)) ?  Date: 18 July 1980 15:58-EDT From: Charles Rich To: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI cc: DANNY at MIT-AI, GJS at MIT-AI I am having trouble figuring out an elegant way to write a function which maps down a list of access functions, (e.g. the fields of a DEFSTRUCT), performing a SETF for each one. For example, I would like something of the following flavor to work (which obviously doesn't because F is not evaluated at the right time in the SETF). (MAPC #'(LAMBDA (F) (SETF (F STRUC) NIL)) '(FIELD1 FIELD2 FIELD3 ...)) This seems like a reasonable repetitive action which it should be easy to specify succintly in the general framework of SETF, LOCF, etc. I appeal to the wizards to show me how to do this nicely; or perhaps this suggests some new macro or extension to SETF. Thanks, Chuck.  Date: 18 JUL 1980 0527-EDT From: JONL at MIT-MC (Jon L White) Subject: YESNOP To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, NIL-I at MIT-MC The handler for the query-io SFA was admitting a "FRESHLINE" operation -- according to all sources I can find, this should have been "FRESH-LINE", and that may account for some anomalous behaviour I've seen recently. I've edited LSPSRC;YESNOP > and recompiled onto LISP;.  Date: 18 JUL 1980 0409-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Request for change to Lisp Source comment To: (BUG LISP) at MIT-MC the lisp source claims that bit 4.7 of OR OR is turned on (syntax bit for reader). Only and have this bit now. This is in second bit table toward top of L;READER. -kmp  Date: 17 JUL 1980 1556-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: READCH To: NIL at MIT-MC CC: (BUG LISP) at MIT-MC Shouldn't things like ASCII and READCH take optional trailing args saying what obarray you want them to intern the symbol on? Just a thought ...  Date: 17 JUL 1980 0115-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: NIL-I at MIT-MC An EQUAL method for STRUCT-CLASS has been defined which does component-wise comparison rather than simply punting to OBJECT-CLASS (which assumes () ). This can, of course, be overridden with individual structure types by giving them an EQUAL method of their own. This was judged a more flavourful default than (EQUAL (CONS-A-FOO BAR 5) (CONS-A-FOO BAR 5)) ==> () If you disagree, flame now.  Date: 16 July 1980 17:55-EDT From: Howard I. Cannon Subject: Atomic Macros To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC, "GJC@MIT-MC PSZGJC@MIT-MC PSZ" at MIT-MC, LIL at MIT-MC I pretty much agree with Alan, and do not think atomic macros should be in MacLisp or LMLisp at the moment.