GSB@MIT-ML 11/07/79 09:24:38 To: (BUG LISP) at MIT-ML Why is copysymbol a no-op on NIL? Why don't we just make the convention that if any function gets called with NIL as a first argument, it always returns NIL? THen we can cause the evaluator and compiler to observe this convention and speed up code a lot.  Date: 7 November 1979 07:45-EST From: Robert W. Kerns To: JONL at MIT-MC cc: KMP at MIT-MC, BUG-LISP at MIT-MC Date: 7 November 1979 01:38-EST From: Jon L White To: KMP cc: BUG-LISP Date: 1 OCT 1979 1624-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Could we please get a LINKF command to link ITS files together so that we don't have to use SYSCALL or VALRET, both of which are op-sys dependent. Thanx. -kmp Well, LINKF is totally op-sys dependent, since only ITS has it. False. ITS, Multics, hopefully someday VMS, Hopefully someday UNIX. Current UNIX and current VMS have something similar but not quite the same.  Date: 7 November 1979 07:40-EST From: Robert W. Kerns Subject: Rem's bug To: BUG-LISP at MIT-MC Date: 7 November 1979 06:45-EST From: Robert W. Kerns To: BUG-LISP Re: Rem's bug REM;SYSCAL > had bugs in it that weren't LISP's bugs, so forget last message. However, it now gives FXPDL out of phase error. Don't know who's doing it yet. Hmm. This is due to SYSCALL not checking it's first argument carefully enough. It should complain if the right-half is not a reasonable number of return values.  Date: 7 NOV 1979 0645-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: Rem's bug To: (BUG LISP) at MIT-MC REM;SYSCAL > had bugs in it that weren't LISP's bugs, so forget last message. However, it now gives FXPDL out of phase error. Don't know who's doing it yet.  Date: 7 NOV 1979 0352-EST From: RWK at MIT-MC (Robert W. Kerns) Subject: +TYO lossage To: (BUG LISP) at MIT-MC CC: REM at MIT-MC (LOAD '|REM;SYSCAL >|) ;echoing is turned off (DO () (()) (+TYO 100 HEX-OUT)) watch it get an IOC error. CHNTB+4 has HEX-OUT, but channel 4 is closed. Who closed it?  Date: 7 November 1979 02:43-EST From: Robert W. Kerns Subject: MACLISP ON VAX To: MILLER at MIT-AI cc: JONL at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC, Steve at SRI-KL, Fin at MIT-ML Date: 3 NOV 1979 1229-EST From: MILLER at MIT-AI (Mark L. Miller) To: Steve at SRI-KL cc: Fin at MIT-ML, Jonl, KMP, (BUG Lisp) Re: MACLISP ON VAX Dear Steve, In Reply To: Date: 2 Nov 1979 1125-PST From: Steve at SRI-KL (Steve Rosenberg) I am exploring ways to get MACLISP up on a VAX, under VMS. I wonder whether you have anything to tell me about this. I know NIL will eventually be up, and that FRANSLISP runs, under UNIX-7. Due to constraints of various kinds, i must use the VMS operating system, and I can't wait a year till NIL is up. So far, the best scheme seems to be to hire someone to bring up FRANSLISP under VMS, and iron out any differenences between it and MACLISP. Good luck! The only current programming languages under VMS are Fortran and Assembler; Pascal may appear thru DECUS soon. It will take you more than a year to do ANYTHING yourself -- and who can you POSSIBLY hire that is any good? (LISP implementors are a pretty scarce breed; I am happy if I can find systems people who have HEARD of it!) This is untrue. I don't know ALL the languages available, but they include BLISS, C, COBOL, APL, and others. I've heard rumours about PL1. Since Franz is written in C, for the price of a UNIX license (or maybe less) you can get a C that runs under VMS and start hacking. I don't know how easy it would be... We, too, are using VMS, as is MIT, even though the entire rest of the world is going over to UNIX. What I suggest is: (a) don't try to use a VAX for at least another year (what EDITOR are you going to use?); (b) if you have no choice, talk to Ken Keller and Bill Joy (UCB grad students) and get the UNIX-UNDER-VMS emulator from a company in San Diego (we are probably going to get this, it includes a UNIX license and is NOT CHEAP however, I think probably >$50K) and then just LIVE WITH FRANZ until NIL is done. Bob Balzer is threatening to put INTERLISP on the Vax, but again, it will be more than a year. There are also various FORTRAN-4 LISPS (probably awful) which MIGHT work. If you can live with 16-bit addresses (i.e., 2**16 byte or less programs, compared to 2**18 WORDS (x4.5 bytes/wd) on a PDP10), you might get MARYLAND PDP-11 ULISP which should run in EMULATOR MODE. My advice is: if you can get on a PDP10 or DEC20, wait a year or two. Hope the world is otherwise treating you ok! Regards, Mark My advice is, work harder at getting a UNIX license, and DON'T wait. Winning software won't happen unless people work on it. But don't depend on getting anything useful done for another year.  KEN@MIT-AI 11/07/79 02:41:34 To: JONL at MIT-MC CC: (BUG LISP) at MIT-AI regarding Date: 7 NOV 1979 0147-EST From: JONL at MIT-MC (Jon L White) KEN@MIT-AI 11/03/79 02:04:21 To: (BUG LISP) at MIT-AI Try typing the following (progn (tyipeek) (read)) The problem is that the read does not return until another read is performed. On the Lisp Machine this code works fine (ie the tyipeek has no affect) Although I seem to remember some such bug under pdp10 maclisp, the above example didn't invoke it - just what did you type after that form? (progn(tyipeek) (read))1 2 for example. (lisp 1861)  Date: 7 NOV 1979 0147-EST From: JONL at MIT-MC (Jon L White) To: KEN at MIT-MC CC: (BUG LISP) at MIT-MC KEN@MIT-AI 11/03/79 02:04:21 To: (BUG LISP) at MIT-AI Try typing the following (progn (tyipeek) (read)) The problem is that the read does not return until another read is performed. On the Lisp Machine this code works fine (ie the tyipeek has no affect) Although I seem to remember some such bug under pdp10 maclisp, the above example didn't invoke it - just what did you type after that form?  Date: 7 NOV 1979 0138-EST From: JONL at MIT-MC (Jon L White) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 1 OCT 1979 1624-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Could we please get a LINKF command to link ITS files together so that we don't have to use SYSCALL or VALRET, both of which are op-sys dependent. Thanx. -kmp Well, LINKF is totally op-sys dependent, since only ITS has it.  Date: 7 NOV 1979 0122-EST From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC ALAN@MIT-AI 10/11/79 01:30:59 To: (BUG LISP) at MIT-AI It looks to me like lisp will only ask for jcl when both the OPTCMD and OPTBRK bits are set in .OPTION . This makes it hard to pass jcl to an inferior lisp, because you have to handle all .BREAKS . It seems to me that if you do a (status jcl) and OPTCMD is set, then that is enough to justify interrupting your superior. I've just edited the source to accomodate this suggestion - should be out in LISP version number 1876 or greater.  Date: 7 November 1979 00:53-EST From: Robert W. Kerns Subject: #\ To: JONL at MIT-MC cc: GSB at MIT-MC, BUG-LISP at MIT-MC Date: 6 November 1979 22:54-EST From: Jon L White To: GSB cc: BUG-LISP Re: #\ GSB@MIT-ML 11/02/79 07:18:54 Re: sharpm, #\ To: (BUG LISP) at MIT-ML HELP and NEWLINE (abbrev NL ?) should be known. CR is an obsolete character from the days of Shitty 33's. Within the ascii alphabet, what suggestions do you propose? #\NEWLINE seems destined for 13., but what about #\HELP ? #\HELP = #O4110  Date: 6 NOV 1979 2254-EST From: JONL at MIT-MC (Jon L White) Subject: #\ To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 11/02/79 07:18:54 Re: sharpm, #\ To: (BUG LISP) at MIT-ML HELP and NEWLINE (abbrev NL ?) should be known. CR is an obsolete character from the days of Shitty 33's. Within the ascii alphabet, what suggestions do you propose? #\NEWLINE seems destined for 13., but what about #\HELP ?  Date: 4 November 1979 01:25-EST From: Jeffrey I. Schiller To: JONL at MIT-AI cc: BUG-LISP at MIT-AI Jonl, I told you the other day that TOPS-20 MacLisp had the problem of not allowing me to open stream oriented devices. I believe this is a similar problem to that which Mark Miller has described, I have patched it on SPEECH-TWENEX, the reason for lossage was because the SIZEF call in the open code was failing (obviously for a stream oriented device) and the error code was considered fatal when it shouldn't have been. -Jeff  Date: Saturday, 3 November 1979 2046-EST From: Scott.Fahlman at CMU-10A Subject: PTYs in MACLISP To: Dave.Touretzky at CMU-10A, Leonard.Zubkoff at CMU-10A CC: bug-lisp @ mit-mc Message-ID: <03Nov79 204632 SF50@CMU-10A> I think I found the problem that prevented opening DEC-10 PTYs in TTY mode. The file NMOBY on the MACLISP dir is a moby with this problem patched out. I suggest that you two do whatever it was you wanted to do with PTYs and subjob control, and if no problems crop up, I will ask JONL to fix the universal source. One problem you should be aware of in NMOBY: it has a DDT linked into the image, and for some reason this makes ^G cause a fatal error. If you want to ^G, do a ^C to the system, REENTER, and type G to the prompt. That works OK. JONL -- In case you're wondering, the problem is at the start of the IFN D10 block following OPEN1P. There is CAME test for device name TTY there that needs to be augmented to test for PTY as well, so that these too can open in TTY SINGLE mode. I have temporarily smashed the CAME at OPEN1P+2 to a SKIPA to create NMOBY. Probably best to wait until this is tortured a bit before smashing the source, unless perhaps you're doing a new version anyway. Cheers, Scott  Date: 3 NOV 1979 1229-EST From: MILLER at MIT-AI (Mark L. Miller) Subject: MACLISP ON VAX To: Steve at SRI-KL CC: Fin at MIT-ML, Jonl at MIT-MC, KMP at MIT-MC, (BUG Lisp) at MIT-MC Dear Steve, In Reply To: Date: 2 Nov 1979 1125-PST From: Steve at SRI-KL (Steve Rosenberg) I am exploring ways to get MACLISP up on a VAX, under VMS. I wonder whether you have anything to tell me about this. I know NIL will eventually be up, and that FRANSLISP runs, under UNIX-7. Due to constraints of various kinds, i must use the VMS operating system, and I can't wait a year till NIL is up. So far, the best scheme seems to be to hire someone to bring up FRANSLISP under VMS, and iron out any differenences between it and MACLISP. Good luck! The only current programming languages under VMS are Fortran and Assembler; Pascal may appear thru DECUS soon. It will take you more than a year to do ANYTHING yourself -- and who can you POSSIBLY hire that is any good? (LISP implementors are a pretty scarce breed; I am happy if I can find systems people who have HEARD of it!) We, too, are using VMS, as is MIT, even though the entire rest of the world is going over to UNIX. What I suggest is: (a) don't try to use a VAX for at least another year (what EDITOR are you going to use?); (b) if you have no choice, talk to Ken Keller and Bill Joy (UCB grad students) and get the UNIX-UNDER-VMS emulator from a company in San Diego (we are probably going to get this, it includes a UNIX license and is NOT CHEAP however, I think probably >$50K) and then just LIVE WITH FRANZ until NIL is done. Bob Balzer is threatening to put INTERLISP on the Vax, but again, it will be more than a year. There are also various FORTRAN-4 LISPS (probably awful) which MIGHT work. If you can live with 16-bit addresses (i.e., 2**16 byte or less programs, compared to 2**18 WORDS (x4.5 bytes/wd) on a PDP10), you might get MARYLAND PDP-11 ULISP which should run in EMULATOR MODE. My advice is: if you can get on a PDP10 or DEC20, wait a year or two. Hope the world is otherwise treating you ok! Regards, Mark  KEN@MIT-AI 11/03/79 02:04:21 To: (BUG LISP) at MIT-AI Try typing the following (progn (tyipeek) (read)) The problem is that the read does not return until another read is performed. On the Lisp Machine this code works fine (ie the tyipeek has no affect)  GSB@MIT-ML 11/02/79 07:18:54 Re: sharpm, #\ To: (BUG LISP) at MIT-ML HELP and NEWLINE (abbrev NL ?) should be known. CR is an obsolete character from the days of Shitty 33's.  GLR@MIT-AI 11/01/79 20:30:47 To: (BUG LISP) at MIT-AI (describe allfiles) says that the arg to allfiles is a namelist. Actually it is a list of namelists.  Date: 1 NOV 1979 1704-EST From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC, (BUG MACSYMA) at MIT-MC That problem with COMPGRIND:TRUE in macsyma is really a lisp grinder bug I think.  Date: 31 OCT 1979 1123-EST From: MOON at MIT-MC (David A. Moon) Subject: DOLIST To: GLS at MIT-AI CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC Unfortunately there are a lot of useful generalizations of DOLIST. I think we decided to hold the line and not make any extensions, to keep it simple and easy to understand. You can always use this LOOP crock (not yet installed), which is like FOR in Interlisp and LIBLSP;FOR, except cleaned up and made less crockish. e.g. (LOOP FOR var1 IN list1 FOR var2 IN list2 ... DO body)  KEN@MIT-AI 10/30/79 21:55:38 Re: Effect of CR in symbols (in respnse to RWK's message) To: (BUG LISP) at MIT-AI I agree with RWK. I remember when first learn ing Lisp being very confused about the way CRs were ignored in such cases.  Date: 30 OCT 1979 2258-EST From: JONL at MIT-MC (Jon L White) Subject: Eror msg for #123R10 To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Changed, to be more informative.  Date: 30 October 1979 16:33-EDT From: Alan Bawden To: JONL at MIT-MC, ALAN at MIT-MC cc: BUG-LISP at MIT-AI Date: 30 OCT 1979 1049-EDT From: JONL at MIT-MC (Jon L White) ALAN@MIT-AI 10/30/79 01:26:17 To: (BUG LISP) at MIT-AI #123r10 should read as 173 (octal) not an error. (ai:lisp;sharpm fasl) According to all maclisp documentation, "ibase"s can only be between 1 and 36., since there are no general ways to get digits beyond "Z". Additionally, beware of the following: due to the ambiguity of syntax, the number part of a #nR must be preceeded with a "+" or "-" if it has non-decimal digits. This latter point is documented in the NEW RECENT, and for maclisp in general. (because, in general "1A" would be taken as a symbol instead of a number.) Then the error message should be fixed.  GLS@MIT-AI 10/30/79 11:33:48 Re: DOLIST To: (BUG LISPM) at MIT-AI CC: (BUG LISP) at MIT-AI, GLS at MIT-AI I would find it useful if DOLIST were compatibly generalized to more than one list. If the first argument form had a non-atomic car, then it would be a list of variable specifications: (DOLIST ((FOO LIST1) (BAR LIST2)) . body) and FOO and BAR would take on successive elements of their respective lists.  Date: 30 OCT 1979 1057-EDT From: JONL at MIT-MC (Jon L White) Subject: Where is SHARPM To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 10/30/79 01:28:38 To: (BUG LISP) at MIT-ML Why are there 2 different SHARPMs - one on LIBLSP, one on LISP? Is this for real or is one just outdated? The one on LIBLSP is older. The one on LIBLSP is no longer for real - I suppose it should be a link to the one on LISP, as is the case on MC. But the source, which may be slightly-out-of-date on ML and AI should live on LIBDOC (master source is on NILCOM at MC).  Date: 30 OCT 1979 1049-EDT From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC ALAN@MIT-AI 10/30/79 01:26:17 To: (BUG LISP) at MIT-AI #123r10 should read as 173 (octal) not an error. (ai:lisp;sharpm fasl) According to all maclisp documentation, "ibase"s can only be between 1 and 36., since there are no general ways to get digits beyond "Z". Additionally, beware of the following: due to the ambiguity of syntax, the number part of a #nR must be preceeded with a "+" or "-" if it has non-decimal digits. This latter point is documented in the NEW RECENT, and for maclisp in general. (because, in general "1A" would be taken as a symbol instead of a number.)  GSB@MIT-ML 10/30/79 01:28:38 To: (BUG LISP) at MIT-ML Why are there 2 different SHARPMs - one on LIBLSP, one on LISP? Is this for real or is one just outdated? The one on LIBLSP is older.  ALAN@MIT-AI 10/30/79 01:26:17 To: (BUG LISP) at MIT-AI #123r10 should read as 173 (octal) not an error. (ai:lisp;sharpm fasl)  MILLER@MIT-AI 10/29/79 01:20:57 Re: Default Syntax Preferences To: (BUG LISP) at MIT-MC I would like it if CR broke symbols, and was significant in strings, provided it could be made invisible by some "continuation" syntax (perhaps \ which I think has been proposed to do that?). It would also be nice if there were a distinction between right and left string delimiters (e.g., for debugging purposes) just as between list delimiters. I realize standard charset does not encourage such a distinction. Perhaps $" for left" (thats a dollar) and "$ for right" ... altho that is more to type. (View this not so much as a specific proposal, but as a problem I wish I knew how to solve.) Mark  GSB@MIT-ML 10/28/79 19:59:07 To: (BUG LISP) at MIT-ML (princ 'foo t) is still not the same as (princ 'foo '(t)) wrt listening to ^W.  GSB@MIT-ML 10/28/79 02:19:55 To: (BUG LISP) at MIT-ML clear-input and clear-output don't work on SFAs.  Date: 27 October 1979 02:23-EDT From: Robert W. Kerns To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 27 October 1979 01:14-EDT From: George J. Carrette To: BUG-LISP In L;ARITH > I noticed a few SQRT algorithms, some of which were titled "another old sqrt algorithm". Q: Which one do you get when you do (SQRT ...) ? The sequence COMMENT | ...| is a comment, so the algorithms which have that around them are commented out. The current one is the last one found. The one that GLS says he doesn't understand (in the comments preceeding), by Kahil.  Date: 27 OCT 1979 0211-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, NIL at MIT-MC Would it cause any problems or be too hard for the number scanner to ignore commas? JPG and probably others would like to be able to group digits of their numbers... Also, comma-return could be ignored (why not, it's quite unambiguous).  Date: 27 OCT 1979 0114-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC In L;ARITH > I noticed a few SQRT algorithms, some of which were titled "another old sqrt algorithm". Q: Which one do you get when you do (SQRT ...) ?  Date: 26 OCT 1979 0029-EDT From: RWK at MIT-MC (Robert W. Kerns) To: rpg at SU-AI CC: (BUG LISP) at MIT-MC Great. Then you also think it's OK for |foo bar| to be the same as |foo/ bar| ? If so, then we agree?  Date: 25 Oct 1979 2030-PDT From: Dick Gabriel To: bug-lisp at MIT-AI 25-Oct-79 2011 Robert W. Kerns CR convention change Date: 25 October 1979 20:08-EDT From: Robert W. Kerns Subject: CR convention change To: RPG at MIT-MC cc: BUG-LISP at MIT-MC Date: 25 October 1979 07:27-EDT From: Jon L White To: BUG-LISP Re: CR convention change Some mail that didn't get forwarded Date: 22 Oct 1979 1156-PDT From: Dick Gabriel Subject: Ok What the hell is the new CR change? I assumed, until today, that this was only to affect vertical-bar macros. Now it looks like it is to be valid in all atoms? If the latter, we object and don't want the new code, if the former, sure. Would you elaborate? What are your objections? How strongly do you hold them? How do you feel about the change being only inside vertical bars? (I think the change is as important outside as inside, but am willing to at least consider the idea that they should be considered separately). If the rest of the world did this, are there different conditions at SAIL (political, operating-system, editing, or whatever) that make it necessary to be different? If it were made SAIL-only for outside, and everybody kept CR's in vertical bars, I can't see any real problem with transportability, so my main objection to SAIL doing whatever they want wouldn't hold in that case. Care to fill us in on the rest of your opinion on this issue? It sounds as though you are arguing for a convention we have had for years, namely, that foobar => foobar not foobar. I forgot that ITS did thatwrong. I hope that inside vertical bars it will be consistent after the change. -rpg-  Date: 25 October 1979 23:26-EDT From: Robert W. Kerns Subject: Effect of CR in symbols To: SJOBRG at MIT-AI cc: BUG-LISP at MIT-MC Date: 10/21/79 15:49:17 From: SJOBRG at MIT-AI To: (BUG LISP) at MIT-AI Re: Effect of CR in symbols I think should be a break character identical to space. Does the proposed change mean just that, or something else? It does NOT mean it is identical to space, which I don't think you mean either. Consider |FOO BAR| I don't think you mean to claim this should be the same as |FOO BAR|. If you mean "It should break symbols when unquoted, just like SPACE", then yes.  Date: 25 October 1979 23:21-EDT From: Robert W. Kerns Subject: CR To: GJC at MIT-MC cc: BUG-LISP at MIT-MC Date: 21 October 1979 19:26-EDT From: George J. Carrette To: BUG-LISP Re: CR Uhm, the only changes it would make in my code is it would add extra CR's to stuff inside |...| The example is this: (DOCUMENT-MACRO DOC1 '| text......./ kdkdkjfjdk/ | ) That is, I use the first hidden CR to make it easier to line up the document text. But slashing all the CR's I want is also a pain. So I'd rather have the extra CR ... What's wrong with: (DOCUMENT-MACRO DOC1 ' |text....... kdkdkjfjdk | ) Which is less extra characters on each line?  Date: 25 October 1979 22:56-EDT From: Robert W. Kerns Subject: CR in symbols and strings To: RLB at MIT-MC cc: BUG-LISP at MIT-MC Date: 22 October 1979 08:20-EDT From: Richard L. Bryan To: BUG-LISP Re: CR in symbols and strings I've been waiting for that for years. However, there's always the issue of compatibility with files written by older MacLISPs. What happens if a symbol with FLATSIZE > linel is written? MacLISP currently offers no line continuation character sequence, and either one would be needed, or else we'd have to decide that it would be ok to write past linel. My answer is that we should decide that it's ok to write past linel if we don't have a choice.  Date: 25 October 1979 22:51-EDT From: Robert W. Kerns To: BUG-LISP at MIT-MC cc: EAK at MIT-MC Date: 22 October 1979 10:51-EDT From: Earl A. Killian To: RWK Re: Effect of CR in symbols I was sort of grossed out that FOOBAR read in as FOOBAR instead of FOOBAR. I think it is highly non-obvious. When I complained, the reason I got was that PRINT liked to print FOOBAR as FOOBAR to avoid overflowing the linel. Seems poor to me. That indeed was part of the original reason. The decision dates from before ITS handled breaking of lines, I think.  Date: 25 October 1979 22:49-EDT From: Robert W. Kerns Subject: CR in LISP To: RBRN at MIT-AI cc: BUG-LISP at MIT-MC Date: 10/22/79 11:33:26 From: RBRN at MIT-AI To: (BUG LISP) at MIT-AI, rwk Re: CR in LISP Although there probably are not many programs that depend on CR being ignored, there are (or at least historically were) several programs that groveled over LISP code, and introduced CRs where none were before. For this reason the syntax of CR should be left alone. Besides, what would be the purpose of such a change? Anyway, for your own use you could probably just modify the syntax via your own LISP init file. What programs are these? Are there any still in use? If you mean GRIND, it hasn't done that in many years. I can't think of any reason why a reasonable program would introduce CR's in the middle of an atom. The purpose of the change is to make things more compatible with the rest of the world. Currently, ITS MACLISP is incompatible with Multics MacLisp even. The LISP Machine already does things this way; wouldn't you like your code to be compatible between it and ITS? Obviously, this has nothing to do with my own use. It would be a mistake for me to set it this way in my init file, since then I would be incompatible with everybody else. I think most people do want it changed.  Date: 25 OCT 1979 2125-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: RZ at MIT-MC Why isn't there an ASH function?  Date: 25 October 1979 20:08-EDT From: Robert W. Kerns Subject: CR convention change To: RPG at MIT-MC cc: BUG-LISP at MIT-MC Date: 25 October 1979 07:27-EDT From: Jon L White To: BUG-LISP Re: CR convention change Some mail that didn't get forwarded Date: 22 Oct 1979 1156-PDT From: Dick Gabriel Subject: Ok What the hell is the new CR change? I assumed, until today, that this was only to affect vertical-bar macros. Now it looks like it is to be valid in all atoms? If the latter, we object and don't want the new code, if the former, sure. Would you elaborate? What are your objections? How strongly do you hold them? How do you feel about the change being only inside vertical bars? (I think the change is as important outside as inside, but am willing to at least consider the idea that they should be considered separately). If the rest of the world did this, are there different conditions at SAIL (political, operating-system, editing, or whatever) that make it necessary to be different? If it were made SAIL-only for outside, and everybody kept CR's in vertical bars, I can't see any real problem with transportability, so my main objection to SAIL doing whatever they want wouldn't hold in that case. Care to fill us in on the rest of your opinion on this issue?  GSB@MIT-ML 10/25/79 17:43:45 Re: how about... To: (BUG LISP) at MIT-ML .entry untyi subr 003 movei ar1,(b) $untyi: jsp tt,xfosp jrst barf jfcl jsp t,fxnv1 movei a,(tt) pushj p,untyi+2 movei a,.atom T popj p, barf: exch a,ar1 wta [NOT FILE OR SFA - UNTYI!] exch a,ar1 jrst $untyi  Date: 25 OCT 1979 0727-EDT From: JONL at MIT-MC (Jon L White) Subject: CR convention change To: (BUG LISP) at MIT-MC Some mail that didn't get forwarded Date: 22 Oct 1979 1156-PDT From: Dick Gabriel Subject: Ok What the hell is the new CR change? I assumed, until today, that this was only to affect vertical-bar macros. Now it looks like it is to be valid in all atoms? If the latter, we object and don't want the new code, if the former, sure.  DKM@MIT-AI 10/24/79 20:50:10 To: (BUG LISP) at MIT-AI Changing the meaning of CR is surely a winning idea, for several reasons: 1) People read a CR as being an end-of-symbol. For example, when you see a FOO BAR you surely think of this as being two separate symbols, not one. 2) Novice LISP hackers expect a CR to terminate an atom. I know, having made this mistake myself -- I want to find the value of FOO, so I type FOO and soon begin to wonder about ITS's response time. Another place is in typing in a long list of atoms: I type a CR at the end of a line and start the next line; LISP ignores the CR, fouling things unnecessarily. 3) CR already has a meaning similar to terminate-symbol: It terminates a ; comment. Are there any reasons not to change CR? DKM  MLB@MIT-AI 10/23/79 14:56:44 To: (BUG lisp) at MIT-MC YES! I would like to see the handliing of CR changed. I get screwed by the current scheme fairly regularly.  RIVEST@MIT-ML 10/23/79 12:01:16 To: (BUG LISP) at MIT-ML I'm in favor of CR being treated as a blank!!! Ron Rivest  DLW@MIT-AI 10/23/79 02:01:29 To: (BUG LISP) at MIT-AI The change to have CRs break symbols is long overdue. By all means, put it in. As I belive the printer has been fixed to allow the operating system do the line-wraparound rather than inserting the spurious CRLFs itself, which was the only reason for the reader peculiarity anyway, I greatly doubt the number of bugs caused will be > 1% of the number of bugs averted.  Date: 23 OCT 1979 0056-EDT From: KMP at MIT-MC (Kent M. Pitman) Sent-by: TURNIP at MIT-MC Subject: 's To: (BUG LISP) at MIT-MC ... to my last note I should add that since no one has saved strings so far there is no reason strings shouldn't instantly obey the winning new convention (of making significant). Also, I wonder if PRIN1/PRINT should know to print 'strings' specially with "..." around them .......... probably not ...... just a thought, tho'. -kmp  Date: 23 OCT 1979 0054-EDT From: KMP at MIT-MC (Kent M. Pitman) Sent-by: TURNIP at MIT-MC Subject: Last minute paranoia about ignoring 's To: (BUG LISP) at MIT-MC Some points to consider ... (1) JPG claims there may be a large number of Macsyma save files with bignums broken across lines... (2) As I recall, RLB mentioned something to me a long time ago about compatibility on other sites where there is a maximum record-length and records are delimited by 's ... this might mean it is impossible for a system to store lines past a certain length for us. Probably end-of-records could be special cased in some way so that the could be meaningful in all other places -- eg, 's that occur at that boundary might be ignored? a double- at that point might be needed for intended single there ... dunno. I'm still in favor of flushing the current convention, but let's make sure nothing much will break first ...  BAK@MIT-AI 10/23/79 00:08:28 Re: Effect of CR in symbols To: (BUG LISP) at MIT-AI I am 100% for RWK's suggestion, and I wonder why this wasn't changed years ago. The only utility for the present lossage that I can think of is on operating systems that do not support automatic wrap around when typing beyond the screen limit (as ITS does). This would be the only way to enter symbols whose size is greater than the linel minus current position. The present scheme seems to help nobody and has 2 noticeable disadvantages. (1) What you see isn't what you get inside vertical bar'd symbols. This is particularly annoying because CRs don't print. Slashified CRs look just like slashes hanging in midair (which could be quoting a space for all you know). (2) Normal conventions in virtually every other parser treat CR as a delimeter for tokens. Natural language text follows similar conventions. This causes confusion, particularly with beginners.  GLS@MIT-AI 10/22/79 21:38:53 Re: Effect of CR in symbols To: RWK at MIT-MC CC: (BUG LISP) at MIT-AI, GLS at MIT-AI If you make CR significant in delimiting atoms then it is imperative that both PRIN1 and GRINDEF never ever ever break symbols across lines (for PRIN1 it would suffice to make TERPRI have the other value (I can never remember which is which) as the initial default). Otherwise one might write out code or data and then re-read it incorrectly. Some languages have an "un-slash" character which can be used to un-escape a carriage return or tab or whatever. Suppose "\" to be such a character; then writing |Foobar\ \ \ this really bites the \ \ BAG!| would be the same as writing |Foobar this really bites the BAG!|. I think Multics has such a character, for example. This is so that one can split things across lines for readability.  Date: 22 OCT 1979 1405-EDT From: ARCHY at MIT-MC (William M. York, Jr.) Subject: Effect of CR in symbols To: (BUG LISP) at MIT-MC CR should NOT be ignored. FOO BAR should be two symbols, FOO and BAR.  Date: 22 OCT 1979 1257-EDT From: REM at MIT-MC (Robert Elton Maas) Subject: Changing CR in LISP, reply/opinion To: (BUG LISP) at MIT-MC I presume the original reason for CR being ignored was that data written out to a file with finite linelength shorter than the longest atom pname or numeric value could be read back in without hassle even if the data had been broken to make it fit. How to you propose to handle this if the change is made to break atoms across crlf? (I have some programs currently that generate large BIGNUMs and write them to files. I don't know if they are broken across crlf, since this is masked by TCTYP width when I try to type it out, unless I look carefully and distinguish 72 from 78 characters.) I have always been bothered by crlf being ignored when I type in stuff, but have learned to live with it. Living with the "standard" way instead would be interesting...  RBRN@MIT-AI 10/22/79 11:33:26 Re: CR in LISP To: (BUG LISP) at MIT-AI, rwk at MIT-MC Although there probably are not many programs that depend on CR being ignored, there are (or at least historically were) several programs that groveled over LISP code, and introduced CRs where none were before. For this reason the syntax of CR should be left alone. Besides, what would be the purpose of such a change? Anyway, for your own use you could probably just modify the syntax via your own LISP init file.  LH@MIT-ML 10/22/79 09:23:29 To: (BUG LISP) at MIT-ML Yes, by all means have CR act like a space.  Date: 22 OCT 1979 0820-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: CR in symbols and strings To: (BUG LISP) at MIT-MC I've been waiting for that for years. However, there's always the issue of compatibility with files written by older MacLISPs. What happens if a symbol with FLATSIZE > linel is written? MacLISP currently offers no line continuation character sequence, and either one would be needed, or else we'd have to decide that it would be ok to write past linel.  Date: 22 OCT 1979 0353-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: RJF at MIT-MC, RWK at MIT-MC, JPG at MIT-MC One more thing: (4) I guess if this change were to go through, there should be some way to specify "continuation" for very long atoms so that one could type "continuation" and have the ignored, so that one would not be forced to run near or over linel in order to input a very long atom. This is almost necessary when using devices for later printout which have losing or blurred columns, etc.  Date: 22 OCT 1979 0331-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: RJF at MIT-MC, RWK at MIT-MC, JPG at MIT-MC I am in favor of the proposed CR change. However, it would certainly cause some trouble to MACSYMA if things were changed. (1) MACSYMA SAVE files are written to by using PRINT and CRs are generated by default in LISP when very long atoms (e.g. numbers) are printed. I do not relish having to mend user's SAVE files to support this change. Perhaps if any change here were switchable at least for some reasonable period of time while LISP stopped behaving in TERPRI NIL mode wrt printing very long atoms, things would be ok. (2) A similar problem occurs on the user input end. People would have to train themselves to overflow lines without typing CR when inputting long atoms. I suppose this is not too much to ask. (3) When I used to use ML's LPT, it used to overprint horribly when outputting atoms > its linel in length. (I.e. when no newlines were used.) Is it really the case that there are no similar lossages today, that if one tries to print out a very long atom that one will win no matter what the output device is, i.e. no obliterating overprinting will occur?  Date: 22 OCT 1979 0016-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC WHATS AN SFA ?  GRAND@MIT-AI 10/21/79 21:50:20 To: (BUG LISP) at MIT-AI Treating CR as a delimiter is just fine with me. I find it to be a lot more natural to type that way. I currently have the appropriate setsyntax in my init file to effect this.  Date: 21 OCT 1979 1926-EDT From: GJC at MIT-MC (George J. Carrette) Subject: CR To: (BUG LISP) at MIT-MC Uhm, the only changes it would make in my code is it would add extra CR's to stuff inside |...| The example is this: (DOCUMENT-MACRO DOC1 '| text......./ kdkdkjfjdk/ | ) That is, I use the first hidden CR to make it easier to line up the document text. But slashing all the CR's I want is also a pain. So I'd rather have the extra CR ...  Date: 21 OCT 1979 1904-EDT From: RJF at MIT-MC (Richard J. Fateman) To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC, JPG at MIT-MC IGNORING THE CR'S IN MACSYMA HAS THE EFFECT OF MAKING FOR I:1 THRU 10 DO PRINT(I); BE A SYNTAX ERROR : DOPRINT IS NOT AN INFIX OPERATOR... I THINK THIS IS A LOSS. I THINK IT IS A LOSS IN LISP TOO, BUT THERE MIGHT BE REASONS FOR IT THAT I DO NOT KNOW ABOUT.  ALAN@MIT-AI 10/21/79 17:08:23 To: (BUG LISP) at MIT-AI Yes, Yes, Yes. should be treated just as any other whitespace character. This has the effect that typing FOO at toplevel will read the symbol FOO, which is what I gather people mean when they talk about a force-feed character. The only objection I can see to correcting the syntax of is that the printer will have to be fixed to not output a in the middle of a symbol. This cannot be too much of a screw since I have never, never actually seen the printer do this. (The LispMachine printer doesn't output any s at all, and no one seems to mind.)  Date: 21 OCT 1979 1631-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Effect of CR in symbols To: (BUG LISP) at MIT-MC The current way CR's is handled is totally wrong. Treating them basically like space for symbols, and correctly in strings, is of course the right thing.  Date: 21 OCT 1979 1620-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Changing syntax To: (BUG LISP) at MIT-MC I think I've expressed my favor of not being ignored in atoms any more, but just for the record I thought I'd say it. Does this mean that would be like ? ... I think that would be nice too... Confuse a lot less people who wonder why does nothing...  Date: Sunday, 21 October 1979 1551-EDT From: Scott.Fahlman at CMU-10A Subject: Proposed CR change. To: bug-lisp @ mit-mc Message-ID: <21Oct79 155157 SF50@CMU-10A> I like the proposed change to the default status of CR. As a minor datum, note that the default at CMU is to set CR as a break character (we also use linemode input, mostly) so the change would not screw anyone here. -- Scott  SJOBRG@MIT-AI 10/21/79 15:49:17 Re: Effect of CR in symbols To: (BUG LISP) at MIT-AI I think should be a break character identical to space. Does the proposed change mean just that, or something else?  EB@MIT-AI 10/21/79 14:29:58 To: (BUG LISP) at MIT-AI I am in favor of the CR change. Also, a question: Is there now, or does there exist somewhere code to get, or is it possible to have, a control character that erases to beginning of line like Ctrl U does for most things on Tosp-20? I realize that this would require some kind of line-buffering, but it is terrible to have ^G and ^X be the only alternatives to lotsa rubouts. Or failing that, is there a character (or could there be) to abort the current read and do it over? I understand there would be possible problems with read-macros, but is any solution possible?  DHD@MIT-AI 10/21/79 13:19:52 Re: crs in atoms To: (BUG LISP) at MIT-AI Why not make CR a force feed character, as in lispm? This seems to be a major problem with new maclisp users as well. I definatly (sic) support the change.  APW@MIT-AI 10/21/79 13:01:03 Re: Effect of CR in symbols To: (BUG LISP) at MIT-AI A good idea.  Date: 21 OCT 1979 1058-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC For what its worth, I like RWK's suggestion about the syntax of CR.  Date: 20 OCT 1979 1246-EDT From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, BSG at MIT-MC Date: 18 October 1979 21:34-EDT From: Glenn S. Burke Subject: format of (status features) The maclisp manual claims that (car (last (status features))) is the implementation name. Actually, it was meant to mean "name of operating system type", such as TOPS-10, TOPS-20, TENEX, ITS, MULTICS . . . I have also been under the impression that (cadr (reverse (status features))) was itself significant, ie the "machine identifier" or somesuch (eg "ML"), but i don't have an old manual handy to see if it actually claims this. This is not really a "feature" - it was used in the days when the various ITS machines had to have different assemblies of LISP. But now, the same code is used on all three systems (yes, Virginia, we don't make use of the fact that the KL10 has . . .) I see however that multics maclisp now has "Maclisp" as the last element, and the lisp machine uses neither of those last elements. It would be kind of nice if these items could be found by some means other than enumeration. This might seem a bug, if we would expect the last element to be the supporting operating system name.  Date: 20 OCT 1979 0949-EDT From: JONL at MIT-MC (Jon L White) Subject: FASLP loses on twenex To: SCOTT at SRI-KL CC: (BUG LISP) at MIT-MC Gllaaag. Found, and corrected in the source. Will reassemble within a day or so (other bugs being corrected too). Tnx superly for finding this one.  Date: 20 OCT 1979 0801-EDT From: JONL at MIT-MC (Jon L White) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, KMP at MIT-MC Date: 19 OCT 1979 0640-EDT From: RWK at MIT-MC (Robert W. Kerns) "foo " ==>|foo| This is wrong, incompatible with every " macro I've ever seen. Not really - a decision long ago was that for maclisp, would be invisible unless slashed. Try typing |AB| and see what you get! One argument is that maclisp's convention is contrary to some other systems, but at least it is internally consistent.  Date: 19 Oct 1979 0425-PDT From: Scott at SRI-KL (Scott Kramer) Subject: faslp loss on twenex To: bug-lisp at MC This returns the proper value...and more. (faslp '|qtrace.fasl|) T ;FXPDL OUT OF PHASE (SYSTEM ERROR) ;BKPT *RSET-TRAP (faslp '|qtrace.lsp|) NIL ;FXPDL OUT OF PHASE (SYSTEM ERROR) ;BKPT *RSET-TRAP -------  Date: 19 OCT 1979 0640-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Foobar, " broken To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC "foo " ==>|foo| This is wrong, incompatible with every " macro I've ever seen.  Date: 19 OCT 1979 0634-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC the LISP software device should be defined on ITS! Say you have (LOAD '|LISP:FOO BAR|), it would be nice if this would work as well as (LOAD '((LISP) FOO BAR)), which happens to work merely because it's ambiguous and gives you the LISP directory.  Date: 19 OCT 1979 0356-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: INCLUDEF To: (BUG LISP) at MIT-MC, CWH at MIT-MC, RWK at MIT-MC, GLS at MIT-MC CC: KMP at MIT-MC RWK says it hasn't been officially released, so I'll make one last naming plea ... I don't think the subr version of INCLUDE ought to be called INCLUDEF. There are several families of functions in MacLISP which deal with files. They include (no pun intended) ... Family 1 - File system manipulators (fully external operations) PROBEF, RENAMEF, LINKF (non-existent, but hopefully to come soon?), DELETEF, ... Family 2 - Environment loaders (unit i/o) INCLUDE, LOAD, FASLOAD Family 3 - General I/O UREAD, UWRITE, CLOSE, OPEN, ... The first category all end in F. None of the others do. To create a function INCLUDEF would violate this rule. The transformation of INCLUDE into a subr is more akin to the creation of the group: ((BREAK . *BREAK) (THROW . *THROW) (CATCH . *CATCH)). INCLUDEF is an ugly name. I still vote for changing this to *INCLUDE. -kmp  Date: 18 October 1979 21:34-EDT From: Glenn S. Burke Subject: format of (status features) To: BUG-LISP at MIT-ML, BUG-LISPM at MIT-ML cc: BSG at MIT-ML The maclisp manual claims that (car (last (status features))) is the implementation name. I have also been under the impression that (cadr (reverse (status features))) was itself significant, ie the "machine identifier" or somesuch (eg "ML"), but i don't have an old manual handy to see if it actually claims this. I see however that multics maclisp now has "Maclisp" as the last element, and the lisp machine uses neither of those last elements. It would be kind of nice if these items could be found by some means other than enumeration. ITS people: Can't there be some hack so that the machine name will be correct if a dumped lisp is transported? Like making the last two cons cells pure, so that SHAREP will make it be correct?  Date: 18 OCT 1979 1440-EDT From: JONL at MIT-MC (Jon L White) Subject: "rubbing out" string-like tokens in maclisp To: GJC at MIT-MC CC: GSB at MIT-MC, KMP at MIT-MC, ALAN at MIT-MC, (BUG LISP) at MIT-MC THe soon-to-be-released maclisp, version 1873, has a function for " as a read-macro, but it is not initially set up (so that losers who are using it in an alphabetic way can't complain). If you do the SETSYNTAX to make it a macro, it will "rubout" the same way as | - there is a new variable holding an a-list for characters which delineate string-like tokens. To get a preview, see MC:LISP;NEW RECENT  Date: 18 OCT 1979 1436-EDT From: GJC at MIT-MC (George J. Carrette) To: GSB at MIT-ML CC: (BUG LISP) at MIT-MC, GJC at MIT-MC Well, I'll try some of your suggestions out. Its not like its very vital to have things read from the TTY in the correct way in user read macros because I want to use them mainly to make code look prettier in files. If there was a standard macro shell that acted like | acts then that would be all I would need. I want to have {cruft...n} read in as if it was (some-atom-crunching-macro |cruft...n|) then one could do explode or whatever. (SSTATUS STRING-LIKE-MACRO BALANCE { } 'some-atom-cruncher) Macros wich call READ seem to win always, ones that call TYI loose, and from your description its because of maclisps own tty pre-scanner, sounds like its easier to add a fix to the system that will cover almost all cases. Could the code for | be addapted slightly to cover this? Is balancing harder then delimiting?  GLS@MIT-AI 10/18/79 10:27:53 To: GRAND at MIT-AI CC: GLS at MIT-AI, (BUG LISP) at MIT-AI GRAND@MIT-AI 10/16/79 22:39:58 Isn't change (setq + -) to (or (equal - '+) (setq - '+)) what I said? No, you said (or (equal + '+) (setq - +)) [and in the above, the last + should not be quoted, of course].  Date: 17 OCT 1979 0942-EDT From: JONL at MIT-MC (Jon L White) To: grand at MIT-AI CC: GLS at MIT-MC, (BUG LISP) at MIT-MC GRAND@MIT-AI 10/16/79 22:39:58 To: GLS at MIT-AI CC: (BUG LISP) at MIT-AI Isn't change (setq + -) to (or (equal - '+) (setq - '+)) what I said? No, you had Change (setq + -) to (or (equal + '+) (setq + -)) I presume that the effect you want is: if you type a "+" at the top-level loop, you don't want the next value of + to be "+". Quux's rewriting of this as change (SETQ + -) to (OR (EQUAL - '+) (SETQ + -)) would accomplish this (more or less at TLEVAL).  Date: 17 October 1979 05:33-EDT From: Alan Bawden To: GJC at MIT-MC cc: BUG-LISP at MIT-AI, KMP at MIT-MC Rubout processing on the LispMachine works at all times, even in the middle of the wierdest reader macro. This is because a read is actually in process as you are typing, when you type the rubout character a throw is done out of the reader and it is re-invoked on whatever input is left as soon as you stop typing rubouts. This has the wierd side effect that syntax errors sometimes cause an error before you are even finished typing the form. GSB has a frob that does someting like this in MacLisp, but for various reasons that he will be happy to flame about, it cannot actually work in a working MacLisp environment.  Date: 17 OCT 1979 0102-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC Rub-out processing inside ones own read macros works sometimes but not all the time. You know this of course, when a usual lisp atom boundary is reached then you cannot rub out after that (in time or space). If a boundary has not been reached the rub-outs work as usual. If rub-outs never worked in user read-macros (unless the user handles them specificaly) then this would be o.k. But working for some cases but not others is not soo good. Is there a way to fix this? Can I turn off all rub-out processing (when inside the macro) and handle it myself? Can it be made to work like on the lisp machine?  GRAND@MIT-AI 10/16/79 22:39:58 To: GLS at MIT-AI CC: (BUG LISP) at MIT-AI Isn't change (setq + -) to (or (equal - '+) (setq - '+)) what I said?  GLS@MIT-AI 10/16/79 12:20:55 Re: GRAND's suggestion To: (BUG LISP) at MIT-AI CC: GRAND at MIT-AI Maybe he really wanted to change (SETQ + -) to (OR (EQUAL - '+) (SETQ + -)) ?  Date: 13 October 1979 12:09-EDT From: Robert W. Kerns To: ALAN at MIT-AI cc: BUG-LISP at MIT-MC Date: 10/11/79 01:30:59 From: ALAN at MIT-AI To: (BUG LISP) at MIT-AI It looks to me like lisp will only ask for jcl when both the OPTCMD and OPTBRK bits are set in .OPTION . This makes it hard to pass jcl to an inferior lisp, because you have to handle all .BREAKS . It seems to me that if you do a (status jcl) and OPTCMD is set, then that is enough to justify interrupting your inferior. Indeed. The test should be for existance of a superior plus %OPCMD.  Date: 13 October 1979 11:48-EDT From: Robert W. Kerns To: MACRAK at MIT-MC cc: BUG-LISP at MIT-MC Date: 12 October 1979 19:03-EDT From: Stavros M. Macrakis To: BUG-LISP I had ^D on and ground a function. I got ; new list segment added to make this a long line (defun foo (x) bar q... That is, the GC message totally screwed up the grind. I don't see how to avoid this though, unless GC messages remember what charpos they started at and restore that position at the end of the line.... The obvious thing would be for the message-printer to do a fresh-line operation before the message and a new-line after. (A fresh-line operation is like ^PA or (CURSORPOS 'A), but generalized to arbitrary streams). Probably not worth fixing in MacLisp, which is a loser anyway...  GRAND@MIT-AI 10/13/79 10:13:17 Re: sugestion for modification to top-level To: (BUG LISP) at MIT-AI Change (setq + -) to (or (equal + '+) (setq + -))  Date: 12 OCT 1979 1903-EDT From: MACRAK at MIT-MC (Stavros M. Macrakis) To: (BUG LISP) at MIT-MC I had ^D on and ground a function. I got ; new list segment added to make this a long line (defun foo (x) bar q... That is, the GC message totally screwed up the grind. I don't see how to avoid this though, unless GC messages remember what charpos they started at and restore that position at the end of the line....  Date: 11 October 1979 1215-EDT From: Dave Touretzky Subject: vops.exe and fasload bug To: bug-lisp @ mc CC: Scott.Fahlman at CMU-10A, John.McDermott at CMU-10A VOPS.EXE got moved from account A780JM01 to A312JM01. The files BORDER.MCL and XTTY.MCL are still on A780JM01 though. All files are on TEMP:. (In case you forgot, these are the files needed to demonstrate that funny fasload bug.)  ALAN@MIT-AI 10/11/79 01:33:46 Re: typo To: (BUG LISP) at MIT-AI that last sentence should end ".. interrupting you superior."  ALAN@MIT-AI 10/11/79 01:30:59 To: (BUG LISP) at MIT-AI It looks to me like lisp will only ask for jcl when both the OPTCMD and OPTBRK bits are set in .OPTION . This makes it hard to pass jcl to an inferior lisp, because you have to handle all .BREAKS . It seems to me that if you do a (status jcl) and OPTCMD is set, then that is enough to justify interrupting your inferior.  Date: 10 October 1979 1929-EDT From: Dave Touretzky Subject: strange fasload bug To: bug-lisp @ mc CC: Scott.Fahlman at CMU-10A, John.McDermott at CMU-10A There appears to be a strange bug in FASLOAD that causes it to get halfway through and then say "file not in fasload format", although under other conditions the file will load fine. To reproduce this bug, log in on CMUA and do: .mount temp: ;if temp: not already mounted .run vops[a780jm01] (lslurp a780jm01 xtty) (lslurp a780jm01 border) (configure order7) Note that the program tries to load SORT.FAS and gets an error from fasload. Also, EDIT.FAS may fail to load under the same conditions. I know the fasl files are alright; they load without trouble most of the time. But in certain weird but reproducible situations this bug shows up. Things to think about: SLURP has its own autoload handler. Perhaps the bug is in some compiled code in the SLURP package clobbering something that fasload uses. Setting the variable GC-MESSAGES to T shows that FIXNUM space is being expanded during the autoload. However, you can ^G out and call (SORT) or (EDITF) explicitly, and the second time storage does not get expanded but the error recurs. This bug is causing some grief to one of our MacLisp users. Any help you could give me on it would be appreciated.  KMP@MIT-ML 10/10/79 09:17:28 To: (BUG LISP) at MIT-ML (^ 1031. 11.) gives the error message: ;RESULT LARGER THAN FIXNUM - a To: LISP-MANUAL at MIT-ML Test, now that ML is up.  Date: 2 OCT 1979 1255-EDT From: JONL at MIT-MC (Jon L White) Subject: LISP; directory on MC To: (BUG LISP) at MIT-MC I've moved most of the "FOO TALK" and "FOO NOTE" files into AR4:LISP; , and moved a few more FASL files from LIBLSP to LISP.  Date: 2 October 1979 02:29-EDT From: Carl W. Hoffman Subject: MacLisp documentation To: BUG-LISP at MIT-MC, miller at MIT-AI, Dave.Touretzky at CMU-10A cc: Scott.Fahlman at CMU-10A Date: 1 October 1979 1954-EDT From: Dave Touretzky In-Reply-To: MILLER's message of 30 Sep 79 12:24-EST Here at CMU we have tried to reduce the seriousness of the documentation problem by producing a summary of MacLisp functions, variables, status calls, etc. It's about 25 pages long (in two-column form), and covers most of MacLisp as it exists at CMU. We plan to distribute this to students taking an introductory LISP course this week, and eventually to release it as a pocket reference. There are probably a few errors left, which is why we want to test it on the students, but anybody who wants a copy of the source file (the summary was done in SCRIBE) should send me mail. -- Dave Touretzky You should note that the Student Information Processing Board of MIT publishes an excellent introductory text on MacLisp written by Bernie Greenberg. It is not a comprehensive reference guide, but is useful for those just learning the language. It is currently being used by two introductory computer science courses at MIT (about 150 students) and is available by sending $3.00 to: Student Information Processing Board Room 39-200, MIT Cambridge, MA 02139  MILLER@MIT-AI 10/02/79 00:19:48 Re: Maclisp problems on Twenex. To: RMS at MIT-AI CC: (BUG Lisp) at MIT-MC I suppose it IS fair to say that it is more a matter of unfinished business and lack of support than incompatibility. However, it would be nice, e.g., to have a "virtual file system" defined by Lisp which does its best to work in most reasonable op sys environments. E.g, Unix seems to have this property in that if you port a Unix to your machine you get a set of file primitives, kernal calls etc. for C. In some sense, I am saying that we need coherent programming systems, not just languages. I realize it is non-trivial to make I/O etc work independently of the operating system; this is an ideal to be aimed at and achieved to a greater or lesser extent. The comment about ^C, by the way was not because of the ^C and ^Z interchange; that is just a minor nuisance. I was referring to the discussion of 7,8, and 12 bit character sets and the Lispm discussion of whether (TYI) should return 3. or something else when you hold down control key and e.g., lowercase c, uppercase C, etc. I guess I agree with the claims that the proliferations of dialects at MIT right now are a sign of life, whereas the stable state of Interlisp might be viewed as stagnation. I hope a stable state is reached, though, soon, including a reliable manual defining a single n-way compatible dialect, so i know what I am arguing for out in the (ugh) "real world". I will try to contribute some 20X tools as they grow at my site. I hope other sites will do likewise. Regards, Mark  Date: 1 October 1979 1954-EDT From: Dave Touretzky Subject: [Re: MacLisp documentation] To: bug-lisp @ mc, miller @ ai CC: Scott.Fahlman at CMU-10A In-Reply-To: MILLER's message of 30 Sep 79 12:24-EST Here at CMU we have tried to reduce the seriousness of the documentation problem by producing a summary of MacLisp functions, variables, status calls, etc. It's about 25 pages long (in two-column form), and covers most of MacLisp as it exists at CMU. We plan to distribute this to students taking an introductory LISP course this week, and eventually to release it as a pocket reference. There are probably a few errors left, which is why we want to test it on the students, but anybody who wants a copy of the source file (the summary was done in SCRIBE) should send me mail. -- Dave Touretzky  Date: 1 OCT 1979 1827-EDT From: RWK at MIT-MC (Robert W. Kerns) To: LISP-MANUAL at MIT-MC All the files are back on LSPMAN; The directory is allocated to THIRD:, so space doesn't matter that much.  Date: 1 OCT 1979 1624-EDT From: KMP at MIT-MC (Kent M. Pitman) Sent-by: ___101 at MIT-MC To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC Could we please get a LINKF command to link ITS files together so that we don't have to use SYSCALL or VALRET, both of which are op-sys dependent. Thanx. -kmp  Date: 1 Oct 1979 0609-PDT From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: MacLisp Manual (what else?) To: RWK at MIT-MC, LISP-MANUAL at MIT-MC In-reply-to: Your message of 1-Oct-79 0605-PDT I heard a rumor that RPG was writing some doc. on I/O, maybe someone should see if anything was done on that. -------  Date: 1 OCT 1979 0905-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: RWK0 at MIT-MC Subject: MacLisp Manual (what else?) To: LISP-MANUAL at MIT-MC I've created the mailing list Lisp-Manual, and you are on it. Feel free to remove yourself if you want to escape. Initially, MILLER, ELLEN, GSB, HIC, and BUG-LISP are on it. MILLER has volunteered to do some work of a yet to be determined nature. GSB, HIC, and myself have all muttered about writing up I/O. I've brought back most of the files on LSPMAN;, and will bring back the rest when TY is finished doing the dump.  Date: 1 OCT 1979 0505-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Manual To: MILLER at MIT-MC CC: (BUG LISP) at MIT-MC, ELLEN at MIT-MC Great!  Date: 1 October 1979 01:01-EDT From: Mark L. Miller Subject: MacLISP documentation To: MILLER at MIT-AI, RWK at MIT-MC cc: BUG-LISP at MIT-AI, ELLEN at MIT-MC I hereby officially volunteer to write a chapter over the next few months. This will be done in my "spare time" as a donation to a worthy cause. (The next few weeks are already committed however.) I will even try to recruit some more volunteers at TI. Regards, Mark  Date: 1 OCT 1979 0058-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: MacLISP documentation To: MILLER at MIT-MC CC: (BUG LISP) at MIT-MC, ELLEN at MIT-MC I and everyone else agrees with you 100% about needing an updated manual. Chapters 1-3 are already done, as you know, and are available. However, people ARE needed to do the rest of it. If you are volunteering, I'll get the necessary files from tape later tonight (the LSPMAN; directory), ellen can tell you what you need to know to get started, and pick what you'd like to do. Not only will you facilitate the eventual publication of this much needed manual, but you'll earn everyone's gratitude as well.  Date: 30 Sep 1979 1650-PDT From: Mark Crispin Subject: Mark Miller's comments about LISP compatability To: Miller at MIT-AI, RWK at MIT-MC, Bug-LISP at MIT-AI I must agree with Mark whole-heartedly on this point. I get questions all the time from WAITS MACLISP users who are using SCORE MACLISP for the first time which I cannot answer at all. Fortunately, the two versions aren't that skew, but a manual would be damned useful. I'm sure too that it would help the proliferation of LISPM's greatly if you could access them via the Arpanet rather than having to be at 545 Tech Sq. It would certainly end the rumors from self-appointed experts about the LISPM's performance, etc. I hate to say it, but INTERLISP is winning out at Stanford, despite efforts by a small group of people (including me) to keep MACLISP alive. INTERLISP eats SCORE alive when somebody's running it, and when there are multiple INTERLISPs you don't even want to log in unless you're in an independent pie-slice. [Of course, I should add that SCORE was purchased to run INTERLISP] -------  Date: 30 September 1979 17:20-EDT From: Robert W. Kerns Subject: Incompatibility To: MILLER at MIT-AI cc: BUG-LISP at MIT-MC I did have a long spiel in my first reply about how you're basing complaints of incompatability on Tops-20 MacLisp is wrong. I deleted it on the grounds of uneeded flaming on the obvious, but... It is definately true that many very useful things which suffer from an operating-system dependence in their implementation (ledit, etc) have never been implemented on Twenex. Tops-20 MacLisp is rather new, and hasn't had the large amount of work done on it that ITS MacLisp has. That CANNOT be considered a problem with upwards compatibility; on the contrary, that is a DOWNWARDS compatability problem. You are trying to transport heavily machine-dependent code to a less-complete MacLisp system. If you were to write an ALLFILES for 20x, the apropriate hackery for LEDIT, etc. we'd be HAPPY to distribute them, but until someone writes the code, it can't happen. Certainly, it's absurd to suggest that this reflects on our philosopy of upwards-compatibility. It does say that we are not providing ideal support for Tops-20 MacLisp. We cannot; we lack the manpower. If you have a solution to the problem of new features added conflicting with people's older features, I'd like to hear it. I do not believe it exists. However, just because there is a new LET should not break your code. It is perfectly possible to redefine LET. If it's incompatble with the standard LET it may cause some confusion for people reading your code, but that is part of the reason there has been this effort on standardizing features like LET, etc. This is part of what is necessary to be able to write transportable code. There was a proliferation of LET's, backquotes, and sharpsign-macros before, all of them slightly different. THAT was a REAL source of incompatibilities. Indeed, the biggest reason for use of the sharpsign-macro is to allow the writing of transportable code from one operating-system to another, to allow the user to make use of things which are operating-system or machine dependent, or to take advantage of features which don't exist everywhere. But as you know, these things autoload, and if you redefine them, a little confusion may result but the code will work. The only incompatible change among them is that you cannot use comma in random places anymore (it is no longer treated like whitespace). Certainly it can't hurt you much to have to delete your commas. Only 3 characters have been changed: backquote, comma, and sharpsign. As for some of the specific Twenex things you mention in your note: ^C is like ^Z on ITS. Or are you putting your LISP in some mode to trap ^Cs? I'd suggest you do the same thing EMACS does ... exchange the functions of ^Z and ^C in your program's. I.e. don't expect to see any ^C's get tyi'd. Note you'll have to do (sstatus ttyint 26. NIL) to turn off the interrupt function normally on ^Z. I'm not certain, but I think the IMAGE output problem is just one of the little problems that hasn't been made to work yet. If you don't know how defun works, I recommend the section in the Lisp Machine Manaul on it. It is indeed unfortunate that this is all the better we can do for documentation. MacLisp is not going to take over the world -- the 10 is not an adaquate vehicle for AI research. Certainly, it cannot support the kinds of user-interface and programming aids that we would like, and continue to support such large systems as Macsyma. Most of the additional features being added to MacLisp these days are for backward compatibility and transportability, since everybody here is engaged in, or soon to be engaged in moving their software to larger LISPs. It is NOT a case of AI not tolerating the existance of other sites trying to do similar work! On the contrary, that's why TOPS-20 MacLisp exists at all. That's why we're working on NIL, since not everyone can get a LISP Machine. That's one of the uses of the # macro, to write code which can be transported elsewhere. In short, I think many of your complaints are justified agonizing on the lack of some features away from M.I.T., but not relevant to questions of compatibility in NIL and LISPM. And remember, those features you're agonizing about not having cost lots of effort to obtain on ITS. We've given you MacLisp on Tops-20 with our own effort, but I don't think it is unreasonable to expect that extended features like Ledit should be written by a Tops-20 user just as the original was written by an ITS user (not a LISP maintainer!!).  Date: 30 SEP 1979 1433-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC Date: 30 SEP 1979 1236-EDT From: MILLER at MIT-AI (Mark L. Miller) To: RWK at MIT-MC CC: (BUG LISP@M) at MIT-AI In Reply to: Date: 28 SEP 1979 2224-EDT From: RWK at MIT-MC (Robert W. Kerns) I'm not sure why you view the "proliferation of flavours NIL, LISPM, MACLISP" as a problem to be survived, instead of a sign of proliferic growth, while hoping for InterLisp to proliferate onto the VAX or XEROX or BBN frob. It seems inconsistant. Because the proliferation doesn't seem to be taking the need for upward-compatibility very seriously. I'd love to have some of the new features, if I did not have to live in 545 Tech Square to use them. The approach that says, you have to have an I.T.S. or a Lisp Machine (just try and get one) built at M.I.T. to do A.I. is parochial and mal-adaptive. It is time for A.I. to go out into the world and for us to tolerate the existence of other sites trying to do similar work. For God's sake, I don't even know how DEFUN works anymore! I always tried to write very straightforward code, yet most of what I wrote less than a year ago cannot even READ INTO my 20X MacLisp. Consider: my LET macro has been superceded, ALLFILES does not work on 20X, LEDIT does not work on 20X, (TYO 27.) does not work on 20X, "IMAGE" in general does not work on file output, there are a dozen new magic characters that autoload features I didn't really want, etc. If I had a manual (not a collection of news and notes) I could at least look things up when they stopped working. We can't even agree on what (TYI) should return when the user types ^C! -- Mark  MILLER@MIT-AI 09/30/79 12:24:24 Re: Documentation! To: (BUG Lisp) at MIT-MC The biggest single problem with MacLisp is the lack of a manual. The myriad collection of mostly unavailable Moonuals, 2-3 chapter updates, Lisp news files, etc. is really unacceptable. I personally would be prepared to join forces with other interested parties in creating a single unified interim document. Perhaps if each of a dozen serious users took on one chapter it could be made to happen. The current state of affairs is a disgrace to the field of AI, symbolic computation, etc. -- Mark P.S. Let's not wait for the invention of yet another xgp-oriented text justifier to create the manual. Something you can read on-line on a 24x80 terminal would be far more useful.  Date: 28 SEP 1979 2326-EDT From: JONL at MIT-MC (Jon L White) Subject: RANDOM To: SGR at MIT-MC CC: (BUG LISP) at MIT-MC See the file LISP;LISP NEWS, entry dated "MAY 16,1977" about the new form for RANDOM. You call a status function for re-seeding now.  Date: 28 SEP 1979 2308-EDT From: SGR at MIT-MC (Stephen G. Rowley) Subject: The random number generator. To: (BUG LISP) at MIT-MC The Lisp Manual documents the function RANDOM on p. 2-74 as resetting the random number generator's seed when given two fixnums as an argument, i.e., (random n1 n2) resets the seed. However, the interpreter chokes and says that this is the wrong number of args. Has the RANDOM function been changed since the date of the manual? Thanks, SGR  Date: 27 SEP 1979 1721-EDT From: CFFK at MIT-MC (Charles F. F. Karney) Subject: RANDOM of one arg To: (BUG LISP) at MIT-MC If N = 2*(2^35.+1)/3 then (RANDOM N) is twice as likely to return a result in the range [0,N/2) as in the range [N/2,N).  GSB@MIT-ML 09/27/79 04:50:23 Re: lap - multiply-defined symbols To: (BUG LISP) at MIT-ML LAP should use UNWIND-PROTECT!!!!!! Otherwise quitting out of it can SCREW YOU TO THE WALL  Date: 26 September 1979 1806-EDT From: Dave Touretzky Subject: COMPLR and line numbers To: bug-lisp @ mc, Scott.Fahlman at CMU-10A COMPLR on Bottoms-10 should complain if passed a file with line numbers. Better yet, it should ignore them. Currently it just gives lots of bogus compilation errors, and some naive users can't figure out what the problem is. (You can test if a file has line numbers by looking for a 1 in the rightmost bit of the first word of the file.)  GSB@MIT-ML 09/26/79 08:07:52 Re: FINISH To: (BUG LISP) at MIT-ML, (BUG LISPM) at MIT-ML It would be convenient if the various stream operations (FINISH, FORCE-OUTPUT, CLEAR-OUTPUT, CLEAR-INPUT, LISTEN, etc.) all had corresponding functions defined for them so that the user code doesn't have to worry about whether it wants to FUNCALL, SFA-CALL, or SYSCALL all the time.  ALAN@MIT-AI 09/26/79 01:51:05 Re: Macroscope To: GLS at MIT-MC, RWK at MIT-MC, NIL at MIT-MC CC: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI, KMP at MIT-MC GLS@MIT-MC 09/18/79 10:24:48 Re: Macroscope RWK@MIT-ML 09/18/79 03:57:37 Re: Macroscope Often macros would like to know if they're called for value or effect. ... ... Actually, another thing a macro sometimes wants to know is the set of variables lexically bound around its invocation... There are all sorts of things a macro might want to know about about the context it is expanding in. Often I have wanted to communicate something to all the macros that are expected to expand in a particular scope. The LispMachine's COMPILER-LET is a special form that can be used to perform such feats of macrology. In the interpreter COMPILER-LET acts just like LET, but in the compiler the variables are bound at compile time for the benefit of anyone who would care to look at them during the time that the body of the COMPILER-LET is being processed. If we are going to start providing reasonable expand-time environments to macros, then I would like to see COMPILER-LET introduced to the NIL and MacLisp worlds at the same time that any special variables that the compiler whould be obligated to bind are introduced to all three. One issue is going to be: to what are these special variables to be bound in the interpreter? Perhaps you should have to do a (status complr) before you can feel safe looking? Or perhaps reasonable constant values can be found, for example, it should always be safe to assume that you are expanding for value. Anybody have any reasonable suggestions for names to give to these specials? Or any other things the compiler could provide to the curious macro?  Date: 26 SEP 1979 0134-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: displace To: (BUG LISP) at MIT-MC This is the second time I have been screwed by this, and it can't be that hard to fix: (displace '(1 . 2) nil) => (nil) this should be (progn nil) as we all know.  Date: 22 SEP 1979 1249-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: More on XX APPEND mode lossage To: (BUG LISP) at MIT-MC (OPEN 'FOO/.OUT/.1 'APPEND) gives ; File Already exists (new file required) or something of that sort.  Date: 22 September 1979 11:46-EDT From: Robert W. Kerns Subject: Not a bug! To: GRAND at MIT-MC cc: BUG-LISP at MIT-MC Date: 09/22/79 09:48:25 From: GRAND at MIT-AI To: (BUG LISP) at MIT-AI I regret to report a bug in lisp. I was trying to get a program of mine to locally use the default symbol table when I found out that (PROG (READTABLE)(ARRAY READTABLE READTABLE T)) modifies the top level readtable and leaves the readtable in the prog bound to nil. Please advise me on the resolution of this problem and/or a way to circumvent it.^J ^J -- Mark Grand As JONL told you a few days ago, this is *NOT* a bug. You are doing very much the wrong thing. Let me try again to explain: Doing (PROGN (x) ....) binds x to NIL. This is it's defined behaviour. First off, I'd recommend against your using PROG at all. It is usually not the right thing, being designed for doing things in a Fortran-like manner, with GO's etc. It is ALWAYS wrong to PROG-bind something for which NIL is not a legal value, such as READTABLE. Instead, you should Lambda-bind it (using the LET construct) to a new readtable. The way you create a new readtable is (ARRAY () READTABLE T). The object is not to put an ARRAY property on the symbol READTABLE (as your "(ARRAY READTABLE READTABLE T)" does) but to bind the symbol READTABLE to a new readtable. However, you probably do NOT want to create a new readtable every time you do whatever it is you're doing. So probably the right thing for you to do is to create your readtable once, at load-time. I.e. put in your file the following top-level form. (LET ((READTABLE (ARRAY () READTABLE T))) (SETQ MY-READTABLE READTABLE) ; So we can use this latter (SETSYNTAX .....)) ; Do whatever modifications we want Then, when you want to read with this modified readtable, just do (LET ((READTABLE MY-READTABLE)) ) If you need help with the LET syntax, let me know.  GRAND@MIT-AI 09/22/79 09:48:25 To: (BUG LISP) at MIT-AI I regret to report a bug in lisp. I was trying to get a program of mine to locally use the default symbol table when I found out that (PROG (READTABLE)(ARRAY READTABLE READTABLE T)) modifies the top level readtable and leaves the readtable in the prog bound to nil. Please advise me on the resolution of this problem and/or a way to circumvent it. -- Mark Grand --  Date: 20 September 1979 21:02-EDT From: "Guy L. Steele, Jr." Subject: readtable hacking To: DAVE.TOURETZKY at CMU-10A cc: SCOTT.FAHLMAN at MIT-MC, BUG-LISP at MIT-MC Date: 20 Sep 1979 1743-EDT From: DAVE.TOURETZKY at CMU-10A I've had two requests from users for readtable hacks. Can you tell me how to do the following? 1) Make ] be both a letter and a break character. Example: the character sequence AB]CD should produce three atoms: AB, ], and CD. Make ] have "single character object" syntax. The easiest way to do this is to say (SETSYNTAX '/] 'SINGLE ()). 2) Implement an Interlisp-style "super paren", e.g. make ] or escape insert enough right parens to close out the current s-expression. Alternatively, it could insert some constant number of right parens, providing we can make the constant big enough. This is fairly difficult to do in the current set-up. Super-parens were never installed in MacLISP because you don't need them very much if you have a good screen editor, and they are rather ugly. Sorry. Thanks, -- Dave Touretzky  Date: 20 Sep 1979 1743-EDT From: DAVE.TOURETZKY at CMU-10A Subject: readtable hacking To: SCOTT.FAHLMAN, bug-lisp at MIT-MC I've had two requests from users for readtable hacks. Can you tell me how to do the following? 1) Make ] be both a letter and a break character. Example: the character sequence AB]CD should produce three atoms: AB, ], and CD. 2) Implement an Interlisp-style "super paren", e.g. make ] or escape insert enough right parens to close out the current s-expression. Alternatively, it could insert some constant number of right parens, providing we can make the constant big enough. Thanks, -- Dave Touretzky  Date: 20 SEP 1979 0821-EDT From: JONL at MIT-MC (Jon L White) Subject: Subr version of INCLUDE To: RWK at MIT-MC, CWH at MIT-MC, (BUG LISP) at MIT-MC CC: KMP at MIT-MC, RJF at MIT-MC, JPG at MIT-MC According to the generalized syntax rules that generated the other newio function names, this should be called INCLUDEF (after LENGTHF, DELETEF, PROBEF, ...) Three different rules in maclisp syntax now permit putting a * in the front of a name, and the one which would get you a subr version of an fsubr is a very weak case, involving none of the newio subrs: 1) LSUBRs with restricted number of args; primarily for compiler output (e.g., *PRINT, *LESS, *QUO) 2) Name conflicts for features in semantic transition (e.g., *FUNCTION, *CATCH, *THROW, *REARRAY) 3) Subr version of some FSUBR - only *ARRAY and *BREAK.  Date: 20 SEP 1979 0804-EDT From: JONL at MIT-MC (Jon L White) To: GRAND at MIT-AI CC: (BUG LISP) at MIT-MC GRAND@MIT-AI 09/20/79 07:08:14 To: (BUG LISP) at MIT-AI This isn't a bug (I hope). I have a program in which I wanted to employ the default readtable without changing the global environment. I wrote: (PROG ( ...READTABLE... ) (*ARRAY READTABLE READTABLE T) ... ) and got ;NIL BAD VALUE FOR READTABLE What you should do is, first, look at the section of LISP NEWS (dsk:lisp;lisp news) for the entry of "APRIL 23,1974" entitled "[3] NEW ARRAY SCHEME". Probably you want the syntax (LET ((READTABLE (*ARRAY () 'READTABLE 'T))) ...)  GRAND@MIT-AI 09/20/79 07:08:14 To: (BUG LISP) at MIT-AI This isn't a bug (I hope). I have a program in which I wanted to employ the default readtable without changing the global environment. I wrote: (PROG ( ...READTABLE... ) (*ARRAY READTABLE READTABLE T) ... ) and got ;NIL BAD VALUE FOR READTABLE Why is this happning to me?  Date: 20 Sep 1979 0015-PDT From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: *INCLUDE To: RWK at MIT-MC, (BUG LISP) at MIT-MC Cc: CWH at MIT-MC, JPG at MIT-MC, KMP at MIT-MC, RJF at MIT-MC In-reply-to: Your message of 19-Sep-79 1922-PDT "Yes" for making sharpsign autoloadable. -------  Date: 19 SEP 1979 2222-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: *INCLUDE To: (BUG LISP) at MIT-MC CC: CWH at MIT-MC, JPG at MIT-MC, KMP at MIT-MC, RJF at MIT-MC I've added *INCLUDE, a SUBR version of INCLUDE, for the next version of LISP. The name is due to CWH. If you don't like it, there's still time to hassle it out. What do you think about making the sharpsign macro autoloadable? Not assigned to a key, merely giving the function an autoload property.  Date: 19 September 1979 19:13-EDT From: Kent M. Pitman To: RWK at MIT-MC, BUG-LISP at MIT-MC, CWH at MIT-MC, KMP at MIT-MC, JPG at MIT-MC, RJF at MIT-MC *INCLUDE would seem to me to be the obvious name.  Date: 19 SEP 1979 1451-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC, CWH at MIT-MC, KMP at MIT-MC, JPG at MIT-MC To: RJF at MIT-MC What should a SUBR version of INCLUDE be called?  Date: 19 SEP 1979 0813-EDT From: JONL at MIT-MC (Jon L White) To: wjl at MIT-ML CC: (BUG LISP) at MIT-MC WJL@MIT-ML 09/18/79 16:04:58 To: (BUG LISP) at MIT-ML On XX (IFIX 0.0) complains the number is too big to turn into a fixnum. Fixed!  Date: 19 SEP 1979 0606-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC I think it is pretty awful that just typing `(A B) at LISP causes DEFMAX 13 to be loaded in. I can't believe this used to be the case when I created a MACSYMA in the current LISP on 8/26, was it?  WJL@MIT-ML 09/18/79 16:04:58 To: (BUG LISP) at MIT-ML On XX (IFIX 0.0) complains the number is too big to turn into a fixnum.  Date: 17 SEP 1979 2233-EDT From: JONL at MIT-MC (Jon L White) Subject: DESETQ (LET package) To: RWK at MIT-MC, sjobrg at MIT-AI, alan at MIT-AI, gsb at MIT-ML CC: (BUG LISP) at MIT-MC Corrected version now installed.  Date: 17 SEP 1979 0152-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC The symbols SFTV/| and NVID have autoload properties of ((DSK LISP) NVID FASL). There is no such file.  Date: 15 SEP 1979 0911-EDT From: RWK,SJOBRG at MIT-MC Sent-by: RWK at MIT-MC Subject: DESETQ totally broken To: (BUG LISP) at MIT-MC (MACROEXPAND '(DESETQ X X)) = ((LAMBDA (NIL NIL) (SETQ DESETQ X) (SETQ X NIL)) NIL NIL) (MACROEXPAND '(DESETQ X (X))) = ((LAMBDA (NIL NIL) (SETQ DESETQ X)) NIL NIL) This also breaks the OPTIONAL-P feature of DEFMACRO. Maybe DEFUN& to, although I haven't checked.  Date: 13 SEP 1979 0810-EDT From: JONL at MIT-MC (Jon L White) Subject: GC-LOSSAGE To: REM at MIT-MC CC: (BUG LISP) at MIT-MC, MATHLAB at MIT-MC I'VE FOUND IT! AND CORRECTED IT!, Yes, the random bug in what has turned out to be the bignum division code was what caused your test program on CF2 to get a spurious GC-OVERFLOW interrupt - it seems that indeed in one place a random register was left pointing to a random cell, which later got turned into the free-storeage list. DOes anyone else think that they may have had a manifestation of this bug? By the bye, I ran the test from CF2 for 30 minutes of CPU time, and there was no GC-OVERFLOW, so I'm sure that's it.  Date: 13 September 1979 03:55-EDT From: Robert W. Kerns Subject: Splicing macros are fun! To: ALAN at MIT-AI, BUG-LISP at MIT-AI Date: 09/13/79 03:15:01 From: ALAN at MIT-AI To: (BUG LISP) at MIT-AI Re: Splicing macros are fun! (setsyntax #/~ 'splicing 'read) T (plist 'foobar) ;Why would I do that? NIL '(a b c ~foobar d e f) (A B C . FOOBAR) ;Not quite what I expected (plist 'foobar) (D E F) ;AH HA! Fixed and patched.  ALAN@MIT-AI 09/13/79 03:15:01 Re: Splicing macros are fun! To: (BUG LISP) at MIT-AI (setsyntax #/~ 'splicing 'read) T (plist 'foobar) ;Why would I do that? NIL '(a b c ~foobar d e f) (A B C . FOOBAR) ;Not quite what I expected (plist 'foobar) (D E F) ;AH HA!  Date: 13 SEP 1979 0227-EDT From: JONL at MIT-MC (Jon L White) To: SCOTT at MIT-MC CC: RWK at MIT-MC, (BUG LISP) at MIT-MC (FASLOAD DEFVST FASL DSK MACLISP) on TOPS-20 systems should win, regardless of DEFAULTF. But indeed, I'm making a change to FASLOAD (and there is a bug in LOAD) to be sure that it looks for the FASL file first. The "*" in the version-number field of DEFAULTF is correct - LOAD and FASLOAD try to convert it to 0.  Date: 12 September 1979 23:06-EDT From: Alan Bawden Subject: Control characters in # macro. & RMSs suggestion. To: INFO-LISPM at MIT-AI cc: ALAN at MIT-AI, CWH at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC If no one objects then I will make #^ be the same as #/ for the LispMachine reader.  Date: 12 SEP 1979 0706-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: ___020 at MIT-MC Subject: Agreement To: RMS at MIT-MC, ALAN at MIT-MC, CWH at MIT-MC, NIL at MIT-MC To: (BUG LISP) at MIT-MC I agree with RMS on #^A and #^B/A. (note that it's hard to type #^B/A in MACLISP since Control-B is an interrupt!)  Date: 12 September 1979 07:02-EDT From: Glenn S. Burke Subject: Control characters in # macro. To: RMS at MIT-AI, ALAN at MIT-AI, CWH at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC I agree with RMS.  Date: 12 September 1979 07:02-EDT From: Robert W. Kerns Sender: ___046 at MIT-MC To: scott at SRI-KL cc: BUG-LISP at MIT-MC I believe you have your DEFAULTF set wrong. I believe you want it set to ((DSK SCOTT) SCOTT TEMP 0), or better ((DSK SCOTT) SCOTT LSP 0). Note that's 0, not *. Generally, you don't want a * in any of the positions of DEFAULTF that you wouldn't want defaulted to be * literally. I.e. it might make sense to use ((DSK SCOTT) * LSP 0), since it would generally be foolish to default the first name, but it does make sense to default the extension and version number. However, I'm not sure that's the right error message for the situation. But try using 0 instead of * in your DEFAULTF, and see how things look. (JONL: Why does LISP use PS: as the default instead of DSK: ? Wouldn't it make more sense to use DSK:? Isn't DSK: normally defined already to be PS: in most people's environment, and isn't it's semantics the same as that component of DEFAULTF? If LISP were to change, I don't think Scott would have any reason to be setting DEFAULTF at all...)  Date: 12 Sep 1979 0337-PDT From: Scott at SRI-KL (Scott Kramer) Subject: Fasload error To: bug-lisp at MC The error below occurs when I am connected to my own directory in TOPS-20 Maclisp: !l: LISP 1864 Alloc? ^W ; Loading MacLisp init--Loaded! T defaultf ((DSK SCOTT) SCOTT TEMP *) [*** This is my defaultf in my init ***] (fasload defvst fasl dsk maclisp) ;(LOAD ((PS MACLISP) VSAID TEMP *)) NO SUCH FILE TYPE ;BKPT IO-LOSSAGE This has happened before, but I can't pinpoint that example right now, but it was similar. Scott -------  Date: 12 September 1979 04:04-EDT From: Richard M. Stallman Subject: Control characters in # macro. To: ALAN at MIT-AI, CWH at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC My opinion is that #^A should be read on the Lisp machine the same as #/A, while #/A should read in Maclisp as a 9-bit character. This achieves these goals: 1) A simpleminded program that wants to define C-A as a command and presumably uses 7-bit input on ITS can use #^A and work on both machines. 2) A hairier program that wants to deal with the control and meta bits can use #/A and work on both machines. 3) In Maclisp, then, you can specify a character in either character set and no other switch is required for specifying which. As for NIL, if it is going to define non-ASCII characters at all then it should define #/A to produce one. Otherwise, it should not accept #/A. It should accept #^A as the ASCII control character.  Date: 12 SEP 1979 0109-EDT From: JONL at MIT-MC (Jon L White) Subject: UUO for MACLISP TOPS-10 TTY output To: dd at MIT-AI CC: (BUG LISP) at MIT-MC I guess that'll have to go in the next round of MACLISP corrections, and I can't say when that will be. There are two flavors of outputting, and I thought one of them used the TTCALL 1,... the other is for IMAGE output to the TTY. but maybe some bit is not being tested properly, so that eveal ASCII mode TTYS are being outputted to in image mode.  Date: 11 September 1979 17:40-EDT From: Alan Bawden Subject: Control characters in # macro. To: ALAN at MIT-AI, CWH at MIT-MC, MOON at MIT-MC, GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC Date: 11 September 1979 10:16-EDT From: Carl W. Hoffman The idea of a character called Control-C is the same when typed on the Lisp Machine as when typed on an ascii keyboard. There are two ways of typing a Control-C from a Knight keyboard to MacLisp: You can hold down CTRL and type C, or you can hold down TOP and type X. The two cases are the same for a keyboard open in the vanilla way. If you hack 12 bit input however, you get extra high-order bits telling you just how the character was typed. I simply want ONE way of writing this object. The problem is it isn't ONE object! There's no reason why a piece of code which does (= (TYI) #/C) can't work on both the Lisp Machine and in TOPS-20 MacLisp. OK lets think it through. Lets try and figure out what fixnum #/C should be. Since the tty is normally open in a vanilla way it can't return a number greater than 177, so the only reasonable choice is for #/C to read in as 3. (presumably #/C errs out in some reasonable way.) Now suppose the tty was open in 12 bit mode how are we to generate the 12 bit character code? #/C can't read the users mind (or his code). The problem which Alan tries to solve with his #^ hack is the fact that two character sets are available in ITS MacLisp. #/C can read as two different things -- Control-C as represented in ascii or as represented in the ITS 12-bit character set. This could be controlled by a read-time switch. OK so instead of reading my mind I have to tell the reader what I am thinking, This isn't to bad (I have to tell it what base I have in mind too!) Anyone hacking both character sets would presumably canonicalize to a single form. If you are hacking both "character sets" you have to have #/C generate the 12 bit code. This is why this should be the default meaning for #/C. (In the other mode you are going to have to deal with the meaning of #/c and #/C somehow!) The point of #^C is for hacking the strict ASCII character set in a mnemonic way. It is only for MacLisp because only maclisp has this restriction. It is still true that #/ (which reads the same) looks funny on some terminals. So if we try and create a # macro that MacLisp users can use (even when they are not writing compatable code) It should have this ability.  Date: 11 September 1979 10:16-EDT From: Carl W. Hoffman Subject: Control characters in # macro. To: MOON at MIT-MC, CWH at MIT-MC, GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, ALAN at MIT-AI Date: 10 SEP 1979 1830-EDT From: MOON at MIT-MC (David A. Moon) Date: 10 September 1979 11:08-EDT From: Carl W. Hoffman Subject: Control characters in # macro. To: GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, Well, this isn't right. One of the motivations for using #/ and #\ is to be independent of the character set of the particular system being used. Clearly, #\RUBOUT should read as 207 on the Lisp Machine and in QCMP, and as 177 in MacLisp. The same should be true of "control" characters. In MacLisp, though, they could read as ascii characters or in the ITS 12-bit character set. No. Anything that uses the ascii control characters cannot be independent of character set, since Lisp machine lisp does not even have them. If a program needs to use #^ in Maclisp, no amount of syntax will make it work unchanged on the Lisp machine. The idea of a character called Control-C is the same when typed on the Lisp Machine as when typed on an ascii keyboard. I simply want ONE way of writing this object. There's no reason why a piece of code which does (= (TYI) #/C) can't work on both the Lisp Machine and in TOPS-20 MacLisp. The problem which Alan tries to solve with his #^ hack is the fact that two character sets are available in ITS MacLisp. #/C can read as two different things -- Control-C as represented in ascii or as represented in the ITS 12-bit character set. This could be controlled by a read-time switch. Anyone hacking both character sets would presumably canonicalize to a single form.  Date: 11 September 1979 10:16-EDT From: Carl W. Hoffman Subject: Control characters in # macro. To: MOON at MIT-MC, CWH at MIT-MC, GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, ALAN at MIT-AI Date: 10 SEP 1979 1830-EDT From: MOON at MIT-MC (David A. Moon) Date: 10 September 1979 11:08-EDT From: Carl W. Hoffman Subject: Control characters in # macro. To: GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, Well, this isn't right. One of the motivations for using #/ and #\ is to be independent of the character set of the particular system being used. Clearly, #\RUBOUT should read as 207 on the Lisp Machine and in QCMP, and as 177 in MacLisp. The same should be true of "control" characters. In MacLisp, though, they could read as ascii characters or in the ITS 12-bit character set. No. Anything that uses the ascii control characters cannot be independent of character set, since Lisp machine lisp does not even have them. If a program needs to use #^ in Maclisp, no amount of syntax will make it work unchanged on the Lisp machine. The idea of a character called Control-C is the same when typed on the Lisp Machine as when typed on an ascii keyboard. I simply want ONE way of writing this object. There's no reason why a piece of code which does (= (TYI) #/C) can't work on both the Lisp Machine and in TOPS-20 MacLisp. The problem which Alan tries to solve with his #^ hack is the fact that two character sets are available in ITS MacLisp. #/C can read as two different things -- Control-C as represented in ascii or as represented in the ITS 12-bit character set. This could be controlled by a read-time switch. Anyone hacking both character sets would presumably canonicalize to a single form.  Date: 11 SEP 1979 0744-EDT From: REM at MIT-MC (Robert Elton Maas) Subject: BLOAT bug? To: (BUG LISP) at MIT-MC CC: RWG at MIT-MC I currently believe that I am experiencing the same bug in L (i.e. LISP) that I experienced in LINREL in MACSYMA. I am doing a lot of bignum arithmetic, and LIST SPACE is filling up and not emptying even though I return to the top level and repeat the same computation. Storage gradually gets more and more full as I repeat the same calculation several times. My calculation doesn't grow any global data structures. It creates some during each time I repeat the calculation (the same ones each time) and they should go away when I ^G out of the ;BKPT GC-OVERFLOW and restart. But they don't seem to go away. Turning on ^D from inside the BKPT and doing an explicit (GC) shows LIST is 25% empty which is consistant with getting the BKPT. Doing a $P somehow reclaims all but 10% by the time the next GC is done, even though a check of my EVALFRAMEs in the most likely spot shows only a tiny amount of storage is being used by my program (this check is NOT exhaustive; this isn't the prime reason for my belief in bug in LISP). Doing a ^G then a (GC) also seems to reclaim all but 10%, but since the next repeat of the same calculation yields quicker ;BKPT (thus indicating that there is less storage available at the start of the calculation) I'm bewildered. Is there any way to easily diagnose such problems? I'd like to call some function which will map down (1) atoms (2) stacks (3) accumulators and tell me the name or machine address where any suspicious giant data structure is located, or simply add up the total sizes of all objects and tell me how much I'm really using in each category. MAPATOMS works for atoms, but I don't know the internal pointers to stacks nor which acs are in use for s-expressions so can't write these diagnostics myself without help. Not wanting to spend weeks reading source code at 300 baud, I'm asking the wizards for suggestions...  Date: 10 SEP 1979 2106-EDT From: RWK at MIT-MC (Robert W. Kerns) To: MOON at MIT-MC, CWH at MIT-MC, GLS at MIT-MC, KMP at MIT-MC To: NIL at MIT-MC, (BUG LISP) at MIT-MC, ALAN at MIT-MC If the syntax #^C were to be the same as #\CONTROL-C, I don't see any problem with machine independece. If you define machine independence as doing the same thing on all levels, then yes, it's not independent, but if you define it as having the same semantics, there is no problem. On the LISPM, it returns the character with CONTROL bit added in. On the 10 or VAX, it uppercasifies and XOR's 100. Knight keyboards, with the TTY opened in FIXNUM mode, there is yet another character set, but it is not usually used from LISP, and if the user wants to talk in that langugae, he can just redefine #^. On the S-1, it probably does something else. The point is that while the exact fixnum meant varies from machine to machine, the user is in each case going to hold down the control key and type a character, and that's the machine-independent action we want to capture. Yes, you can do #\CONTROL-C (and I've just added those to SHARPM), but I happen to think those are ugly to see in your code. (TYO #\CONTROL-C) vs. (TYO #^C)  Date: 10 SEP 1979 2051-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Fakery To: (BUG LISP) at MIT-MC (defun nil () ()) NIL (plist 'nil) (EXPR (LAMBDA NIL NIL)) (NIL) ;NIL UNDEFINED FUNCTION OBJECT ;BKPT UNDF-FNCTN So the fake PLIST of NIL is really fake after all!  Date: 10 September 1979 19:45-EDT From: Kent M. Pitman Subject: Control characters in # macro. To: MOON at MIT-MC, CWH at MIT-MC, GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, ALAN at MIT-AI *********************************************************** *** Ridiculously long message to which this is a reply *** *** has been omitted for your viewing pleasure. *** *********************************************************** I was under the impression that what CWH was saying is that we shouldn't use eg, #^? but rather #\RUBOUT; not #^L but rather #\FORMFEED; etc. That should read correctly. If there are control characters for which #^ is now required, they should be given symbolic names so that they can be appropriately called from #\ on either machine. This suggestion seems reasonable to me.  Date: 10 SEP 1979 1830-EDT From: MOON at MIT-MC (David A. Moon) Subject: Control characters in # macro. To: CWH at MIT-MC, GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC To: (BUG LISP) at MIT-MC, ALAN at MIT-AI Date: 10 September 1979 11:08-EDT From: Carl W. Hoffman Subject: Control characters in # macro. To: GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, ALAN at MIT-AI Date: 10 September 1979 03:58-EDT From: Alan Bawden The MacLisp #/C would return 303 not 3 since thats the bit that is set if you try and hack keyboards with control and meta. MacLisp also has a #^ that uppercases and then xors it with 100 so that #^C is 3 (as is #^c) and #^? is rubout. This is sometimes usefull in MacLisp but never in LispMachine lisp, and I don't know about NIL. Well, this isn't right. One of the motivations for using #/ and #\ is to be independent of the character set of the particular system being used. Clearly, #\RUBOUT should read as 207 on the Lisp Machine and in QCMP, and as 177 in MacLisp. The same should be true of "control" characters. In MacLisp, though, they could read as ascii characters or in the ITS 12-bit character set. No. Anything that uses the ascii control characters cannot be independent of character set, since Lisp machine lisp does not even have them. If a program needs to use #^ in Maclisp, no amount of syntax will make it work unchanged on the Lisp machine.  Date: 10 September 1979 17:45-EDT From: Earl A. Killian To: BUG-LISP at MIT-MC I was looking through some code in NILCOM and was annoyed to see things like (PRINC '|message|) instead of (PRINC "message"). Why don't you define a macro like the following one: (setsyntax '/" 'macro #'(lambda () (do ((string () (cons character string)) (character (tyi) (tyi))) ((= character 34.) `(quote ,(maknam (nreverse string)))) (cond ((= character 47.) (setq character (tyi)))) ))) or maybe (setsyntax '/" 'macro #'(lambda () (do ((string () (cons character string)) (character (tyi) (tyi))) ((= character 34.) (setq string (maknam (nreverse string))) (set string string)) (cond ((= character 47.) (setq character (tyi)))) ))) Then in NIL (and the LISPM) you'd get strings when you wanted strings, and only in MACLISP would you get atoms when you meant strings.  Date: 10 Sep 1979 1430-EDT From: Eak at MIT-XX Subject: (LOAD '(DEFVST FASL PS MACLISP)) To: bug-lisp at MIT-MC This loses, complaining that NIL is not a numeric argument. -------  Date: 10 September 1979 11:08-EDT From: Carl W. Hoffman Subject: Control characters in # macro. To: GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC, ALAN at MIT-AI Date: 10 September 1979 03:58-EDT From: Alan Bawden The MacLisp #/C would return 303 not 3 since thats the bit that is set if you try and hack keyboards with control and meta. MacLisp also has a #^ that uppercases and then xors it with 100 so that #^C is 3 (as is #^c) and #^? is rubout. This is sometimes usefull in MacLisp but never in LispMachine lisp, and I don't know about NIL. Well, this isn't right. One of the motivations for using #/ and #\ is to be independent of the character set of the particular system being used. Clearly, #\RUBOUT should read as 207 on the Lisp Machine and in QCMP, and as 177 in MacLisp. The same should be true of "control" characters. In MacLisp, though, they could read as ascii characters or in the ITS 12-bit character set.  GSB@MIT-ML 09/10/79 07:56:22 To: (BUG LISP) at MIT-ML i replied to HMR re (pnput mumble 6)  Date: 10 SEP 1979 0750-EDT From: HMR at MIT-MC (Harry M. Rath) To: (BUG LISP) at MIT-MC (PNPUT mumble 6) seems to do exactly what (PNPUT mumble 7) does, which is useless.  Date: 10 September 1979 04:04-EDT From: Glenn S. Burke To: RWK at MIT-MC, BUG-LISP at MIT-MC cc: JPG at MIT-MC, NIL-I at MIT-MC Date: 8 SEP 1979 0238-EDT From: RWK at MIT-MC (Robert W. Kerns) (OPEN 'T) will always do something damaging, why don't we change it to do the reasonable thing instead? Clearly, if the person is wanting to open a new TTY or whatever, he can deal in the right file-object by some other means. If you want to think about the semantics of this, consider it to be that the SYMBOL meaning of T takes precedence over the FILE meaning of T where the two would conflict. In the other uses of T, there is no meaningful interpretation as a SYMBOL, so the interpretation as a FILE stands. I hope we aren't going to purpetuate this crock onto NIL except through some non-default compatiblity package.... Whereas (LOAD NIL), which clearly is meaningful and useful, is a special-case no-op for some perverse and unspecified reason.  Date: 10 September 1979 03:58-EDT From: Alan Bawden Subject: Control characters in # macro. To: GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, BUG-LISP at MIT-MC The MacLisp #/C would return 303 not 3 since thats the bit that is set if you try and hack keyboards with control and meta. MacLisp also has a #^ that uppercases and then xors it with 100 so that #^C is 3 (as is #^c) and #^? is rubout. This is sometimes usefull in MacLisp but never in LispMachine lisp, and I don't know about NIL.  Date: 9 SEP 1979 1909-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: FORMAT bug To: (BUG LISP) at MIT-MC The format configuration ~| (or ~/| as we have to type it) is documented in the Lisp machine manual as outputing formfeeds. The ascii for formfeed should be 12., not 10. -- a 10. is a linefeed.  Date: 9 SEP 1979 0755-EDT From: HMR at MIT-MC (Harry M. Rath) To: (BUG LISP) at MIT-MC (SUBST NIL NIL FOO) loses if foo has hunks in it.  Date: 8 SEP 1979 1257-EDT From: MOON at MIT-MC (David A. Moon) Subject: Control characters in # macro. To: GLS at MIT-MC, KMP at MIT-MC, NIL at MIT-MC, (BUG LISP) at MIT-MC The lisp machine uses #/A for control-A ( is alpha). Beta and epsilon are used for meta and control-meta. Characters haven't been chosen for hyper and super yet. I understand NIL and Maclisp support the same syntax. The Lisp machine doesn't have the ascii controls so there's no issue there; I don't know what the NIL position (if any) on this may be. You can also put numbers between the # and the operator (slash or other). This isn't used for anything yet although an obvious choice would be fonts.  Date: 8 SEP 1979 1240-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KMP at MIT-MC, NIL at MIT-MC, (BUG LISP) at MIT-MC CC: GLS at MIT-MC Date: 5 SEP 1979 0548-EDT From: KMP at MIT-MC (Kent M. Pitman) It would be nice to see the # macro accept "^" after it to mean controlify (ie, (LOGAND #O37)) next thing read. Eg, #^/C would mean 3... Actually, a more complete theory of this needs to be worked out. In the NIL extended character set, controllifying actually means adding in the control bit, not anding out bits. Maybe the ^ suggestion is a good idea for alternative "spellings", i.e. one can write #^/C instead of #/, etc. To get Control-C, on the other hand, one could write #.(CONTROL #/C) or something.  Date: 8 SEP 1979 0238-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, JIM at MIT-MC, NIL-I at MIT-MC (OPEN 'T) will always do something damaging, why don't we change it to do the reasonable thing instead? Clearly, if the person is wanting to open a new TTY or whatever, he can deal in the right file-object by some other means. If you want to think about the semantics of this, consider it to be that the SYMBOL meaning of T takes precedence over the FILE meaning of T where the two would conflict. In the other uses of T, there is no meaningful interpretation as a SYMBOL, so the interpretation as a FILE stands. I hope we aren't going to purpetuate this crock onto NIL except through some non-default compatiblity package....  Date: 7 SEP 1979 1659-EDT From: JONL at MIT-MC (Jon L White) To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC Date: 6 SEP 1979 0901-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC Lisp is broken. (eq (car (pnget undf-fnctn 7)) (car (pnget unbnd-vrbl 7))) => NIL. Presumably this is a bug in the structure macros? Is this a complaint, or a curio? Try substituting "=" for "eq". Or maybe you are remembering years gone by (several, at least) when sub-parts of these "+INTERNAL-..." pname-list were shared in an attempt to "save core"?  Date: 7 SEP 1979 1500-EDT From: DCP at MIT-MC (David C. Plummer) To: (BUG LISP) at MIT-MC change all 3_1 to 3_3. I think I found the general case, also. n_ and n^ (where n is a string of digits) parses as n_n and n^n.  Date: 7 SEP 1979 1457-EDT From: DCP at MIT-MC (David C. Plummer) To: (BUG LISP) at MIT-MC This is a question on an implementation issue, not really a bug report. Why does 3_ pase as 3_1 instead of |3_|. 3_ does not really represent a completed number, but it parses as one. And for the second question, why does it parse as 3_1 instead as 3_0 ??  gsb@MIT-ML (Sent by WJL@MIT-ML) 09/07/79 10:34:56 To: (BUG LISP) at MIT-ML In the interest of simplicity and sanity, how about adding a keyword to SETSYNTAX that means "totally ignored random character", ie the way many of the control characters are initialized?  Date: 7 SEP 1979 0312-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, JIM at MIT-MC Typing (LOAD 'T) at LISP seems to break things. It appears to be trying to OPEN ((TTY *) * *), and typing control-G doesn't get heard. I was hoping (LOAD 'T) would work like (LOAD 'A).  Date: 7 SEP 1979 0004-EDT From: JIM at MIT-MC (James E. O'Dell) To: (BUG LISP) at MIT-MC do (load t) as if you meant (load '|foo;t >|) you lose bad.  Date: 6 SEP 1979 0901-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC Lisp is broken. (eq (car (pnget undf-fnctn 7)) (car (pnget unbnd-vrbl 7))) => NIL. Presumably this is a bug in the structure macros?  Date: 5 SEP 1979 0548-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC It would be nice to see the # macro accept "^" after it to mean controlify (ie, (LOGAND #O37)) next thing read. Eg, #^/C would mean 3...  Date: 5 SEP 1979 0115-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC Typing (^ 2 36.) causes a very strange error message to get printed.  Date: 3 SEP 1979 1839-EDT From: REES at MIT-MC (Jonathan A. Rees) To: (BUG LISP) at MIT-MC PROGV doesn't check its arguments for validity!!! This makes debugging kind of difficult. If I give it a list which isn't all symbols as first argument, it should yell at me. Try saying, e. g. (PROGV '(1 2 3) '(1 2 3) 4).  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: 1 Sep 1979 2243-PDT From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: ALLFIL on TOPS, Mach Lang Hacker To: MILLER at MIT-AI, JONL at MIT-MC Cc: BUG-LISP at MIT-AI In-reply-to: Your message of 1-Sep-79 2237-PDT I thought he meant MIDAS. -------  Date: 2 September 1979 01:37-EDT From: Mark L. Miller Subject: ALLFIL on TOPS, Mach Lang Hacker To: MILLER at MIT-AI, JONL at MIT-MC cc: BUG-LISP at MIT-AI, scott at SRI-KL I am willing to take a crack at it in my "spare time", but I may need some help. I assume by "machine lang" you mean LAP? Mark  Date: 2 SEP 1979 0101-EDT From: JONL at MIT-MC (Jon L White) Subject: ALLFIL on TOPS To: miller at MIT-AI CC: (BUG LISP) at MIT-MC, scott at SRI-KL Someone started the TOPS-10 verison of this, but I don't think it ever worked. I believe the TOPS-20 version would be both more complete, and easier to write. GLS wrote the original version, but it is not very likely he'd want to re-hack it now. Lets see if we can't turn Scott Kramer into a machine-lang hacker? Or how about someone at TI?  Date: 1 September 1979 20:48-EDT From: Mark L. Miller Subject: ALLFIL etc. To: BUG-LISP at MIT-AI, MILLER at MIT-AI, Scott at SRI-KL Has anyone worked on this for 20X? I could really use it. -- Mark  Date: 30 AUG 1979 1749-EDT From: MACRAK at MIT-MC (Stavros M. Macrakis) To: (BUG LISP) at MIT-MC (mpacar '(lambda (x) (errset (open x) t)) (allfiles '(((dsk macrak))))) Starts getting "All I/O channels already in use" starting with New78S, but all these files should be closed by garbage collection. Obviously I can close the file when I'm done with it, but something's wrong....  Date: 28 AUG 1979 1821-EDT From: JONL at MIT-MC (Jon L White) Subject: EDIT on nothing To: GSB at MIT-MC CC: JPG at MIT-MC, (BUG LISP) at MIT-MC Indeed two "K"s given to a fresh (EDIT) cause a random mpv. I tried out several combinations and note that merely setting ^^^ to () initially cures it. So I've updated EDIT to set ^^^ to ().  Date: 28 August 1979 17:46-EDT From: Glenn S. Burke Subject: EDIT in maclisp To: JONL at MIT-MC cc: BUG-LISP at MIT-ML, JPG at MIT-MC K only gets an MPV when EDIT has the (lack of) initialization jeff noted. The variables ^^^, , and  should be initialized to NIL, as they were before EDIT was made autoloadable.  Date: 28 August 1979 17:35-EDT From: Glenn S. Burke Subject: EDIT in maclisp To: JONL at MIT-MC cc: BUG-LISP at MIT-ML, GSB at MIT-MC  Date: 28 AUG 1979 1031-EDT From: JONL at MIT-MC (Jon L White) Subject: EDIT in maclisp To: JPG at MIT-MC CC: GSB at MIT-MC, (BUG LISP) at MIT-MC Since EDIT is now autoloading, it will print out a random pointer if you merelys say (EDIT) instead of, say, (EDIT FOO). Thats not really a bug. But I don't know anyting about getting an MPV when you type K at it.  Date: 28 AUG 1979 0505-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC Sorry, ignore that note about typing YF to (EDIT).  Date: 28 AUG 1979 0500-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC Indeed, (EDIT) may be trully broken. GSB tells me that typing K at it gives an MPV. And it didn't like to hear YF from me.  Date: 28 AUG 1979 0455-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC Typing (EDIT) at LISP prints out . #100002) I suppose this is not intended?  Date: 27 AUG 1979 2019-EDT From: RWK, REES at MIT-MC Sent-by: REES at MIT-MC Subject: HUNK1024 Anyone? To: (BUG LISP) at MIT-MC I wonder if the sweep phase of the GC would do the right thing if it got to collect an entire segment at a time!  Date: 26 AUG 1979 2244-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: VALRET To: (BUG LISP) at MIT-MC CC: KGK at MIT-MC (VALRET '$$U):VK $P ;FXPDL OUT OF PHASE (SYSTEM ERROR) ;BKPT WHATEVER This seems to be a rather humorous bug. What is going on is that someone put in code to convert certain VALRET's of strings to suitable things on other systems, but forgot(!) to put it under an IFE ITS conditional, so on ITS it tries to convert these things to the apropriate thing, and fails. The :kill and friends are under the apropriate conditional, but $$U is not. Thus, it suffers from the embarasement of trying to simulate ITS for ITS, and doing it wrong. And even buggily.  RMS@MIT-AI 08/26/79 22:23:15 Re: MacLisp Editors & Random Gripes To: MILLER at MIT-AI, (BUG LISP) at MIT-AI, HIC at MIT-MC To: jonl at MIT-MC, mlk at MIT-MC Multics EMACS has been implemented in Maclisp. But, then, that Maclisp does have strings.  Date: 26 AUG 1979 2144-EDT From: MILLER at MIT-AI (Mark L. Miller) Subject: Re: some of us twenex maclisp users... To: Scott at SRI-KL CC: (BUG LISP) at MIT-AI, jonl at MIT-MC My plan is to try a hand-"transor" of the interlisp versions. I am waiting for sources to arrive (by covered wagon, it would seem). Does that sound like a plausible strategy to you? -- Mark  GSB@MIT-ML 08/26/79 21:44:51 Re: &whole-form To: (BUG LISP) at MIT-ML, RMS at MIT-ML How about &CALL, since that argument would be the original "call" form?  Date: 26 AUG 1979 2142-EDT From: JONL at MIT-MC (Jon L White) Subject: DEFMACRO To: (BUG LISP) at MIT-MC A new defmacro version (number 83) has been dumped out on ITS systems - consider this one slightly experimental. It has the "&WHOLE" keyword, which works in tested cases. Name for this keyword is still experimental. Previous version (number 81) is on DSK:LISP;DEFMAC OFASL  Date: 26 Aug 1979 1629-PDT From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: some of us twenex maclisp users... To: bug-lisp at MIT-AI, miller at MIT-AI Hmm, we're thinking along the same lines today. I was just looking at some of the interlisp functions for fork handling and they are quite acceptable. I'd like to start work on these much needed twenex functions (in order, from trivial to complex), am not really sure where to start. I think that a cursorpos equivilent would perhaps be one of the easier functions, and ones like syscall (jsys) and valret (subsys) are quite hairy. I am not an midas user; would any of these be writable in lisp/lap? At one time, RWK suggested trying a cursorpos using SFA's, does anyone have any ideas along these lines? One last thing, there seems to be very few words from the twenex maclisp community. I'd like to hear from them, the number of maclisp users at SRI is countable on one hand. Thanks, Scott ------- -------  MILLER@MIT-AI 08/26/79 18:57:08 Re: Twenex Needs To: (BUG LISP) at MIT-AI Us Twenex MacLisp users could sure use a few of the Interlisp-like functions for fork handling. E.g., (JSYS --) (TENEX --), (SUBSYS --) and friends. Sure, I suppose we can each write our own, but there is a lot to be said for standardization of such generally useful things. I have actually heard of people using Interlisp as a "Job-ring handler" for moving between Emacs and MacLisp! Likewise we could use something analogous to the effect of (tyo ^P) on I.T.S., in terms of super-raw-TYO (e.g., for CRT drivers). -- Regards, Mark  MILLER@MIT-AI 08/26/79 18:44:42 Re: MacLisp Editors & Random Gripes To: MILLER at MIT-AI, RMS at MIT-AI, (BUG LISP) at MIT-AI To: HIC at MIT-MC, jonl at MIT-MC, mlk at MIT-MC Hic: Thanks for putting MLK and I together on the subject of Emacs-like editors written in MacLisp-like languages. I am very interested in having a MacLisp-based screen editor. For one thing, we have a Vax and this would mean killing two problems with one stone. For another, I want to study issues of user-engineering and ease-of-learning etc., including AI-based tutors, in the domain of screen-oriented text editing. I am willing (I may even have funding) to work on this problem, or to encourage others in my group to help out. We can't keep tooting the Emacs and Lisp horns and yet keep apologizing about things like why you have to write Emacs macros in (groan) TECO! Either Lisp is a winning language or it is not. I feel that any language incapable of supporting an implementation of Emacs is NOT winning. Come on, Lisp fans, if Lisp is only winning with one of the world's 7-8 specialized hardware hacks, and you have to live at MIT to use it, who are we kidding? The last BYTE magazine has put us in the public eye, let's try to live up to our claims. Anyone else up for some serious hacking? I might add that the proliferation of dialects is going to be our downfall, if the lack of manuals is not. Can't we get out an interim definition of a "core MacLisp" from which the rest can be built? Every time I get some bug-lisp type mail about yet another magic character, etc., I begin to wonder if I still know what Lisp is! Put that in your cons and reclaim it! -- Mark p.s. Even Microsoft Basic has strings!  Date: 26 AUG 1979 0824-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (DEFUN FOO (&REST NIL) ...) ;(&REST NIL) Bad Variable-list syntax -- DEFUN&  Date: 26 August 1979 06:57-EDT From: Robert W. Kerns Subject: A possible LISP bug? To: BUG-LISP at MIT-MC Date: 25 August 1979 12:20-EDT From: Kleanthes Koniaris To: BUG-LISP Re: A possible LISP bug? (VALRET '|$$U|):VK Then, I get a DDT. (Yes, the DDT prompts.) Thank you, --KGK What is this, an anti-hack check? It really does happen, and only for $$U, not or $$V, for example. It seems to have the strings $$U and $$u already in LISP, for comparison purposes...  GRAND@MIT-AI 08/25/79 12:48:23 To: (BUG LISP) at MIT-AI My init file for lisp (USERS1;GRAND LISP) causes LISP to die with GC CALLED FROM ALLOC - LOSE, LISP IS DEAD What can I do?  Date: 25 AUG 1979 1220-EDT From: KGK at MIT-MC (Kleanthes Koniaris) Subject: A possible LISP bug? To: (BUG LISP) at MIT-MC (VALRET '|$$U|):VK Then, I get a DDT. (Yes, the DDT prompts.) Thank you, --KGK  Date: 24 AUG 1979 0946-EDT From: JONL at MIT-MC (Jon L White) Subject: CATCH syntax To: CTH at MIT-MC CC: (BUG LISP) at MIT-MC We decided about 2 or 3 years ago that (CATCH ... ) is the better syntax, but there was so much existing code with the old form that the following was done: 1) *CATCH is defined with the new syntax , and so is *THROW 2) a period of years will pass, so that old code can be converted or flushed 3) then CATCH and THROW will have the alterd new syntax also. For now, just use *CATCH and *THROW.  Date: 23 AUG 1979 2044-EDT From: CTH at MIT-MC (Chris T. Hibbert) To: (BUG LISP) at MIT-MC Wouldn't CATCHes and THROWs be more understandable if the syntax were (CATCH
) instead of (CATCH )? This seems to be good for the same reason many people (Me, at least) use LET instead of LAMBDA even when they don't want the destructruring.  Date: 23 AUG 1979 0753-EDT From: JONL at MIT-MC (Jon L White) Subject: &WHOLEFORM To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC Could we adopt "&WHOLEFORM" instead of "&WHOLE-FORM"? RMS@MIT-AI 08/22/79 23:36:38 To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI (DEFMACRO FOO (&WHOLE-FORM X) ...) I'm in favor of this approach too, *** even though this is another special case *** added to the differences between DEFMACRO and DEFUN. To clean this up, would'nt it be better to adopt the destructuring notions of the maclisp DEFUN/DEFMACRO? That way, the forms (DEFMACRO X ...) (DEFUN FOO X ...) would be undefined cases, but the former could continue to be a kludge for the benefit of those who won't (or can't) change their old code. This way, DEFUN and DEFMACRO would have identical argument syntaxes, *** including the way destructuring is performed *** except in the &WHOLE-FORM case.  HIC@MIT-MC 08/23/79 02:24:03 To: RMS at MIT-AI, (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI RMS@MIT-AI 08/22/79 23:36:38 (DEFMACRO FOO (&WHOLE-FORM X) ...) ----- I also like this idea.  MOON@MIT-MC 08/23/79 01:34:36 To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI RMS@MIT-AI 08/22/79 23:36:38 To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI I would suggest that it is better to define a new keyword for DEFMACRO which would let it get at the whole form rather than make (DEFMACRO FOO X ...) do so. This is not just for the sake of compatibility with old code, but for keeping DEFMACRO's definition free of special cases. It could be (DEFMACRO FOO (&WHOLE-FORM X) ...) This sounds like a good idea.  RMS@MIT-AI 08/22/79 23:36:38 To: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI I would suggest that it is better to define a new keyword for DEFMACRO which would let it get at the whole form rather than make (DEFMACRO FOO X ...) do so. This is not just for the sake of compatibility with old code, but for keeping DEFMACRO's definition free of special cases. It could be (DEFMACRO FOO (&WHOLE-FORM X) ...)  Date: 21 AUG 1979 2231-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: GJC at MIT-MC, KMP at MIT-MC Loading a file with a single | in it does not give an error. ie, an end-of-file in read error would be just the thing ...?  Date: 21 AUG 1979 1313-EDT From: JONL at MIT-MC (Jon L White) To: GLS at MIT-MC, RICH at MIT-MC CC: (BUG LISP) at MIT-MC RICH@MIT-AI 08/21/79 11:00:38 Re: TYIPEEK bug To: (BUG LISP) at MIT-AI (PROGN (TYIPEEK)(PRINT (READ))(PRINT (READ)))A B A B T The A and B don't come out until the space after the B is typed. This is a bona-fide bug in the interface to the TTYSCAN routine, and doesn't have anythin particular to do with TYIPEEK - I can make it happen in other ways, e.g. (PROGN (REAL-TIME-ACTION) (PRINT (READ)) (PRINT (READ))) where "(REAL-TIME-ACTION)" causes something to be put on the buffer-back-list of the input file array; then same behaviour appears. This is the same kind of situation which was at the root of Jim Stansfield's bug, which was recently fixed - a tty-interrupt function caused something to go on the buffer-back-list, and the various input routines were "unaware" of this. The problem in this case, however, is that the main "TYI" input routine ($DEVICE) interfaces badly to the rubout processor, i.e. the routine specified by (STATUS TTYSCAN). Rather than have $DEVICE call the tty-scanner, why not have READ call it? This problem is due to the fact that the tty-scanner is not called until after READ gobbles up the character which was TYIPEEKd. READ waits until $DEVICE decides to call it, but it is really READ that knows when it should be called.  RICH@MIT-AI 08/21/79 11:00:38 Re: TYIPEEK bug To: (BUG LISP) at MIT-AI For your files, this is the "tyipeek" bug. (PROGN (TYIPEEK)(PRINT (READ))(PRINT (READ)))A B A B T The A and B don't come out until the space after the B is typed.  Date: 20 AUG 1979 1233-EDT From: JLK at MIT-MC (John L. Kulp) Subject: LISP Bugs Fixed While You Wait To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC I suppose we will never be free from gratuitous changes that do nothing but introduce bugs, but then again, due to all the traditional ITS lossage, LISPT must remain a rather gross hack...  RICH@MIT-AI 08/20/79 09:14:59 Re: New Lisp on AI To: (BUG LISP) at MIT-AI CC: SJOBRG at MIT-AI :L on AI has an incompatibility with :OL which can be exhibited by the following test example: (DEFUN TEST (F C)(PRINT (TYI))) (SSTATUS TTYINT 5 'TEST) If you now type ^E in the old Lisp, 5 gets printed out, i.e. the TYI gets the control character. In the new Lisp, the next character after ^E gets printed out. This breaks the ^E Ledit interrupt and anybody else who does a tyi (or tyipeek) from an interrupt char in old Lisp. Thanks, Chuck.  Date: 20 AUG 1979 0435-EDT From: JONL at MIT-MC (Jon L White) Sent-by: ___021 at MIT-MC Subject: LISPT in new LISP To: HENRY at MIT-MC CC: JLK at MIT-MC, (BUG LISPT) at MIT-MC, (BUG LISP) at MIT-MC CC: hal at MIT-AI I reassembled and added the (foolish) symbol $DEV5K for LISPT's benefit, so it seems to work well now again.  HENRY@MIT-AI 08/19/79 00:26:34 To: (BUG LISP) at MIT-AI, (BUG LISPT) at MIT-AI CC: HAL at MIT-AI LispT loses in the new Lisp. It complains that FASLOAD couldn't get some DDT symbol.  Date: 18 August 1979 21:07-EDT From: Robert W. Kerns Subject: LISP Bugs Fixed While You Wait To: BUG-LISPT at MIT-MC, REES at MIT-MC, ALAN at MIT-AI, BUG-LISP at MIT-AI Date: 08/18/79 14:51:18 From: ALAN at MIT-AI To: (BUG LISP) at MIT-AI Re: God damn it! STILL wrong! Now splicing macros at top level always return NIL. That is ~(a) => nil at top level. Fixed. Also LISPT users are going to have a hard time since $DEV5K is no longer there for GETDDTSYM to find. (Perhaps this is in some package LISPT uses (HUMBLE ?) I didn't have the patience to find out.) LISPT PATCH patches $DEV5K. In 1860, $DEV5K has been renamed $DEVBUF, which is a somewhat superior name. I have patched LISP to also have the symbol $DEV5K for this location. LISPT PATCH seems to work properly under the cursory examination I gave it. However, somebody should probably check it out a bit more to be sure, and change it to use the symbol $DEVBUF instead by the next LISP version.  Date: 18 August 1979 20:44-EDT From: Robert W. Kerns Subject: God damn it! ~(A) ==> NIL To: ALAN at MIT-AI, BUG-LISP at MIT-AI Foo. I Dunno how I did it, but I somehow managed to have the source not reflect what I was testing or something. Anyway, by taking the CAR instead of the CDR of the frob, we win. Patched.  ALAN@MIT-AI 08/18/79 14:51:18 Re: God damn it! To: (BUG LISP) at MIT-AI STILL wrong! Now splicing macros at top level always return NIL. That is ~(a) => nil at top level. Also LISPT users are going to have a hard time since $DEV5K is no longer there for GETDDTSYM to find. (Perhaps this is in some package LISPT uses (HUMBLE ?) I didn't have the patience to find out.)  Date: 18 AUG 1979 0157-EDT From: jonl at MIT-MC (Jon L White) Sent-by: KMP at MIT-MC Subject: ,@ ,. ., To: BYRON at MIT-MC CC: (BUG LISP) at MIT-MC When before the last element of a list there is no structural difference in the resultant data frob, but for the purposes of GRINDEFing, the first two will be "recognized", wheras the last form has the flaw that the READMACROINVERSE feature of GRINDEF wont recognize it. Also, in the future, there may be an attempt for ,@ to actually copy the top level of the list which it preceeds; in that case, "(A ,@B)" would produce a strictly-private list, whereas "(A ,.B)" would share the cdr with B.  Date: Thursday, 16 August 1979 2024-EDT From: Scott.Fahlman at CMU-10A Subject: Bug in LISP 860 at CMU To: bug-lisp @ mit-ai CC: Dave.Touretzky at CMU-10A Message-ID: <16Aug79 202444 SF50@CMU-10A> Jonl, Our new lisp now loads OK and runs the INI files. But it is impossible to run it on TOPS-10 with DDT. It seems to be blowing away some locations starting at 4525, which are part of DDT when we have DDT loaded. It is interesting to note that 4525 is the octal high part of the PPN corresponding to C380. This, of course, makes it look like the MACLISP directory is being used as an address at which to store something, perhaps more literally than is intended. I suspect some other random bug is caused when DDT is not loaded. I will try to poke around and pinpoint the problem more precisely over the weekend, though it will be hard with DDT being clobbered. Just thought I'd mention it to you in case it rings a bell. It presumably has to be due to the recent batch of changes -- DDT was working fine earlier. -- Scott  Date: 16 AUG 1979 0747-EDT From: REM at MIT-MC (Robert Elton Maas) Subject: FIXNUM-IDENTITY et al To: RMS at MIT-MC, (BUG LISP) at MIT-MC I think I disagree with RMS. These are identity functions in the mathematical sense, with domain and range as indicated. Their names take the functional point of view. Perhaps FIXNUM-COERCE and FLONUM-COERCE would be slightly better since their DOMAIN can be coerced from other numerical domains thus isn't as rigid as their present name might indicate. RMS's suggestion, however, is worse, since it implies a global side-effect like the ASSUME feature of MACSYMA, which these functions don't provide. Well, there's my intelligent vote, for what it's worth.  Date: Thursday, 16 August 1979 0014-EDT From: Scott.Fahlman at CMU-10A Subject: New MACLISP To: bug-lisp @ mit-ai CC: Dave.Touretzky at CMU-10A Message-ID: <16Aug79 001444 SF50@CMU-10A> Jonl, I tried assembling the big-lowseg version of the new MACLISP today. There was a problem with the HSGORG constant. At one point you have .DECTWO and what you need is .DECTWO HSGORG to get it to load right. I changed it in the source we have here, but it should also be fixed at your end. We have some other problem with the new source that seems unrelated to the big lowseg or to the above-mentioned change (it occurred with the old version, normal assembly). At the end of reading our normal LISP.INI, we get an illegal UUO lossage at 41066. Still trying to track this down. -- Scott  EB@MIT-AI 08/15/79 18:45:40 Re: FIXNUM-IDENTITY To: RMS at MIT-AI, (BUG LISP) at MIT-AI MSG: LISP? 1 RMS@MIT-AI 08/15/79 03:16:52 Re: FIXNUM-IDENTITY Does anyone agree that this function would be better named ASSUME-FIXNUM? If so, let me and BUG-LISP know. yes  Date: 15 AUG 1979 1239-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: FIXNUM-IDENTITY To: RMS at MIT-AI CC: (BUG LISP) at MIT-MC Since RMS brings it back up, I guess I think ASSUME-FIXNUM would be more obvious in meaning to a naive user running across it in code ...  LH@MIT-ML 08/15/79 11:50:41 To: (BUG LISP) at MIT-ML, rms at MIT-AI ASSUME-FIXNUM is indeed a much better name than FIXNUM-IDENTITY. And while you're at these, put in ASSUME-NON-NUMBER so I needn't suffer PDLNMK checks for macro-generated RPLACs of objects known not to be numeric.  Date: 15 AUG 1979 0739-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: ASSERT-FIXNUM To: (BUG LISP) at MIT-MC CC: Dave-Trouretzky at CMU-10A Actually, in compiled code it will blindly assume it's a fixnum and treat it like one, without checking to see if the assumption is valid. In the interpreter, it merely checks at that time, it doesn't assert it in any database or anything. So ASSUME is the more appropriate term here, I would assert. I assume you'll agree.  Date: 15 August 1979 0557-EDT From: Dave Touretzky Subject: Re: ASSUME-FIXNUM To: bug-lisp @ mit-mc In-Reply-To: Robert W. Kerns's message of 15 Aug 79 04:50-EST If this FIXNUM-IDENTITY is supposed to be a declaration, then ASSUME-FIXNUM is fine. But if it is asserting a fact about an argument that you wish MacLisp to verify, I think ASSERT-FIXNUM is more appropriate. It coincides with the notion of "assertions" in proving or testing programs. Some experimental languages allow you to make fairly complex assertions about the state of the computation at various places, and the runtime system then checks each assertion as it comes to it. ASSERT-FIXNUM appears to be a simple example of the above.  Date: 15 AUG 1979 0550-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: ASSUME-FIXNUM To: (BUG LISP) at MIT-MC CC: RMS at MIT-MC, DUFFEY at MIT-MC, GSB at MIT-MC I also agree that ASSUME-FIXNUM is a superior name! While I understand the meaning of FIXNUM-IDENTITY, that's only because I know how these things operate. FIXNUM-IDENTITY makes you sound like you're trying to sound like a mathametician, while ASSUME-FIXNUM says just what you want.  DUFFEY@MIT-AI 08/15/79 04:38:45 Re: FIXNUM-IDENTITY vs ASSUME-FIXNUM To: (BUG LISP) at MIT-AI CC: RMS at MIT-AI I agree with RMS that the better (ie. more understandable) name for this function is ASSUME-FIXNUM. Indeed, the name FIXNUM-IDENTITY does not suggest anything to me. Roger Duffey  Date: 14 AUG 1979 1016-EDT From: JONL at MIT-MC (Jon L White) Subject: Your bug note of Jul 26 To: David.McDonald at CMU-10A CC: (BUG LISP) at MIT-MC, Fahlman at CMU-10A, touretzky at CMU-10A I had been on vacation when you sent this note, and am just now getting around to incorporating your suggested code for setting the terminal length under CMU system. Thnx muchly, Dave, for hacking this one out - I don't really know much about this part of maclisp since the TOPS-10 i/o interface was generally coded by someone else.  Date: 14 AUG 1979 0653-EDT From: JONL at MIT-MC (Jon L White) Subject: Suggestion for LET extensions To: byron at MIT-ML CC: (BUG LISP) at MIT-MC BYRON@MIT-ML 08/13/79 16:11:32 To: (BUG LISP) at MIT-ML I have a suggestion for augmenting LET in the direction of type declaration. Instead of limiting LET to variables or (variable-structure init-val), how about adding a third item which would be a type declaration? Separate declare statements would then be less necessary. E.G. (let ((x (plus a b) flonum) ((u v w) (foo a b c) (flonum notype fixnum))) ) would bind x with initial value (plus a b) and type flonum, and would bind u, v, and w to the car, cadr, and caddr of (foo a b c) and declare them to have the types indicated. The part about a third item in the LETlist, "(x (plus a b) flonum)" sounds good to me, but the compound form "((u v w) (foo a b c) ...)" loses since it conflicts with the "destructuring" syntax of LET; i.e., this should mean "bind u to the CAR of the value of (foo a b c), bind v to the CADR, and bind w to the CADDR".  BYRON@MIT-ML 08/13/79 16:11:32 To: (BUG LISP) at MIT-ML CC: BYRON at MIT-ML I have a suggestion for augmenting LET in the direction of type declaration. Instead of limiting LET to variables or (variable-structure init-val), how about adding a third item which would be a type declaration? Separate declare statements would then be less necessary. E.G. (let ((x (plus a b) flonum) ((u v w) (foo a b c) (flonum notype fixnum))) ) would bind x with initial value (plus a b) and type flonum, and would bind u, v, and w to the car, cadr, and caddr of (foo a b c) and declare them to have the types indicated.  Date: 13 AUG 1979 0750-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: '(A B . ~(C)) ==> Dot Context Error To: ALAN at MIT-MC, (BUG LISP) at MIT-MC This has been fixed for the next version of LISP, to be released soon. I can patch it into the current LISP if you like. The new LISP should be released around Thursday.  Date: 13 AUG 1979 0554-EDT From: RWK at MIT-MC (Robert W. Kerns) To: ALAN at MIT-MC, (BUG LISP) at MIT-MC The reason why your MC:ALAN;SPLICE ING file makes ~ start losing on '(A B . ~(C)) is because LISP is taking the CDR of the C, and checking that against NIL. The CDR is the PLIST, and you put something on C's PLIST. I'm not sure if we've got two pieces of code joining where they shouldn't or what, but I'll investigate further.  Date: 13 AUG 1979 0327-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, GLS at SU-AI CC: LPH at MIT-MC JPG@MIT-MC 22 AUG 1978 0350-EDT To: (BUG LISP) at MIT-MC It would be nice if something were done about the cute "gleep! out of bit blocks" message. This message is unintelligible to us all wrt the state it is trying to convey and its seriousness. E.g., can a MACSYMA be reasonably continued after the user receives this message? Can it happen when (STATUS MEMFREE) is not 0? And exactly what does it mean as far as the functioning of the GC or whatever? I sent the above message almost a year ago but have gotten no response. The "gleep" message is still confusing MACSYMA users. Guy, if we appended an "Out of core" line or some such that would help. What do you think?  RMS@MIT-AI 08/13/79 01:17:41 To: (BUG LISP) at MIT-AI I have changed DEFMACRO to be defined with DEFMACRO. It works, but it is possible you will have bootstrapping problems if you are using the same source file.  Date: Sunday, 12 August 1979 2011-EDT From: Scott.Fahlman at CMU-10A Subject: Lossage in the new LISP. To: Bug-Lisp @ MIT-AI CC: Dave.Touretzky at CMU-10A Message-ID: <12Aug79 201123 SF50@CMU-10A> Jonl, Tried running LISPs derived from our new source (857). Any attempt to print a system message (as opposed to normal output) dies horribly, spewing garbage characters at random. This is true both with LISP.LOW and LISP.SHR (generated by you?), LISP.REL, and BIGLSP.REL which I assembled today to try enlarging the lowseg. Any ideas? Is the ITS version similarly afflicted? -- Scott  Date: 12 AUG 1979 0622-EDT From: JONL at MIT-MC (Jon L White) Subject: TYPED-IDENTITY To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC, (BUG LISPM) at MIT-MC There appears to be good reason for flushing the fsubr notion of this; but since it makes little sense to have a changeable type argument, how about accepting two new "numerical" subrs FIXNUM-IDENTITY and FLONUM-IDENTITY Thus (FIXNUM-IDENTITY (car l)) would require the interpreter to check that "(car l)" evaluate to a fixnum, and the compiler would treat it similarly to "(+ (car l))". The reason why the latter will no longer be satisfactory for this purpose is that (ho! ho!) the compiler will "optimize" this into merely "(car l)", thereby losing the type-restriction information that comes along with "+". The need for these on the LISPM is less urgent since there is not compilation advantage to be had, but it would be a consistent way to get the argument type checking that goes along with compilation.  Date: 11 AUG 1979 2243-EDT From: LPH at MIT-MC (Leo P. Harten) To: (BUG LISP) at MIT-MC, MACSYM at MIT-MC while hacking with large lists, received the error message: ;GLEEP! OUT OF BIT BLOCKS CORE capacity exceeded (while requesting LIST space)  GSB@MIT-ML 08/09/79 17:14:15 Re: typed-identity To: RMS at MIT-ML CC: (BUG LISP) at MIT-ML, (BUG LISPM) at MIT-ML, NIL at MIT-ML The conceptualization i had for the use of this routine is that it would not be something a user would use much if at all, but rather the low-level form to be recognized by the compiler; the named types which would be allowed would be only certain data-types in the implementation, eg, FIXNUM and FLONUM in Maclisp. I would think that a more reasonable user interface could then be built on top of this, allowing extensible data-type information (even if it doesn't allow these extended types to be different types in their own right), maybe in a heirarchical or flavorful (hic?) form... this routine just isn't high level enough in my opinion to warrant its taking up a "good" name.  Date: 9 Aug 1979 1009-PDT From: RAND.KLAHR at SU-SCORE Subject: OPENing a file with APPEND on Tops-20 To: bug-lisp at MIT-MC It seems that when one opens a file with 'append it creates a new file version (ie. it acts just like 'out) Also (open '|foo.lisp.0| 'out) opens a file called foo.lisp.1 Ken Kahn and Phil Klahr -------  Date: 9 AUG 1979 0147-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: Splicing macros again (I think). To: (BUG LISP) at MIT-MC In a fresh lisp (1840): (setsyntax '/~ 'splicing 'read) T '(a b . ~(c)) (a b . c) ;This is good! (load '|mc:alan;splice ing|) T '(a b . ~(c)) ;DOT CONTEXT ERROR ;BKPT *RSET-TRAP ;This is bad. Except the file mc:alan;splice ing doesn't have anything to do with "~"! It defines "#" as a LispMachine compatable splicing macro. Why should the behavior of one effect the other? A dribble file of the incident actually looked like this: '(a b . ~(c) ;DOT CONTEXT ERROR ;BKPT *RSET-TRAP ) You figure it out.  JONL@MIT-MC 08/08/79 21:09:00 Re: TYPED-IDENTITY To: rms at MIT-AI CC: (BUG LISP) at MIT-MC, NIL at MIT-MC probably nothing as short as both of us would like would be suitable, but how about another macro-character option? say, #&(foo...) for (TYPED-IDENTITY FIXNUM (foo...)) and #$(foo...) for (TYPED-IDENTITY FLONUM (foo...)). This feature is more like a "requirement" rather than a "coercion" or declaration; Quux and I once suggested a series of Identity functions, PROJi named by analogy with mathematical projection functions, but these fail to have the strong typing information in them.  RMS@MIT-AI 08/08/79 21:00:05 To: (BUG LISP) at MIT-AI I like the idea of TYPED-IDENTITY but I think it's a bad name. How about ASSUME-TYPE or TYPE-ASSUME? I'd prefer something shorter even than that.  GSB@MIT-ML 08/08/79 19:07:49 To: (BUG LISP) at MIT-ML Grindef doesn't know anything about MACRO.  Date: 7 AUG 1979 0347-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC, (BUG LISPM) at MIT-MC GSB and I propose a new fsubr, TYPED-IDENTITY, in order to locally certify and inform the compiler about the type of random quantity. (TYPED-IDENTITY FIXNUM x) requires that x evaluate to something of type FIXNUM; (TYPED-IDENTITY FLONUM x) similarly requires FLONUM. In both cases, the argument "x" is returned, and the interpreter would signal an error if the type constraint is not met. This format follows the same syntactic pattern as ARRAYCALL, SUBRCALL etc. [no, it isn't the same as LOCAL-DECLARE]. I've tested this out in an experimental complr and there seems to be no problems - any comments?  Date: 7 AUG 1979 0147-EDT From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC I'll retract the comment about defaultf being ((DSK JONL) @ @) ... I didn't realize you had $$'d me into a different msname. I go along with the change to * > as a default, but I still don't understand why the load err message was ((DSK JONL) FOO >) with emphasis on the ">" was given ...  Date: 6 AUG 1979 2336-EDT From: JONL at MIT-MC (Jon L White) Subject: DEFAULTF To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC `((DSK ,msname) @ @) is the current setting - soon we will change it to `((DSK ,msname) * >). As for your complaint about DEFAULTF having something other than your current "msname" in the directory part, have you considered the current value of your DDT's msname?  Date: 6 AUG 1979 2327-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC DEFAULTF seems to be set to ((DSK JONL) @ @) in a bare lisp. Saying (LOAD 'FOO) says ((DSK JONL) FOO >) not found. I would guess JONL tried to patch it so DEFAULTF was set so that load did the 'right' thing ... I thought we decided all that meant was that DEFAULTF would just be set initially to ((DSK something [hsname or sname?]) * >) ... Not that anything in LOAD was going to be altered -- ie, why was it looking at FOO > if that's not what DEFAULTF was set to?  Date: 6 AUG 1979 2308-EDT From: JONL at MIT-MC (Jon L White) Subject: Increas in fasl file size for FOR To: BYRON at MIT-MC CC: GSB at MIT-MC, (BUG LISP) at MIT-MC It turns out that DEFMACRO usages cause the outputting of some random form into the fasl file, which tries to insure the that DEFMAX file is loaded into the object environment; This is no longer necessary, as of LISPs installed after May of this year, but for a while, I've been letting this thing continue so that old dumps wouldn't be faced with unnecessary error msgs "|forget-macromemos/|| Undefined Function ..." With the next DEFMACRO release, which should occur this week, those extra forms will not be present. As it happens, this is also the explanation for GSB's complaint about LET doing some loadings. You will probably want to think about FOR again in a few weeks or so.  Date: 6 AUG 1979 2037-EDT From: jonl at MIT-MC (Jon L White) Sent-by: KMP at MIT-MC To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 08/06/79 16:26:44 The random loading of DEFMAX by LET (and others) should go through the autoload handler! IE, (funcall autoload '(needed-function . ((dsk lisp) defmax fasl))) LET doesn't do any loadings. It uses functions which have AUTOLOAD properties pointing to the DEFMAX file  GSB@MIT-ML 08/06/79 16:26:44 To: (BUG LISP) at MIT-ML The random loading of DEFMAX by LET (and others) should go through the autoload handler! IE, (funcall autoload '(needed-function . ((dsk lisp) defmax fasl)))  Date: 6 AUG 1979 0436-EDT From: JONL at MIT-MC (Jon L White) Subject: BAKTRACE To: (BUG LISP) at MIT-MC calls to PRINC were patched to be PRIN1 as per suggestion GSB.  GSB@MIT-ML 08/05/79 00:00:35 To: (BUG LISP) at MIT-ML Why is it that BAKTRACE still is princing stuff instead of prin1ing? Seeing BAKTRACE +INTERNAL-UDF-BREAK_ DEFINE-SMART-OBJECT MACRO_ *EVAL_ *EVAL_ isn't particularly clear or aesthetic.  Date: 4 AUG 1979 1703-EDT From: JONL at MIT-MC (Jon L White) Subject: VALUE-CELL-LOCATION To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC GSB@MIT-ML 08/04/79 03:55:29 Re: VALUE-CELL-LOCATION If this gets implemented, it probably would be a good idea to allow differentiation of unbound variables which have the shared value cell and those that do not (the way (get var 'value) returns NIL if var has never been bound, else (NIL . UNBOUND)). Maybe -1 in one case and 0 in the other, making PLUSP the canonical check on VALUE-CELL-LOCATION's result to see if the var is bound? I meant to say in my original proposal, that 0 was to be returned if there were no "private" value cell, and the address of the "private" value cell would be returned when there was one, regardless of whether or not the symbol was "bound". A combination of BOUNDP and VALUE-CELL-LOCATION can distinguish the two cases you mention, namely, "unbound, but no private value cell", and "unbound, with unoubnd marker in private value cell".  GSB@MIT-ML 08/04/79 03:55:29 Re: VALUE-CELL-LOCATION To: (BUG LISP) at MIT-ML If this gets implemented, it probably would be a good idea to allow differentiation of unbound variables which have the shared value cell and those that do not (the way (get var 'value) returns NIL if var has never been bound, else (NIL . UNBOUND)). Maybe -1 in one case and 0 in the other, making PLUSP the canonical check on VALUE-CELL-LOCATION's result to see if the var is bound?  Date: 4 AUG 1979 0104-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC I'm installing my patched version of last night, which appears to be whole. It does not fix the lack of error checking I just reported now, however.  Date: 4 AUG 1979 0100-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC '(a . b c d e) ==> (A . B . C . D . E .) I think this is a little over-helpful, and should give a helpful error message.  Date: 4 AUG 1979 0050-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC Floating unnormallized zero (430000,,0) prints as -0.000000000000 to an apparent infinity of zeros.  Date: 3 AUG 1979 0717-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC Both Macsyma and GRIND use LINEL as a special variable. Macsyma sets it to (LINEL TYO), but apparently GRIND clobbers it to something less than this.  Date: 3 AUG 1979 0551-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC I think that the default setting of DEFMACRO-FOR-COMPILING should be NIL, as I think this is the more frequent setting. In a large system, there will usually be only a few macro packages, but many of the component files will define macros for use only within the file.  Date: 3 AUG 1979 0507-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: FIX To: (BUG LISP) at MIT-MC I think I've got all my recently-reported READER problems fixed, will install when I get a chance to check it out.  Date: 3 AUG 1979 0128-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (In unpatched reader too, it's not a new bug). '(A . (B) .) gives (A . (B) . #51 .)  Date: 3 August 1979 01:14-EDT From: Alan Bawden To: JONL at MIT-MC cc: BUG-LISP at MIT-AI, RWK at MIT-MC VALUE-CELL-LOCATION then.  Date: 3 AUG 1979 0030-EDT From: JONL at MIT-MC (Jon L White) To: ALAN at MIT-MC, RWK at MIT-MC CC: (BUG LISP) at MIT-MC VALUE-CELL vs VALUE-CELL-LOCATION There are several internal kinds of data not yet visible to the lisp user - value cells are one of them. The segment table entry for value cells makes them look like some kind of LIST cell, just so that PRINT and CAR and CDR can hack them (if you should, perish the thought, ever get a pointer to them). But there are other kinds of spaces, for which the the segment table gives up with a more-or-less RANDOM description, and you can't do any lisp-like operations with them; e.g. the "symbol-block" space, "pdl" spaces, "system" spaces, "uuolinks" areas, etc. Really, rather than deal with any of the questions of how to extend these pointers into the LISP world, I'd prefer to give only primitives which return locations (addresses) and let the user use MUNKAM in order make the transfre explicit. There is of course, no penalty in time or space, in compiled code, in this approach - (MUNKAM (VALUE-CELL-LOCATION x)) is just as fast a (VALUE-CELL x). Especially, the only known application now for value-cell hackery is LAP, and it wants the location, not a "pointer" of any kind, for assembly into code. I'd like to prepare a LAP which takes this approach, supplying the needed gap from (GET x 'VALUE) if loaded into a LISP without the new feature; how about it guys, will VALUE-CELLL-LOCATION be acceptable?  Date: 2 August 1979 16:42-EDT From: Alan Bawden Subject: VALUE-CELL To: BUG-LISP at MIT-MC VALUE-CELL returning the value cell or nil would seem to be the rught thing. I presume there are no problems with having these objects in the real lisp world? (If the GC reclaims value cells of GCed atoms you could get screwed by GCTWA)  Date: 2 August 1979 08:18-EDT From: Robert W. Kerns Sender: ___024 at MIT-MC Subject: DEFUN& To: BUG-LISP at MIT-MC DEFUN& should offer the syntax (FOO &OPTIONAL (BAR BAR-default BAR-supplied-p)) I believe the LISP machine already offers this (at least RMS said he was going to implement it).  Date: 2 AUG 1979 0711-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: VALUE-CELL To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC Why not call the function "VALUE-CELL", and have it return the value cell itself rather than the address as a fixnum? There can be other use for having a locative to the value cell, but the real reason is that it would seem to make more sense to deal in objects than in addresses.  Date: 2 AUG 1979 0341-EDT From: JONL at MIT-MC (Jon L White) Subject: VALUE-CELL-LOCATION To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC I'm suggesting that this be a function which returns the address of a value cell, or else 0, meaning, the argument (a symbol) was not bound.  Date: 2 AUG 1979 0313-EDT From: JONL at MIT-MC (Jon L White) Subject: (GET foo 'VALUE) To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Yea, I suppose we should change lap, and have another method for getting a pointer to the value cell. Taking CDAR of a symbol isn't really kosher, especially if CAR and CDR are not equal to T - so how about a new function say VALUE-CELL-LOCATION?  Date: 2 August 1979 02:34-EDT From: Alan Bawden Subject: VALUE "property" special to GET To: JONL at MIT-MC cc: BUG-LISP at MIT-AI How I got shafted should be obvious. I wrote a piece of code that used the 'value property, and spent most of an evening trying to figure out why this trivial code wouldn't work. ("well gee, when I do a (plist 'foo) it says (value 777), so when I do a get...") It's not trivial to catch on that get is doing this wierd special case. If lap is the only thing to depend on this crock, then it seems obvious that it should be flushed. (I mean you can just replace (get x 'value) with (cdr (car x)) and it will do the right thing. Right?).  Date: 2 AUG 1979 0128-EDT From: JONL at MIT-MC (Jon L White) Subject: lisp init file hanging around To: SJOBRG at MIT-MC CC: (BUG LISP) at MIT-MC SJOBRG@MIT-AI 08/01/79 11:23:10 How come my LISP init file never gets closed during a LISP session? Even doing a GC doesn't help ... I actually have to kill the job before it closes. Due entirely to your useless line of code "(setq ^q nil)" which causes the value of INFILE to be kept pointing at the init file, rather than popping INSTACK at the EOF of the init. When that line is removed, you win totally. Try :LISP SJOBRG;FOO which is a copy of your init file with the offender removed.  Date: 2 AUG 1979 0004-EDT From: JONL at MIT-MC (Jon L White) Subject: VALUE "property" special to GET To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC Yes, LAP depends upon getting a locative to the value cell. As far as I know, no other program depends on such a locative. The decision to let GET bet the kludgy entry (instead of inventing another function name) was partly for ease of transferring from the old scheme, where the value cell was really hung off the property list as the VALUE property, to the new scheme with symbol-header-blocks etc. So how did you get shafted?  Date: 1 AUG 1979 2319-EDT From: JONL at MIT-MC (Jon L White) Subject: Splicing macros following a dot To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC In your examples, you point out that a splicing macro which immediatly follows a dot, *** and returns some non-null list ***, causes an unexpected result; but you missed the point of returning a null-list, namely that the stuff "just disappear". For example, what should (A B . ;Well this is a comment ) return? I claim it should be the same as (A B . ) which under the new rules is a hunk. If there is some merit to what you suggest it seems to be here: 1) let splicing macros at top-level, which return a list of length 1, exit from read with the single item from that list (instead of being ignored, and causing a rescan into READ again, as now happens) 2) let splicing macros immediately following a dot, which return a list of length 1, appear as of the item in that list were the thing typed; thus (A B . ~(C)) would read the same as (A B . C) This is probably pretty trivial to do.  Date: 1 AUG 1979 2319-EDT From: JONL at MIT-MC (Jon L White) Subject: Splicing macros following a dot To: ALAN at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC In your examples, you point out that a splicing macro which immediatly follows a dot, *** and returns some non-null list ***, causes an unexpected result; but you missed the point of returning a null-list, namely that the stuff "just disappear". For example, what should (A B . ;Well this is a comment ) return? I claim it should be the same as (A B . ) which under the new rules is a hunk. If there is some merit to what you suggest it seems to be here: 1) let splicing macros at top-level, which return a list of length 1, exit from read with the single item from that list (instead of being ignored, and causing a rescan into READ again, as now happens) 2) let splicing macros immediately following a dot, which return a list of length 1, appear as of the item in that list were the thing typed; thus (A B . ~(C)) would read the same as (A B . C) This is probably pretty trivial to do.  SJOBRG@MIT-AI 08/01/79 11:23:10 To: (BUG LISP) at MIT-AI How come my LISP init file never gets closed during a LISP session? Even doing a GC doesn't help ... I actually have to kill the job before it closes.  Date: 1 AUG 1979 0801-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Splicing macros fixed To: (BUG LISP) at MIT-MC, ALAN at MIT-MC, CWH at MIT-MC, KMP at MIT-MC To: JPG at MIT-MC, (BUG LISPM) at MIT-MC I took a gander at the READER code, and was thouroughly grossed out by the things like TLO T,4 and the like. But by the help of a few lucky guesses, and despite the lack of symbolic names for the flags, I was able to figure out what's going on. I've fixed in the source, and patched the current LISP to do splicing macros correctly at top-level and following the "." in dotted pairs. The one remaining problem is error detecting of forms like (FOO . ~(C) ~(D)), which should be an error, but currently returns (FOO D . C), which is going to confuse the user terribly, should he have such a bug. The fix involves a new flag, but since the current flags in T aren't symbolic, it's kinda hard for me to tell what bits if any are still free. So I'm postponing that part of the problem to another day. Also, (FOO . ~()) isn't detected either (it returns a one-hunk, which syntactically could be argued to be correct). That too would be fixed by the new flag. I left the old binary as MC:LISP;BBLISP 840QIR, in case I blew the patch, but it's been approved by the experts (ALAN, JPG). The patch should correspond exactly to my source changes (fingers crossed).  ALAN@MIT-AI 08/01/79 04:43:39 Re: I DON'T BELIEVE IT!!!!!!!!! To: (BUG LISP) at MIT-AI I have just been shafted by the most obscure "feature" in MacLisp. The indicator "value" is special to the function "get". That is (get 'foo 'value) returns foo's value cell! (Thats right the real thing, you can rplacd it and everything!) Now how many people do you suppose are aware of this? The obscurity is heightened by the fact that putprop and plist know nothing about get's strange behavior, so you can (putprop 'foo 34 'value) and the (plist 'foo) and everything looks fine! Now I can't believe there is anybody who depends on this feature, and if there is I vote we take him out and shoot him. Clearly this is somthing long overdue for flushing.  Date: 1 AUG 1979 0414-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Splicing macros, done right. To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC, KMP at MIT-MC, CWH at MIT-MC I just talked with ALAN. He implied the right way to do it in his last note, but let me summarize: 1) NIL is always ignored. No change. 2) (FOO) returned from a splicing macro is the same as just having typed FOO, at top level or inside a list. The only change is in top-level READ it has to know to return FOO instead of reading it. Also in the position after a . [his (A B . ~(C)) example]. 3) (FOO BAR) is just like FOO and BAR typed in without the ~ or parens. At top level and after a ., this should be an error. This really is a small pertebation in the current behaviour, and will fix both ALAN's and my complaints (being the same). It completely subsumes any need for macros to determine at run time whether or not they want to be splicing. It is simply a matter of making their behaviour consistant at top-level. Oddly enough, it probably means special-casing at the top-level (and after a ".") but in an innocuous way.  Date: 1 August 1979 01:41-EDT From: Alan Bawden Subject: interesting effects of losing splicing macros To: RWK at MIT-MC cc: BUG-LISP at MIT-AI, CWH at MIT-MC, KMP at MIT-MC This is all caused by the same effect, namely that splicing macros are ignored at "top level". In Maclisp # must be a splicing macro because of the actions of #q #m #- etc.  Date: 1 AUG 1979 0106-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: interesting effects of losing splicing macros To: (BUG LISP) at MIT-MC CC: ALAN at MIT-MC, CWH at MIT-MC, KMP at MIT-MC RWK: (LOAD '|MC:LIBMAX;CHAR FASL|) LISP: 124332 RWK: #/a () LISP: NIL RWK: '(#/a) LISP: (141) RWK: '#/a j LISP: J RWK: `(,#/a) ) ) () ) LISP: (NIL) We all know why this happens, but it definately is a screw; we should look into fixing it. A LISPM/NIL/MACLISP compatible #-macro won't be possible until this too is fixed. Any opinions on the "right" way to fix it?  Date: 31 JUL 1979 2209-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: Splicing macros after a dot. To: (BUG LISP) at MIT-MC CC: (BUG LISPM) at MIT-MC (setsyntax '/~ 'splicing '(lambda () (read))) (a b ~(c)) reads as (a b c) AND! (a b . ~(c)) read as (a b c) !!! Now no matter what your splicing macro philosophy is, this has Got To Be Wrong. As I see it the "right" thing to happen is for (a b . ~(c)) to be (a b . c). Also (a b . ~nil) should be an error (Not a hunk, as it is now). Also ~(foo) at top level should be the same as just foo, not ignored (/; can damn well return nil if it wants to be ignored). If someone makes these changes then there can be a lisp machine compatable # macro, but not untill then.  Date: 31 JUL 1979 1359-EDT From: MRG at MIT-MC (Michael R. Genesereth) To: (BUG LISP) at MIT-MC I notice that DEFMAC still has the losing 3 argument IF rather than the extended n argument version, i.e. (IF P Q1 R1 R2 R3 ...) goes to (COND (P Q1) (T R1 R2 R3 ...)))  Date: 27 JUL 1979 1929-EDT From: JONL at MIT-MC (Jon L White) Subject: GC bug To: REM at MIT-MC CC: (BUG LISP) at MIT-MC, HIC at MIT-MC, RLB at MIT-MC Have just returned from a two-week vacation, and saw your plaints about losing certain FIXNUM constants during fasloading. Indeed, sending notes to BUG-LISP (or BUG-COMPLR, as the case may be) is the right thing to do, since many persons monitor these notes, and various persons may have already seen the particluar problem at hand, or know its solution. As to the fasload/gcprotect problem, I don't think I wrote that code to do the "omit-gcprotect-if-already-protected-otherwise" thing, but I do remember the discussions on it: 1) an instruction like "(MOVEI 1 '(HERE IS 3.5))" should cause the whole quotified list to be put on the gcprotect table, but should not cause any of the atoms "HERE", "IS", or "3.5" to be enterend on the table (thereby consuming space to protect something already protected by virtue of its being part of the protected list) 2) but instructions like "(MOVEI 1 'FOOBAR)" and "(MOVEI 1 '3.5)" should make direct entries for the gcprotect table (unless, as in the case of symbols, they are already protected by the so-called "ccn" bit.) I remember HIC hacking this about a year ago, so assume that his analysis is correct, i.e. that fasload is not protecting directly-referenced numbers, and will try to add that to the source within a day or so. If you (REM) are using the SAIL version of maclisp, you will need a re-assembly in order to see the difference; hopefully, the ITS versions can merely be patched  Date: 26 JUL 1979 2056-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: CURSORPOS 'S and friends being documented To: (BUG LISP) at MIT-MC Of course, we all know LISP's documentation ain't worth a damn!  Date: 26 JUL 1979 2047-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: CURSORPOS 'S, 'R To: (BUG LISP) at MIT-MC These are documented as working, and I'm pretty sure they used to work. I also can't think of any valid reason for LISP using them internally. I think they should be made to work properly. Certainly LISP did not consistantly think they DIDN'T work, either. Certainly Q and P should work...  Date: Thursday, 26 July 1979 2044-EDT From: David McDonald Subject: Bug in MacLisp To: bug-lisp @ ai Message-ID: <26Jul79 204422 DM20@CMU-10A> The code to get the width of a terminal in the CMU version of MacLisp is incorrect. The current code is: seto 11,0 ; current job for getlin uuo calli 11,34 ; get sixbit terminal name. tlz 11,-1 ; zero left half of result. movei 10,1012 ; parameter to trmop uuo ; to return tty width. move 12,[xwd -2,10] ; 10 contains 1012 (get widthof ; terminal). 11 contains the ; users terminal index. calli 12,116 movei 10,111 ; default width of 73(decimal). subi 10,1 ; make it one less so that wrap ; around doesn't occur. movem 10,? ; store it in a random location The calli 11,34 returns the sixbit name of the terminal attached to the current job. The trmop uuo (calli ,116) requires the universail I/O index for the terminal. The sixbit name is not wanted, thus the calli 11,34 should be replaced with calli 11,115. This will return the universal I/O index for the terminal. Note that the calli 11,115 may give an error return by not skipping the next instruction. The -2 in the [xwd -2,10] operand should be a 2 as the calli 12,116 UUO needs the absolute length of its parameter block. Since the calli 116 should return the width of the terminal in register 12, the three following instructions should use 12 not 10. In the current system the calli 116 takes the error return and uses the default of 72 characters. The code that should be used to get the width of the terminal should be something along the following lines: seto 11,0 ; current job for trmno uuo calli 11,115 ; get universal I/O index for ; terminal jrst Default ; use default length on error. movei 10,1012 ; parameter to trmop uuo ; to return tty width. move 12,[xwd 2,10] ; 10 contains 1012 (get widthof ; terminal). 11 contains the ; users terminal index. calli 12,116 ; get current width of terminal Default: movei 12,111 ; default width of 73(decimal). subi 12,1 ; make it one less so that wrap ; around doesn't occur. movem 12,? ; store it in a random location This is not a high priority bug, since the current MacLisp uses the default value of 72 because the calli 12,116 gets an error. - David McDonald.  Date: 25 Jul 1979 (Wednesday) 1653-EST From: DEWOLF at WPAFB-AFAL Subject: Complr bug To: bug-lisp at MIT-AI From: Tim Finin at U. of Illinois I'm forwarding you the following bug report: From George[1000,170] on July 25, 1979 at 11:22 AM Tim, a bug in the compiler: if you say "(declare (notype (foo ? ? 2)))" then say (at top level) "(array foo t 40 24 2)", subsequent functions are compiled as if the array foo is never going to change (i.e., you get illegal mem ref's). This doesn't happen if the "(array ...)" is placed at the end of the file. Just thought you might want to know. --geo replies to finin@mit-ai. Tim Finin  Date: 25 JUL 1979 1553-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: GC bug (?) To: REM at MIT-MC CC: (BUG LISP) at MIT-MC I have found your bug. The problem was that you were running a complicated function (namely, (TEST)) before the FASLOAD finished. Unfourtunatly, due to a misfeature in FASLOAD, numbers don't get GCPROTECTED until **AFTER** the fasload is done. Therefore, simply completeing the fasload before calling (TEST) wins. JONL: What should happen is that instead of the stupid refernece bit approach, whenever a thing in the atom table gets used, it should be GCPROTECTED if it hasn't been before (I guess the reference bit could be redefined). This bug came up with symbols, and I fixed it once for that, but not in the most general fashion.  Date: 24 JUL 1979 1640-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: (CURSORPOS 'R/S) To: KMP at MIT-MC, (BUG LISP) at MIT-MC The original theory behind omitting R and S from the cursorpos command set was that they are only a one-level stack, and LISP sometimes uses (or used to use) them, and if LISP did then it woulld screw whatever the user was doing. You can always get the effect (somewhat less efficiently (?)) by just readin the cursor position yourself and then restoreing it. -- GLS  Date: 23 JUL 1979 1827-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: What does ;BKPT GCCON indicate to YOU? To: JIM at MIT-MC, RWK at MIT-MC, MACSYM at MIT-MC To: (BUG LISP) at MIT-MC Got me. I can't find the string "GCCON" anywhere in the LISP source!  Date: 23 JUL 1979 1331-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: (CURSORPOS 'S, R, P, or Q) To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC, HIC at MIT-MC None of the above worked. The code had been munged in various wrong ways, at CRSRP9 the bits enabling these were missing. At the two tables, one was right (i.e. it knew what kind of TTY's could do the operations, but it later thought they were in error....rather than simply "all done with no side effect...) I made it think they all don't do anything to the cursor, which not true of any of them but may let KMP win for now. The right answers are: P,Q -- Move forward 1 space if in sail mode not image, 2 if not image not sail, else 0 (not LISP's problem!). S,R -- S should save it, R should restore it. I've got other other things to do right now, so I haven't made it do them right. I did fix and patch as described above (patch only on MC), and put in a WARN in the source to remind whoever (JONL) that it's in need of a (easy) fix. Also, I left extra sources around for you to SRCCOM if you like, needing flushing. Gad, what an incoherent note, must have something to do with my continually falling asleep while typing. Anyway, I think the facts are all there.  Date: 23 JUL 1979 0905-EDT From: KMP at MIT-MC (Kent M. Pitman) Sent-by: BMT at MIT-MC To: (BUG LISP) at MIT-MC CC: CWH at MIT-MC (CURSORPOS 'R TYO) and (CURSORPOS 'S TYO) do not work as documented in .INFO.;LISP CURSOR - all they have to do is send R and S which work just peachy. If this could be fixed, I'd appreciate it. Thanx. -kmp  DHD@MIT-AI 07/22/79 07:05:03 To: (BUG LISP) at MIT-AI (STATUS OSPEED) on a TV --> 454 while (STATUS OSPEED) on a DATAPOINT --> 4540 ????!!!! Pls explain ????!!!!  Date: 22 JUL 1979 0158-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC (^ 2 37.) prints ;ANSWER TOO BIG -  You're missing a bit someplace.  Date: 20 JUL 1979 0051-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: RZ at MIT-MC To: DHD at MIT-MC CC: (BUG LISP) at MIT-MC (CURSORPOS 'TOP) works quite well. I think documenting this is better than changing the behaviour of LISP, because I don't see any compatible change which will also fix the (CURSORPOS 'T) case. DHD: The problem is that T has the meaning of STANDARD-IO, i.e. the terminal, controlled by ^W etc. flags. And CURSORPOS is defined to work for a FILE as the first argument just as (CURSORPOS) looks at T or something. So it really is defined conflictingly, but (CURSORPOS 'TOP) works fine. Interestingly, (CURSORPOS 'T 'T) also works fine, because the meaning of the T's are unambiguous, and different! Actually, it should be standardized as (CURSORPOS 'CLEAR), (CURSORPOS 'FORWARD) etc.....  DHD@MIT-AI 07/19/79 23:58:23 To: (BUG LISP) at MIT-AI (CURSORPOS 'T)  (CURSORPOS) rather then going to the top of the screen as its supposed to. (Would u please notify me when this is fixed?) tnx, dhd.  Date: 17 JUL 1979 1655-EDT From: REM at MIT-MC (Robert Elton Maas) Subject: Update to previous notes on bug in QCOMPL and GC To: (BUG LISP) at MIT-MC, (BUG QCOMPL) at MIT-MC CC: (BUG NCOMPL) at MIT-MC, RWG at MIT-MC I am cleaning up my directory now that I have my program working. To start it, say this: :LISP N (FASLOAD (CYLIKR FASL DSK REM)) 3 ^G #SAFE (SETQ #SAFE NIL) (REC-EV-BD #BD T 4 1) ;(COUNT-BITS 377750040_11 YIELDS 377100242453) error message detecting ;BKPT *RSET-TRAP clobbered FIXNUMs if you omit the (SETQ #SAFE NIL) step, it works correctly because all the FIXNUM constants accessed by the buggy compiled code are on a global s-expression #SAFE thus they get marked during GC and not reaped. Source is currently REM;CY13 > but may change if I work on program, but that file or any with similar name should suffice for diagnosing the bug in QCOMPL as interfacing to G.C. in LISP (or vice versa). You may wish to delete parts of earlier messages which are obsoleted by this message (such as old file names and less-precise guesses as to the cause of the bug).  Date: 17 JUL 1979 0525-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC CC: JPG at MIT-MC It seems that "IGNORE" is being used to mean intentionally-unused lambda variable on LISPM and "NIL" is used for this purpose in MACLISP. Can you guys come to a meeting of the minds and agree on at least one of these two which will work for both MACLISP and LISPM. Incompatibilities like this just make it hard for us programmers who want to write code which will be treated similarly in both environments.  DHD@MIT-ML 07/17/79 03:32:23 To: (BUG LISP) at MIT-ML If you give a symbol to READ by typing "foo " the space is not TYI'd - why is this - is it a bug|feature?  Date: 16 JUL 1979 2200-EDT From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC CC: (BUG QCOMPL) at MIT-MC, RWG at MIT-MC Final message (probably) on bug in GC in LISP, pointers from compiled code to FIXNUMs not traced during GC causing FIXNUM objects to be reaped while code still points to them. MC:REM;CY12 > CY12 FASL Contains (SETQ #SAFE (LIST 111111111111 7007007007 777000777 777777 -7777 -1 -2 -3 -6 -9. -18.)) which protects all these constants }from reaping and fixes the bug. The following JCL wins: :LISP N (FASLOAD CY12) T ^G (REC-BD-VAL #BD T 4 1) runs for 10 or 20 seconds and returns the correct value of 0 but if you do (SETQ #SAFE NIL) just before calling REC-BD-VAL, i.e. unproect those constants from GC, within a couple seconds after starting REC-BD-VAL it detects that the result of COUNT-BITS isn't in range 0 to 36. thus showing at least one of the masks or shift-amounts has been reaped and replaced by some new random FIXNUM object. (Or at least that's what all the evidence points to.)  Date: 16 JUL 1979 2140-EDT From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC Now I'm almost sure the problem with CY11 FASL is a bug in GC, not failing to update pointers as it compactifies memory (it doesn't do that anyway), but rather failure to mark all pointers from compiled code. I found that by simply setting a global variable to a list of all the FIXNUM values, they are protected from getting reaped, and the compiled EXPR that uses those values fails to break like it did when the values weren't protected.  Date: 16 JUL 1979 2120-EDT From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC More on that clobbered-fixnum-space bug. MC:REM;CY11 > and MC:REM;CY11 FASL are the source and compiled code for the latest version of my program which has an additional trap to see if the number of bits in a word (computed by HAKMEM shifting) is out of the range 0 to 36. It hits this bugtrap rather quickly, indicating that the masks (all FIXNUMs) or shift-amounts (small FIXNUMs -1 -2 -3 -6 -9 and -18) are clobbered rather quickly. JCL for making bug strike is: :LISP N (FASLOAD CY11) T ^G (REC-BD-VAL #BD T 4 1) Changing the ALLOC? answer from N to Y and giving 200000 extra FIXNUM space doesn't help, the program bombs out when (STATUS SPCSIZE 'FIXNUM) reaches 14000 just as if the alloc hadn't been done at all. But giving an explicit (ALLOC '(FIXNUM (200000 200000 NIL))) after the control-G just before the call to (REC-BD-VAL ...) causes the bug to go away!! Size of FIXNUM at the time REC-BD-VAL returns the correct answer (zero) is about 140000. I believe strongly this is a GC bug wherein compiled code doesn't get its registers (pointing to FIXNUM objects) or stacks (ditto) updated properly when GC is done, or other GC bug. Anybody wan to tackle this one? The fact that it works correctly when given lots of FIXNUM space gives me confidence it is bug in LISP rather than something I'm doing dumb, but of course it's still possible...  REM@MIT-ML 07/16/79 18:55:33 Re: Addenda to my message of last night To: (BUG LISP) at MIT-ML To make LISP world-clobberage occur, do this: :LISP N (FASLOAD REM FASL DSK USERS3) T ^G #BD Should print out (377770_22 . 37777) if you did the above stuff correctly. (REC-BD-VAL #BD T 4 1) Will run for a few seconds (maybe 30) then get the program-detected error: ;(10_22 10_22 -7777 WORLD CLOBBERED) which means the program has detected that (CAR RESLIST) isn't equal to (1+ -10000) even though the previous prog statement was (SETQ RESLIST (CONS -7777 ...)) The first item in the list and the second item are -7777 (constant compiled into the function) and (CAR RESLIST), the third item is (1+ -10000). They should all be equal but aren't!! At SU-AI the same bug happens as at ML. File is CY.FAS[1,REM]. Sources are ML:USERS3;REM CY10 and SU-AI:CY.10[1,REM]. I AM NOT DOING ANY RPLACA or RPLACD, and the only NCONC is implicit in a MAPCAN, so I don't believe I'm clobbering anything. Interpreted it runs 40 times as slow but without error.  Date: 16 July 1979 14:54-EDT From: Earl A. Killian To: REM at MIT-MC cc: BUG-LISP at MIT-MC, BUG-CRTSTY at MIT-MC There is no way to tell CRTSTY to hold off on display updating. It is not possible to do this sort of thing without having two screen images. There are two things you can do: 1. Buffer your output and only send it to the TTY when you're done. 2. Don't use CLEOL as freely as you do now - don't expect that you can use them anytime you want and have CRTSTY do all the work for you. Even better, of course, would be to get rid of your CLEOL-less terminal.  REM@MIT-ML 07/16/79 10:38:35 To: (BUG LISP) at MIT-ML CC: (BUG NCOMPL) at MIT-ML Is there any way to run interpreted LISP so as to get the same results as compiled LISP? The program SU-AI:CY.10[1,REM] executes perfectly (but very slowly) when interpreted, but when compiled and run on either SU-AI or MIT-ML (MIT-MC was down at the time) it manages to clobber various FIXNUMs so that the compiled (= -7777 (1+ -10000)) yields NIL. How do I diagnose this problem???  Date: 16 JUL 1979 0022-EDT From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC, (BUG CRTSTY) at MIT-MC Not a bug, rather a question. Is there any way LISP can send a signal to the CRTSTY it's running under that says in effect "don't update the screen until I tell you", then later send a signal that says in effect "ok, now I'm done making all the changes I want for now, please send the terminal all updates necessary at this point in time before listening to me any more"? I have a program that types out a checkerboard on the terminal. To run in display mode I simply do (CURSORPOS 0 0) just before printing the board, but timing races in CRTSTY cause it to frequently erase part of a line that didn't change and retype it. If I could set up batches of output and if CRTSTY could stabilize on a batch before starting updates, the number of characters sent over the 300-baud TIP port would be much fewer, only what is actually necessary to make actual changes, and the effect on the eye would be much better, I'd see motion of checkers without spurious erase-retype motions elsewhere on the board.  Date: 16 JUL 1979 0002-EDT From: REM at MIT-MC (Robert Elton Maas) To: (BUG LISP) at MIT-MC It would seem to me that the following: (PROG NIL (PRINC 'FOO) (FORCE-OUTPUT TYO) (PRINC 'BAZ) (CLEAR-OUTPUT TYO)) should send FOO to the terminal, force it to actually reach the terminal, send BAZ to the terminal, flush output of BAZ, and return NIL to toplevel. Thus FOO should always print, and BAZ will usually be flushed unless the system is very busy and the output of BAZ wins the race over CLEAR-OUTPUT. What actually happens is that neither FOO nor BAZ print. Is this a bug? (I'm running LISP under :CRTSTY REMB under AMES-TIP)  Date: 15 JUL 1979 0845-EDT From: JONL at MIT-MC (Jon L White) Subject: .5LOCKI and a bug by JLS To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC, jls at MIT-AI I presume you wrote the greater part of the code for $DEVICE - maybe you could comment on this analysis: There are two places which could invert the order of two characters typed in at the tty: 1) the .5locki permits some interrupts durint the i/o wait for the tty, and indeed during the whole routine. one such interrupt could, sub-recursively, call read etc. and cause some chars to be "buffered-back". 2) the CALL to the tty-buffering routine (rubout processor) is done after doing UNLOCKI. thus during the time in which it runs up to the point wherein the list of returned chars is smashed into the FI.BBC slot of the tty file array, there could be an interrupt which could, sub-recursively, call read etc. and cause some chars to be "buffered-back". In the first case, the first "buffered-back" char will be interchanged in time sequence with the char which was currently being read by the .IOT (or whatever); in the second, all such "buffered-back" chars are lost due to the smashing action. I believe this explains the following bug, found by Stansfield, and also believe I have (gleep with many instructions) patched it. JLS@MIT-AI 06/18/79 15:29:02 HI, I FOUND SOME STRANGE BEHAVIOR IN LISP. THE FOLLOWING IS THE TYPE-IN AND TYPE-OUT AS IT APPEARED ON THE SCREEN. IT SEEMS THAT THE FUNCTION TO CONSTRUCT ATOMS FROM INPUT GETS CONFUSED AND PUTS IN A DELIMITER WHERE THERE IS NONE. (DEFUN FOO (X Y) (PRINT (TYI)) (PRINT (READ))) FOO (SSTATUS TTYINT 6 'FOO) FOO BAR ;; I TYPE IN CONTROL-F "BAR" AND 6 ;; FOO ECHOES CONTROL-F BAR HJK ;; FOO ECHOES BAR. I TYPE HJK ;H UNBOUND VARIABLE ;BKPT UNBND-VRBL ;JK UNBOUND VARIABLE CAN YOU TELL ME WHY HJK IS SPLIT UP INTO TWO ATOMS. JIM STANSFIELD I also wonder if there have been any other bug-lisps reported which this corrects - it still doesn't take care of the case of a pseudo-space being inserted at the end of some toplevel symbols.  Date: 15 JUL 1979 0014-EDT From: JONL at MIT-MC (Jon L White) Subject: LINEMODE To: (BUG LISP) at MIT-MC I see that a line of code is missing in the "function" TOP-LEVEL-TERPRI, namely the one that should fetch the linemodep bit from the tty file array. Does any one remember a bug related to this (probably only shows up in DEC10 versions).  Date: 14 JUL 1979 2202-EDT From: JONL at MIT-MC (Jon L White) Subject: .5LOCKI To: (BUG LISP) at MIT-MC CC: JLS at MIT-MC Well, nice try, but only half a bannana. This takes care of restoring register T if a TTY interupt occurs during tty-input wait (and maybe the file array moved around), but it doesn't take care of flow-of-control decisions made on the basis of an empty buffer-back list (FI.BBC). This is the root of the JLS weirdo wherein " IJK" gets contorted into "I JK". Maybe I can fix this today.  Date: 11 Jul 1979 2204-PDT From: Guy Steele Subject: DEFVST and friends To: BUG-LISP at MIT-MC It would make debugging easier if the error "incorrect selector - SETVST" were correctable. A hairy thing but convenient would be to suppress the warning message if the redefinition of an existing structure is the same as the old definition.  Date: 10 Jul 1979 1718-PDT From: Guy Steele Subject: Optional argument presence test To: bug-lisp at MIT-MC, bug-lispm at MIT-AI I too rather like the syntax &OPTIONAL (var1 init1 predvar1) (var2 init2 predvar2). It does present certain implementational difficulties, but I think they can be overcome. An interesting phenomenon is that if ij) and predvari is null (resp. non-null) then predvarj is also. Compiler optimizers take note!  ALAN@MIT-AI 07/10/79 00:22:39 Re: huh? To: RMS at MIT-AI CC: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI Perhaps you could remind those of us who don't remember. Just what is RWK's suggestion for &OPTIONAL?  RMS@MIT-AI 07/10/79 00:17:46 To: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI I like RWK's &OPTIONAL (BAR NIL NAR-P) idea. Any objections?  Date: 9 JUL 1979 1310-EDT From: JONL at MIT-MC (Jon L White) Subject: (FUNCALL ) To: touretzky at CMU-10A CC: (BUG LISP) at MIT-MC We've been propogating the term "special forms" for the use of symbols in LISP that are sort of "built-in" - one problem with the term "fsubr" is that it leads you to suspect that it is usable anywhere that a normal "subr" function is. FUNCALL is only for functions - it appears to be a deficiency of the interpreter and compiler that FUNCALL doesn't check this. We did extend the meaning of APPLY for "fsubrs" such that (APPLY ) is to mean the same as (EVAL (CONS )) and it is the shared code (between funcall and apply) that is causing FUNCALL to miss out on checking.  Date: 09 Jul 1979 0312-PDT From: Rod Brooks Subject: CompiledInterpreted To: bug-lisp at MIT-MC Is something wrong with the compiler's (888) side effects analysis? (DEFUN TTT (STREAM) (PROG2 () (CAR (SYMEVAL STREAM)) (SET STREAM (CDR (SYMEVAL STREAM))))) ;; interpreted (SETQ X '(3 4)) (3 4) (TTT 'X) 3 X (4) ;; compiled (SETQ X '(3 4)) (3 4) (TTT 'X) 4 X (4)  Date: 9 JUL 1979 0238-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC Sorry 'bout that, left off an "M" there...  HIC@MIT-AI 07/09/79 02:19:21 To: (BUG LISP) at MIT-AI A) Create specials with PROGV, bind them to NIL B) MAKUNBOUND them C) Close over them D) Access them in the closure E) Discover that you get DTP-NULL trap as opposed to unbound. Also, *EVAL now treats DTP-ENTITY the same way as DTP-CLOSURE  Date: 8 Jul 1979 1911-EDT From: DAVE.TOURETZKY at CMU-10A Subject: bug in COMPLR To: bug-lisp at MIT-AI cc: SCOTT.FAHLMAN (funcall 'grindef (list fn-name)) works in the interpreter, but not when compiled. I have reason to suspect that it is passing fn-name rather than (list fn-name). grindef is of course a fexpr. (apply 'grindef (list fn-name)) works everywhere. is this a bug in complr, or in me?  Date: 6 JUL 1979 2308-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Correction to last note To: SKH at MIT-MC, (BUG LISP) at MIT-MC Sorry, I left out a line in my reconstruction of what you said that was relavent. (There was a BIT more than that that was relavent!) (TRACE MOVE) (DEFUN MOVE ....) (GRINDEF MOVE) ;TRACED . (I got interrupted half-way through typing in the message and dropped a few bits, sorry.) Anyway, the rest of my comment still stands. In fact, it looks like what GRINDEF must be doing is looking at the variable TRACED-STUFF, rather than anything meaningfully coordinated with DEFUN and the property-list of the function!  Date: 6 JUL 1979 2259-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: GRINDEF/TRACE interaction To: SKH at MIT-MC, (BUG LISP) at MIT-MC The only thing that you said that had any relevence was: (TRACE MOVE) (GRINDEF MOVE) ;TRACED. I.e. that GRINDEF doesn't understand traced functions. It should. It should also probably have a better check for traced functions, say actually looking at the EXPR property for a (COMMENT /;TRACED (old-expr)) and then use the frob in the comment as the frob to print.  Date: 5 JUL 1979 2323-EDT From: H at MIT-MC (Jack Holloway) To: (BUG LISP) at MIT-MC Strange "see JONL" error comment when compiling JONL;stippl 49.  Date: 5 JUL 1979 2244-EDT From: SKH at MIT-MC (Kipp E.B. Hickman) To: (BUG LISP) at MIT-MC while using Q, I loaded the file |SKH HANOI|. Then i ^Z'd out of it, and :disown it then edited my skh hanoi file again, then reowned the Q, and :proced it. Then i reloaded the file |SKH HANOI|. I then tried to GRINDEF a function and all I got was: ;TRACED * ;I.e. NO function was listed. The function existed, but GRINDEF didn't find it. THe file is on GUEST3, by the way. Also, i used (LOAD '|SKH HANOI|) to load it, both times.  Date: 3 July 1979 08:43-EDT From: Robert W. Kerns Sender: ___022 at MIT-MC Subject: *MACROARG* To: BUG-LISP at MIT-MC, RMS at MIT-MC cc: RWK at MIT-MC How about something like (DEFUN FOO (BAR BAZ &OPTIONAL BRAP &LENGTH LENGTH) ....) to access the number of arguments? Or alternately, (DEFUN FOO (BAR BAZ &OPTIONAL (BRAP NIL BRAP-P) ...) would bind BRAP-P to T or NIL according to whether or not the optional arg was supplied. Or both. They're not incompatible, and really are more suited for different cases. I really don't like the *MACROARG* technique at all.  Date: 3 JUL 1979 0316-EDT From: JONL at MIT-MC (Jon L White) To: ken at MIT-AI CC: (BUG LISP) at MIT-MC KEN@MIT-AI 06/26/79 03:33:19 Re: defun& To: (BUG LISP) at MIT-AI On the Lisp Machine (DEFUN FOO (X &OPTIONAL (Y)) ...) is idenitical to (DEFUN FOO (X &OPTIONAL (Y NIL)) ...) while only the second form is acceptable to maclisp's defun& (the first one it complains about bad syntax) This has been fixed now.  Date: 3 JUL 1979 0314-EDT From: JONL at MIT-MC (Jon L White) To: rms at MIT-AI CC: (BUG LISP) at MIT-MC RMS@MIT-AI 06/28/79 18:17:34 To: (BUG LISP) at MIT-AI Maclisp DEFMACRO doesn't use *MACROARG* to hold the form which makes it incompatible with Lispm DEFMACRO. It is necessary to use *MACROARG* to tell for certain whether an optional arg was supplied or not. There are 3 reasons why the maclisp DEFMACRO does not use *MACROARG* in imitation of the LISPM defmacro: 1) It is not a documented feature of defmacro in the LISPM manual, so any dependence upon it is a kludge that deserves to lose randomly. 2) In order to determine how many args are actually being passed, when there are &optional (or &rest) variables, it would be nice to have a method consistent between both DEFUN and DEFMACRO. Using *MACROARG* defeats this goal. Admittedly, there is no "ARG" function for either DEFUN or DEFMACRO, but having pored over much LISPM and MACLISP code, I can say that using some distinctive marker as the default value for the optional variable *is* is consistent and workable. [This "distinctive marker" may have to be suitable constructed from a description of the program - I doubt that a single marker would work for all possible programs]. 3) There is an inherent flaw in scoping, when using just a single name such as *MACROARG*, illustrated by the following: (DEFMACRO BLETCH (A &OPTIONAL B) `(RUN ,a (RLIST ,(cond ((cddr *MACROARG*) b) (default-value-for-b)) ,a))) (DEFMACRO RLIST (X Y) `(LIST ,y ',(eval x))) Admittedly, this sort of thing, explicit calling of EVAL, leads one to all sorts of non-modularity bugs, but here the problem is even more obscured, since there is nothing in the code to suggest that the "free(?)" variable *MACROARG* will be captured by the scope of RLIST. The maclisp DEFMACRO uses a name constructed by string- appending the macro name to "-MACROARG", so that *MACROARG* in the definition of BLETCH above would become BLETCH-MACROARG; however I'm not fully satisfied with that, for I'm sure there are some glitch cases even there.  Date: 3 JUL 1979 0227-EDT From: JONL at MIT-MC (Jon L White) Subject: SETF on macro-expanded forms To: gls at SU-AI CC: (BUG LISP) at MIT-MC Date: 19 Jun 1979 0112-PDT From: Guy Steele Subject: Screw with DEFVST (which otherwise works fine) To: bug-lisp at MIT-MC (DEFVST GRUNT FOO BAR BAZ) (DEFMACRO CLOBBER (FROB) `(SETF ,FROB (CLOBBERIFIER ,FROB)) ) (CLOBBER (GRUNT-BAR MY-FAVORITE-GRUNT)) This fails to work because the two occurrences of FROB (i.e. of (GRUNT-BAR MY-FAVORITE-GRUNT)) in the generated SETF form will be EQ. The second occurrence is evaluated first, and macro-expanded in the process. As a result, the SETF (i.e. SETVST) sees a form as its first argument whose car is MACROEXPANDED rather than GRUNT-BAR, so it gets very unhappy. I am fixing this by writing instead `(SETF ,(APPEND FROB '()) (CLOBBERIFIER ,FROB)) but this seems to be a crock. Is there any hope of a reasonable general solution to this problem? Yes, there are several general solutions to this problem, which is not unique to DEFVST 1) simply, during the runtime environment, set MACRO-EXPANSION-USE to something other than MACROEXPANDED; like, say, (), or DISPLACE, or MACROMEMO. 2) during the definition of the structure, use the "temporary override" feature for DEFMACRO-DISPLACE-CALL; see the latest two LISP RECENTs to see how (DEFMACRO (foo flag-name flag-value ...) ...) differes from (DEFMACRO foo ...). DEFVST permits the same kind of temproary settings for the various "flag-name"s. WARNING! A bug in DEFVST caused this to fail for DEFVST, but I just fixed that; so try FTP'ing over to SAIL the latest LIBLSP;DEFVST FASL. With the corrected DEFVST, I tried "(DEFVST (GRUNT DEFMACRO-DISPLACE-CALL ()) ...) and won properly. 3) push for a general acceptance of SETF in the maclisp community (which your function CLOBBER seems to be going in that direction), and let SETF know specifically about MACROEXPANDED.  GSB@MIT-ML 07/02/79 20:25:38 To: (BUG LISP) at MIT-ML lisp doesn't appear to be checking the number of args that an lsubr (at least one that takes a fixed number of args) gets when it is called from compiled code with nouuo=NIL. It does catch it in nouuo T mode. Both of these with *RSET T.  DDM@MIT-AI 07/01/79 22:51:09 Re: ignore prior message To: (BUG LISP) at MIT-AI ...I had inadvertantly fallen into a mode where prin1 was bound to a routine that did the funny hunk format.  DDM@MIT-AI 07/01/79 22:45:00 To: (BUG LISP) at MIT-AI When did the printing convention for hunks go over to this {}-style list and what do I have to do to get the dotted-list format back ??!!  Date: 1 JUL 1979 1541-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (DEFUN FOO ((A B)) (LIST B A)) seems to be accepted by lisp but does the following: (DEFUN FOO (G0003) (COMMENT ARGLIST = ((A B))) (LET (A) (DESETQ A G0003) (LIST B A))) This doesn't seem quite like what I had hoped it would do...  GSB@MIT-ML 07/01/79 01:30:06 To: (BUG LISP) at MIT-ML (tyipeek ) always seems to act as (tyipeek NIL ). Apparently the sfa-testing code at incall is treating them all the same, if the sfa handles TYIPEEK. But if i flush TYIPEEK from the which-operations mask (so that each TYIPEEK will be simulated with a TYI/UNTYI pair) then ISTCAL gets called with various and sundry things in AR1, causing gross lossage.  Date: 30 JUN 1979 1632-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC (CHARPOS () ) Barfs with an error msg. Shouldn't CHARPOS accept () the same as T by translating it to value of TYO?  Date: 30 JUN 1979 1124-EDT From: JONL at MIT-MC (Jon L White) Subject: FORMAT for maclisp To: DHD at MIT-MC CC: (BUG LISP) at MIT-MC When I try (format nil '|foo ~r| 5), I get an error msg different than the one you mentioned. There is a new FORMAT, with the changes suggested by GLS a few weeks ago, on the COMLAP directory, and it merely tells you that "R" is not (yet) implemented.  DHD@MIT-ML 06/29/79 22:54:08 To: (BUG LISP) at MIT-ML (format nil '|foo ~r| 5) --> ";STRING-SEARCH-CHAR UNDEFINED FUNCTION IN UUO CALL"  Date: 29 Jun 1979 1600-PDT From: Dick Gabriel Subject: LINEL on TOPS-20 To: bug-lisp at MIT-MC Should (LINEL ()) = -1 initially, as it is now? -rpg-  JONL@MIT-MC 06/29/79 10:40:55 Re: TOPS-20 MACLISP bugs To: SCOTT at SRI-KL CC: (BUG LISP) at MIT-MC, johan at PARC-MAXC2, Admin.MRC at SU-SCORE HA! Found both bugs. Will reassemblel to fix them. 1) Terminal line length was read in by RFMOD, but code tried to get data from AC 1 instead of AC 2; 2) Some internal symbols were missing from the TOPS-20 version, so that some hand-coded functions were unable to link to them. EDIT is such a hand-coded package.  Date: 29 JUN 1979 0254-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Why does (EXPT -2.0 2) => 4.0 but (EXPT -2.0 2.0) => ;-2.0 NON-POS ARG - LOG Yes, I do understand that logs are getting called to do this operation, but can't the sign be hacked by EXPT before passing it to LOG? Tnx. -kmp  Date: 29 JUN 1979 0055-EDT From: RWK,GJC at MIT-MC Sent-by: ___017 at MIT-MC To: (BUG LISP) at MIT-MC The TTY interrupt routine should look at the file array, and if isn't a TTY file array, (i.e. opened with the TTY option) it shouldn't assume that what's in the buffer is a table of interrupt routines! It shouldn't be necessary to specify the TTY option if all you're doing is treating a foreign TTY as a file!  RMS@MIT-AI 06/28/79 18:17:34 To: (BUG LISP) at MIT-AI Maclisp DEFMACRO doesn't use *MACROARG* to hold the form which makes it incompatible with Lispm DEFMACRO. It is necessary to use *MACROARG* to tell for certain whether an optional arg was supplied or not.  Date: 28 JUN 1979 1309-EDT From: JONL at MIT-MC (Jon L White) Subject: GRINDEF To: (BUG LISP) at MIT-MC Load in the file MC:JONL;ROD BUG and try (GRINDEF ROD). for some reason, it will print the second line with about (3/2)*LINEL characters on it, instead of breaking it up into two or three lines.  Date: 28 JUN 1979 0005-EDT From: MOON at MIT-MC (David A. Moon) To: (BUG LISP) at MIT-MC RMS@MIT-AI 06/27/79 21:45:39 To: (BUG LISPM) at MIT-AI Maclisp DEFMACRO doesn't use *MACROARG* to hold the form which makes it incompatible with Lispm DEFMACRO. It is necessary to use *MACROARG* to tell for certain whether an optional arg was supplied or not.  Date: 27 JUN 1979 2238-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: HUNKS (OK, OK, so don't read the message if they upset you that much!) To: (BUG LISP) at MIT-MC (setq x (hunk 1)) ;this now makes a HUNK2 instead of a CONS (1 .) ;I don't mind the way they print now (too much) (car x) ;this is with *rset t #777777 ;Hmm, I think this should be caught (its the ;only case where car should check!) (hunk) ;... nil ;Now I see why this might be the "right" thing ;but I am pretty damn sure that if I ever try ;and create such a thing it is an error and I ;would like to be told about it.  Date: 26 JUN 1979 1747-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC CC: JLS at MIT-AI JLS@MIT-AI 06/18/79 15:29:02 HI, I FOUND SOME STRANGE BEHAVIOR IN LISP. THE FOLLOWING IS THE TYPE-IN AND TYPE-OUT AS IT APPEARED ON THE SCREEN. IT SEEMS THAT THE FUNCTION TO CONSTRUCT ATOMS FROM INPUT GETS CONFUSED AND PUTS IN A DELIMITER WHERE THERE IS NONE. (DEFUN FOO (X Y) (PRINT (TYI)) (PRINT (READ))) FOO (SSTATUS TTYINT 6 'FOO) FOO BAR ;; I TYPE IN CONTROL-F "BAR" AND 6 ;; FOO ECHOES CONTROL-F BAR HJK ;; FOO ECHOES BAR. I TYPE HJK ;H UNBOUND VARIABLE ;BKPT UNBND-VRBL ;JK UNBOUND VARIABLE CAN YOU TELL ME WHY HJK IS SPLIT UP INTO TWO ATOMS. JIM STANSFIELD  Date: 26 JUN 1979 1343-EDT From: PRATT at MIT-MC (Vaughan Pratt) To: (BUG LISP) at MIT-MC I'm STILL having trouble with (status featur 'noldmsg) which seems to come out NIL when I use complr. (Try compiling the empty CGOL file beginning (cgol) to see what I mean. CGOL gets loaded, tests noldmsg, finds it is NIL, and prints a load message.)  KEN@MIT-AI 06/26/79 03:33:19 Re: defun& To: (BUG LISP) at MIT-AI On the Lisp Machine (defun foo (x &optional (y)) ...) is idenitical to (defun foo (x &optional (y nil)) ...) while only the second form is acceptable to maclisp's defun& (the first one it complains about bad syntax)  Date: 25 Jun 1979 (Monday) 0113-EST From: DEWOLF at WPAFB-AFAL Subject: Complr bug To: bug-lisp at MIT-AI I got the following message and thought I'd forward it to you. It occured in a old COMPLR (633 by 632), but, who knows, maybe this bug exists still. -------------------------------------------------------------- From Onr Project[1000,222] on June 19, 1979 at 8:13 AM Re: lisp compiler bug (cond ((null j) nil) ...) cause it to generate code as if (cond (j nil) ...) To fix it do the following: (cond ((null j) any-dummy-function-here) ...) T. Wong (3 man-hours) [Forwarded from Tim Finin] ______________________________________________________________ Tim  Date: 24 JUN 1979 0630-EDT From: KMP at MIT-MC (Kent M. Pitman) To: JONL at MIT-MC, GJS at MIT-MC CC: (BUG LISP) at MIT-MC The new version of GRINDEF has been released. I don't think I broke anything and it seems to do some winning new things. In particular, the following feature has been added: Rather than using FLATSIZE to tell the width of something, a function called GFLATSIZE1 is called. GFLATSIZE1 takes two args (1) An object (2) A flag which should be NIL only if the 1st args is a CDR'd list (ie, if it is a list whose CAR should not be treated as a functional object) GFLATSIZE1 differs from FLATSIZE in that it will (1) never call FLATSIZE except on atoms (2) if the CAR of an atom has a GRINDFLATSIZE property, it should be a function of 1 arg which will return a fixnum saying the size of the object. That function may recursively call GRINDFLATSIZE1 on any of its subparts if it desires. ` ' , ,@ all have initial GRINDFLATSIZE properties. This fixes the bug that caused '`(,a ,b ,c ,d ,e ,f ,g) to print vertically on an 80 char screen because it thought it didn't have enough room to fit it horizontally. Additionally, GJS's '(LAMBDA (X . Y) ...) bug is fixed in this new version of GRINDEF. --kmp  BYRON@MIT-ML 06/23/79 18:00:42 To: (BUG LISP) at MIT-ML CC: BYRON at MIT-ML Now that MACLisp no longer tries to evaluate the car of a function call, it seems that PROGN could be made implicit. That is, a list of s-expressions, the first of which is not an atom, could be treated as an implicit PROGN, evaluating each member in turn, and returning the value of the last. (Macsyma does something like this.)  KEN@MIT-AI 06/22/79 07:06:20 To: (BUG LISP) at MIT-AI sys2;ts olisp was linked to SYS2;purqio 1785 which did not exist I took theliberty of relinking it to sys;purqio 1785 (this is on ai)  MJA@MIT-AI 06/22/79 02:40:03 To: (BUG LISP) at MIT-AI THE SAME ERRORS OCCUR (SEE MY PREVIOUS MAIL) WHEN TOPS10=1 AND KI10=1 HOWEVER TOPS10=1 AND KA10=1 DOES NOT PRODUCE ANY ASSEMBLY ERRORS. ONE PROBLE M I DID FIND WITH THE LATTER IS THAT DOING A UREAD OF THE SAME FILE MORE THAN ONCE WILL CAUSE A NON-EXISTANT PPN ERROR TO OCCUR.  MJA@MIT-AI 06/22/79 02:27:53 To: (BUG LISP) at MIT-AI WHEN MACLISP 1804 IS ASSEMBLED USING MIDAS 406 WITH THE FOLLOWING NON-DEFAULT SWITCH SETTINGS: TOPS10=1 KL10=1 THE FOLLOWING ERRORS OCCUR: FP4E0 421342 0. 276-016 D1.0E8 UNDEFINED FP4E1+2 421350 0. 276-035 D10.0 UNDEFINED FP4E+2 421354 0. 276-056 D1.0E8 UNDEFINED FP4E2 421357 0. 276-078 D10.0 UNDEFINED THESE ERRORS OCCUR ONLY ON PASS 2.  Date: 21 JUN 1979 1523-EDT From: GSB at MIT-MC (Glenn S. Burke) To: (BUG LISP) at MIT-MC (GETCHARN 'FOO 0) => 30792. Bletch; either return 0 or barf.  Date: 20 Jun 1979 1737-PDT From: Guy Steele Subject: CASE To: bug-lisp at MIT-MC It really would be nice to have CASE as well as CASEQ.  SUN@MIT-ML 06/20/79 17:55:44 Re: my previous problem with 1804 imaging everything. To: (BUG LISP) at MIT-ML Remember last time: I complained that in Tops-10 1804 my output didn't seem to be padded. Well that was true since lisp was using IONeEEOU's instead of OUTCHR's to output everything. The problem is at TYOF6 where for some reason I don't know, lisp either uses the IONEOU or OUTCHR depending on the tts.ty bit of the ttsar. (as I said who knows why). Well it always uses the IONEOU instead of the OUTCHR. I patched the TLNN to be a TLNE so it always uses the OUTCHR. When you open a TTY in image mode it doesn't even use this code. Till you figure out what is happening in this code, my TLNE patch works fine.  gjs@MIT-AI 06/20/79 12:59:30 To: (BUG LISP) at MIT-AI CC: DICK at MIT-AI Actually, thinking about that sprinter bug, I think that the current grindef package is rather kludgerous and a much better one could be adopted. I suggest that you look into the one prepared by DICK@AI.  Date: 19 Jun 1979 1843-PDT From: Guy Steele Subject: proposed FORMAT hack To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-AI CC: GLS at SU-AI, RPG at SU-AI, GJS at MIT-AI Let there be some new escape, say U. It gobbles two arguments; one is a floating-point number (or is coerced to be one), and the other is a symbol or string which is the "units" of the number, which should be a metric word such as "meter" or "liter". The operator scales the number to be "reasonable", then prints the number, an appropriate metric prefix, the unit, and "s" if that is appropriate. With the colon modifier, abbreviated prefices are used. Example: (format t ";~:U requires ~U" 4300.0 '|m| 0.0543 "liter") might print ";4.3 km requires 54.3 milliliters" Maybe it's all pretty silly, but maybe from this someone can invent a more useful theory.  Date: 19 June 1979 06:20-EDT From: Kent M. Pitman Subject: Sprinter lossage To: GJS at MIT-MC cc: JONL at MIT-MC, BUG-LISP at MIT-MC gjs@MIT-AI 06/18/79 01:28:51 To: (BUG LISP) at MIT-AI (SPRINTER '(RUN-SCHEME '((LAMBDA (X . Y) ...) ...))) => (RUN-SCHEME '((LAMBDA (X #74514) ...) ...)) sprinter loses on dotted pair! ^_ Actually, not all dotted pairs, just under certain special cases where it was forgetting to look for non-null termination of list. btw, you realize of course the only reason you didn't get ((LAMBDA (X #74514 EXPR (LAMBDA (X) ...)) ...) ...) is probably that Y didn't have a property list! In any case, I think I found the bug. Boy is the Grindef package an ugly file. Proves you need more than just a grinder to win with lisp! In any case, the fix is on my dir right now. I have another bug I am trying to track down and when I get that fixed I will release it to the world. -kmp  Date: 19 Jun 1979 0112-PDT From: Guy Steele Subject: Screw with DEFVST (which otherwise works fine) To: bug-lisp at MIT-MC CC: GLS at SU-AI (DEFVST GRUNT FOO BAR BAZ) (DEFMACRO CLOBBER (FROB) (COND ((EQ (CAR FROB) 'CAR) `(RPLACA ,(CADR FROB) (CLOBBERIFIER ,FROB))) ((EQ (CAR FROB) 'CDR) `(RPLACD ,(CADR FROB) (CLOBBERIFIER ,FROB))) (T `(SETF ,FROB (CLOBBERIFIER ,FROB))))) (CLOBBER (GRUNT-BAR MY-FAVORITE-GRUNT)) This fails to work because the two occurrences of FROB (i.e. of (GRUNT-BAR MY-FAVORITE-GRUNT)) in the generated SETF form will be EQ. The second occurrence is evaluated first, and macro-expanded in the process. As a result, the SETF (i.e. SETVST) sees a form as its first argument whose car is MACROEXPANDED rather than GRUNT-BAR, so it gets very unhappy. I am fixing this by writing instead ... (T `(SETF ,(APPEND FROB '()) (CLOBBERIFIER ,FROB))))) but this seems to be a crock. Is there any hope of a reasonable general solution to this problem?  Date: 19 Jun 1979 0017-PDT From: Mark Crispin Subject: [RAND.FAUGHT: maclisp complr] To: Bug-LISP at MIT-MC --------------- Date: 19 Jun 1979 0016-PDT From: RAND.FAUGHT Subject: maclisp complr To: admin.mrc Cc: rand.faught, rand.klahr Mark, I was hoping the new complr would compile my file, but alas... I have a file int.lisp which runs ok when interpreted, but will not compile and apparently breaks the compiler. Are there some special things I have to do to the file or something? Feel free to try it yourself. Let me know if you can get farther than I can. Bill Faught ------- --------------- -------  Date: 18 Jun 1979 2231-PDT From: Guy Steele Subject: FORMAT loses To: BUG-LISP at MIT-MC CC: GLS at SU-AI, RPG at SU-AI (FORMAT MSGFILES '|~R ~:R ~@R ~:@R| 2 2 2 2) ;(G0002 42) LOSING OUTPUT FILE SPECS This happens at both SAIL and MIT, so I'd say there is something drastically wrong with FORMAT. It doesn't lose for ~S, however.  Date: 18 JUN 1979 2016-EDT From: JONL at MIT-MC (Jon L White) Subject: MC:COMLAP;FORMAT * To: BAK at MIT-MC CC: GLS at MIT-MC, (BUG LISP) at MIT-MC The FORMAT on COMLAP now has the few bugs correct that BAK has reported, namely ~% and ~[ things. It also has incorporated the "incompatible" change regarding STANDARD-OUTPUT. If there aren't too many objections, it will be moved to LISP and thus become the autoloadable one in, say, two weeks.  Date: 18 JUN 1979 1933-EDT From: JONL at MIT-MC (Jon L White) Subject: "T" and "(T)" as newio file specs To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, GLS at MIT-MC I agree that the documentation of maclisp, and out expectations for (PRINC 'FOO '(T)), don't agree. My tendency is to think that lisp should be "fixed" so that "T" and "(T)" as file-specs act the same. There is some attempt to make "T" differ from the value of TYO by the paying-of-attention to ^W. Whos has preferences on this? I definitely prefer that FORMAT be made compatible with LISPM, so that "(FORMAT NIL ...)" coughs up a string (symbol in maclisp) and "(FORMAT T ...)" acts like "(PRINC NIL)"  GSB@MIT-ML 06/18/79 19:18:57 Re: Your reply to rwk's reply re format change To: gls at MIT-MC CC: (BUG lisp) at MIT-MC, rwk at MIT-MC "T" as a filespec is NOT the same as "(T)" as a filespec. The value of ^W is not heeded when "T" is given to (say) PRINC, but it is when "(T)" is. (Lisp news of january 13, 1978 says that it should be, so either the documentation or lisp should be fixed.)  Date: 18 JUN 1979 1237-EDT From: JONL at MIT-MC (Jon L White) To: RIVEST at MIT-MC CC: (BUG LISP) at MIT-MC SXHASH on lists At one time, SXHASH had a definition such that the hash of a cons node was not determinable from the hash's of the car and cdr of that node. So we changed SAHASH, in order to make it possible for the function to be written easily in LISP. Admittedly, we should have chosen to make it commutative in the car direction rather than the cdr direction. But changeing things like that is not so easy - the primary use of SXHASH is for list structure in FASL files, and all those file have been comiled useing the existing algorithm, incorporatig in the file the various sxhash numbers. It wont break the code to change the algorithm, but likely many many many copies of a given constant expressions would be generated, whereas now there is just one copy of a given s-expression for all files loaded.  gjs@MIT-AI 06/18/79 01:28:51 To: (BUG LISP) at MIT-AI (RUN-SCHEME (QUOTE ((LAMBDA (X . Y) (CONS Y (BLOCK (ASET (QUOTE Y) (QUOTE E)) (CONS Y X)))) (QUOTE A) (QUOTE B) (QUOTE C)))) (RUN-SCHEME '((LAMBDA (X #74514) (CONS Y (BLOCK (ASET 'Y 'E) (CONS Y X)))) 'A 'B 'C)) sprinter loses on dotted pair!  Date: 17 JUN 1979 0400-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC It would be nice if the ~n| option of FORMAT would do a (CURSORPOS 'C) rather than a (TYO 12) to its stream argument. Another gripe: (TYO 12) prints ^L or plus/minus depending upon the type of terminal you have, but (TYO 7) actually feeps the bell rather than printing pi or ^G. This is inconsistent. There should exist CURSORPOS options or special functions (e.g. tv-beep) for performing special operations on the terminal, and (TYO n) would print either a SAIL character or (string-append "^" (string (+ n 100))) for n < 33.  Date: 16 June 1979 19:58-EDT From: "Guy L. Steele, Jr." Subject: Proposed incompatible change to MacLISP FORMAT function To: RWK at MIT-MC cc: BUG-LISP at MIT-MC Date: 16 JUN 1979 0323-EDT From: RWK at MIT-MC (Robert W. Kerns) Date: 06/15/79 19:44:18 From: GLS at MIT-AI To: *CMU, *DM, *MC, *ML, *AI Re: Proposed incompatible change to MacLISP FORMAT function Currently NIL means "output to the standard output files" (under the control of TYO, OUTFILES, ^W, and ^R variables), and T means "output to the file in the TYO variable". ... to get what NIL now means, one can use T. To get what T now means, one can use a list of T, i.e. (T). Any objections? -- GLS What's wrong with using TYO to mean "output to the file in the TYO variable"? (For that matter, why not call TYO something LISPM compatible like CONSOLE-OUTPUT? It's probably too late, but calling the variable TYO was a mistake, I think.) I have never used T to mean TYO, I always use TYO directly, so this won't break any of my code on that score, although maybe the NIL might. However, I think this change is important enough to change to make it worth fixing the various code which will be broken. (JONL: No cracks about fixing DRB's modes package, please!) I forgot to mention that T means "use the value in TYO, UNDER THE CONTROL OF THE ^W SWITCH". Hence (FORMAT '(T) ...) and (FORMAT TYO ...) would mean slightly different things.  Date: 16 JUN 1979 1444-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (sprinter '(macroexpanded frobs sprinter lousily)) LOUSILY  Date: 16 JUN 1979 1441-EDT From: RWK,KMP at MIT-MC Sent-by: KMP at MIT-MC Subject: HUH? To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC :L Alloc? N * MACROEXPANDED ==> NIL `(FOO ,T) ==>(FOO T) MACROEXPANDED ==>MACROEXPANDED (SET * NIL) ==> NIL MACROEXPANDED ==>MACROEXPANDED ;So it's gonna be persistant, eh? We got a little suspicious about here. (EQ MACROEXPANDED 'MACROEXPANDED) ==> NIL ; So why does NIL always get a space in front of it in this msg? MACROEXPANDED ==>MACROEXPANDED ^Z :MAIL BUG-LISP $>From: RWK,KMP ... etc.  Date: 16 JUN 1979 1344-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Why is it that... (HUNKSIZE (CDR '`(A ., B .))) => 3 ?? Seems it ends up as `(A . B . #51 .) I bet this is to do with the way hunks are being read nowadays, rather than a bug in the backquote stuff. It smells very much of the old bug of '(a .) => (a . #51) ... In any case, if this could be fixed I'd muchly appreciate it. -kmp  Date: 16 JUN 1979 1321-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC The backquote macro is not up on type-in-able hunks. ie, `(a . b . c .) expands into (a . c) Presumably this is because backquote was written when hunks could be typed in. If someone has some free time it might be nice to fix this bug. Thanx. -kmp  Date: 16 JUN 1979 0323-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Proposed incompatible change to MacLISP FORMAT function To: (BUG LISP) at MIT-MC Date: 06/15/79 19:44:18 From: GLS at MIT-AI To: *CMU, *DM, *MC, *ML, *AI Re: Proposed incompatible change to MacLISP FORMAT function Currently NIL means "output to the standard output files" (under the control of TYO, OUTFILES, ^W, and ^R variables), and T means "output to the file in the TYO variable". ... to get what NIL now means, one can use T. To get what T now means, one can use a list of T, i.e. (T). Any objections? -- GLS What's wrong with using TYO to mean "output to the file in the TYO variable"? (For that matter, why not call TYO something LISPM compatible like CONSOLE-OUTPUT? It's probably too late, but calling the variable TYO was a mistake, I think.) I have never used T to mean TYO, I always use TYO directly, so this won't break any of my code on that score, although maybe the NIL might. However, I think this change is important enough to change to make it worth fixing the various code which will be broken. (JONL: No cracks about fixing DRB's modes package, please!)  Date: 16 JUN 1979 0256-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (OPEN '((DSK KMP) FOO >) 'IN) #FILE-IN-|FOO 1|-70774 Why doesn't this print as #FILE-IN-|DSK:KMP;FOO 1|-70774 ... I would find the full namestring infinitely more useful. Thanx. -kmp  Date: 15 Jun 1979 1505-PDT From: Guy Steele Subject: Changes to FORMAT To: jonl at MIT-MC CC: bug-lisp at MIT-MC Sounds good to me. I'm sure no one at SAIL uses it yet -- I had to import it. Why not put up a msg on ITS and find out? I doubt anyone would be screwed seriously.  KEN@MIT-AI 06/15/79 01:40:59 To: (BUG LISP) at MIT-AI Why does (quotient .25) return .25 while (//$ .25) returns 4.0?  Date: 14 JUN 1979 1805-EDT From: JONL at MIT-MC (Jon L White) Subject: FORMAT To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC I've added a line or two to FORMAT source code so that the FASL will indeed be independent of SAIL/ITS distinction for tilde; also, I put in that suggestion you made last April about letting NIL as first argument to FORMAT mean return string, and T mean "STANDARD-OUTPUT", so that if one wants to specify the "T" rather than "TYO", he would have to type "'(T)". If you like this, and if it seems to work, howabout sending out a Questionaire to the ITS/SAIL maclisp community to see if it is acceptable, and then we can move the FASL code from COMLAP to LISP. I hesitate to do it myself since I have no usages of format except for relativety trivial ones, and don't have any feel for how serious the change is.  Date: 14 JUN 1979 1254-EDT From: JONL at MIT-MC (Jon L White) Subject: maclisp FORMAT To: gls at SU-AI CC: (BUG LISP) at MIT-MC 1) the problem you mentioned with format doing (STATUS ITS) has been moot for some time, since the standard maclisp has DEFUN& as an autoloadable macro. Nevertheless, I edited the source to flush all referencees to DEFUN& (since "(DEFUN FOO (X Y &REST Z) ...)" will automatically convert itself into DEFUN& and autoload if necessary. 2) I too don't see any solution to the tilde problem except recompilatin at SAIL. 3) there have been a few suggesions accumulation re FORMAT for both the LISPM and MACLISP, and I wonder who wants to do them? I especially liked your suggestion "(b)" of June 7 re right-, center-, and left-justification for fields.  Date: 13 JUN 1979 2351-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC Although (ARGS 'NOT) yields (NIL . 1), (NOT T T T) returns nil, (NOT NIL NIL NIL) returns T, and (NOT) returns NIL. All three cases should give an error.  Date: 13 Jun 1979 2124-EDT From: DAVE.TOURETZKY at CMU-10A Subject: ^c's in output when linmode = T To: bug-lisp at MIT-AI cc: SCOTT.FAHLMAN When sending output to a dribble file with (status linmode) = T, MacLisp is inserting ^c's between user typein and MacLisp output. This is true both at CMU (using DRIB.MCL[c380sf50]) and at MIT-MC (using LIBLSP;DRIBBL FASL). The problem does not occur when linmode is set to NIL. Even stranger: typing T produces, in the dribble file, T^cT, while typing T produces TT^c, and T produces TT^c. Weird!!!  Date: 13 Jun 1979 1716-PDT From: Guy Steele To: bug-lisp at MIT-MC FORMAT I suggest that the relevant form in FORMAT be changed as follows: (EVAL-WHEN (EVAL COMPILE) (OR (GET 'DEFUN& 'MACRO) (LOAD (OR (GET 'DEFUN& 'AUTOLOAD) `((DSK ,(COND ((STATUS FEATURE ITS) 'LISP) ((STATUS FEATURE DEC20) 'MACLISP) ((STATUS FEATURE SAIL) '(MAC LSP)) (T (STATUS UDIR))) ) DEFUN& FASL)))))  Date: 13 Jun 1979 1357-PDT From: Guy Steele Subject: FORMAT To: BUG-LISP at MIT-MC The FORMAT file has two problems: [a] It makes the calls (STATUS ITS) and (STATUS DEC20), which clearly have the keyword FEATURE missing. [b] For SAIL, the tilde character is ascii 32 octal, not 176 octal. The trick of saying (GETCHARN '|~| 1) doesn't work if you try to transport the FASL file, though it should win if I recompile the source here.  Date: 12 Jun 1979 1404-PDT From: Guy Steele To: henry at MIT-AI CC: GLS at SU-AI, bug-lisp at MIT-AI, bug-lispm at MIT-AI 11-Jun-79 1907 HENRY at MIT-AI (Henry Lieberman) CASEGO Date: 11 JUN 1979 2209-EDT From: HENRY at MIT-AI (Henry Lieberman) Subject: CASEGO To: GLS at SU-AI What you really have in the examples you give to show the use of CASEGO is a loop. I think it should be coded as such, either by the use of DO or auxiliary functions rather than your proposed CASEGO. (DEFUN CASEGO-EXAMPLE (THE-FROB) (CASEQ THE-FROB ((BAR) ...) ((FOO)) (T (... "I'll assume BAR") (CASEGO-EXAMPLE 'BAR)))) I think your proposal is like coding a loop using GO, which is generally acknowledged to be less winning. This is true, although what you have written is not semantically equivalent (though functionally equivalent) in that it re-performs the dispatch needlessly. This corresponds to the situation with the famous Boehm-Jacopini "theorem", which shows that any program can be made "structured" provided that a number of boolean variables and redundant tests are introduced. Also, without LABEL or LABELS or some such I can't write the above in MacLISP "in place". A better way around the problem using functions would be just to do (CASEQ THE-FROB ((BAR) (BAR-CASE)) ((FOO) ...) ... (T (... "assume BAR") (BAR-CASE))) ... (DEFUN BAR-CASE ...) Again, in MacLISP I can't really write this "in place" and take advantage of local variables. I just used the name GO by analogy with the behavior in a PROG. Actually, I might phrase my request entirely without reference to GO (because some people dislike GO), and say that I want a construct CASERETRY such that (CASEQ FROB ((FOO) FOO1) ((BAR) BAR1 (CASERETRY HUNOZ)) ((BAZ QUUX) BAZQUUX1) (T BARF (CASERETRY 'BAR)) expands into (LABELS ((FOO-CASE (LAMBDA () FOO1)) (BAR-CASE (LAMBDA () BAR1 (DISPATCH HUNOZ))) (BAZQUUX-CASE (LAMBDA () BAZQUUX1)) (DEFAULT-CASE (LAMBDA () BARF (BAR-CASE))) (DISPATCH (LAMBDA (X) (SELECTQ X ((FOO) (FOO-CASE)) ((BAR) (BAR-CASE)) ((BAZ QUUX) (BAZQUUX-CASE)) (T (DEFAULT-CASE)))))) (DISPATCH FROB)) where SELECTQ represents the more primitive simple-dispatch operation. Now this uses no GOs, and therefore must be generally acknowledged to be more winning, right?  Date: 12 JUN 1979 1430-EDT From: JONL at MIT-MC (Jon L White) Subject: TOPS-20 maclisp memory errors, and (STATUS UDIR) To: mrc at SU-AI, dekleer at PARC-MAXC2 CC: (BUG LISP) at MIT-MC I've just started assembling MC:LISP;RELD20 835 (version 1835) which will try to do an ordinarry error out to top level (being caught by *RSET if that is on) for memory errors. I agree that that would be preferable to merely a bomb out to the exec with no hint of where the offending instruction was. Also, as indicated in earlier note, there is an attempt to make the DIRST get the right information into the (STATUS UDIR) slot.  Date: 12 JUN 1979 0311-EDT From: JONL at MIT-MC (Jon L White) Subject: TOPS10/CMU bug in maclisp To: fahlman at CMU-10A, touretzky at CMU-10A CC: (BUG LISP) at MIT-MC 1) that problem with the PC being of by one, at interrupte level, on KA10s seems only to be when there is a pure page trap - a regular "non-existent memory error leaves the PC at the offender. 2) some renamef bugs fixed today 3) Apparetly NAMESTRING never worked on CMA, and this has caused me many bugs - there is a minor fix or too the catches this problem too.  Date: 12 JUN 1979 0121-EDT From: JONL at MIT-MC (Jon L White) Subject: BUG RE-INSTALLED To: RWK at MIT-MC, HENRY at MIT-MC CC: (BUG LISP) at MIT-MC, MACSYM at MIT-MC The bug whereby (CXR 0 (MAKHUNK '(A))) is inconsistent with other hunk usage has been reinstalled for the benefit of RWK, who cant find these buggy instances in DRB's code. Also for HENRY if he depends on it. This bug applies only in the case when MAKHUNK = (); sometime after about 6 months to a year, all code should assume that the value of MAKHUNK is irrelevant and the that operations of hunks are as they are now with MAKHUNK non-null.  Date: 12 JUN 1979 0030-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: I PROTEST!!!!! To: (BUG LISP) at MIT-MC, MACSYM at MIT-MC CC: HENRY at MIT-MC As I have warned repeatedly, the new lisp is incompatible with the old with MAKHUNK=NIL !!! PLEASE, PLEASE, PLEASE FIX IT! There is no point whatsoever to having the MAKHUNK switch unless it is truely going to be compatible! Until this is put back, I do not feel this LISP is suitable for MACSYMA, since there is then no way to run SOLVE code interpreted in such a LISP!  HENRY@MIT-AI 06/12/79 00:24:43 Re: latest changes to hunking To: (BUG LISP) at MIT-AI CC: HENRY at MIT-AI In the previous Lisp, (MAKHUNK '(AN-ELEMENT)) produced (AN-ELEMENT). In the latest Lisp, it gives (NIL . ELEMENT) when MAKHUNK is NIL.  Date: 11 JUN 1979 2024-EDT From: RWK at MIT-MC (Robert W. Kerns) To: KMP at MIT-MC, (BUG DDT) at MIT-MC CC: (BUG LISP) at MIT-MC Date: 10 JUN 1979 1101-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG DDT) cc: (BUG LISP) Typing :OQ at DDT gives the message: 6 @(;^: KMP; ;RH  P 0"H  U - LINK TO NON-EXISTENT FILE It strikes me that this is a non-optimal diagnostic. SYS;TS OQ is linked to SYS2;TS ONEWIO (which doesn't exist). Due to use of a "0" instead of a "o" in a name. Fixed in the source, will install.  Date: 11 Jun 1979 1713-PDT From: Guy Steele Subject: DEFVST To: BUG-LISP at MIT-MC CC: GLS at SU-AI DEFVST really ought to arrange to return the name of the structure defined, and not the name of whatever was the last defined selector. This is merely for aesthetic purposes; but I find it confusing when UREAD'ing in a file of DEFVST's not to see the structure names themselves.  Date: 11 JUN 1979 1855-EDT From: JONL at MIT-ML (Jon L White) Subject: RENAMEF bugs To: KMP at MIT-ML, fahlman at CMU-10A, ken at MIT-AI, moon at MIT-AI CC: (BUG LISP) at MIT-ML Mergeing of new non-ITS code for RENAMEF buggified the ITS version, but this has been corrected as follows: 1) (RENAMEF '|EXISTING FILE| '|NON-EXISTING FILE|) where the first arg is not an open file array, but a namelist or namestring was randomly merging with some code assuming that first arg was a file array; patched on ITS dumped versions, and being corrected in the source for TOPS-10 versions. 2) (RENAMEF '|NON-EXISTING FILE| '|ANY NAME|) as well as (RENAMEF closed-file-array '|ANY NAME|) was merging into a code-sequence common with the non-ITS versions at a point just before the "release-interrupt-lockout" and ocasionally causing a bomb-out to DDT; an ITS-only problem, now patched. 3) RENAMEF was incorrectly clobbering the TRUENAME of the file array it was being applied to; patched on ITS dumped versions, and being corrected in the source for TOPS-10 versions.  JONL@MIT-ML 06/11/79 18:19:30 Re: READER clobbering NIL, and NAMSTRING bugs To: RG at MIT-ML, KMP at MIT-ML CC: (BUG LISP) at MIT-ML, JPG at MIT-ML, HIC at MIT-ML The problem whereby a semi-colon comment as the first thing in a list clobbers NIL is patched. [e.g. "( ;HI^MBAR)" but not "(HI;FOO^MBAR)"]. Also the problem of NAMESTRING turning into SHORTNAMESTRING depending on the state of the processor flags (!) has been patched.  RG@MIT-AI (Sent by RG0@MIT-AI) 06/11/79 04:36:42 To: (BUG LISP) at MIT-AI LATEST LISP (1831) CLOBBERS NIL READING IN LISPM;.LISP. (INIT). (1785) DOESNT DO THIS.  Date: 10 Jun 1979 2243-PDT From: Guy Steele Subject: CASEQ and SELECTQ To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI CC: GLS at SU-AI, RPG at SU-AI I have long wished for a couple of extra features in CASEQ, and having them now would sure make coding a lot easier for me. I propose that CASEQ and SELECTQ mean slightly different things. SELECTQ would remain as it is now, and CASEQ would mostly remain the same, except for two added features: [1] If there is no default (i.e., T or OTHERWISE) clause in a SELECTQ, the default value () is produced. I suggest that a CASEQ instead produce some sort of correctable error as the "default default". This correctable error for (CASEQ ... ) ideally would be something like (FERROR ':UNSEEN-CASE-KEY ;or maybe UNSEEN-GO-TAG? "The CASEQ key ~S produced by does not occur in the CASEQ" ) If the error is corrected, the CASEQ should be retried with the returned value. This is a construct I am constantly reconstructing by hand. It wouldn't be too hard to write a macro for CASEQ in terms of SELECTQ to do this. [2] I wish there were a construct (CASEGO ), which would take an evaluated argument and effectively jump to the top of the containing CASEQ and perform the selection with the specified item. (I suppose there would have to be a CASEQ-NAMED as well to handle a CASEGO to an outer CASEQ. In that case (sorry), CASEGO should take an optional unevaluated second argument, as for GO.) In the situation where the first argument to CASEGO is a constant, then the code can be optimized to go directly to the relevant clause. I find that I am using CASEQ a lot, and either the processing for one key involves doing a diddle and then doing code identical to that for another key; or I want to do my own error handling and write (CASEQ ((FOO) ...) ((BAR) ...) ((BAZ) ...) ... (T (WARN "you blew it, bunky; I'll assume BAR for now") (CASEGO 'BAR))) instead I have to resort to the awkward (CASEQ ((FOO) ...) ((BAZ) ...) ... (T (OR (EQ 'BAR) (WARN "you blew it, bunky; I'll assume BAR for now")) ...)) which is asymmetrical in the keys, requires me to put the code for BAR last, and requires me to write twice.  Date: 11 JUN 1979 0139-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: previous message To: (BUG LISP) at MIT-MC Note that the file renaming does succeed. it dies after the rename.  Date: 11 JUN 1979 0138-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Where BAZ 1 does not exist and BAR 1 does ... (RENAMEF '|KMP;BAR 1| '|KMP;BAZ 1|) causes the following error message to be generated... ERROR: RFNAME: - BAD CHANNEL NUMBER RENAM1+5>>.CALL RFNAME (RFNAME)  Date: 11 JUN 1979 0128-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (RENAMEF '|KMP;NOSUCH FILE| '|KMP;ANY FILE|) loses with the same .val 0 error as the one where file exists. In an ERRSET it gives the appropriate file not found error. -kmp  Date: 11 JUN 1979 0122-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Assume file "KMP;FOO BAR" exists. (SETQ A '((KMP) FOO BAZ) 'OUT)) (CLOSE A) (RENAMEF A '(FOO BAR)) .VAL 0; EROR5A+22>>PUSHJ P,UINT This should NOT die to DDT. At worst a FILE EXISTS error should be generated. Btw, doing this same thing in an ERRSET will generate the FILE EXISTS error instead of .VAL 0'ing.  Date: 11 JUN 1979 0019-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC :LISP (NAMESTRING '((DSK TNP) FOO /1)) |DSK:TNP;FOO 1| (NAMESTRING '((DSK TNP) FOO /1)) |DSK:TNP;FOO 1| (NAMESTRING '((DSK TNP) FOO 1)) |FOO 1| (NAMESTRING '((DSK TNP) FOO /1)) |FOO 1| Maybe a fixnum arg in one of the parts of a namelist is a hidden switch i missed? this is screwing some of my programs that want to open numbered files. it used to work.  Date: 10 JUN 1979 2051-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC How come.... '( ; Hi BAR) says ;(NIL BAR) NIL CLOBBERED in the new lisp...?? -kmp  Date: 10 JUN 1979 1118-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC (SETQ A (OPEN '((DSK KMP) FOO BAR) 'OUT)) #FILE-OUT-|DSK:KMP;FOO BAR|-70776 (RENAMEF A '((DSK KMP) FOO BAZ)) #FILE-OUT-|* *|-70776 (NAMESTRING *) |DSK:KMP;FOO BAZ| What's with the funny printname for the file object? (Btw, there are other bugs with RENAMEF or some other operation that I call near there. I am trying to pin them now). -kmp  Date: 10 JUN 1979 1101-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG DDT) at MIT-MC CC: (BUG LISP) at MIT-MC Typing :OQ at DDT gives the message: 6 @(;^: KMP; ;RH  P 0"H  U - LINK TO NON-EXISTENT FILE It strikes me that this is a non-optimal diagnostic. SYS;TS OQ is linked to SYS2;TS ONEWIO (which doesn't exist).  RIVEST@MIT-ML 06/09/79 18:01:03 To: (BUG LISP) at MIT-ML I just found out that SXHASH(!'(A B))=SXHASH(!'(B A)) for atoms A and B. This is a real nuisance and contrary to the random behavior one would expect from shuch a function.... This cost me quite a while to discover. It should be fixed. Ron Rivest  moon,ken@MIT-AI (Sent by KEN@MIT-AI) 06/09/79 06:40:09 Re: Bug in Lisp 1831 with RENAMEF To: (BUG LISP) at MIT-AI When called with 2 arguments that are namelists (not file-objects), after doing the RENAME system call it jumps to RENAM1 with A containing one of the arguments, rather than a file-object which is expected. It then blows out randomly depending on what it manages to put into TT.  Date: 9 JUN 1979 0423-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: Like backquote, like DEFUN& To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC How about fixing DEFUN& to produce "displaced" code which the grinder can know about and re-display in the non-ugly form? I.e. expand into something like: (LAMBDA +INTERNAL-LEXPR-LAMBDA-VAR (COMMENT ORIGINAL FORM = ) )  Date: 9 JUN 1979 0404-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: SAVEFILE To: KMP at MIT-MC CC: EJS at MIT-MC, ELLEN at MIT-MC, (BUG LISP) at MIT-MC, JPG at MIT-MC Date: 4 June 1979 01:12-EDT From: Kent M. Pitman To: JPG, RWK cc: EJS, ELLEN By the way, I tried opening SAVEFILE in MANLEY's macsyma. Got the file munged up so closed it and tried re-opening it. That lost. The file wouldn't open (did manage to get it CNAMEF'd ok, tho' - by picking names for the file that I was sure were on the obarray - creating even one new symbol gave a major restart!) ... Fortunately, I had come equipped with a TELNET wallpaper file open and just ended up printing all values on the tty and editting the wallpaper file later.... I would be interested to know why when I did (OPEN SAVEFILE 'OUT) the second time, it returned T but [1] Didn't open the file, [2] Didn't err out at all, and [3] said losing output file specs when I tried printing into the file... Bob? -kmp Because it is initially opened in FIXNUM mode. This would seem to violate the LISP documentation in .INFO.;LISP NEWS which claims that opening tends to reset the file array, and that the default mode is ASCII, not FIXNUM. Jeff, why is it originally opened as FIXNUM?  Date: 9 JUN 1979 0304-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: (HUNK 'A) when MAKHUNK = NIL To: JONL at MIT-MC, GSB at MIT-MC CC: KMP at MIT-MC, RWK at MIT-MC, (BUG LISP) at MIT-MC Date: 7 June 1979 09:34-EDT From: Jon L White To: GSB cc: KMP, RWK, BUG-LISP Re: (HUNK 'A) when MAKHUNK = NIL I vote for (NIL . A) rather than (A) or even (#777777 . A). the reasoning is semi-backwards compatibility, that no #777777 frobs appear in list structure (that is supposed to be an "illegal" pointer!), and also consistency in what (CXR 0 (HUNK )) returns. As per our conversation last Tuesday, this is not at all compatible. What is used to return is what is compatble: (A) ... Just because it has consistancy doesn't NOT make it compatible! If the MAKHUNK has no other purpose than compatibilty, DON'T BLOW IT BY NOT PROVIDING TRUE COMPATIBLITY INSTEAD OF CONSISTANCY. If you're not going to provide consistancy, don't even bother with the switch!  DDM@MIT-AI 06/09/79 00:53:07 To: (BUG LISP) at MIT-AI The new version of lisp (i.e. 1831) has a bug. When I load my mumble system a spurious (i.e. does not occur in olisp) clobbering of nil occurs To get this error, start a lisp using my init file... when it asks if you want to load any systems type "m" and type "n" to any subsequent questions it may ask. After about 1:40 min. of cpu time, the error will occur -- somewhere inside the form "(def-strategy trailing-attributive-relative ...)" in my file MUMBLE;MGRAM2 > happy hunting.