RWK@MIT-AI 08/15/78 18:37:25 To: (BUG LISP) at MIT-AI According to LISP ARCHIV, (DIRECTORY T) should return all the properties DIRECTORY knows about. However, it returns none at all. Also, it really OUGHT to be able to take a single-file-object. Right now, if you give it something atomic, it does something fairly random, mapping over the universe. Presumably it is CDRing down some non-list?  Date: 15 AUG 1978 0410-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: CFFK at MIT-MC CC: (BUG LISP) at MIT-MC, JLK at MIT-MC, MRG at MIT-MC, JPG at MIT-MC CFFK@MIT-MC 08/15/78 00:29:27 Re: Macsyma doing random things Doing Loadfile(Rombrg,Fasl,DSK,CFFK)$ BATCH(DPOLE)$ WRITEFILE()$ B[4]; B[4]; B[4]; ==> 2* ;Failed to converge, 0.583803125 B calls ROMBERG on a simple function PHI. The ROMBERG in the version on DSK,CFFK has been modified to write out into the writefile the positions where PHI is evaluated and the values returned. The bug occurs because PHI randomly returns wrong values. I've split the writefile up into 3 piece corresponding to the 3 evaluations of B[4]. So you can see the different values by doing :SRCCOM CFFK;ERR 1 and :SRCCOM CFFK;ERR 2. The probability of an error seems to be about 0.1%. ---------------------------------------------------------------------------- One value it seems to consistently, but rarely, die on is PHI(10.3125,.04); which is supposed to return 0.0, but every now and then (say once every 1000 times) returns 7521.08276 . The (or a) reason for this is that PHI calls SECH(10.3125) which is supposed to return 6.64305973E-5, but when PHI fails, SECH here returns 1.0 instead. (Which happens to be the value returned by TANH(10.3125), but I don't know if that means anything.) Anyway, someone else can try to narrow this down further. The LISP functions SECH and TANH are defined in MRG;TRIG > .  Date: 15 AUG 1978 0111-EDT From: RJF at MIT-MC (Richard J. Fateman) To: (BUG GRIND) at MIT-MC THIS BUG SEEMS NOT TO HAVE GOTTEN FIXED: COMMENTS ARE SOMETIMES SPLIT OVER LINES BY THE GRINDER, AND SEMICOLONS NOT PUT IN THERE!! SEE FOR EXAMPE, RJF;EDITCO 4. I REMEMBER THIS BUG FROM 4 YEARS AGO!  Date: 12 AUG 1978 0805-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: RWK1 at MIT-MC To: (BUG LISP) at MIT-MC :L Alloc? N (SETQ FOO (OPEN 'TTY: '(SINGLE FIXNUM))) (IN FOO)^G MPV; TTYIC1+2>>HLR R,(TT) R/ SETZ C 116003/ ??  Date: 12 AUG 1978 0039-EDT From: HIC at MIT-MC (Howard I. Cannon) To: CFFK at MIT-MC, (BUG LISP) at MIT-MC Date: 11 AUG 1978 2259-EDT From: CFFK at MIT-MC (Charles F. F. Karney) To: (BUG LISP) at MIT-MC WITH :TCTYP TEL (CURSORPOS 'C) ==> T (SHOULD BE NIL) ---- Well....not really....ITS actually prints a blank line for (CURSORPOS 'C), and when my suggested change is implemented, (if it hasn't been already), doing the ^PC will clear the line counter (this will winn with glass TTY's). Therefore, I think that CURSORPOS 'C should work on all TTY's. --howard  Date: 11 AUG 1978 2259-EDT From: CFFK at MIT-MC (Charles F. F. Karney) To: (BUG LISP) at MIT-MC WITH :TCTYP TEL (CURSORPOS 'C) ==> T (SHOULD BE NIL)  Date: 10 AUG 1978 2347-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: HIC at MIT-MC, JONL at MIT-MC CC: (BUG LISP) at MIT-MC CC: (BUG LISP) at MIT-MC Is there any reason why we couldn't allow the form (DO ((A 1 (1+ A)) B) (IF-DONE B) ...) in MACLISP to be equivalent to (DO ((A 1 (1+ A)) (B)) (IF-DONE B) ...) ?? I believe I extended the LET macro to permit singleton symbols. ------- I don't see any reason why that can't be done...I'll put it in my queue for the next LISP. The ability to omit the parentheses drastically reduces the chances of catching incorrect parenthesis levels (such as omitting the parentheses surrounding the entire set of variable specs, a somewhat common blunder), while not significantly increasing the functionality of the construct. Other than that there seems to be no problem.  Date: 10 AUG 1978 1633-EDT From: MOON at MIT-MC (David A. Moon) Subject: CASEQ To: JONL at MIT-MC, (BUG LISP) at MIT-MC, NIL at MIT-MC Are you saying that you aren't allowed to have null (what we used to call NIL) be one of the cases you can select for with CASEQ? Come on now, JONL, that is obviously unreasonable. As far as I can see, the migration from OTHERWISE to T to () is picking more and more commonly-used objects as the distinguished thing which you have to put in parentheses if you want it, with less and less mnemonic names, which makes CASEQ less and less useful. This is not the direction you should be going!  Date: 10 AUG 1978 1544-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC Date: 10 AUG 1978 1213-EDT From: JONL at MIT-MC (Jon L White) To: HIC at MIT-MC CC: (BUG LISP) at MIT-MC Is there any reason why we couldn't allow the form (DO ((A 1 (1+ A)) B) (IF-DONE B) ...) in MACLISP to be equivalent to (DO ((A 1 (1+ A)) (B)) (IF-DONE B) ...) ?? I believe I extended the LET macro to permit singleton symbols. ------- I don't see any reason why that can't be done...I'll put it in my queue for the next LISP.  Date: 10 AUG 1978 1213-EDT From: JONL at MIT-MC (Jon L White) To: HIC at MIT-MC CC: (BUG LISP) at MIT-MC Is there any reason why we couldn't allow the form (DO ((A 1 (1+ A)) B) (IF-DONE B) ...) in MACLISP to be equivalent to (DO ((A 1 (1+ A)) (B)) (IF-DONE B) ...) ?? I believe I extended the LET macro to permit singleton symbols.  Date: 10 AUG 1978 0622-EDT From: JONL at MIT-MC (Jon L White) Subject: CASEQ To: (BUG LISP) at MIT-MC, NIL at MIT-MC RLB has suggested a good resolution of the ambiguity inherent in the "force-acceptance" clause for CASEQ: instead of the symbol T, let it be the nullist. True in maclisp, the nullist is also a symbol, but in NIL the nullist will be outside the range of any of the forms on which to dispatch (SYMBOLs, FIXNUMs, FLONUMs, CHAROBs). Who will be adversely affected by this change? Can we put out a feeler in the AI/LCS community for the change to be effective in MACLISP also? As for MACLISP, if the "forcer" does conflict by being a symbol, it can be made unambiguous in the "search" context by listifying it.  Date: 10 AUG 1978 0536-EDT From: JONL at MIT-MC (Jon L White) Subject: ALAN's modification of DISPLACE To: HIC at MIT-MC CC: (BUG LISP) at MIT-MC Personally, I'd rather see DISPLACE generate an error if either argument is atomic (not just the first), but I wont push it. There is nothing to do in the compiler since it is close-compiled.  Date: 10 AUG 1978 0530-EDT From: JONL at MIT-MC (Jon L White) Subject: -101_) To: (BUG LISP) at MIT-MC CC: BEE at MIT-MC I believe adding the line ANDI TT,777 or something equivalent just before the EXCH at RDFXEX+3 will solve this embarrassment.  BEE@MIT-AI 08/09/78 21:26:51 To: (BUG LISP) at MIT-AI -101_) causes MPV.  Date: 9 AUG 1978 2053-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: SAIL and segmentation To: (BUG LISP) at MIT-MC, GLS at SU-AI CC: GLS at MIT-MC, LES at MIT-MC, RPG at MIT-MC Well...hmm.... I think that it would certainly be possible to convert to a one segment system. BUT, who is going to do it?? Even if I place it on my queue at a high priority, I really can't see when it's gonna get done. Is there any hopes of SAIL having real user-hackable paging in the near future? I suspect a conversion to a paging SAIL system would be fairly trivial. I'm sure I'll be able to do the single-segment conversion, but I wouldn't say any sooner than by November....Perhaps you, GLS, could hack it...or else I guess it'll have to wait... sorry, -howard  Date: 9 Aug 1978 1625-PDT From: GLS at SU-AI (Guy Steele) Subject: SAIL and segmentation To: bug-lisp at MIT-MC CC: GLS, LES, RPG Several people here at SAIl are having tremendous difficulty using MacLISP because of the small address space in the low segment. They have small amounts of compiled code, and so sharing is of little consequence; also, SAIL now has lots of physical memory. What matters is the limitation on list structure. Horror upon horrors, how difficult would it be at thisstage of the game to re-install the ability to have a one-segment LISP for TOPS-10/SAIL? The system segments would have to be back down below BPS and initial list structure, with the attendant changes to guys like SYSP who hack BEGFUN and ENDFUN, etc.; also the core allocator would have to be munged a little, and the high-segment FASLOAD stuff excised or at least disabled. They are really hurting here -- what do you think?  Date: 9 AUG 1978 1451-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, ALAN at MIT-AI FOR NEXT RELEASE OF LISP: Definition of DISPLACE in the interpreter is now the following: ALAN@MIT-AI 07/29/78 06:10:14 To: HIC at MIT-MC (DEFUN DISPLACE (X Y) (AND (ATOM X) (ERROR '|-- not a list. (DISPLACE)| X)) (COND ((ATOM Y) (RPLACA X 'PROGN) (RPLACD X (NCONS Y))) (T (RPLACA X (CAR Y)) (RPLACD X (CDR Y))))) JONL: Can it become this in the compiler?  Date: 9 AUG 1978 1404-EDT From: HIC at MIT-MC (Howard I. Cannon) To: GLS at MIT-MC, (BUG LISP) at MIT-MC CC: NEAL at MIT-MC, RWK at MIT-MC Perhaps it should MERGEF with DSK:COMMON; instead? ----- This has been done for the next LISP.  Date: 9 AUG 1978 0819-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC Is it intended that ARGS is bound to the TYI file array when you do a ^B break?  Date: 9 AUG 1978 0647-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, KAT at MIT-MC If you set (RANDOM 2), then the first 120000.+ or so entries do not duplicate. Its hard to check it out much further empirically.  Date: 9 AUG 1978 0445-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, KAT at MIT-MC The standard random-number-generator in MACLISP will duplicate itself after 72797. calls, with the number -25450782157.  Date: 9 AUG 1978 0204-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, RWG at MIT-MC CC: JPG at MIT-MC KAT@MIT-MC 08/08/78 21:01:22 If (RANDOM 2) is used to generate random numbers 1 or 2, how many will be generated before the series repeats itself, or does it ever repeat? Can JONL or RWG or whoever answer the above? Thanks.  Date: 8 AUG 1978 1954-EDT From: NEAL at MIT-MC (Neal Feinberg) To: (BUG LISP) at MIT-MC CC: GLS at MIT-MC The previous message was sent to me with nasty intensions. It should not have been so, as RWK sent the bug logged in as me. Hmm...  Date: 8 AUG 1978 1952-EDT From: NEAL at MIT-MC (Neal Feinberg) To: (BUG LISP) at MIT-MC CC: GLS at MIT-MC  Date: 8 AUG 1978 1922-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KLE at MIT-AI CC: (BUG LISP) at MIT-MC Using @define causes an ;@define undefined function error You're supposed to stick it in a DECLARE.  KLE@MIT-AI 08/08/78 16:54:48 To: (BUG LISP) at MIT-AI Using @define causes an ;@define undefined function error  KLE@MIT-AI 08/07/78 16:06:01 To: (BUG LISP) at MIT-AI how do I put a statement in my .lisp. (init) to allocate a known number of words?  Date: 6 AUG 1978 2028-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: (BUG LISP) at MIT-MC CC: NEAL at MIT-MC So what use is the autoload handler MERGEF'ing with COM:mumbl mumble ??? DSK: LIBLSP; gubble gubble ? Then at least when you do (DEFPROP LET |LIBLSP; MACRO FASL| AUTOLOAD) it would do the right thing. I would claim it should be trying to find system stuff there anyway.... Perhaps it should MERGEF with DSK:COMMON; instead?  Date: 6 AUG 1978 2026-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: RWK at MIT-MC, (BUG LISP) at MIT-MC CC: NIL at MIT-MC The subtlety you are missing (and which I admit may never have been properly documented) is that IN is a type FIXNUM function. This implies that it can return ONLY fixnum values. On EOF, it follows the same convention as TYI, namely that EOF returns a -1 value instead of the standard NIL value (this has been documented, I am sure). Even if you explicitly specify an EOF value of NIL, both IN and TYI will "coerce" this NIL to be a -1. Unfortunately, unlike TYI, IN is capable of returning any fixnum whatsoever as a valid result, so -1 cannot serve as a unique flag. Therefore, because of the constarints on its valid domain and its total domain, there can be no special distinguished EOF value. It follows that the THROW trick is in fact the only way to win. Now perhaps in NIL the use of multiple-return values could provide an alternative technique, as could the use of continuations (though the latter would probably be somewhat slower).  HIC@MIT-MC 08/06/78 17:47:16 To: RAF at MIT-AI, (BUG LISP) at MIT-AI RAF@MIT-AI 08/01/78 23:48:40 To: (BUG LISP) at MIT-AI I got the message ;fxpdl out of phase (system error) after typing (setq ^r t). ------- Can you give more info?? Was it a fresh LISP?  Date: 6 AUG 1978 1654-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: NEAL at MIT-MC Subject: SPRINTER on odd-length SETQ's To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC It would be nice if SPRINTER were to do something reasonable on odd-length SETQ's rather than die in SET-PREDICT. Often debuggers want to SPRINTER forms, and if you die due to a parens mis-match, it is rather disconcerting for SPRINTER to die too.  Date: 5 AUG 1978 2205-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC All right, what's going on here. In MACLISP, the function IN only takes one argument, so there is no way to specify an EOF value. Also, the IO-LOSSAGE interrupt appears to be broken. While it is totally undocumented, (LISP ARCHIVE mutters about it not being new in NEWIO, but the old LISP manual is totally silent on the issue), one would expect that (SETQ IO-LOSSAGE '(LAMBDA (X) '(NIL))) would cause (IN FOO) to return NIL on EOF. It does not. It returns -1 times the last value returned. It would seem that the only way to handle EOF on a fixnum file is (SETQ IO-LOSSAGE '(LAMBDA (X) (COND ((EQ CAR X) 'IN) (THROW (CADR X) 'IN-EOF))) or the sledgehammer of an ERRSET. I'm not sure what the best way to handle EOF is, but I hope NIL can do better than this!! I also hope that MACLISP will be retrofitted with whatever fix is decided on for NIL. How could this deficiency have lasted this long, is there something obvious I'm missing?  Date: 5 AUG 1978 1933-EDT From: NEAL at MIT-MC (Neal Feinberg) To: (BUG LISP) at MIT-MC So what use is the autoload handler MERGEF'ing with COM:mumbl mumble ??? DSK: LIBLSP; gubble gubble ? Then at least when you do (DEFPROP LET |LIBLSP; MACRO FASL| AUTOLOAD) it would do the right thing. I would claim it should be trying to find system stuff there anyway....  Date: 3 AUG 1978 0415-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC NOTE WELL: *THROW must be an FSUBR, for many routines want to identify things by whether or not they need special-form handling. In a sense, people are right to complain that PROGN should be an FSUBR.  RAF@MIT-AI 08/01/78 23:48:40 To: (BUG LISP) at MIT-AI I got the message ;fxpdl out of phase (system error) after typing (setq ^r t).  From: Greenberg at MIT-Multics Date: 07/30/78 2254-edt Subject: Proposed KMP/RWK cond To: kmp at MIT-MC cc: (bug lisp) at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHddhbkQHlN A better understanding of my objection to this construct is that it seems totaaly limited to "predicates" with meaningful results (i.e., other than t/nil) like memq/assq. I never considered either of these quys one of the more elegant featues of lisp; it is clearly a kludge for not having multiple return values. Since most predicates are designed to yield the exciting results t or nil, i dont think making a special internal lambda variable to holddthat answer has much generality.  Date: 30 JUL 1978 2221-EDT From: KMP,RWK at MIT-MC Sent-by: KMP at MIT-MC To: NIL at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC To: BSG at MIT-MC UNCC:Greenberg@MIT-MULTICS Suppose the syntax for cond were as follows: (COND [] ( ...) ...) And inside a named-cond, the label would be initially bound to NIL and each time a were EVAL'd, the label would get the value. (Naturally the compiler could optimize this out where possible). This allows the flexibility provided by GLS's extension, with a cleaner, more Lisp-like syntax. RWK is implementing a 'CCOND' macro in MacLISP that will describe the exact specifications of this. Comments?  From: Greenberg at MIT-Multics Date: 07/30/78 1045-edt Subject: This list To: (bug lisp) at MIT-MC, (bug lispm) at MIT-MC, To: bee at MIT-MC, kle at MIT-MC, moon at MIT-MC, To: nil at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHdcQlZBQlg I don't know where or in whose head this mailing list is kept, but both me and my eq brother , BSG at MC and Greenberg at Mit-Multics seem to be on it. Since we share no secrets and have identical opiions, I would appreciate if one, but not boht of us, were removed from it, because our mailbox clutters twice as fast. -The Greenberg brothers, Bernie and Bernie.  From: Greenberg at MIT-Multics Date: 07/29/78 1317-edt Subject: IF To: (BUG LISP at MIT-MC, (BUG LISPM) at MIT-MC, To: BEE at MIT-MC, BSG at MIT-MC, MOON at MIT-MC, To: NIL at MIT-MC Message-ID: [MIT-Multics]1.1.BBBJHdZGnjlDmD Maclisp has effectively consigned progn to fairly obscure cases and people who are trying to get away using AND without having to resor to COND. The extra level of parentheses in COND makes me, at least, shun it in cases where I know that I'm only going to have one consequent, and use AND in these cases (I only use "my" IF macro in emacs extension code). I don't think that saying "Ok, If is good for only 1 consequent or anti-consequent, if you need more use COND" makes anything better than it is now, or for that matter, makes a whole lot of sense. Similarly, if IF needs progns to solve THAT issue, it is inutile too. I myself am queasy about "keywords", but the more I think about the explanation of Fexprs as "special forms" the more sense it makes. Progn is a syntactic kludge, like "end;" in PL/I. Devising a "simplification" of the silly lisp COND that forces people to use PROGN is no improvement. I have faced several times thedifficulty of explaining Lisp: progn is a rough one; given NOT using AND the way it was not intended, Maclisp makes it so that it should almost never be neceessary. I, for one, favor keeping it that way. And if the IF frob is not good enough for "all" cases given that, let's not have it.  Date: 30 JUL 1978 0216-EDT From: KLE at MIT-AI (Edward Jay Kleban) Subject: AND and OR To: Greenberg at MIT-MULTICS, BEE at MIT-MC, (BUG LISP) at MIT-MC To: (BUG LISPM) at MIT-MC, BSG at MIT-MC, MOON at MIT-MC, NIL at MIT-MC Chalk up one vote for the simple form of if as proposed by ALAN which I find most convenient and I whole heartedly agree with bee's reasoning of making programs readable, of which I think IF does an extremely good job.  Date: 29 JUL 1978 1925-EDT From: ALAN at MIT-AI (Alan Bawden) Subject: IF and PROGN To: Greenberg at MIT-MULTICS, (BUG LISP) at MIT-MC To: (BUG LISPM) at MIT-MC, NIL at MIT-MC Just a clarification of how I use IF. Code such as: (IF (TEST A) (PROGN (FOO) (BAR)) (BAZ)) Is never prefered to using COND as far as I am concerned. IF is only useful in those simple cases where it improves readability. I would prefer to read a two clause COND than to have to search for a keyword.  Date: 29 JUL 1978 1925-EDT From: BEE at MIT-MC (Bruce E. Edwards) Subject: AND and OR To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC To: Greenberg at MIT-MULTICS Further clarification of what I dont like about AND and OR. If you have the form (AND ) and you are pricipally using form1 ... formn for side effect, not value it seems to me that this construct is poor.  Date: 29 JUL 1978 1629-EDT From: BEE at MIT-MC (Bruce E. Edwards) Subject: AND and OR To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, BEE at MIT-MC To: BSG at MIT-MC, MOON at MIT-MC, NIL at MIT-MC To: Greenberg at MIT-MULTICS Time for another favorite flame. I can't stand the idea of using AND and OR for control primitives. I can't think of a more obscure feature, than using AND and OR for control primitives. It completely obscures the purpose of the code. If you are using it for a boolean value, then you should use AND or OR, but if you are using as a selection mechanism, then you should use some other command. I dont know why people persist in using AND and OR. It would seem to be about as mnemonic to have a function (COMPLETELY-CONFUSE-THE-READER-AND
) that preforms the same operation. A function called IF can only make code more readable. Maybe someone should come up with a syntax that performs the control tasks of AND and OR and rename it.  Date: 29 JUL 1978 1303-EDT From: BEE at MIT-MC (Bruce E. Edwards) Subject: IF macro To: MOON at MIT-MC, NIL at MIT-MC, (BUG LISP) at MIT-MC To: (BUG LISPM) at MIT-MC CC: BSG at MIT-MC I do not in general like the syntax of the if with the keyword ELSE. I find IF marginally useful, because usually I have more than one thing to do in one of the clauses, however, when I only have one thing to do, it is clear (at least to me) that IF is the right thing. I therefore think that it should be included, and also flamed about, just like backquote.  ALAN@MIT-AI 07/29/78 06:46:16 Re: IF macro To: MOON at MIT-MC, NIL at MIT-MC, (BUG LISP) at MIT-MC To: (BUG LISPM) at MIT-MC CC: BSG at MIT-MC OK, lets flame about the IF macro: I prefer (and use as well!) the following: (IF ) If I wish to do more than one thing in one case or the other then I will write a COND, that is what COND does best. But for the simple case I prefer the simple form. This is the way the currently installed IF macro works on the Lisp Machine.  Date: 29 JUL 1978 0636-EDT From: MOON at MIT-MC (David A. Moon) Subject: IF macro To: NIL at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC CC: BSG at MIT-MC I don't use this myself, but I thought that if we can have 100 pieces of mail about lsubr cons and backquote this may be worthy of discussion. There are extant at least a half-dozen different incompatible IF macros. Since so many people seem to like it, it would seem to be a good idea to standardize on one that would be compatible across all programs. The one I like the best is Bernie Greenberg's. It looks like: (IF .... ELSE ....) The keyword ELSE and the else-forms may be omitted. The implied PROGN seems so useful as to counteract the slight cruftiness of having an extra embedded keyword. For myself, I would probably continue to use COND.  Date: 28 JUL 1978 1720-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: LIST* and ` To: KLE at MIT-MC, NIL at MIT-MC, (BUG LISPM) at MIT-MC To: (BUG LISP) at MIT-MC KLE@MIT-AI 07/28/78 13:59:12 Re: LIST* and ` To: JONL at MIT-MC, NIL at MIT-MC, (BUG LISPM) at MIT-MC To: (BUG LISP) at MIT-MC I am not sure about the LISPM approach but I believe it is the case that at least in the version of backquote which I use in Maclisp, that coma [sic] and @ are defined in such a way that they only have thier magic effect when found within backquoted expressions. That is '(2 , 4 , 3) still returns (2 4 3) and '(3 ,@ 4) still returns (3 @4) since neither of these expressions backquoted. I think that if this is also done I would not be unhappy with the LISPM approach of having ` defined in the standard readtable. Making all three chars reader macros however, with , and @ returning error messages if not used within a backquote I would consider an ursurping of too many valuable characters. Although I agree in spirit that probably this could be engineered (the multiple definitions of "," and "@"), it hardly seems appropriate to the mood of cleanliness and readability we need to establish. In order to maintain maximal readability of code written with these macros, it would be nice to have "," only useable in that context (so that there is no need to search outward to see your context in order to interpret this). Certainly making those two chars be an error out of context is a complete loss, and I hope no one is pushing that. If so, I wish they would pick a less used symbol than "," ... Proposal: I might suggest that the global syntax for "," should be an abbreviation for (EVAL (READ)) and that the global syntax for "@" should be as splicing macro. So that saying ,A at Lisp would be like saying (EVAL A) and saying @(A B C) would be like entering A, B, and C in sequence (almost like A,B,C in lisp does now. This could be useful if typing several things that you didn't want to get snarfed until you were sure you had the whole list ready and typed the ")" on it... A,B,C suffers from the loss that it delays action from the Lisp because it doesn't wake up the lisp, but when you try to rub out over the , you find you have awakened it and all is lost. It would have to be a context error for a non-list to follow an @ by this scheme unless some way of defining it i consistently were come up with. My point is that if this scheme or something similar were adopted, it would replace some of the consistency that might otherwise be lost in current plans for back-quote. If something along this lines seems to unreasonable to accept, then I would sooner have @ and , just have normal chracter syntax outside of ` context than have optional secondary meanings for them as there are now. Comments?  KLE@MIT-AI 07/28/78 13:59:12 Re: LIST* and ` To: JONL at MIT-MC, NIL at MIT-MC, (BUG LISPM) at MIT-MC To: (BUG LISP) at MIT-MC I am not sure about the LISPM approach but I believe it is the case that at least in the version of backquote which I use in Maclisp, that coma and @ are defined in such a way that they only have thier magic effect when found within backquoted expressions. That is '(2 , 4 , 3) still returns (2 4 3) and '(3 ,@ 4) still returns (3 @4) since neither of these expressions backquoted. I think that if this is also done I would not be unhappy with the LISPM approach of having ` defined in the standard readtable. Making all three chars reader macros however, with , and @ returning error messages if not used within a backquote I would consider an ursurping of too many valuable characters.  Date: 28 JUL 1978 0801-EDT From: JLK at MIT-MC (John L. Kulp) Subject: LSUBR CONS and back-quote To: NIL at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC I agree with RWK, and I bet MRG would agree also (judging by his code), that code doing data structure construction using lists makes heavy use of backquote outside of the context of macros. I would also guess it is used a lot less this way on the LISPM due to DEFSTRUCTs.  Date: 28 JUL 1978 0416-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: ` and , as initial macro characters To: JONL at MIT-MC, NIL at MIT-MC, (BUG LISPM) at MIT-MC To: (BUG LISP) at MIT-MC It is interesting to note that the initial macro characters in LISP are thus ` ' , ; -- that is, all the "bits and pieces" characters. Thhe LISP Machine additionally uses : as a package marker. (I am ignoring |, which is implemented as a macro, because it spoils the general theory.)  Date: 28 JUL 1978 0102-EDT From: JONL at MIT-MC (Jon L White) Subject: LIST* and ` To: NIL at MIT-MC, (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC Looks like consensus on nomenclature is LIST* and I am happy with that. As for backquote, there has arisen many non-macro-defunition usages which we are all aware of now (from the flood of mail), so the only question is how much to standardize. Who would be unhappy with the LISPM approach, which uses backquote and comma as macro chars, with comma looking ahead one char to see if atsign signals a splice. Probably in NIL and eventually in MACLISP we would be better off setting both chars as initial macros-chars.  Date: 27 JUL 1978 2153-EDT From: RLB at MIT-MC (Richard L. Bryan) To: (BUG LISP) at MIT-MC FASLAPSETUP/| and friends should generate SYM properties for all symbols which live in LSYMS - the globalsym patch is considerably faster than the search thru LAPFIV etc. Also, FASLAP then wouldn't complain about ... undefined converted to DDT symbols ... when the loading Lisp won't have to consult DDT. Perhaps this means removing the distinction between globalsyms and extrasyms.  Date: 27 JUL 1978 2142-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: lsubr CONS and backquote To: JONL at MIT-MC, (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC To: NIL at MIT-MC As far as backquote is concerned: If I had one handy, I'd ue it, but I have not yet gone through the trouble of snarfing or writing one. I'd like to see it easily accessible in the system. As far as LSUBR CONS goes: I would like to make LSUBR CONS, as it is in LISP 1703, be LIST* and make CONS back to be what it was! I'll do this pronto and then we'll have somthing consistant to release. Code is going to have to be changed anyway in order to take advantage, and one might as well change it to LIST* than LSUBR CONS.  Date: 27 Jul 1978 1559-PDT From: GLS at SU-AI (Guy Steele) Subject: EREAD in NEWIO To: BUG-LISP at MIT-MC CC: GLS The SAIL EREAD hack should, among other things, use the SHOWIT UUO on the channel involved (see the SAIL UUO manual) so that the who-line will show the progress on that channel. This is a very useful feature here.  Date: 27 JUL 1978 1603-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: LSUBR CONS and back-quote To: NIL at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC I think the best reason for wanting LSUBR CONS is so that the code that you write with backquote is somewhat readable...however I would disagree that "`" is generally useful only for macros. I often find I want to generate list structure that shares many of the characteristics of EXPR code, but is not code at all. For example, it is the most convenient way of consing up MACSYMA expressions, say to represent the sum of expressions A and B, one would write `((MPLUS SIMP) ,A ,B). I think that this kind of application is very common, and would like to see backquote in the standard readtable.  Date: 27 JUL 1978 1226-EDT From: JONL at MIT-MC (Jon L White) Subject: lsubr CONS and backquote To: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, NIL at MIT-MC I have many places in the COMPLR where I would like to use an LSUBR version of CONS, namely to do something like (CONS (CAR X) (CONS (CADR X) (CONS 'MUMBLE (CONS Z (CDDDR L))))) [hence I would like to see LISP 1703 be made the system LISP asap] Now this is not exactly a problem for backquote since I would like to write the code directly and the code using 2-arg cons is bletcherous (which is what the read-macro-expansion of backquote produces anyway!). Note the similarity of the pre-expanded input using backquote and that using lsubr cons `(,(CAR X) ,(CADR X) MUMBLE ,Z . ,(CDDDR L)) (CONS (CAR X) (CADR X) 'MUMBLE Z (CDDDR L)) In short, backquote seems best used when most of the stuff is quoted, whereas lsubr cons seems best used when most of the stuff is evaluated. Yes I *am* aware of the extended generality of the ,@ feature of backquote, but that is no reason to demand usage of a sledgehammer when a toothpick will do, for it takes a lot more to control the heavy-tool when it is not the instrument especially suited for the job. For example, the above example requires typing 5 unquoter characters (","s) for backquote, but only one quoter character ("'") for forwardquote. It is a little annoying that backquote produces such bletcherous consy code - it could use lsubr cons also when all things are installed - and somewhat annoying that there is no "forwardquote", i.e. something that evals everything except where there is a quote. I know the LISPM has *LIST - any hopes of generalizing CONS to many args both in LISPM and NIL and standardizing on that definition? For now (may change mind) I tend to agree with DLW that backquote is essentially only used in MACRO defunitions, and we could ignore any systemic use; thus it needn't go in the system of MACLISP or NIL to be usable, but merely in the prefaces (or helper-files) for MACRO subpackages etc.  Date: 26 JUL 1978 1831-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, HENRY at MIT-AI HENRY@MIT-AI 07/24/78 23:42:41 To: (BUG LISP) at MIT-AI Unfortunately, I still need to load symbols for my graphics stuff. They need symbols having to do with setting up the TV array: GETCOR, SACONS, 1DIMF, CFIX1 ----- All but 1DIMF were in the table. I have added 1DIMF to the table and it will be in the next release of LISP. --howard  Date: 26 JUL 1978 1550-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: DDT Symbols etc. To: (BUG LISP) at MIT-MC Given the presence in much code of something like (or (getddtsym 'T) (valret '|^W:sl sys:ts l/ :vp |)) I propose instead (yet) another status/sstatus option pair: (status ddtsyms) returns T if the superior claims to be a DDT and has symbols loaded; (sstatus ddtsyms) returns falsity if the superior is not a DDT, else returns T if the DDT has symbols loaded, else requests the DDT to load symbols **from the correct SYS:PURQIO nnn** or wherever and returns T if that was successful. Alternatively, this could set some flag for GETDDTSYM which would cause it to load symbols if necessary. The advantage of all this is that symbols could be guaranteed to be loaded from the 'right place' even in the presence of hacking file load defaults, etc. Hopefully it could even work in the presence of multiple levels of pdumping, although this would require more careful thought than I am putting into it now.  GSB@MIT-ML 07/25/78 17:16:32 Re: evalhook, applyhook To: (BUG LISP) at MIT-ML Just for the record, i find evalhook to be rather useful, and not really a crock. Applyhook would be a really great extension, though i have no idea how easily it could be put in.  Date: 25 JUL 1978 1708-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC CC: GLS at SU-AI Of well, the last message won..just a fluke I guess...  Date: 25 JUL 1978 1707-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC CC: GLS at SU-AI This is a test. If this fails, I am going to remove (BUG-LISP SAIL) from the .MAIL.;NAMES > file. GLS, you should look into this and see what is going on here. The last BUG-LISP message I sent failed to SU-AI with a: No Hablo "2" wierd...  Date: 25 JUL 1978 1704-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JPG at MIT-MC, (BUG LISP) at MIT-MC CC: RWK at MIT-MC Date: 25 JUL 1978 0530-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC, JPG at MIT-MC In a fresh MACSYMA, type control-^ to quit into LISP. (CDR '%SIN) will show you a property of $INVERSE with value %ASIN. Type (FASLOAD SOLVE FASL DSK MACSYM). (CDR '%SIN) shows you that the property is now ADISPLINE, a function in SOLVE, rather than $INVERSE. Fasloading in other files instead of SOLVE FASL clobbers the property list of %SIN (and %COS, etc., wherever "$INVERSE" appears) in other similar ways. $INVERSE is a purified property. -------- The bug is that you had only pure structure pointing to the symbol ($INVERSE) and PURCOPY did not insure that the symbol was gcprotected. Therefore, the symbol was being treated as TWA. Now, if the symbol on the PUTPROP list is not pure itself, it is PURCOPY'ed when someone attempts to PUTPROP a property on it. This fix will not help the current macsyma. In order to fix the bug in the current macsyma, setq some random symbol to the list that PUTPROP is SETQ'ed to during loading. This will cause the symbols to be marked and therefore not GCTWA'ed away. --howard  Date: 25 JUL 1978 1432-EDT From: JONL at MIT-MC (Jon L White) To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC The compilation of MACRAK;RPART > involves using macrak's foolish macro package MACRAK;OPERS MACFAS which has an interpretive usage of LABEL. LABELs are losers, and don't work in the interpeter unless (SSTATUS PUNT ()) has been done. It would be a good idea to find the source for this loser macro package, and do it without LABEL.  Date: 25 JUL 1978 0530-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC, JPG at MIT-MC In a fresh MACSYMA, type control-^ to quit into LISP. (CDR '%SIN) will show you a property of $INVERSE with value %ASIN. Type (FASLOAD SOLVE FASL DSK MACSYM). (CDR '%SIN) shows you that the property is now ADISPLINE, a function in SOLVE, rather than $INVERSE. Fasloading in other files instead of SOLVE FASL clobbers the property list of %SIN (and %COS, etc., wherever "$INVERSE" appears) in other similar ways. $INVERSE is a purified property.  HENRY@MIT-AI 07/24/78 23:42:41 To: (BUG LISP) at MIT-AI Unfortunately, I still need to load symbols for my graphics stuff. They need symbols having to do with setting up the TV array: GETCOR, SACONS, 1DIMF, CFIX1  Date: 24 JUL 1978 2146-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KLE at MIT-AI CC: (BUG LISP) at MIT-MC, MOON at MIT-AI KLE@MIT-AI 07/24/78 18:33:42 To: MOON at MIT-AI, (BUG LISP) at MIT-AI Is it the case that three control-c's are always appended to the end of a file when reading files from lisp or is it just that Im doing something funny thats putting 3 control c's there??? As a result of historical development of ITS, files which are output in block mode are padded with ^C to a multiple of five characters. TECO still writes out its files in tis mode. LISP uses the more modern string mode, thus allowing you to see the ^C's. Until all programs use string mode (probably never), programs should by convention ignore ^C's if possible (LISP ordinarily does).  KLE@MIT-AI 07/24/78 18:33:42 To: MOON at MIT-AI, (BUG LISP) at MIT-AI Is it the case that three control-c's are always appended to the end of a file when reading files from lisp or is it just that Im doing something funny thats putting 3 control c's there???  Date: 24 JUL 1978 1146-EDT From: JONL at MIT-MC (Jon L White) Subject: FLATC To: henry at MIT-AI CC: (BUG LISP) at MIT-MC Yes, the current definition of FLACT is more like STRINGLENGTH - this permits very fast computation, but at the expense of special checking for weird characters. Strictly speaking, we'd have to have a system call, or some closer cooperation with the ITS ascii output routines, in order to be accurate there.  HENRY@MIT-AI 07/23/78 15:55:42 To: (BUG LISP) at MIT-AI If you have atoms with a Back Space [Control-H] in their print names, FLATC counts this as one character. This is correct on interpretation of flatc as meaning "How many characters in the print name?". A problem is that some programs, like pretty printers, use FLATC to answer the question, "How many print positions is this going to take on the screen?", so get messed up because back space is really like -1 print position. I guess this is also true of control characters on some terminals. Should programs just check for this specially, have another flavor of FLAT functions, or what?  Date: 22 JUL 1978 1817-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, DCH at MIT-ML DCH@MIT-ML 07/22/78 16:19:14 To: (BUG LISP) at MIT-ML EVALHOOK with 3 arguments (1: thing to eval, 2: a-list ptr, 3: what to bind EVALHOOK to) gets a NIL CLOBBERED error. For instance, in a fresh Lisp, (evalhook 2 nil nil) gets the error. A real a-list ptr as the second arg also gets the error. And it doesn't seem to matter what the third arg is. ------ Fixed and patched on all systems.  DCH@MIT-ML 07/22/78 16:19:14 To: (BUG LISP) at MIT-ML EVALHOOK with 3 arguments (1: thing to eval, 2: a-list ptr, 3: what to bind EVALHOOK to) gets a NIL CLOBBERED error. For instance, in a fresh Lisp, (evalhook 2 nil nil) gets the error. A real a-list ptr as the second arg also gets the error. And it doesn't seem to matter what the third arg is.  Date: 21 Jul 1978 1520-PDT From: WP at SU-AI (Wolfgang Polak) Subject: Interpreted SUBRCALL To: bug-lisp at MIT-MC The code at PTRCHK: should in the D10 version account for the possible existence of a high-segment BPS. -- GLS -------  Date: 21 JUL 1978 0125-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, HENRY at MIT-AI Well, I personnaly don't want to perpatuate the EVALHOOK thing, having been convinced that it really is a crock. If you really need it though, I suppose it could be arranged...  HENRY@MIT-AI 07/21/78 00:33:49 To: (BUG LISP) at MIT-AI How hard would it be to have an APPLYHOOK feature analogous to the EVALHOOK feature? When stepping, it is often desired to ignore the details of argument evaluation and get into stepping the definition of the function, so it would be helpful to have a hook onto APPLY.  MOON5@MIT-AI 07/20/78 01:46:09 To: (BUG LISP) at MIT-AI Once again I was screwed by a function declared to return fixnum that didn't, and therefore didn't get its first instruction executed, causing mysterious bugs that took hours to track down. When is Lisp going to detect this error? (It is trivial to detect).  Date: 19 JUL 1978 2051-EDT From: BEE at MIT-MC (Bruce E. Edwards) To: (BUG LISP) at MIT-MC When the garbage collector is called from sycon1, it says GC DUE TO ? when ^d is on.  Date: 19 JUL 1978 1525-EDT From: KMP at MIT-MC (Kent M. Pitman) To: RLB at MIT-MC, (BUG LISP) at MIT-MC Date: 19 JUL 1978 1505-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: Proposed GETSYNTAX function To: (BUG LISP) at MIT-MC, KMP at MIT-MC getsyntax SUBR 2 args... A fine idea. You may go ahead with it, HIC. It has my approval. --kmp  Date: 19 JUL 1978 1505-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: Proposed GETSYNTAX function To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC getsyntax SUBR 2 args (getsyntax c s) returns information about the synttax of the character c in the readtable. c can be a fixnum which is the Ascii code for a character, or it can be a character object. s is a symbol selecting which information is required. SYNTAX - the syntax bits are returned as a fixnum. SINGLE - if the syntax of c is that for single character objects, T is returned; otherwise, NIL. MACRO - if c is a macro character, the function is returned. SPLICING - if c is a splicing macro character, the function is returned. CHTRAN - returns a character object which is the chtran of c .  Date: 19 JUL 1978 0633-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: () as a lambda variable To: JONL at MIT-MC, (BUG LISP) at MIT-MC Date: 18 JUL 1978 2346-EDT From: JONL at MIT-MC (Jon L White) Subject: () as a lambda variable To: (BUG LISP) at MIT-MC Would it be possible for the next version of the interpreter to permit constructs such as "(LAMBDA (V1 V2 () V4) . . .)" to be applicable; thus one could explicitly show where he expects a lambda- variable to be unused, without the compiler complaining. This is in the current COMPLR, but of course is of little value until the interpreter will overlook () in the bound var list. -------- I guess I didn't send out a note, but this has already been implimented (try :XL). It does not do the **INTERNAL** frob, it actually ignores the (). --howard  Date: 18 JUL 1978 2349-EDT From: JONL at MIT-MC (Jon L White) Subject: () in bound var list To: (BUG LISP) at MIT-MC Perhaps one way to fake-out the interpreter is merely to have some internal symbol to act as a shunt. Thus the interpreter, when applying "(LAMBDA (V1 () V2 () V3) . . .)" would act as if "(LAMBDA (V1 **INTERNAL** V2 **INTERNAL** V3) . . .)" had been typed instead. There seems to be no problem with multiple occurences of the same varialbe, and if it is truly internal, then the only loss is that it takes up space on the SPECPDL when used.  Date: 18 JUL 1978 2346-EDT From: JONL at MIT-MC (Jon L White) Subject: () as a lambda variable To: (BUG LISP) at MIT-MC Would it be possible for the next version of the interpreter to permit constructs such as "(LAMBDA (V1 V2 () V4) . . .)" to be applicable; thus one could explicitly show where he expects a lambda- variable to be unused, without the compiler complaining. This is in the current COMPLR, but of course is of little value until the interpreter will overlook () in the bound var list.  Date: 18 JUL 1978 1928-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KLE at MIT-MC CC: (BUG LISP) at MIT-MC Date: 18 JUL 1978 0909-EDT From: KLE at MIT-MC (Edward Jay Kleban) To: (BUG LISP) at MIT-MC Foo! How come (* 15.0 3.4) evaluates to 51.0 and (* 3 3.4 5) evaluates to 51.0000005 ?? I know lisp is supposed to be a great language with neat huristics and everything, but not even fortran's that bad at floating point. You are a victim of floating-point round-off error. I actually tried it on the local FORTRAN. It printed both results as 50.9999995000.  Date: 18 JUL 1978 0909-EDT From: KLE at MIT-MC (Edward Jay Kleban) To: (BUG LISP) at MIT-MC Foo! How come (* 15.0 3.4) evaluates to 51.0 and (* 3 3.4 5) evaluates to 51.0000005 ?? I know lisp is supposed to be a great language with neat huristics and everything, but not even fortran's that bad at floating point.  Date: 18 JUL 1978 0753-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: GCPRO To: JONL at MIT-MC, (BUG LISP) at MIT-MC Date: 17 JUL 1978 2257-EDT From: JONL at MIT-MC (Jon L White) Subject: GCPRO To: (BUG LISP) at MIT-MC At GCPR1+13 (or thereabouts) the line MOVSI TT,SY.CCN should be turned into MOVSI TT,SY.CCN\SY.OTC ------- Done and patched.  Date: 17 Jul 1978 2336-PDT From: GLS at SU-AI (Guy Steele) Subject: SAIL BPS To: BUG-LISP at MIT-MC Here is a good idea: the SAIL default BPS size should be big enough to accommodate GRINDEF and TRACE. -------  Date: 17 JUL 1978 2309-EDT From: JONL at MIT-MC (Jon L White) Subject: MAKUNBOUND To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC At one time, GLS and I worked out the logic that has put us in the current bind (no pun!): the information as to whether or not a value-cell is needed by compiled code can only be kept in the symbol block of the symbol; thus if a value-cell is disconnected from its symbol, then it must be reclaimed, for there is no provision to sweep the value-cell space. Of course, if a symbol itself is being swept up due to nothing at all pointing to it, or due to it being a TWA (herein defined to be a symbol with no properties on its PLIST, one which is not BOUNDP, and is on at most the current obarray) then the value-cell pointed to that symbol may be explicitly reclaimed (again excluding SUNBOUND). The sad part about the latter reclamation scheme is that it prevents two symbols from sharing a value cell (for what if one is swept and the other is not?). At any rate, there would seem to be little loss if we removed the explicit-reclamation code from MAKUNBOUND, since most value-cells to be reclaimed could be ggrabbed by the explicit symbol-sweeper. The currently-rejected alternative is to have two bit-blocks for each value-cell segment, one which would be a standard mark-bit bit-block for the GC marker to use, and the other to be a sort of CCN-bit bit-block for FASLOAD and GCPROTECT to use. Currently LAP makes a distinction when it calls GCPROTECT by giving a second arg VALUE in one case, and T in all others; but GCPROTECT merges all non-NIL (and non-?) second args into the T case.  Date: 17 JUL 1978 2257-EDT From: JONL at MIT-MC (Jon L White) Subject: GCPRO To: (BUG LISP) at MIT-MC At GCPR1+13 (or thereabouts) the line MOVSI TT,SY.CCN should be turned into MOVSI TT,SY.CCN\SY.OTC  Date: 17 JUL 1978 2226-EDT From: JONL at MIT-MC (Jon L White) Subject: Checking in apply and bind for internal unbound frob To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC I guess that your motive in this is for some, albeit inadequate, compensation for the failure of the PDP10-compiled code to check for accessing unbound variables. I'm sort of against it since it doesn't do much more than a little compensation, and would be doubly confusing to users who would notice that it would be alright to listify such things, obtain them by car-cdring (and any other opencoded computation) but not use then in function calls. But I'm not dead set against it. 1) at .SET1, squeeze in the two lines below, just before the PUSH: CAIN A,QUNBOUND JRST this will catch any binding caused by SET, or by interpreted versions of SETQ PUSH POP . 2) at a number of places in the uuo handler, such as at ARGPDL and PDLARG, and at UUOS03+8 (or so) and UUOLB3+2, and at any place in the uuo handler where PDLNMK or PDLNKJ is called; This will catch most leakage thru compiled-code to compiled-code linkage. 3) at the interpreter's versions of the CARCDR function, ie at CR7+1, at EVSYM (which is already done), and probably at interpreter's accessing of hunks, arrays, etc. 4) at SPEC2+1 (which is SPECBIND) So 1, 2, and 4 will stop almost all "leaks" of QUNBOUND out of compiled code (and interpreted code cant generate this loser!), the single exception is when it is open-coded into some list structure (or hunk, or array). That exceptional case should be caught by 3.  Date: 17 JUL 1978 1112-EDT From: HIC at MIT-MC (Howard I. Cannon) To: RLB at MIT-MC, (BUG LISP) at MIT-MC Date: 11 JUL 1978 2122-EDT From: RLB at MIT-MC (Richard L. Bryan) To: (BUG LISP) at MIT-MC After reopening TYO in '(ECHO) and TYI in '(ECHO FIXNUM) (the latter to be able to tyi the full char set), rettyconsing TYI & TYO, resetting the tty prescan, (sometimes) moving all the interrupt functions (whew!), (TYI) returns the right number including the bucky bits, but (TYI TYI) barfs about TYI not being an Ascii file object. (IN TYI) barfs about TYI not being a binary input file. How the hell can this be? --------- TYI (et al.) now accept binary files if they are TTY's. IN/OUT now accept TTY binary files and do the "right" thing. This has been fixe din the source and patched in the running LISP on MC.  Date: 17 JUL 1978 1018-EDT From: HIC at MIT-MC (Howard I. Cannon) To: GLS at SU-AI, RPG at SU-AI CC: (BUG LISP) at MIT-MC I installed a new SYS:NLISP and COMPLR[NEW,LSP] on SAIL. The new NLISP has EOPEN function which will handle E files correctly. In the compiler, I have SETPLIST'ed OPEN to EOPEN's plist and that seems to win grossly. I wrote EOPEN so that it only hacks ASCII, DSK, IN files. Therefore, it should be substitutable for OPEN. I have substituted it internally for INCLUDE, expr LOAD, and UREAD and this seems to win. The new compiler reads E files with no barfaage. Please report any bugs. RPG: Also note that you have used NOARGS T in a decalre in EDIT.113 This function no longer exists. Have fun!! --howard  Date: 17 JUL 1978 0656-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, GSB at MIT-ML GSB@MIT-ML 07/17/78 05:16:43 To: (BUG LISP) at MIT-ML DOn't give me this shit that |MOD630 92 99| is a bad namestring. ------- This bug has been fixed in the source (for a while...)  GSB@MIT-ML 07/17/78 05:16:43 To: (BUG LISP) at MIT-ML DOn't give me this shit that |MOD630 92 99| is a bad namestring.  Date: 17 JUL 1978 0413-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC MOON@MIT-AI (Sent by MOON0@MIT-AI) 07/16/78 00:41:42 To: (BUG LISP) at MIT-AI Foo, foo, foo! In lisp 1633 (cursorpos 'x) does nothing because the test at CNPOK+27 (TLNE TT,%TOMVB+%TOOVR) is wrong. This is screwing me. ------- This has been fixed and patched on all machines.  HIC@MIT-MC 07/17/78 03:38:04 To: DCH at MIT-ML, (BUG LISP) at MIT-ML The system more processor uses the TTYCONS to determine where to read the "more character" from. If it doesn't find a TTYCONS, it ignores the more interrupt. Define your own more handler as such: (defun my-more (output-file) (nointerrupt nil) ;Make sure the guy can ^G (etc..) (princ '|##MORE##| output-file) ;Since GSB is such a pain, you might also want to flush rubout, and ; ignore control characters (and (= (tyipeek nil tyi) 40) (tyi tyi)) ;If space typed, flush it (cursorpos 'T output-file) (cursorpos 'L output-file)) ;Must clear line that printing will be on That should do it.  DCH@MIT-ML 07/16/78 21:20:29 To: (BUG LISP) at MIT-ML I am having trouble with +INTERNAL-TTY-ENDPAGEFN, which doesn't seem to do ##MORE## when it is supposed to. I'm using SCML to set up an echo area, and so I have two channels open: TOP-TTY and BOTTOM-TTY (= TYO). The problem is that ##MORE## seems to happen only on the channel that is TTYCONS'd with TYI. In order for rubout processing etc. to work properly in the echo area, I must do (SSTATUS TTYCONS TYI BOTTOM-TTY). But then if I output a lot of stuff to TOP-TTY, making it get to the bottom of the screen, no ##MORE## happens, and it wraps around. If I do (SSTATUS TTYCONS TYI TOP-TTY) then the ##MORE## happens correctly, but then ruboutting doesn't work. I know the ##MORE## interrupt is getting through from ITS, because if I run with Dick Water's #PRINT package, which has its own ENDPAGEFN, the ##more## happens on both channels, and doesn't depend on the TTYCONS. So, can you explain this behavior? I tried looking at the stuff in LISP ARCHIV, but it's hard to make head or tails of it.  MOON@MIT-AI (Sent by MOON0@MIT-AI) 07/16/78 00:41:42 To: (BUG LISP) at MIT-AI Foo, foo, foo! In lisp 1633 (cursorpos 'x) does nothing because the test at CNPOK+27 (TLNE TT,%TOMVB+%TOOVR) is wrong. This is screwing me.  Date: 15 JUL 1978 2203-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC From: KMP at MIT-MC (Kent M. Pitman) STATUS SYNTAX and STATUS MACRO have some of the shoddiest syntax I have ever seen. ... We know, we know... we can't change it without screwing up 1.0E9 programs. NIL will not have this screw. At least SETSYNTAX solves the more important setting side of the problem.  MOON@MIT-AI 07/15/78 05:17:31 To: (BUG LISP) at MIT-AI It would be handy if in *RSET T mode apply would check for passing UNBOUND as an argument, or maybe if the interpreter checked for binding a symbol to UNBOUND. That way such errors would be caught closer to the point of the error.  Date: 15 JUL 1978 0507-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC MAKUNBOUND flushes the value cell. This is dangerous (you may have a pointer to it on the stack), unnecessary (QUNBOUND can be used instead to make unbound), and goes against BIBOP LISP where all atoms are created with value cells. MACSYMA certainly wants QUNBOUND to be stuck in instead, and if LISP is to provide the user with a MAKUNBOUND function and only one, surely this should be it. If GLS and JONL do not object to this change, I believe HIC is willing to make it.  Date: 14 JUL 1978 2208-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC STATUS SYNTAX and STATUS MACRO have some of the shoddiest syntax I have ever seen. Any function that would be hurt by the change of (DEFUN SYN (X) (STATUS SYNTAX (GETCHARN X 1.))) to (DEFUN SYN (X) ((LAMBDA (Y) (STATUS SYNTAX Y)) (GETCHARN X 1.))) is really losing. The 1/2-FEXPR nature of the thing makes it incredibly tricky to write into a program, tho' it may be useful in debugging to not have to quote an arg, I would venture a guess that no one would mind its being EXPR in the char of its second arg. If there is not a very good reason why this function feels a need to evaluate only non-atomic args, I would be interested. Otherwise, I would just as soon see it remodelled to evaluate second arg always.  Date: 14 JUL 1978 1639-EDT From: JONL at MIT-MC (Jon L White) Subject: Clarification on OWN-SYMBOL To: (BUG LISP) at MIT-MC, bruc at MIT-ML Probably most users wont have to do OWN-SYMBOL declarations, since they will not be concerned with either of the two far-out cases that cause problems: 1) when a macro definition expects to use, in its body, the renamed versions of some system function, which was made into a macro by the user, 2) when the integrity of the compiler is at stake, such as would be the case if some simple function was defined as a macro and then the toplevel usage of the compiler would be non-standard; or when some simple system function is redefined as a SUBR (or LSUBR) and the compiler has not snapped the compiled-code links to the system version.  Date: 14 JUL 1978 1634-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC, bruc at MIT-ML Yes, the new COMPLR permits the user to redefine most system SUBRs and FSUBRs as macros, either by fasloading in a macros file in his init (or from inside a DECLARE), or by haveing the macro definitions lexically present. There is one minor lossage with redefining the system functions necessary for the operation of the compiler itself, so recently we have invented a new declaration OWN-SYMBOL which has the effect of removing from the COBARRAY the declared symbols, and installing thereon new symbols with the same pname; thus as a users file is read in he gets reference to a symbol that is not connected with the system one. E.g. (DECLARE (OWN-SYMBOL PUSH POP XCONS)) (DEFUN PUSH MACRO . . . ) (DEFUN POP MACRO . . . ) (DEFUN XCONS MACRO . . . )  BRUC@MIT-ML 07/14/78 10:24:30 To: (BUG LISP) at MIT-ML Does the latest version of QCOMPL eliminate the problem where the compiler would ignore user redefinitions of system defined macros? This problem came up in OWL where PUSH and POP were defined before they were defined in LISP. Bob Bruccoleri  Date: 14 JUL 1978 0027-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Fun with Setsyntax To: KMP at MIT-MC, (BUG LISP) at MIT-MC CC: RWK at MIT-MC The bug with your setsyntax frob was that you were setting the syntax of 13. to 32., which is 40 ooctal which is a meaningless syntax. WHat you want is: (SETSYNTAX 13. (STATUS SYNTAX 32.) ... )  Date: 13 JUL 1978 1104-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Fun with Setsyntax To: (BUG LISP) at MIT-MC CC: RWK at MIT-MC, KMP at MIT-MC If you do (SETSYNTAX 13. 32. 13.) and then do ( ) It will say ;BLAST, MISSING ")" This is a minimal case. You can experiment yourself. Another fun thing to do is (SETQ A '((FOO ))) You have to have the space on the 2nd line if I remember right so that you don't get the ;BLAST, MISSING ")" error, and it will give you back ((FOO )) as a result (no vertical bars!!) ... Bob looked up the printname of it and it is a list ( ( FOO^M . NIL ) . NIL) ...  Date: 13 JUL 1978 1006-EDT From: MOON at MIT-MC (David A. Moon) To: KMP at MIT-MC, (BUG LISP) at MIT-MC, NIL at MIT-MC Having a prompt dynamic-variable which the rubout handler looks at is, of course, a good idea. I don't see how this has anything to do with streams except in so far as the rubout handler might be associated with a particular stream if that was the way it worked. Since a process can only be inputting from one stream at a time a dynamically-bound variable is the right thing. The prompt certainly should not be an attribute of the stream; it is an attribute of the particular call to read or readline or readfrob or whatever.  Date: 13 JUL 1978 0321-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: MERGEF To: JONL at MIT-MC, (BUG LISP) at MIT-MC Date: 12 JUL 1978 1323-EDT From: JONL at MIT-MC (Jon L White) Subject: MERGEF To: (BUG LISP) at MIT-MC Does the MOONUAL claim that the following format of args to MERGEF is ok? (MERGEF '((* JONL) * BAR) '((DSK) . *)) ------- Yes, and in actuality it seems to work.  Date: 12 JUL 1978 1323-EDT From: JONL at MIT-MC (Jon L White) Subject: MERGEF To: (BUG LISP) at MIT-MC Does the MOONUAL claim that the following format of args to MERGEF is ok? (MERGEF '((* JONL) * BAR) '((DSK) . *))  GSB@MIT-ML 07/12/78 13:18:27 To: (BUG LISP) at MIT-ML It appears that with the compiler doing a (movei a 't) to open-code a call to err, the only problems are lisps. It seems to do most of the possible permutations of calls to ERR incorrectly, according to the moonual. eg, (errset (err 'foo nil)) ==> ((QUOTE FOO) NIL) which should yield FOO. (errset ((lambda (foo) (err foo t)) 'bar)) ==> BAR This presumably should yield either the toplevel value of foo or a ubv error. I'm not sure what the cases are which are 'supposed' to signal the errset user interrupt, but as it says in the moonual, it is 'signalled when an error is caught by an errset.'  Date: 12 JUL 1978 1129-EDT From: JONL at MIT-MC (Jon L White) To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, HIC at MIT-MC Well, you are right about ERR using ERUNDO also, but there is this weird behaviour that I hadn't noticed before: If (ERR NIL) breaks up an errset, then the ERRSET handler is not called at all, whereas if (ERR ) breaks up the ERRSET, then the handler is called. So I will take the cheap and dirty solution - cause the COMPLR to output the extra instruction "(MOVEI 1 'T)", but I'm still not sure that we have the semantics of all this worked out yet.  Date: 12 JUL 1978 1125-EDT From: JONL at MIT-MC (Jon L White) Subject: COMPLRs OWN-SYMBOL declaration To: DRB at MIT-MC, RWK at MIT-MC CC: (BUG LISP) at MIT-MC I think that the sequence (DECLARE (EVAL (READ))) (FASLOAD MACROS) will work if one line in the MACROS file is something like (COND ((MEMQ COMPILER-STATE) '(MAKLAP TOPLEVEL)) (OWN-SYMBOL PUSH POP . . .)) (T (MAPC 'REMPROP '(PUSH POP ) '(FSUBR FSUBR . . .)))) Thus if a macro-package require use of some SYMBOL as a macro or auxilliary function, which conflicts with some system FSUBR (or other kind of SUBR), then it can force deletion both in the interpreter and compiler of the system meaning.  Date: 12 JUL 1978 1107-EDT From: JONL at MIT-MC (Jon L White) To: DRB at MIT-MC CC: RWK at MIT-MC, (BUG LISP) at MIT-MC I share your preference for system macros, but wonder if it is worth the hassle to try to change (Again!). Probably we would have instituted a whole new class of initial objects (system macros) had we known the protest that arose over PUSH and POP as FSUBRs. Does not the problem still arise however if one wants to macro-define something that just happens to have the same name as some system FSUBR, e.g. STATUS or SIGNP?  Date: 12 JUL 1978 0943-EDT From: DRB at MIT-MC (David R. Barton) To: JONL at MIT-MC, RWK at MIT-MC, DRB at MIT-MC, (BUG LISP) at MIT-MC I have thought about it and I would rather have PUSH, POP, and CASEQ be system MACROS than system FSUBRS. I realize this is difficult, but I just wanted to point out the philosophical issue - these are trivial macros, and add nothing to the power of lisp, really, just convenience, and also I don't want to have to tell my damn macro expander about them, as I've told it about almost all the other system FSUBRS [if they're macros, it will just macro-expand them, and then have FSUBRS it knows how to deal with]. I realize this is difficult to do in the current LISP, but I thought I'd bring up the idea to see if you all agreed.  Date: 12 JUL 1978 0935-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC, NIL at MIT-MC In your design of streams, maybe that is a good place to correct the absence of a prompt capability. Case in point is: (PROGN (CURSORPOS 'A TYO) (PRINC '|-> | TYO) (SETQ INPUT (READLINE TYI))) If the guy types ^Z or ^L he will completely lose his orientation and can't really get a prompt back conveniently. ^K similarly could derive nicer display by running a PROMPT function special to a given stream, or by printing what is in the PROMPT variable, or whatever mechanism might be made available. I think this is particularly important becuz I would like to use the lisp readline function but don't often becuz it is very often true (I have lots more cases of it in last few days w/ SDRC project am working on and the users that are using it) that a person will get a :SEND or something in the middle of what he is doing and then think he is at DDT -- since typing ^L can't offer any assistance in orienting him, he loses, and ends up typing a :SEND back to me from inside Lisp. Those of us who know what is going on are not bothered much by the current reader, but a person using a predesigned package without knowing much about ITS will not. --kmp  Date: 12 JUL 1978 0235-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Your WRITE macro and GRINDEF To: (BUG LISP) at MIT-MC, KLE at MIT-AI The reason that GRINDEF fails after you use your write macro is that leave OUTFILES bound to a list of a closed file object. The correct thing to do is: (defun write macro (n) ;(write ) `((lambda (outfiles ^r ^w) ,(caddr n) (close (car outfiles))) (list (open ,(cadr n) 'out)) t t)) You should almost always lambda-bind ^W or ^R in a program (though at top-level you usually setq them). This prevents screws like the one you experience with GRINDEF. GRINDEF is wrong, though (JONL take note) as it should only look at OUTFILES if ^R is non-NIL. --Howard  Date: 12 JUL 1978 0042-EDT From: MOON at MIT-MC (David A. Moon) Subject: Rubout quickly loses To: JPG at MIT-MC, BEE at MIT-MC, (BUG LISP) at MIT-MC Rubbing out quickly on a display loses in Macsyma, and just about every place else. It is not that RMS can fix but won't. He and I have worked out a somewhat hairy scheme to change the way ITS does echoing to fix this and some some other problems. However, no one has had time to code it yet; it's hairy.  Date: 11 JUL 1978 2122-EDT From: RLB at MIT-MC (Richard L. Bryan) To: (BUG LISP) at MIT-MC After reopening TYO in '(ECHO) and TYI in '(ECHO FIXNUM) (the latter to be able to tyi the full char set), rettyconsing TYI & TYO, resetting the tty prescan, (sometimes) moving all the interrupt functions (whew!), (TYI) returns the right number including the bucky bits, but (TYI TYI) barfs about TYI not being an Ascii file object. (IN TYI) barfs about TYI not being a binary input file. How the hell can this be? Of course, (CAR (SYSCALL (+ 1 (LSH (+ %TINWT %TIFUL %TIACT) 18.)) 'IOT TYI)) does the right thing. There must be a better way .....  KLE@MIT-AI 07/11/78 19:03:03 To: (BUG LISP) at MIT-AI after using the following macro: (defun write macro (n) ;(write ) `(progn () (setq outfiles (list (open ,(cadr n) 'out)) ^r t ^w t) ,(caddr n) (close (car outfiles)) (setq ^r nil ^w nil) t)) Which expands into: (DEFUN WRITE MACRO (N) (CONS 'PROGN (CONS 'NIL (CONS (CONS 'SETQ (CONS 'OUTFILES (CONS (CONS 'LIST (CONS (CONS 'OPEN (CONS (CADR N) '('OUT))) 'NIL)) '(^R T ^W T)))) (CONS (CADDR N) '((CLOSE (CAR OUTFILES)) (SETQ ^R NIL ^W NIL) T)))))) it seems that after you use this macro grindef refuses to work. Why?  Date: 11 JUL 1978 1854-EDT From: JONL at MIT-MC (Jon L White) Subject: ERRSET undoification in compiled code To: (BUG LISP) at MIT-MC the routine beginning at label "ERUNDO" should be replaced with ERUNDO: SKIPN ERRTN JRST LSPRET SETZM TYOSW JRST ERUN0 as far as I can see, there is no need ever for ERUNDO to allow for "errors" so come thru - this is only the ERSTP break-up upon successful completion of an ERRSETted computation.  Date: 11 JUL 1978 1819-EDT From: JONL at MIT-MC (Jon L White) Subject: readline To: (BUG LISP) at MIT-MC Currently, (READLINE input-arg eof-val) will return the eof-val if the last "line" of the file doesn't have a carriage return ending it; KMP suggests that the eof condition act like a carriage-return character, so that READLINE will return the non-null line. (If there are no characters "buffered up" by READLINE, then it can return the eof-val). Also, after closing a line "by force" when the eof is encountered, the file should not be closed, but rather (FILEPOS input-arg T) should be done, so that the subsequent call to READLINE (or indeed any inputting fucntion) will cause the signalling of an eof condition.  GSB@MIT-ML 07/11/78 04:25:14 Re: (list (read) (tyi))X: etc. To: (BUG LISP) at MIT-ML The reader appears to have this kludge that it uses to get past TYI/UNTYI/TYI sequences. It reads the break character (in this case ':'), remembers the macro function only, then when it realizes it needs to untyi the character, looks up the macro function in the readtable to find out which character must have given us that macro function. (How quaint!) It would seem more reasonable for it to use 2 variables to remember this state, (or one in halfwords)... The variable in question is RDBKC, and the losing routine (which only gets called when exiting a toplevel read when there is a char that needs to be untyied) is RVRCT , called at READ0+6.  Date: 11 JUL 1978 0310-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: READ modifying characters. To: (BUG LISP) at MIT-MC CC: DRB at MIT-MC, GSB at MIT-MC, RWK at MIT-MC If SETSYNTAX ~ and : to be character macros, and the macros are EQUAL (not only for EQ, they just need to be EQUAL!) then you get very anomolous behaviour: (LIST (READ) (TYI))X~ ;space to activate.... (X 72) ;X: !?! (LIST (READ) (TYI))X: (X 72) ;At least one of them works! (LIST (READ) (TYIPEEK) (TYI) (TYI))X~~ ;TYIPEEK sees it too, (X 72 72 176) ;But only the first TYI sees it, after that ;TYI behaves normally (LIST (READ) (TYIPEEK T) (TYI))X ~ (X 176 176) ;(TYIPEEK T) won't do it, and it only happens ;to the character that terminates a read.  Date: 11 JUL 1978 0043-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC (cursorpos 't) doesn't work as described in .info.;lisp cursor.  KLE@MIT-AI 07/10/78 23:12:44 To: (BUG LISP) at MIT-AI WHY CANT M-V AND C-V SET THE MARK?  Date: 10 JUL 1978 2113-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: BEE at MIT-MC CC: (BUG LISP) at MIT-MC BEE@MIT-MC 9 JUL 1978 1028-EDT To: (BUG MACSYM) at MIT-MC, (BUG LISP) at MIT-MC You probably have heard about this before, just thought I would mention it. I am not sure if the problem is in lisp or in macsyma. When you rubout quickly, macsyma does the rubout, but doesnot do the backspace and erase character. So that the screen is not correct, but macsyma gets the right thing for example if I type FOOBAR; then the screen echos FOOBAR; but macsyma returns FOO The problem is neither a LISP bug, nor a MACSYMA bug, but an ITS bug. MOON claims that he discussed this with RMS whose code is involved, and that RMS can fix it but won't. Politics or something.  GSB@MIT-ML 07/10/78 01:24:30 Re: FRESH-LINE stream operation To: (BUG LISP) at MIT-ML CC: (BUG LISPM) at MIT-ML Maclisp currently has the capability to tell a stream/sfa, when it is doing a PRIN1, that it needs such-and-such amount of space to fit a portion of what it is printing on a line. Any opinions on having FRESH-LINE with no argument (or NIL arg?) have the semantics that LISPM gives to it, with the addition that if it receives an additional argument, the stream should go to a new line if there is not that much space remaining on the line? For maclisp, i would suggest (FRESH-LINE (optional FILE-SPEC) (optional AMOUNT-OF-SPACE-NEEDED))  Date: 9 JUL 1978 2136-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, GSB at MIT-ML GSB@MIT-ML 07/08/78 19:23:08 To: (BUG LISP) at MIT-ML Please people, RUBOUT (ascii 127 decimal) has a print width of 2 (TWO), and , (ascii 7 decimal) has NO print width! Currently they are backwards. ------ We "people", and we do not take the term as lightly as you seem to, have fixed your bug.  Date: 9 JUL 1978 2113-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, GSB at MIT-ML GSB@MIT-ML 05/03/78 13:19:45 To: HIC at MIT-ML I see that the more processor now ignores control chars... unfortunately, it flushes altmode. Maybe a better test would be to look at the syntax, and see if the character gets TOTALLY ignored - eg. ^S shouldn't be ignored, since it is a splicing macro, and $ is extended ascii (i presume). ----------- ^S and are now handled specially and not ignored.  Date: 9 JUL 1978 1914-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: MAP instruction and LISP To: (BUG LISP) at MIT-MC, GLS at SU-AI CC: GLS at MIT-MC, MRC at MIT-MC The MAP label has been changed to $MAP in the source.  Date: 9 JUL 1978 1028-EDT From: BEE at MIT-MC (Bruce E. Edwards) To: (BUG MACSYM) at MIT-MC, (BUG LISP) at MIT-MC You probably have heard about this before, just thought I would mention it. I am not sure if the problem is in lisp or in macsyma. When you rubout quickly, macsyma does the rubout, but doesnot do the backspace and erase character. So that the screen is not correct, but macsyma gets the right thing for example if I type FOOBAR; then the screen echos FOOBAR; but macsyma returns FOO  GSB@MIT-ML 07/09/78 05:14:26 To: (BUG COMPLR) at MIT-ML CC: (BUG LISP) at MIT-ML When the compiler compiles an ERRSET for effect, it should damn well make sure that A has something non-null in it before it does a JRST ERUNDO. If it does not do this, then lisp will run the ERRSET user interrupt function if there is one. I presume that this crock is so that the compiler can open-code lexically scoped calls to ERR, given that it does so. Also, why does it make a difference (at ERR0+1) whether *RSET is NIL or not? Shouldn't ERRSET get called anyway?  Date: 9 JUL 1978 0206-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JPG at MIT-MC, (BUG LISP) at MIT-MC Date: 9 JUL 1978 0131-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC Get a MACSYMA and type: LOADFILE(OLDF,CHART,DSK,TJR); THRU 1000 DO REV(C); Type ^] many times to get the computation time. You will most likely get at some time a possible infinite loop of ;(#FILE-OUT-|TTY:* *|-64014 #FILE-OUT-|DSK:BR;Z Z|-64674) LOSING OUTPUT FILE SPECS . (To see BR's (TJR's colleague) incredible REV definition, do DISPFUN(REV); . I don't know if this is a LISP bug, a bug in MACSYMA display, a bug in our handling of ^], or due to BR's increduosity. --------- Fixed in the source and patched in the running LISP.  Date: 9 JUL 1978 0131-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC Get a MACSYMA and type: LOADFILE(OLDF,CHART,DSK,TJR); THRU 1000 DO REV(C); Type ^] many times to get the computation time. You will most likely get at some time a possible infinite loop of ;(#FILE-OUT-|TTY:* *|-64014 #FILE-OUT-|DSK:BR;Z Z|-64674) LOSING OUTPUT FILE SPECS . (To see BR's (TJR's colleague) incredible REV definition, do DISPFUN(REV); . I don't know if this is a LISP bug, a bug in MACSYMA display, a bug in our handling of ^], or due to BR's increduosity.  GSB@MIT-ML 07/08/78 19:23:08 To: (BUG LISP) at MIT-ML Please people, RUBOUT (ascii 127 decimal) has a print width of 2 (TWO), and , (ascii 7 decimal) has NO print width! Currently they are backwards.  Date: 7 JUL 1978 1531-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC CC: GLS at SU-AI In the next release of LISP, a solitary fixnum as a namestring will give a WTA error.  Date: 7 Jul 1978 1219-PDT From: GLS at SU-AI (Guy Steele) Subject: Fixnums as namestrings To: bug-lisp at MIT-MC CC: GLS Right, I suggest that only symbols and strings be permitted as namestrings. -------  Date: 7 JUL 1978 1446-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, SUN at MIT-ML CC: (FILE [ML:SUN;LISP NOTES]) at MIT-MC Obviously hacking the memory management is a pain, of my suggestions, the only trivial one I'd like to have would be the uof TRMOP to do the IO for TTY's and the corallary abilty to diddle the IO. bits with SSTATUS TTY. This would make secondary TTY's useful. The GL. bits stick even after you leave the lisp, while (for example) twiddling the IO.SUP bit of IO. whould give io suppression that stops when that channel goes away. ------- I think this can be arranged. ------- As to keeping compatible to 5.06 when 7.01 will be out in a few months, I don't know what the worth is of being compatwith a 4 year old operating system. 7.01 is said to have values for CRT's by the way. ------- Well, the 5.06 monitor is the only reasonable one around for KA10's. 5.06B is probably the best monitor DEC has ever come out with (not in terms of features, of course, but in terms of usability and reliability). Even CMUB is running one. Therefore, I have no plans to become incompatible to any large degree, even when DEC releases 20.05C! -------- Oh well, see you guys (no pun intended) later. -------- OK. --howard  Date: 7 JUL 1978 1441-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JONL at MIT-MC, (BUG LISP) at MIT-MC CC: GLS at SU-AI Date: 7 JUL 1978 1157-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC Say, I dont think "(OPEN 4 'OUT)" should be legal. Shouldn't we require "(OPEN '(4) 'OUT)" or even "(OPEN '(4) '(OUT))"??? ------- Well, I think it would be a reasonable thing to not allow FIXNUMS as namestrings. I suspect that htis can cause more screws then it cures. I would like to hear GLS' opinion.  Date: 7 JUL 1978 1157-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC Say, I dont think "(OPEN 4 'OUT)" should be legal. Shouldn't we require "(OPEN '(4) 'OUT)" or even "(OPEN '(4) '(OUT))"???  SUN@MIT-ML 07/07/78 11:15:18 To: (BUG LISP) at MIT-ML CC: (FILE [SUN;LISP NOTES]) at MIT-ML Obviously hacking the memory management is a pain, of my suggestions, the only trivial one I'd like to have would be the uof TRMOP to do the IO for TTY's and the corallary abilty to diddle the IO. bits with SSTATUS TTY. This would make secondary TTY's useful. The GL. bits stick even after you leave the lisp, while (for example) twiddling the IO.SUP bit of IO. whould give io suppression that stops when that channel goes away. Sorry about saying taht the system knows if you are a crt, that ia local hack here, we are using the TIDY bit to mean that. As to keeping compatible to 5.06 when 7.01 will be out in a few months, I don't know what the worth is of being compatwith a 4 year old operating system. 7.01 is said to have values for CRT's by the way. If you wish to keep somebody alive in an ancient operating system, maybe yet another conditional assebly is what is wanted (argh). Oh well, see you guys (no pun intended) later.  GSB@MIT-ML 07/07/78 03:37:46 To: (BUG LISP) at MIT-ML I seem to get .VAL 0's at UINTPU-1 when i $P my XL after doing something like PP MUMBLE$X after ^Z'ing it while it was waiting for input. The worst part is that after that, (if i just $P that), it is sitting running lisp code with defer words set! It doesn't happen if INHIBIT is -1, only if it is -1,,0 (It happens in the current lisp also)  Date: 6 JUL 1978 2253-EDT From: JONL at MIT-MC (Jon L White) To: RLB at MIT-MC CC: (BUG LISP) at MIT-MC I see no problem with leaving LAPSETUP| alone so that you can use it in the case with PURE = NIL. That way, you are using it only as a clobber a specific CALL to be a PUSHJ (or whatever) and LAP would just never be using it that way - I think the difference is in the NILness of the second arg.  Date: 6 JUL 1978 2148-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC Have just fixed up FASLAP so that it checks for a GLOBALSYM property before checking for the SYM property. Would appreciate it if HIC could change FASLAPSETUP| to put a GLOBALSYM property rather than the SYM (value is the same however.)  Date: 6 JUL 1978 2105-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, RWK at MIT-MC, GSB at MIT-MC, RAF at MIT-MC To: RLB at MIT-MC, DRB at MIT-MC CC: MRG at MIT-MC, RMS at MIT-MC JONL and I talked about 'streams' some more and we finally pinpointed the problem -- that the stuff that currently exists in MacLISP and the new stuff I have been adding (and calling 'streams') are really only subsets of the global thing which we want to impliment in NIL. Since it would be too much effort to retrofit the more comprehensive stuff into PDP-10 MacLISP, we have agreed that the implimentation of the stuff I am calling 'streams' is OK, but that it should not be called streams (as the connotations are too strong and potential conflicts with NIL exist). Therefore, I am renaming the STREAM- prefix on the functions and documentation to SFA- which stands for [S]oftware [F]ile [A]rray. A release date is not currently known, and will be established as work progresses. Hopefully expressing the sentiments of all correctly, Howard  Date: 6 JUL 1978 1925-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC I made a new LAP, which corrects the problem KMP pointed out yesterday that |GWD was declared to be a fixnum function, but was ocasionally returning NIL, thereby lousing up some of his code. Also flushed the private versions of PUSH, POP, DISPLACE to allow for use of the systemic ones. A few other minor bugs and outdated "features" were corrected, and I set up LAP so that in the case of PURE non-NIL but not in the small-magnitude fixnum range, it changes it to be a small fixnum; apparently the calls to LAPSETUP| are still ok, but the one made with first arg T is more-or-less superfluous now (before, it was to be sure that the UUOLINKS pages were set up, but now, these are indefinitely extendible from scratch). I guess I also flushed the self-loader at the front, since almost all usage is by the fasloading of the fasl file; even if it is desired to load an expr version (without all the offending typeout from top level) the LOAD function is appropriate. What a relic of the past the file (ELAP ) is!  Date: 6 JUL 1978 1117-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: Proposed changes to LAPSETUP| To: (BUG LISP) at MIT-MC For the hairy Macsyma symbol reaping stuff I need to be able to smash UUOs in the UUOlinks areas. (Yes, I really do). It is really convenient to be able to call LAPSETUP| from Lisp level to do this, rather than adding yet another bunch of hand-coded Lap to do mere interfacing to code which already exists in the Lisp system. I suppose I can put up with any changes to LAPSETUP| as long as there still exists a flavor which says "smash the ostensible UUO in this place".  Date: 6 JUL 1978 1105-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: LAPSETUP| To: JONL at MIT-MC, (BUG LISP) at MIT-MC  Date: 6 JUL 1978 1105-EDT From: RLB at MIT-MC (Richard L. Bryan) Subject: LAPSETUP| To: JONL at MIT-MC, (BUG LISP) at MIT-MC  Date: 6 JUL 1978 0750-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Gunk! Can you have INCLUDE do a FASLP check on the file as it opens it. There being little in the way of documentation, I just put an (INCLUDE ((DSK KMP) LIB FASL)) in my file and was getting errors like ;PJPCAPS UNBOUND variable I spent a lot of time searching files for that one broken across boundaries, etc. When I got: ;GETCHARN$@ICVTAXASCII"\JU8CAPSSTUFFX UNBOUND VARIABLE it was rather obvious what I had done. A ;BKPT WRONG-TYPE-FILE would have been nice, or even make it smart and if it is doing a load and gets a faslp type file included, make it fasload the thing? But at any rate, please document what it does in this case to save people like me the hassle of having to make something up and find out by trial and error that it is only defined for ascii. Would it be hard for the complr to take already fasl code and insert it directly into the fasl it is outputing on a compilation? That would seem ideal, but for all I know the calling sequence for a fasl file is something dependent on things that the complr couldn't know. Oh, well. Thanx. --kmp  Date: 5 JUL 1978 2323-EDT From: JONL at MIT-MC (Jon L White) Subject: LAPSETUP| To: (BUG LISP) at MIT-MC Desired change consistent with mergeing the PURE = T and PURE = options. First arg is one of three things: 1) NIL meaning setup phase when LAP is being loaded 2) T maining setup phase when a function is about to be LAPped 3) # meaning try to purclobber this location, by making an entry on the current uuolink page and doing a XCT on it (or using existing entry if one already exists). The second arg will always be the current value of PURE, but it actually irrelevant now.  Date: 5 JUL 1978 2041-EDT From: JONL at MIT-MC (Jon L White) Subject: Simplifications for UUO links etc. To: (BUG LISP) at MIT-MC 1) Hau about flushing the alternative for lap and fasload which permits the "snapping" of CALLs and JCALLs during loading etc. The only alternatives then would be PURE = NIL and PURE = non-NIL. With the new incrementally-extendible UUOLINKS area, and its smaller size, there seems to be little reason not to use it in all cases wherein some purification is desired. 2) According to GSB, the UUO clobberer should bypass the clobbering on any binary-program page which is considered pure. There is come code in the UUO handler which tries to decide whether or not to clobber - perhaps we could merely extend it to inspect the GCST for the page in question, and it it is alleged to be pure, then cancel.  Date: 5 Jul 1978 1620-PDT From: GLS at SU-AI (Guy Steele) Subject: SAIL LISP To: bug-lisp at MIT-MC CC: GLS, RPG LISP is in a really bad state out here at SAIL. I desperately want a working CASEQ, for example. NEWIO doesn't work, and we cannot really bring up a new OLDIO either. We also need a new compiler to win with LSUBR CONS, etc. The NEWIO has the bug that reading files with more than one page seems to read the page break as the symbol with the null print name. Please give some thought to bringing up some new SAIL version soon? -------  Date: 5 JUL 1978 1801-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, GSB at MIT-MC, RWK at MIT-MC In the next LISP, CLOSE will return T if it did something, or else NIL.  Date: 4 Jul 1978 2316-PDT From: GLS at SU-AI (Guy Steele) Subject: MAP instruction and LISP To: bug-lisp at MIT-MC CC: GLS, MRC MRC wants to add the new KL10 instructions to MIDAS, which will cause yet another conflict like that of INIT with the instruction MAP. Perhaps the internal label of the MAP function should be changed to $MAP in the near future. -------  Date: 3 JUL 1978 2016-EDT From: RWK at MIT-MC (Robert W. Kerns) Sent-by: RWK0 at MIT-MC To: (BUG LISP) at MIT-MC Rather than || printing as no characters at all, why doesn't the top-level loop do an EQ test, and simply not do the print if it is returned? This would be most likely upwards compatible and much more consistent.  Date: 3 Jul 1978 1642-PDT From: GLS at SU-AI (Guy Steele) Subject: DEFSTRUCT and PASCAL-type Record Variants To: L.DIS[1,GLS]: It would be nice if the DEFSTRUCT hack had a provision for handling PASCAL-type "record variants" (I have an application for them). In this, one field of the structure is a datum whose value determines the format of the rest of the structure. Thus, in my application, one might want to write something like (DEFSTRUCT CODENODE () SEXPRCODE ENVIRONMENT (FUNNY-BITS 0) (VARIANT NODETYPE (VARIABLE VARTYPE VARNAME) (CONSTANT CONSTVAL) (SETQ VARTYPE VARNAME SETQBODY) (LAMBDA LAMBDAVARS (REGISTERS '()) LAMBDABODY) ...)) That is, the VARIANT clause defines a field NODETYPE whose value can be one of VARIABLE, CONSTANT, SETQ, LAMBDA, ... Is is illegal to SETF this field, and its value must be specified to MAKE-CODENODE when a CODENODE is created. Interpretively, at least, SETF could test when altering a field, and access macros could test when accessing, that the structure is of the right variant form for that field to exist. PASCAL does not permit two variants to have the same field name (as VARTYPE and VARNAME in my example); it would be much hairier, but convenient, for DEFSTRUCT to check for this and ensure that fields with the same name occupied the same slot in all variants; in this manner if one knew that a CODENODE was either a SETQ or a VARIABLE variant, then accessing VARTYPE would work properly no matter which variant it were. -------  Date: 3 Jul 1978 1546-PDT From: GLS at SU-AI (Guy Steele) Subject: SORT exchange operator To: eak at MIT-MC CC: GLS, bug-lisp at MIT-MC Well, the use of such an operator would make the sort somewhat slower, but I suppose it could be special-cased the same way some predicates like ALPHALESSP are. One can sort several arrays in parallel by first consing together corresponding elements into single objects in another array, sorting that, then decomposing and storing back (yech). Maybe SORT should just be a clever dispatch to other user-available functions called MERGESORT, QUICKSORT, etc. -------  Date: 3 Jul 1978 1536-PDT From: GLS at SU-AI (Guy Steele) Subject: Motes, singles, and other issues of array theory for LISP To: kle at MIT-AI, L.DIS[1,GLS]: Here are a few thoughts regarding the treatment of motes and singles in LISP for the purposes of the implementation of More-type array-theoretic functions. I would appreciate commants with regard to suitability of concept and requirements of implementation. I bring this up because the design of of the appropriate data types is a pending issue for NIL. Arrays in general in NIL ought to work for boundary cases and have no artificial limits if possible. Thus, arrays should be allowed to have axes of zero length, and to have zero axes. The latter situation is given an interpretation by array theory by considering it to be a cell, for which there is precisely one valid index tuple, namely the empty index tuple. (If one realizes that the number of elements in a rectangular array is the product of the axis lengths, then a zero-axis array clearly has one element, and the index tuple for that element has no indices.) In array theory, More calls such a zero-axis array a *single*. Such zero-axis arrays could be implemented by a special type, and used for various interesting purposes. For example, a dynamic variable holding a flonum cell (a single whose element is always a flonum) could solve the PDLNMK-with- SPECIAL-variables problem. Alternatively, it could just be in the standard array format. (RMS has suggested that one-dimensional arrays, presumably with standard bounds 0:n-1, be implemented as simple vectors. This sounds fine to me except for one glitch, namely that one-dimensional arrays with leaders or other funny stuff would not be interchangeable with arrays (i.e. vectors) which did not have such junk.) Now array theory takes all primitive data types (numbers, characters, etc.) to be classes of objects each of which is a single whose sole element is itself. (Such objects More calls *motes*.) Thus, for purposes of generalized indexing, element extraction, etc., a number or character is considered to be a zero-dimensional array. This causes no problem for array-theoretic functions implemented in NIL, which can just check for such data types and treat them specially. What worries me is the treatment of motes and singles in a way that is implementationally and computationally convenient, especially in the presence of array assignment, and yet consistent with the treatment of array theory. For example, a single containing a mote is considered to be equivalent to the mote itself. Suppose such a single A is created. As an array, its element can be assigned to (using STORE or whatever). If a mote is assigned to it, there is no convenient way to make it be the mote itself, at least in the sense of EQ or even EQUAL. Alternatively, suppose one were to say (STORE (AR-0 43) 'foo), i.e. store 'foo into the single (mote) 43. It is clearly not desirable to allow the alteration of 43! I guess it may suffice merely to decree that array assignment to motes is illegal. By the way, motes remind me an awful lot of self-lists. In a cdr-coded scheme, such a self-list could occupy one cell, and we could decree that the car of a self-list would be itself and its cdr be (). Then singles (cells) would be the generalization of this analogous to the definition of 1-hunks on the PDP-10. It is unfortunate that More chose to use the word *list* for a purpose in array theory. Aside from that there are almost no conflicts with LISP terminology. This in turn raises the question of whether LISP lists are to be considered motes by the array-theoretic functions or not. -------  Date: 3 Jul 1978 1440-PDT From: GLS at SU-AI (Guy Steele) Subject: Extension to merge sort To: bug-lisp at MIT-MC CC: NIL at MIT-MC, GLS, bug-lispm at MIT-AI A useful extension to the merge sort (on lists) would be to extend to "predicate" to have four possible return values. Recall that at each step two items a and b are yanked off of two lists, and on the basis of the predicate one is stuffed into an output list and the other is left on its original input list for iteration. The change would be: (pred a b) = () a  b: output b, leave a behind FIRST output a, and throw away b SECOND output b, and throw away a other non-(): output a, leave b behind The idea is that if the predicate determines that two items are in some sense equal, it may want to just discard one and leave the other in the sort. This is good for eliminating duplicates. If it is not desired to change the semantics of the SORT function, perhaps this new one could be called SIFT or something. Also, it would be convenient if MERGE were available as a separate function. -------  Date: 3 Jul 1978 1358-PDT From: GLS at SU-AI (Guy Steele) Subject: CASEQ extensions To: NIL at MIT-MC CC: GLS, bug-lisp at MIT-MC [a] In NIL, CASEQ will presumably be extended to allow dispatching on characters, as well as fixnums and symbols. [b] It would be convenient to have a syntax for specifying ranges for fixnums and characters. A simple idea would be to allow something of the form (3 7) or perhaps (RANGE 3 7) where a single item would be allowed. The former could be permitted only within a list; the latter could be permitted as a single element by making RANGE a reserved word. (Perhaps &RANGE should be used instead in that event.) -------  Date: 3 JUL 1978 1638-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: JOSH at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC I'd like to find out what the "best" READ algorithm in lisp is. our (rutgers) lisp has a very fast read but it loses for long lists... the length of a list goes on the stack so it blows up in those cases. I asked our resident LISP hacker (before he left) why and he thought that destructive additions to the structure (or reversing it afterwards) was messy. Are there any reasons that either of these methods aren't as straightforward as they seem to me? --JoSH Well, it seems to me that the choice between a clean algorithm that doesn't work and a messy one that does should be obvious. MacLISP uses destructive additions, and it is not "messy" at all.  Date: 2 JUL 1978 0400-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, BYRON at MIT-ML The CASEQ bug you mention (with regard to NIL) has been fixed in the source. I will patch it as soon as possible.  BYRON@MIT-ML 07/02/78 02:07:53 To: (BUG LISP) at MIT-ML NIL and CASEQ don't seem to get along together. e.g. (caseq nil (nil 'foo)) bombs as does (caseq nil (t 'foo)). It seems caseq doesn't like NIL as a SYMBOL, even though the definition of caseq in a recent LISP ARCHIV message dosn't make such an exception for NIL.  Date: 2 JUL 1978 0124-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG COMPLR) at MIT-MC, (BUG MACSYM) at MIT-MC CC: (BUG LISP) at MIT-MC, DRB at MIT-MC DAMN, DAMN, DAMN, DAMN, I DID A MAKLAP1 (from ALJABR;COMPLR >) on RAB;OUTMIS >, and the cretin FASL-CLOSEOUT went and did a RENAMEF on one of the files loaded into it by FASLOAD. CRETIN FASLOAD STILL CLOBBERS DEFAULTF! And why does it matter to the compiler, anyway, asuming that is how it got screwed up, can't it remember what file's what, and do the RENAMEF on the open file-object??? I had to re-create my file, which was painful, since renaming to something unknown is as bad as deleting it! (particularly when the thing unknown is OUTMIS UNFASL !) I'd never have found this except for it bombing when it tried to rename my newly-created version to be the same name as the old version had been clobbered to, and lost!  Date: 2 JUL 1978 0024-EDT From: JOSH at MIT-MC (J Storrs Hall) To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC I'd like to find out what the "best" READ algorithm in lisp is. our (rutgers) lisp has a very fast read but it loses for long lists... the length of a list goes on the stack so it blows up in those cases. I asked our resident LISP hacker (before he left) why and he thought that destructive additions to the structure (or reversing it afterwards) was messy. Are there any reasons that either of these methods aren't as straightforward as they seem to me? --JoSH  GSB@MIT-ML 07/01/78 14:00:03 Re: LAP To: (BUG LISP) at MIT-ML LAP-NIL UNDEFINED FUNCTION IN UUO CALL  GSB@MIT-ML 07/01/78 11:04:34 Re: sxhash To: (BUG LISP) at MIT-ML so document it and call it a feature that it works on sets.  Date: 1 JUL 1978 1025-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC I got a ;FXPDL OUT OF PHASE (SYSTEM ERROR) ;BKPT *RSET-TRAP when i $P'd a job after doing (QUIT) and not typing a space after the :KILL -Kill Protected Job-- What causes this?  Date: 1 JUL 1978 0012-EDT From: BEE at MIT-MC (Bruce E. Edwards) To: (BUG MACSYM) at MIT-MC, (BUG LISP) at MIT-MC The planned scheme with save-file could be hacked to be a little bit more winning. 1) Lisp would have to be changed to never recons a file-object, when it is given one for the first argument. and 2) Macsyma should open the original file object in FIXNUM mode, which will cause it to take up the maximum amount of space, so that the user will be guaranteed to have enough room for the file object, no matter what the mode he wants to use. The reason why this would be good, is that the PLOT2 package wants to use that file-object to copy files, and I needs fixnum mode to do it.  Date: 30 JUN 1978 2217-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: LSUBR CONS and ` To: MOON at MIT-MC, (BUG LISP) at MIT-MC In my opinion LIST* (or LIST. ?) is a much better name for that operation than CONS. Fine by me - I just want the feature, with some standard name. If LISPM already calls it that, it suits me. Note that ,@ 's only conflict with other syntax for @ is that you must remember not to put an @ immediately (without intervening space) after a comma. This is irrelevant to whether @ is a macro character or an alphabetic. I.e. comma does a tyipeek looking for an atsign. I thought of that. It's gritchy, but I guess one could live with it. Still, there could have been other choices, such as ,- , but I guess maybe it isn't worth changing at this point?  Date: 30 JUN 1978 1548-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Complex and double-precision numbers To: (BUG LISP) at MIT-MC CC: MRG at MIT-MC This is what MRG, RLB and I have reached as a fairly firm method of handling complex numbers: Each complex cell will be composed of two words. If the left half of the word is zero, then the right half is a pointer to the component. In order for the generic functions to work, the component must be: A) Fixnum B) Flonum C) Double-precision D) Bignum If the generic functions are not to be used on the complex number, then the components may be anything. If the left half of the word is non-zero, or in the special case of the word being completely zero, then the component is considered a flonum and is contained in the cell itself. The first word is the real portion of the complex, and the second word is the imaginary part. This scheme satisfies the goals: A) Fast and effecient complex-flonum format for the IMSL package B) Reasonably fast/effecient arbitrary complex format for other uses. Note that the notion of DUPLEX (double-precision complex) is no longer needed. For the compilation of these things, RLB and I will hack up a set of macros that will convert the complex operations to operations on the real part and the imaginary part. This should allow NCOMPLR to produce reasonable code using the pdl's in a normal fashion. The goal of making IMSL work well will be easilly satisfied by these macros. The problem of double-precision numbers and compilation is still up-in-the-air. I believe this sumarizes what we have talked about. Comments are requested. --Howard  Date: 30 JUN 1978 0654-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: LSUBR CONS and ` To: (BUG LISP) at MIT-MC, GLS at SU-AI CC: GLS at MIT-MC, (BUG lispm) at MIT-AI LSUBR cons is now implimented in the compiler, and is turned on in the currently being developed interpreter (and seems to win fine). Therefore, unless there are any gross complaints or screws, the interpreter will support LSUBR cons in the next release. I would like to put in my two cents (once again): I would rather see it be LIST* then LSUBR cons. --Howard  Date: 30 JUN 1978 0652-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC Is there a way to test for an end-of-file condition with fixnum files. I would very much like it if all the i/o functions had somewhat similar syntax. It seems there is no way to do with FILEPOS, IN, and a few other random functions what you can do with read (ie, specify a last arg which is the value returned if an EOF is hit.) There also needs to be a seperate function (EOF?) which takes the arg of a file object and tells you if you are about to get an EOF condition. If such a function is not included there is a problem writing efficient code. One would like to be able to declare a variable (say N) to be fixnum and do a (SETQ N (IN )) but since N can return any fixnum, you will always stand to lose somehow. the alternative is to allow to be NIL but then you can't declare N to be a fixnum. the (EOF ) is the only clean way to resolve the problem. [Note that when I say I mean a disk file -- though it would be nice if we had streams, I use the term stream here just becuz it is shorter than file-object, and I'm in the habit of calling files streams for convenience.]  Date: 29 JUN 1978 2107-EDT From: MOON at MIT-MC (David A. Moon) Subject: LSUBR CONS and ` To: (BUG LISP) at MIT-MC In my opinion LIST* (or LIST. ?) is a much better name for that operation than CONS. Note that ,@ 's only conflict with other syntax for @ is that you must remember not to put an @ immediately (without intervening space) after a comma. This is irrelevant to whether @ is a macro character or an alphabetic. I.e. comma does a tyipeek looking for an atsign.  Date: 29 JUN 1978 2100-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC I have answered NATE re INF-EDIT. LISPT no longer supports bare TECO's.  Nate@MIT-ML 06/29/78 20:24:08 To: (BUG LISP) at MIT-ML There has been a change in lisp that seems to prevent proper loading of the right macro into the inferior TECO when using the function INF-EDIT. The editor responds when intially started by lisp with M^R? as its error message. When doing an MZ$$ the macro fails with the same error message. I have only tried this on ML. It would be a great aid if you would fix this nasty bug. Thanks, Nate  Date: 29 Jun 1978 1218-PDT From: GLS at SU-AI (Guy Steele) Subject: LSUBR CONS and ` To: bug-lisp at MIT-MC CC: bug-lispm at MIT-AI, nil at MIT-MC, GLS (a) It might be a good idea to incorporate the ` read-macro into LISP as soon as feasible. It is a slight misfeature that ,@ is used to mean splicing, because then @ cannot be easily used as a separate macro character and then combined with ,. Other than that, and the issue of whether one should always make a complete copy of the structure, or try to share as much structure as possible (the SCHEME " macro uses " for complete copying and "! for sharing, though the use of ! has a similar disadvantage to that of ,@), the LISPM version of ` seems fine. (b) Will CONS ever become as LSUBR soon? I understand that LSIPM has a thing called LIST* which is essentially that. (It is particularly useful for code generated by `.) -------  Date: 29 Jun 1978 1159-PDT From: GLS at SU-AI (Guy Steele) Subject: CASEQ and CHECK-ARGS To: nil at MIT-MC, bug-lisp at MIT-MC CC: bug-lispm at MIT-AI, rwk at MIT-MC, GLS Ordinarily I would agree with you about using CHECK-ARGS. However, CASEQ is a special situation: (a) at the implementation level, what CASEQ is doing already is to check a thing for membership in a set. Doing the entire test first with CHECK-ARGS is redundant. This is particularly bad if symbols rather than fixnums are involved. (b) at the user level, it is a pain to have to enumerate the valid elements twice, once in the CASEQ and once in the CHECK-ARGS forms. (c) given CASEQ with a loopback, you can very easily override the loop with a T (OTHERWISE) clause; but given CASEQ without a loopback, it is very clumsy to get the loop. Thus, while I agree that CHECK-ARGS should be considered the general mechanism for this sort of thing, the above considerations seem to make it worth having CASEQ itself have a check and loopback. As I said in my original note, UNSEEN-GO-TAG might be a more appropriate classification than WRNG-TYPE-ARG anyway; while this is semantic hair-splitting, such a classification would take CASEQ out of the purview of CHECK-ARGS. (I just realized that CHECK-ARGS may actually be spelled CHECK-ARG - I forget. If so, I apologize.) -- GLS -------  Date: 29 JUN 1978 1108-EDT From: HIC at MIT-MC (Howard I. Cannon) To: RWK at MIT-MC, GSB at MIT-MC CC: (BUG LISP) at MIT-MC For next release of LISP: (STATUS HOMEDIR) returns atom which corresponds to sixbit in HSNAME user var Special case check for USR device in PROBEF  Date: 29 JUN 1978 0739-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JLK at MIT-MC, (BUG LISP) at MIT-MC Date: 28 JUN 1978 1730-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC HIC - I thought you put the hack in HUMBLE to set %OPLSP when an inferior is created or reowned? It no longer seems to. ------ The HUMBLE source has the code in it. Look for %OPLSP and take a look at it....I might have blown it. Or perhaps it is not installed; if this is the case, you are welcome to install it. --Howard  Date: 28 JUN 1978 1730-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC HIC - I thought you put the hack in HUMBLE to set %OPLSP when an inferior is created or reowned? It no longer seems to.  Date: 28 Jun 1978 1226-PDT From: GLS at SU-AI (Guy Steele) Subject: CASEQ with no T clause To: bug-lisp at MIT-MC CC: bug-lisp at MIT-AI, nil at MIT-MC, GLS I recommend that a CASEQ which "falls through" not return NIL, but give an error and recycle with the new thing returned from the error. This may seem like a throwback to the days when a COND which fell off the end (*except* in a PROG - what a kludge!) was likewise an error. However, I suggest that if a CASEQ falls off the end, it was more likely the result of an unanticipated bug, giving it something it could not handle. Thus I would have CASEQ expand into something like: (PROG (GNARDS) (SETQ GNARDS THE-THING) BARF (SETQ GNARDS (ERROR '|X{BULLET,DUST,BAG}: CASEQ BIT X| GNARDS 'WRNG-TYPE-ARG))) ;UNSEEN-GO-TAG ?? or, pseudo-equivalently: ((LABEL PHROG (LAMBDA (GNARDS) (COND (T (PHROG (ERROR ... GNARDS 'WRNG-TYPE-ARG)))))) THE-THING) depending on whether you prefer a statement-style or functional-style approach. In any case, I find that *most* CASEQ's I write want to have this kind of error recovery loop wrapped around them, and it's a pain to have to write each one out explicitly. A related idea, which I have seen in some Algol-like proposals (SIGPLAN Notices? but I can't locate a reference), is a kind of statement called, say, CASEGO; it effectively recognizes that CASEQ clauses are "labelled" in a manner similar to PROG statements, and provides a way to go to a specified clause by mentioning a "label": (CASEQ A-FIXNUM ((0 4 6 8) (HACK-EVEN)) ((1 9) (BORING)) ((3 5 7) (MUNCH-PRIME)) ((2) (HACK-EVEN) (CASEGO 3))) ;2 IS ALSO PRIME This is semi-ransom, though probably not all that hard to compile or interpret. I brought it up only because the first problem has a solution expressible as: (CASEQ the-thing ... (T (CASEGO (ERROR ... the-thing 'WRNG-TYPE-ARG)))) CASEGO as such doesn't excite me - it's just random. But the first problem deserves some thought. -------  Date: 28 Jun 1978 1226-PDT From: GLS at SU-AI (Guy Steele) Subject: CASEQ with no T clause To: bug-lisp at MIT-MC CC: bug-lisp at MIT-AI, nil at MIT-MC, GLS I recommend that a CASEQ which "falls through" not return NIL, but give an error and recycle with the new thing returned from the error. This may seem like a throwback to the days when a COND which fell off the end (*except* in a PROG - what a kludge!) was likewise an error. However, I suggest that if a CASEQ falls off the end, it was more likely the result of an unanticipated bug, giving it something it could not handle. Thus I would have CASEQ expand into something like: (PROG (GNARDS) (SETQ GNARDS THE-THING) BARF (SETQ GNARDS (ERROR '|X{BULLET,DUST,BAG}: CASEQ BIT X| GNARDS 'WRNG-TYPE-ARG))) ;UNSEEN-GO-TAG ?? or, pseudo-equivalently: ((LABEL PHROG (LAMBDA (GNARDS) (COND (T (PHROG (ERROR ... GNARDS 'WRNG-TYPE-ARG)))))) THE-THING) depending on whether you prefer a statement-style or functional-style approach. In any case, I find that *most* CASEQ's I write want to have this kind of error recovery loop wrapped around them, and it's a pain to have to write each one out explicitly. A related idea, which I have seen in some Algol-like proposals (SIGPLAN Notices? but I can't locate a reference), is a kind of statement called, say, CASEGO; it effectively recognizes that CASEQ clauses are "labelled" in a manner similar to PROG statements, and provides a way to go to a specified clause by mentioning a "label": (CASEQ A-FIXNUM ((0 4 6 8) (HACK-EVEN)) ((1 9) (BORING)) ((3 5 7) (MUNCH-PRIME)) ((2) (HACK-EVEN) (CASEGO 3))) ;2 IS ALSO PRIME This is semi-ransom, though probably not all that hard to compile or interpret. I brought it up only because the first problem has a solution expressible as: (CASEQ the-thing ... (T (CASEGO (ERROR ... the-thing 'WRNG-TYPE-ARG)))) CASEGO as such doesn't excite me - it's just random. But the first problem deserves some thought. -------  Date: 28 Jun 1978 1053-PDT From: GLS at SU-AI (Guy Steele) Subject: SAIL NEWIO To: bug-lisp at MIT-AI CC: GLS Evidently the interrupt character table for SAIL NEWIO distinguishes CTRL/g from CTRL/G? If so, BOTH should initially be set to the QUIT interrupt, etc. -------  GSB@MIT-ML 06/28/78 10:50:27 To: (BUG LISP) at MIT-ML obviously the evaluater should look to seeif part of the plist is pure, and extract properties from that portion first. This goes for the uuo handler also.  GSB@MIT-ML 06/28/78 10:28:46 Re: plist ordering To: (BUG LISP) at MIT-ML It may be a 'known' feature but it wasn't known to me until i spent a significant portion of time figuring out who had fucked up where. It appears that a little bit of circumspection is in order before this 'feature' put onto the property list. Presumably one DEFUN whether compiled or interpreted will override all others, and there is a limit to the amount of dispensations you can expect people to make to impletations hacks.  Date: 28 JUN 1978 0615-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (ASCII 2120.) returns H but (READLIST '(2120.)) returns an error ;2120. NOT ASCII CHARACTER This doesn't seem very consistent. I would prefer to not get the error. --kmp  Date: 28 JUN 1978 0608-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, JLK at MIT-MC CC: RZ at MIT-MC, RLB at MIT-MC JLK@MIT-MC 06/27/78 17:26:15 To: RLB at MIT-MC, HIC at MIT-MC CC: RZ at MIT-MC, JPG at MIT-MC RZ pointed out that the UUF-Handler loses in *RSET mode because instead of getting a break point, it just punts back to top level rather than breaking. The handler just calls (ERR) and I don't see why this don't cause a break. Any ideas from the LISP hackers? Very simply, compiled calls to ERR work differently from interpreted calls to ERR!!! Of course, this would seem to make no sense. As soon as JONL confirms this, HIC is willing to fix it.  HIC@MIT-MC 06/28/78 04:31:45 To: GSB at MIT-ML, (BUG LISP) at MIT-ML CC: moon at MIT-AI GSB@MIT-ML 06/27/78 22:07:35 If DESIGN-AGGTNS has an EXPR property and then some fasl code gets loaded which gives it a SUBR property and *PURE is T then the fucking SUBR property gets put at the end of the plist!!!!!!!!! -------- Due to the way plist's are purified, the plist is divided into the impure portion and the pure portion. Therefore, strict ordering is not preserved. This is a known 'feature'.  GSB@MIT-ML 06/27/78 22:07:35 To: (BUG LISP) at MIT-ML CC: moon at MIT-AI If DESIGN-AGGTNS has an EXPR property and then some fasl code gets loaded which gives it a SUBR property and *PURE is T then the fucking SUBR property gets put at the end of the plist!!!!!!!!! I just spent 5 hours attempting to find out why morgensterns optimizer didn't work any more!!!!!!!!!!!!!  Date: 27 JUN 1978 1409-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: HIC at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC More generally, the suggestion should be that ATOM be used in preference to NULL in most functions that traverse lists. This should probably be true in most NIL implementations, as a mater of error-checking if nothing else. On the PDP-10 NULL tests are cheaper than ATOM tests. Even in NIL there is the question of whether we want to *define* LENGTH, LAST, etc. to use ATOM tests (which would permit the loser to depend on it), against the possibility that on some NIL implementation a NULL test might be significantly faster than an ATOM check. I would lean toward indeed so defining them to use ATOM, but want to raise that issue.  Date: 27 JUN 1978 1405-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: HIC at MIT-MC CC: (BUG LISP) at MIT-MC It turns out that SXHASH produces the same results for permutations of a single list. ... You're quite alert, but not the first to note this subtle bug. Said mail deluge, "Let's fix this kludge" -- but that we cannot do. The Moonual wise, with all its lies, calls hash a constant screw: However strange, it must not change. What can I do but shrug?  Date: 26 JUN 1978 2312-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC It turns out that SXHASH produces the same results for permutations of a single list. The algorithm: result <-- (rotate[sxhash[car],-1])+(sxhash[cdr]) To be unique under permuations it probably should be: result <-- (sxhash[car])+(rotate[sxhash[cdr],-1]) So?  Date: 26 JUN 1978 2232-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC This idea is from CWH/ALAN (and many others I am sure). I agree, comments? ---------- (1) LENGTH should count the number of conses in a given structure, i.e. (LENGTH '(A B . C)) --> 2. Here is how I think it should behave: (defun length (list) (cond ((atom list) 0) (t (1+ (length (cdr list)))))) (2) LAST should return the last cons in a given structure, i.e. (LAST '(A B . C)) --> (B . C). Here is a definition: (defun last (list) (cond ((atom (cdr list)) list) (t (last (cdr list))))) --------- End of idea.  Date: 26 JUN 1978 1850-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC A suggestion for the LISP (PROBEF '((USR) FOO BAR)) problem: Perhaps there should be a system call: PROBEF Which does the 'right' thing for looking for a file. It would be IDENTICAL to OPEN except that it would set the appropriate device-dependent bits. For DSK, this would be "Don't update reference date" (or similar); for USR, it would be only old job, etc.... How wedged am I?  HIC@MIT-MC 06/26/78 18:44:23 Re: More features for TOPS-10 LISP. To: SUN at MIT-ML, (BUG LISP) at MIT-ML CC: (FILE [SUN;LISP NOTES]) at MIT-MC Again, my responses will be brief until I get more time (I am busily hacking tops-20 right now). MacLISP is designed to run under 5.06B -- A) No interrupt system B) No virtual memory Therefore, many of the things you suggest, though they are definitly winnning ideas, are not practical without MUCH work (which noone has the time to invest right now). The thing that was tried (before I came) was ^C trapping. Apparently, GLS has had bad experience and I can't blame him (Tops-10 can't handle ^C trapping correctly). I don't think it is necessary to send me the interrupt driven tty code (thanks for offering). I have used the software interrupt system and therefore could write the necessary code. When/if Macsyma on tops-10 becomes an issue, it is quite possible that many of your ideas will be implimented (keep sending them!). Thanks for your suggestions and comments (when I get a chance I'll look more closely into some of the issues). --Howard  Date: 26 JUN 1978 1619-EDT From: EAK at MIT-MC (Earl A. Killian) Subject: (PROBEF '((USR) RWK LISP)) To: (BUG ITS) at MIT-MC, (BUG LISP) at MIT-MC, RWK at MIT-MC Perhaps opens on the USR device should work like opens on DSK. I.e. opening for input would never create the job/file, whereas opening for output would. I would think that would be better tahan inverting the sense of the bit.  Date: 26 JUN 1978 1433-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: More features for TOPS-10 LISP. To: SUN at MIT-ML CC: (BUG LISP) at MIT-MC, (FILE [SUN;LISP NOTES]) at MIT-MC The REE control character interrupt kludge seems not to be necessary--it is possible to get TOPS-10 to do interrupts on entering characters using the Software Interrrupt System. ... I suspect that using this would be extremely expensive in practice on TOPS-10, especially those with limited physical memory. Also, this feature may not be available on earlier TOPS-10's (HIC would know about this). Finally, I would hope that it works better than the ^C-trapping kludge, which we tried and which failed miserably. Sorry for being a pessimist -- Quux  SUN@MIT-ML 06/26/78 12:28:35 Re: More features for TOPS-10 LISP. To: (BUG LISP) at MIT-ML CC: (FILE [SUN;LISP NOTES]) at MIT-ML Here's some more stuff for you Howard: The REE control character interrupt kludge seems not to be necessary--it is possible to get TOPS-10 to do interrupts on entering characters using the Software Interrrupt System. A PS.RID happens on I/O completion. If a terminal is opened for terminate on every character (as I assume LISP has to do to termiante on ritght parens and spaces and various other break characters, or are you really just using the 4 break chars you can tell TOPS-10 to break on?) then the interrupt will be signalled on every char. My friend Seldon, whom you met, wrote some code yesterday which does interrupt-driven I/O between two TTY's. If you perhaps want that code (2 pages) just tell me and I'll send it.  Date: 26 JUN 1978 0037-EDT From: RWK at MIT-MC (Robert W. Kerns) To: GLS at MIT-MC, RWK at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC Date: 26 JUN 1978 0028-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC Date: 25 JUN 1978 0701-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (PROBEF '((USR) RWK LISP)) should *NOT* create an inferior! Set the bit! It takes more than just setting the bit - it takes special-casing, and in the face of translations is impossible. The problem is that in general the 1.4 bit has random meaanings on other devices. By a very lucky coincidence that bit is benign, and perhaps even desirable, for PROBEF of the DSK (don't set ref date). But for other devices, who knows what might happen? Sigh. Yes, it takes a CAMN/TRO pair to d this special case check! You're letting that stop you from fixing the bug? I agree that OPEN creating an inferior is in many ways a loss; Probably the meaning of the 1.4 bit should be reversed....but since it is backards in this special case, you need a special case check to give it the right value. There is nothng eivil in using special case checks to handle special cases!  Date: 26 JUN 1978 0036-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: STATUS ARRAY To: KLE at MIT-AI CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC I'm not sure how feasible it is to introduce various zero-cases into the PDP-10 array code, though HIC may wish to stick that on his apparently semi-infinite queue. I would like to see the NIL array implementation, as well as that for the LISP Machine, accommodate any number of axes and any axis length, including zero, subject only to storage limitations and not to random implmentational restrictions. I suppose a rank-zero array, if we follow More's ideas (which seem to be as good as any and better than most), would essentially be a cell, like those in PLASMA. Such cells might be a solution to the flonum-in-special-vallue-cell-without-consing problem?  Date: 26 JUN 1978 0028-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG ITS) at MIT-MC Date: 25 JUN 1978 0701-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (PROBEF '((USR) RWK LISP)) should *NOT* create an inferior! Set the bit! It takes more than just setting the bit - it takes special-casing, and in the face of translations is impossible. The problem is that in general the 1.4 bit has random meaanings on other devices. By a very lucky coincidence that bit is benign, and perhaps even desirable, for PROBEF of the DSK (don't set ref date). But for other devices, who knows what might happen? Sigh.  Date: 25 JUN 1978 1636-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JOHAN at MIT-MC, (BUG LISP) at MIT-MC Date: 25 JUN 1978 0847-EDT From: JOHAN at MIT-MC (Johan de Kleer) To: (BUG LISP) at MIT-MC With ^D set on, the ";GC DUE ...." is followed by a garbled msg. It appears on screen and in DRIBBLE file. Search for "&'0%.;B" is ai:aedes;cascod s for an example. --------- This has been fixed for the next release of lisp.  Date: 25 JUN 1978 0847-EDT From: JOHAN at MIT-MC (Johan de Kleer) To: (BUG LISP) at MIT-MC With ^D set on, the ";GC DUE ...." is followed by a garbled msg. It appears on screen and in DRIBBLE file. Search for "&'0%.;B" is ai:aedes;cascod s for an example.  Date: 25 JUN 1978 0701-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (PROBEF '((USR) RWK LISP)) should *NOT* create an inferior! Set the bit!  Date: 25 JUN 1978 0224-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC CC: NIL at MIT-MC, KMP at MIT-MC, JM at MIT-MC It strikes me that there should be a way in LISP to specify that a certain value locally will be fixnum or flonum. The case arises in Fortran and all sorts of crockish ways have been devised (and (sigh) are being used) to conquer the problem. (ARRAYCALL FIXNUM N 5.) will declare locally that N is a fixnum array -- this is not necessarily the case, but acts as a local declaration to the compiler saying compile a fixnum call the the N array anyway, and screw me if I am wrong. I don't have a similar mechanism however that will cause an efficient compilation of: (LESSP (CAR A) 3.) since I can't declare that (CAR A) is a fixnum. There are several alternatives: [1] As JONL suggested, either by macro or explicitly I could use (LESSP (+ (CAR A)) 3.) which will act as an explicit declaration to the compiler that (CAR A) is fixnum. This is OK, but is an awfully unclean way to go about it. I hope one of these other suggestions will be taken in LISP and/or NIL. [2] Create primitives of the form DECLARE-FIX, DECLARE-FLOAT, etc., which would have the following effect -- in interpreted lisp they could be either something trivial like (LAMBDA (X) X) or something more complex that either did a (LHS X 0.) on it to actually change its type, or did a (LAMBDA (X) (COND ((FIXP X) X) (T (ERR)))) to flag an error if the thing was not the right type -- I am not really concerned with what it does in the interpreter, but hopefully in the compiler something like (LESSP (DECLARE-FIX (CAR A)) 3.) would be converted to (< (CAR A) 3.) [3] An alternative (probably too advanced for MacLISP but maybe not for NIL is something JM brought up - LISP's big weakness is the locality of structure - LIST's lose becuz they are assumed to be completely random in content) would be to allow a declaration of the form (DECLARE (LIST-STRUCTURE (A FIXNUM NOTYPE FIXNUM *))) which would say that A is a list of first element fixnum, second element NOTYPE, third elem FIXNUM, and some optional elements also NO-TYPE following. If the * were omitted it would mean that (LENGTH A) would be compilable as the constant 3, but could still be referenced as (LENGTH A) in the code without loss of efficiency and allowing the user to change his data easily by just modifying the declaration. Choice 2 I would like to see in MacLISP very soon if there are not too many objections. It certainly wouldn't screw anyone's code and would be a very nice feature for me. I would not object if it were even implemented in the compiler as (DEFUN DECLARE-FIX MACRO (X) (LIST '+ (CADR X))) as long as it was not me that had to guarantee its efficiency. For me to be responsible for such a thing means that my software is relying upon a given implementation of the compiler, etc., which I think is non-optimal. Your opinions please? Thanx --kmp  HIC@MIT-MC 06/24/78 20:09:06 Re: STATUS ARRAY To: KLE at MIT-AI, (BUG LISP) at MIT-AI Please talk to me in person about your requests and needs. I am certain that you can be accomodated.  KLE@MIT-AI 06/24/78 17:05:15 Re: STATUS ARRAY To: (BUG LISP) at MIT-AI I am currently in the process of developing a series of extended array functions for the lisp machine and am debugging them in Maclisp due to lack of lisp machines. As I figure these will be generally useful for Maclisp as well I am making them as compatible as possible where reasonable. I would like to request that STATUS become informed about arrays in particular: It should be possible to find out the range of valence (# of dimensions) that an array is allowed to have. Not only the maximum number of axes but the minimum as well. Also it would be nice to know at least the lower limit of the length of an axis: I was very dissapointed to find out that you can not create an empty array in Maclisp on ITS. That is *ARRAY will not allow you to specify the length of an axis for a new arrays as 0 [Can anything be done about this]. Im sure I will find other interesting details as I proceed which are of some reasonable importance to have available, it would be nice if there was some general facility such as (STATUS ARRAY FOO) which had room for expansion as such features were recognized. Thanks --54.  GSB@MIT-ML 06/24/78 14:10:15 Re: (LOAD ()) To: (BUG LISP) at MIT-ML If it is deemed desirably to have a 'null' file to load, then it should be T; passing LOAD an argument of T is one way to screw the lisp, since the namelist of T is ((TTY ) |.LISP.| OUTPUT), and forever after (until that new DSK type tty file gets closed), typing an interrupt character will try to process the interrupt function of a dsk type file... anyway, who ever wants to LOAD the tty?  KLE@MIT-AI 06/24/78 01:47:35 Re: Sharing of LISP jobs. To: ELLEN at MIT-MC, JLK at MIT-MC, JPG at MIT-MC, (BUG HIC) at MIT-MC To: (BUG LISP) at MIT-MC CC: JM at MIT-MC, MRG at MIT-MC, RWK at MIT-MC May I please Add my say also: Why Oh Why Oh Why is BUG-HIC one of the destination mailing lists for this discussion. Believe me folks, HIC really is on the bug-lisp mailing lists and I have been constantly deleting mail in my mail box about a discussion that I have absolutely no concern. I would greatly appreciate it if BUG-HIC were removed from the headers of any further messages as it seems this discussions is liable to carry on for a few millenium. Please restrict your use of BUG-HIC for reporting bugs in HIC and/or adding to the HIC Primer. Thank You --54.  Date: 24 JUN 1978 0031-EDT From: JONL at MIT-MC (Jon L White) Subject: (EQUAL ) To: DRB at MIT-MC CC: (BUG LISP) at MIT-MC, NIL at MIT-MC EQUAL has classically said NO to objects of differing data types (one minor counter to that involves treating the datatype KLUDGE4, KLUDGE8, KLUDGE16, KLUDGE32, and so on as lists if the KLUDGEP swithch is off). So you would have to write your own version of NUMERIC-EQUAL to take account the fact that you want a datum of one numeric datatype to be equal to another kind. E.g., if it is only zero that you are worried about, then hau about (DEFUN N= (X Y) (COND ((OR (NOT (NUMBERP X)) (NOT (NUMBERP Y))) (BARF BARF)) ((ZEROP X) (ZEROP Y)) ((EQUAL X Y)))) Or if you have more intricate involvement, say you want 3.0 to be equal to 3, then hau about something like (DEFUN N= (X Y) (LET ((TX (TYPEP X)) (TY (TYPEP Y))) (COND ((EQ TX TY) (COND ((MEMQ TX '(FIXNUM FLONUM)) (= X Y)) ((EQUAL X Y)))) ((AND (MEMQ TX '(FIXNUM FLONUM)) (MEMQ TY '(FIXNUM FLONUM))) (COND ((EQ TX 'FLONUM) (SETQ Y (FLOAT Y))) (T (SETQ X (FLOAT X)))) (= X Y)) ((EQUAL X Y))))) Remember, flonum equality is bitwise, not in any kind of sense of epsilonics. There are many schemes to try to build the epsilonics into the system, but generally these fail, since the loser can't really escape the effects of limited precision floating point. Systemic attempts to hide it (thru some kind of fuzz factor) give a false sense of security. So if the epsilonics matter in numeric equal, the loser might as well progrma in the test himself, such as e.g. (DEFUN F= (FX FY) (LET ((AFX (ABS FX)) (AFY (ABS FY))) (COND ((< AFX 1.E-30) (< AFY 1.E-30)) ((< AFY 1.E-30) (< AFX 1.E-30)) ((< (//$ (ABS (-$ FX FY)) (+$ AFX AFY)) 1.E-8)))) The two constants could of course be made into globar variables.  Date: 23 JUN 1978 2342-EDT From: JONL at MIT-MC (Jon L White) Subject: (LOAD ()) as NO-OP To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC Well, what argument would you suggest giving to LOAD inorder to do nothing? Its very convenient to have a specifier that more-or-less means the null file, but doesant cause any thrashing about "not found" or "not in mumble format".  Date: 23 JUN 1978 2332-EDT From: DRB at MIT-MC (David R. Barton) To: RLB at MIT-MC, DRB at MIT-MC, (BUG LISP) at MIT-MC Date: 23 JUN 1978 1530-EDT From: RLB at MIT-MC (Richard L. Bryan) To: DRB at MIT-MC, (BUG LISP) at MIT-MC From: DRB at MIT-MC (David R. Barton) (equal 0 0.0) returns NIL. Is there a way to win for checking equality of two lisp numbers, which can be fix, flo, or big? What's wrong with (ZEROP (DIFFERENCE x y)) ? [contagious flonumification] There's a small problem with x being a HUGE bignum and y being a flonum, such that a flonum overflow is generated. Also, it seems like a more efficient check, say for two huge bignums, must exist [?].  GSB@MIT-ML 06/23/78 19:16:14 Re: READ-EVAL-*-PRINT, READ-EVAL-PRINT-*, READ-*-EVAL-PRINT, *-READ-EVAL-PRINT ... To: (BUG LISP) at MIT-ML What lisp needs is some function which will take several arguments and do-the-right-thing, whatever that means, as to read/eval/and-maybe-print; 1) A file or NIL meaning calculate the default one 2) A flag indicating that the value should be printed 3) An EOF indicator, or NIL meaning don't return on EOF but do-the-right-thing; (it should return anyway if a file object was given as argument #1, kind of like read does; it doesn't seem reasonable to pop in input source if the source was specified explicitly) 4) An atomic symbol which says what this call is doing; eg TOPLEVEL, BREAKLEVEL, LOAD, etc. If the call to READ returns an atomic symbol and it has something as its BLECH property, then that is called with some arguments (at least the fourth), and if it returns, that is returned as the result of the READ. This would allow $P to work as before, and allow various other things to be stuck in to, say, give debugging info in a breakloop. If it isn't obvious why it is a bitch not to have this, i will gladly give 4 examples as a starter.  Date: 23 JUN 1978 1857-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: TOPS-10 LISP To: (BUG LISP) at MIT-MC, BAKER at MIT-AI BAKER@MIT-AI 06/23/78 16:51:53 Re: TOPS-10 LISP To: (BUG LISP) at MIT-AI CC: BAKER at MIT-AI How do I TYO non-printing weird characters? ------- Try opening up the tty on another channel in image mode, and then tyoing to that: (SETQ FOO (OPEN '((TTY)) '(OUT IMAGE TTY))) (TYO 177 FOO) this wins on ITS, though I don't know if it has ever been tested on Tops-10. Let me know results (and I will attempt to try it on my version). --Howard  Date: 23 JUN 1978 1817-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: BR at MIT-MC CC: (BUG LISP) at MIT-MC, JPG at MIT-MC BR@MIT-MC 06/22/78 20:53:06 USING (CONTROL)] TO FIND OUT THE RUN TIME VERY OFTEN RESULTS IN THE DESTRUCTION OF THE CALCULATION. TYPICAL MESSAGES ARE LOST USER INTERRUPT OR (LATELY) SOME LONG MESSAGE INVOVLVING FILE SPECS BEING LOST. VERY OFTEN MEANS ONCE OR TWICE A SESSION.... FROM THE USER POINT OF VIEW RATHER OFTEN. I agree that this problem is serious. I have not heard of this occurring for quite some time now previous to your message. Unfortunately this is a LISP bug with LISP's interrupt scheme that is particularly difficult to track down. Perhaps with HIC's help we can devise a breakpoint scheme or something that would make it easier to debug this when it occurs.  Date: 23 JUN 1978 1752-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: BEE at MIT-MC CC: (BUG LISP) at MIT-MC, MRG at MIT-MC, JLK at MIT-MC, ELLEN at MIT-MC CC: JM at MIT-MC I already discussed and vetoed BEE's plan. How does one ascertain that a LISP is winning and that a MACSYMA will win in a new LISP? Almost every new LISP necessitates changes in MACSYMA to work in it. I also am getting very tired of this discussion, and agree with BEE: Let's drop it.  Date: 23 JUN 1978 1744-EDT From: BEE at MIT-MC (Bruce E. Edwards) To: JPG at MIT-MC, ELLEN at MIT-MC, (BUG LISP) at MIT-MC, JM at MIT-MC To: MRG at MIT-MC, RWK at MIT-MC Can we put an end to this inane discussion. I propose a solution, and people can complain to me if they disagree. 1) the lisp that the current macsyma is dumped in has a pointer to it as ts MLISP on sys2; 2) when a macsyma is dumped, the function that reads in the fasl's that comprise the macsyma are copied to the MFASL; directory which will be created 3) There is a loader function that loads all the fasls from the MFASL directory. This makes it simple to bring up the "OLD MACSYMA" in a new lisp as soon as it is ascertained to win. I believe this meets all peoples' points, and should not cause any inconvenience to JPG.  Date: 23 JUN 1978 1741-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC CC: CWH at MIT-MC, DRB at MIT-MC READ-*-EVAL-PRINT and READ-EVAL-*-PRINT seem to be pretty much of a win. I would like to a see a READ-EVAL-PRINT-* appear soon as well. Perhaps a more winning idea would be to create READ-*-PRINT, READ-EVAL-*, etc. This would allow greater control over the interpreter, yet would enable all of the hacks the current scheme allows. For example, there is no simple way to turn off a PRINT occuring during each cycle of the loop, although one can pass it an argument and give it a PRIN1 function to use. The READ-EVAL-* scheme would allow us to do this, yet would enable retaining the PRINT simpliy by putting it in the function which is the value of READ-EVAL-*. I have more ideas on this if you are interested. Now for the gripes: I think that the symbols READ-*-EVAL-PRINT, READ-EVAL-*-PRINT, and PRIN1 should be bound to NIL whenever an error or breakpoint occurs, much in the same manner as READTABLE gets bound to the initial readtable array pointer. I have been having problems finding errors in functions used as values of PRIN1 since the error will occur again as the interpreter attempts to print the error message, and so on.  Date: 23 JUN 1978 1740-EDT From: ELLEN at MIT-MC (V. Ellen Lewis) Subject: Sharing of LISP jobs. To: JLK at MIT-MC, JPG at MIT-MC, (BUG HIC) at MIT-MC To: (BUG LISP) at MIT-MC CC: JM at MIT-MC, MRG at MIT-MC, RWK at MIT-MC May I add my 2 cents worth? What are we worried about? LISP per se is hardly ever run on MC. The only thing, and I guess the thing JLK is concerned about, that runs in LISP is the GLPTR. This is a system for MACSYMA, after all. There is a file on LIBLSP or LIBDOC called LOCK > which has a record of what version of LISP things run in. MACSYMA is listed therein. Users do not dump out subsystems on this system, hackers do. Hackers should have no trouble explicitly loading a LISP version (even I know how to do that!). So the people who dump out GLPTR should dump it in the same version MACSYMA is dumped in. Since MACSYMAs are created only with reasonable frequency, the number of times a GLPTR needed to be redumped to match MACSYMA would be minimal. Not dumping out MACSYMAs very often is good policy from a User point of view, since (modulo the need for bug fixes) Users like something that does not change. PUlling the rug out from underneath users every week or so is obviously not a good thing. And as one further note, JM has told me several times that what really slows MC down with swapping is not MACSYMA but the text editors. (maybe that was 6 cents worth).  Date: 23 JUN 1978 1719-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC HAU ABAUT letting (LOAD ()) be a NO-OP? right now, it is the same as (LOAD (DEFAULTF ())) What is the rationale behind this change?  BAKER@MIT-AI 06/23/78 16:51:53 Re: TOPS-10 LISP To: (BUG LISP) at MIT-AI CC: BAKER at MIT-AI How do I TYO non-printing weird characters? Things like 126., 127. get eaten up and not transmitted to the terminal. Control characters don't get printed out as "^x", but many are interpreted (like tab). Others, such as ^_ are eaten and not sent out. Perhaps TYO should use TTYCALL 15 (IONEOU) to output characters, if not all the time, then perhaps under control of some "image-mode" switch.  Date: 23 JUN 1978 1538-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: JLK at MIT-MC CC: (BUG LISP) at MIT-MC, JM at MIT-MC, BEE at MIT-MC, MRG at MIT-MC CC: RWK at MIT-MC I don't understand this distinction between OLD FASL files and NEW FASL files. There is only one set of FASL files on the MACSYM; directory, and, say, a month after creating a MACSYMA release these FASL files are useless as they are no longer guaranteed to be the same FASL files in existence a month previous. Furthermore, the idea that I am going to dump out a new release MACSYMA in a later LISP without extensive testing horrifies me.  Date: 23 JUN 1978 1530-EDT From: RLB at MIT-MC (Richard L. Bryan) To: DRB at MIT-MC, (BUG LISP) at MIT-MC From: DRB at MIT-MC (David R. Barton) (equal 0 0.0) returns NIL. Is there a way to win for checking equality of two lisp numbers, which can be fix, flo, or big? What's wrong with (ZEROP (DIFFERENCE x y)) ? [contagious flonumification]  Date: 23 JUN 1978 1422-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC If the second arg to displace is a symbol x, then the first arg should be displaced with (progn x), rather than taking the car and cdr of the symbol.  SUN@MIT-ML 06/23/78 14:17:44 To: (BUG LISP) at MIT-ML Well declare part of my previous message inoperative. I have realized the STATUS and SSTATUS do work fine on the TTY and that the bits being displayed/modified are the GL. bits which are probably being set by LISP with TTCALL GETLCH/SETLCH. However there are still the IO. bits.  Date: 23 JUN 1978 1401-EDT From: DRB at MIT-MC (David R. Barton) To: (BUG LISP) at MIT-MC CC: DRB at MIT-MC (equal 0 0.0) returns NIL. Is there a way to win for checking equality of two lisp numbers, which can be fix, flo, or big?  SUN@MIT-ML 06/23/78 11:48:36 To: (BUG LISP) at MIT-ML Two more things. 1) The i/o bits on TOPS-10 do tell if a terminal is a display. Thus rubout processing could be done correctly. 2) On ITS, I just had difficulty opening a secondary tty. (open '|t26:| 'tty) worked while (open '((t26)) 'tty) failed. Seems it didn't like the namelist.  SUN@MIT-ML 06/23/78 10:51:01 To: (BUG LISP) at MIT-ML CC: (FILE [SUN;LISP NOTES]) at MIT-ML Well here I am with some more comments on exercising the TOPS-10 LISP. I've been doing some hacking with multiple TTY's and was using LISP before I wrote stuff in MACRO and FORTRAN. I seem to have found a few things which seem to be doable on TOPS-10 but which LISP doesn't do. 1) When I opened up a secondary TTY, it was not a TTY but a block dsk file to the LISP. This makes single character input and use of LISTEN difficult (hyperbole or should I say hypobole). Is this perhaps due to the fact that LISP is using TTCALLs rather than the newer TRMOP uuo. TRMOP can do anything possilbe to any TTY. 2) A similar deficiency is that STATUS and SSTATUS TTY seem wanted to turn off echoing on input and couldn't (that is done with use of the STATUS TTY on ITS, isn't it?). On TOPS-10 all those bits which I think are the GL. and IO. bits, should be accessable with the TTCALLs GETLCH and SETLCH and with the uuos GETSTS and SETSTS. 3) When I couldn't do a LISTEN from the secondary TTY, I tried to do an alarmclock hack but found taht that wasn't there. PISYS software interrupts can't be used for that? I note taht the SYSTEM-DEATH interrupt could use .PCKSY. The system interrupts are supposed to get better ith 7.01 next year. The LISP shold be aimed at 6.03 for now. Do you guys have a 6.03 manual by the way. 4) Is it really true that binary program space can only be allocaonce at the beginning even if one is running the LISP under a 6.03 with the VM option on a KI or KL?? 5) Is the fact that there is no SYSCALL subr doe to the fact that TOPS-10 has such an erratic calling sequences for its uuos? Oh well, I'm enjoying doing the testout. Communicate any comments or questions. [The missing line above after 2) shold read: "not to produce anything meaningful. I" ] bye.  Date: 23 JUN 1978 1013-EDT From: JLK at MIT-MC (John L. Kulp) Subject: Sharing of LISP jobs. To: JPG at MIT-MC, (BUG HIC) at MIT-MC, (BUG LISP) at MIT-MC CC: JM at MIT-MC, MRG at MIT-MC, RWK at MIT-MC You are not making a distinction between dumping out a MACSYMA in a new LISP with OLD fasl files, versus dumping out a new MACSYMA made of new FASL files. Assuming HIC has done his job of thoroughly testing the new LISP, you should not encounter difficulties dumping an old MACSYMA in a new LISP. If you do, the new LISP should probably be deinstalled. The exception to this is, of course, incompatible LISP changes. These tend to be few and far between, and are therefore not interesting. My main point is that if we do not want SPOOLR's and COMPLR's completely thrashing against MACSYMA's, this issue is important. I would think that it would be in the interest of MACSYMA that you encourage sharing of LISPs between such systems. If you feel it is not important, then I will not bother concerning myself with the issue.  Date: 23 JUN 1978 0232-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JONL at MIT-MC, (BUG LISP) at MIT-MC Date: 23 JUN 1978 0226-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC HAU ABAUT letting (LOAD ()) be a NO-OP? right now, it is the same as (LOAD (DEFAULTF ())) -------- For next release of LISP, LOAD will return nil if its arg is ().  Date: 23 JUN 1978 0226-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC HAU ABAUT letting (LOAD ()) be a NO-OP? right now, it is the same as (LOAD (DEFAULTF ()))  Date: 23 JUN 1978 0137-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JONL at MIT-MC, (BUG LISP) at MIT-MC Date: 23 JUN 1978 0136-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC The world was just cheated, because a suspend with second arg clobbered the existing SYS;CL.DMP 786 before it successfully dumped out the new one. And of course the dump failed due to lack of dsk space. -------- This bug has been fixed in the source. A temporary file is used and a RENMWO is done.  Date: 23 JUN 1978 0136-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC The world was just cheated, because a suspend with second arg clobbered the existing SYS;CL.DMP 786 before it successfully dumped out the new one. And of course the dump failed due to lack of dsk space.  Date: 22 JUN 1978 2005-EDT From: JPG at MIT-MC (Jeffrey P. Golden) Subject: Sharing of LISP jobs. To: (BUG HIC) at MIT-MC, (BUG LISP) at MIT-MC, JLK at MIT-MC CC: JM at MIT-MC, MRG at MIT-MC, RWK at MIT-MC Whereas I agree that sharing amongst LISP jobs is important, I do not care for JLK's proposed solutions. [1] :L, :LISP SHOULD be used for the most recent LISP. This would greatly aid development of programs, of which LISP is one, and encourage usage and testing of the changes in LISP. It is essential that a LISP be tested out before a MACSYMA to be released is dumped in it, and I see of no better way than to call it "L" or "LISP". [2] We have long ago determined that a user, released system such as MACSYMA should not be dumped out frequently, as this is the way to make it stable and reliable, and make it possible for users to cope with changes and bugs. Furthermore, a new MACSYMA undergoes thorough testing before release and this occupies a good deal of my time and others' time. [3] For the best development, systems such as LISP and MACSYMA should be released when most appropriate to their development. Anyway, there might very well be a new MACSYMA soon.  Date: 22 JUN 1978 1424-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG HIC) at MIT-MC, (BUG LISP) at MIT-MC, (BUG MACSYM) at MIT-MC I can see no one is attempting to encourage sharing of LISP jobs. MACSYMA is in LISP 1513 and there is no link of any flavor of LISP to that LISP version. I think it is unreasonable to expect other lisp users to grovel around searching for random PURQIO's to load in order not to gronk MC. :L and :LISP should ALWAYS get you the same LISP as MACSYMA is dumped in. :NLISP or whatever should be used for the most recent LISP. And OLISP should be the previous :LISP (by implication being the LISP that OMAXIM is dumped in). The alternative is to encourage JPG to dump out MACSYMA's more frequently, and HIC to install LISP's no more than once a week...  Date: 22 JUN 1978 1019-EDT From: JLK at MIT-MC (John L. Kulp) To: RMS at MIT-AI CC: (BUG LISP) at MIT-MC LISP people have not yet converted to the scheme of having LISP autoloads default to the LIBLSP directory, or LSPSYS or whatever it will be. As soon as they do, the links on COMMON; could certainly be flushed. In any case, the autoload property for INF-EDIT should be LIBLSP;.  Date: 22 JUN 1978 0416-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Something that has been TYIPEEK'd at doesn't seem to get redisplayed with ^L -- example: (PROGN (TYIPEEK) (READ))ABC^K BC --sigh? ...kmp  Date: 21 JUN 1978 2143-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: DLW at MIT-AI (SLEEP 1.0.) Reads 'correctly' (i.e., without read macro error) but gives an error ((SLEEP 1.0 NIL) (NIL . 1)) TOO MANY ARGS SUPPLIED Sigh.  Date: 21 JUN 1978 2030-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Compiler/Interpreter problems To: SJOBRG at MIT-AI CC: (BUG LISP) at MIT-MC SJOBRG@MIT-AI 06/20/78 08:47:16 Re: Compiler/Interpreter problems To: HIC at MIT-AI The file FCBUG > on my directory was compiled with the new compiler, using _FCBUG > (FKEX) There were no obvious problems with the compilation itself (ie, no messages). But when I start up a Lisp environment and try to LOAD or FASLOAD the fasl file, I get the following: ;(FASLOAD (DSK SJOBRG) FCBUG BUG) FILE NOT IN FASLOAD FORMAT ;(#100) NIL CLOBBERED ------ It turns out that the compiler did give you an error (look in FCBUG UNFASL to see it). The particular error, though, apparently generated a bad fasl file, causing the FILE NOT IN FASL FORMAT error...but, some new code in LISP clobbered nil before detecting this error. The next release of LISP will check for the error condition before bashing NIL! The compiler error, though, is for JONL.... --Howard (p.s. I am done with FCBUG stuff, thanks, and you may kill it at your leisure after looking at the unfasl)  Date: 21 JUN 1978 2014-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, RPG at SU-AI Date: 21 Jun 1978 1021-PDT From: RPG at SU-AI (Dick Gabriel) There's still a screw in the hiseg stuff. Namely, consider this protocol: r nlisp ru mumble in this case we end up with two people with the same hiseg although one guy is changing it. This was why in the oldio version we named the hiseg nnnlsp shifted - so that no one else could attach to it. The ------- Well, the code from OLDIO was being used, but it was wrong in the fasload case (perhaps I brooke it at some time, but I don't recall doing so.). In any case, it should now not have that lossage. The other remaining thing to do with NEWIO (other than to fix bugs) is to add the alarmclock stuff which I didn't put in at my first pass over the interrupt system. I also need to test the interrupt system thouroughly. --Howard  Date: 21 Jun 1978 1154-PDT From: GLS at SU-AI (Guy Steele) Subject: Local function bindings To: nil at MIT-MC CC: bug-lisp at MIT-MC It has occurred to me that the distinction of local/dynamic and the distinction of function cell/vale cell are orthogonal. Moreover, I think I may have an application for local function cells: to make a macro which temporarily and locally changes the meanings of names of functions. The locality is important, so that a compiler can determine what is going on. (Indeed, an unresolved dilemma is how to tell the compiler that some global functon reference is to a function cell that someone else may bind dynamically. I suppose we need a declaration for this.) I therefore propose that NIL permit the local binding of function cells. This is indeed one more thing for the interpreter to keep track of, but in the usual case the local function environment will be empty anyway, and so can be checked quickly. -------  Date: 21 Jun 1978 1136-PDT From: GLS at SU-AI (Guy Steele) Subject: TYPECASEQ and the Type Hierarchy To: nil at MIT-MC CC: bug-lisp at MIT-MC I recommend the introduction of a TYPECASEQ (CASET? but that parses also as C-ASET or CA-SET) construction. The advantage of it over simply (CASEQ (TYPEP ...) ...) is that it can permit the use of names for sets of types, the precise components of which the user is not concerned with (and indeed may not want to be concerned with for reasons of transportability). It is interesting to consider the hierarchy of data types in NIL; here is a picture (somewhat incomplete, and the names may not be the preferred ones): OBJECT / \ / \ ATOM LIST / \ / \ / \ / \ ------------------------- SELFLIST PAIR (or CONS) | | | | | | \ ARRAY | SYMBOL | CHARACTER () others | | VECTOR NUMBER / | \ / | \ STRING | etc FIX | COMPLEX BIT / | FLOAT | \ INUM | | \ PLAIN BIG BIGNUM | \ FLONUM BIGFLOAT There are many other interesting relationships not shown here; one might divide the types into INOB and STOB; also there ought to be a word for a non-selflist atom. Anyway, the point is that it is not a tree, but a partial order. Using these names, one might write: (TYPECASEQ FOO ((NUMBER) ) ((SYMBOL CHARACTER) ) ((LIST SEXPVEC) ) (T )) Now it might be convenient to permit the categories named not to be mutually exclusive, but to permit some overlap. This would make it easy to specify exceptions; e.g. for FIX numbers to go one way, and all other numbers, whatever they may be, another way. I suggest the discipline that overlap be allowed between two categories only if one is a strict superset of the other, and then it is the branch for the latter that is chosen. (This prevents confusion in the case of, e.g., (TYPECASEQ '() ((ATOM) ...) ((LIST) ...)).) As for implementation, this can be made a macro provided that the macro is aware of all the types and categories and their relationships, and expands the clauses into a CASEQ on TYPEP (or whatever). The macro would check for the superset relationship among categories, and then expand all categories into their lowest-level constituents. It is likely that the types and categories distinguishable by TYPECASEQ would extend below the level of the main type code, and so the macro expansion may want to be trickier than what I have outlined. The implementation, whether as macro or fexpr, is likely to be machine-dependent because it may know about low-level types, and so it is desirable to institutionalize it in the language. Indeed, its expansion could involve a numeric CASEQ on the primitive storage data type, lending it speed when compiled. -------  Date: 21 JUN 1978 1320-EDT From: JONL at MIT-MC (Jon L White) Subject: QMARK To: HIC at MIT-MC CC: KMP at MIT-MC, (BUG LISP) at MIT-MC sounds like the atom should be "?" rathern than "QMARK", and that it should not be on the obarray. This is primarly a hac for the SUBR function, so that BAKTRACE (which implicitly uses SUBR) and others can take a code-address and determine which subroutine it is in. Of course, with multiple obarrays, this is merely a guess, since it operates by grovelling over all the current obarray.  Date: 21 JUN 1978 0343-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, RPG at SU-AI The second argument to suspend now seems to work fine in SAIL NEWIO. I built a pure compiler and it also seems to win. (version 708 in 703, which was the one on [MAC,LSP] on SAIL). --Howard  Date: 20 JUN 1978 2315-EDT From: HIC at MIT-MC (Howard I. Cannon) To: KMP at MIT-MC, (BUG LISP) at MIT-MC QMARK subr was added to allow baktrace to find it as the last system subr in case a wierd pointer was on the stack.  Date: 20 JUN 1978 2313-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Clarification of my earlier note to bug-lisp, since GLS thinks I was unclear. (Apologies to GLS for having to hear this twice.) Only thing is that if I snarf some lisp function and put it on something in my fortran->lisp translator for instance, I don't want to read a fortran program and alias an atom to something else on the basis of whether it conflicts with code in the translator environment, i want to do aliasing for things that will conflict with system names in a bare lisp environment! This doesn't happen, but I conceive this as one of the main uses of the SYSP function -- i.e., by an environment that is hacking things like compiling, translating, etc., and usually one that doesn't want its personal environemnt to get mixed up with the real one it is preparing things for.  Date: 20 JUN 1978 2308-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: Labelled PROGs (and DOs) To: JONL at MIT-MC, (BUG LISP) at MIT-MC CC: NIL at MIT-MC ... could find all instances of (RETURN . . . ) for n > 1, and convert them to (MRETURN 'prog_id . . .) Do you really mean for MRETURN to take an evaluated prog_id? Since GO does not, maybe it's a typo?  Date: 20 JUN 1978 2255-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 20 JUN 1978 2252-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (SETPLIST 'GARBAGE (PLIST ')) (AUTOLOAD (INDEX FASL COM)) (SYSP 'GARBAGE) AUTOLOAD ...sigh. I think it should base on some canonical list of what the initial atoms of the system are ... the above seems to be non-optimal (also meaningless in the case of an AUTOLOAD, but SUBR's that have been snarfed don't seem like they oughta be SYSP. --kmp The SYSP'ness is a property of the SUBR (i.e. of the code), not of the atomic symbol which happens to name it.  Date: 20 JUN 1978 2252-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (SETPLIST 'GARBAGE (PLIST ')) (AUTOLOAD (INDEX FASL COM)) (SYSP 'GARBAGE) AUTOLOAD ...sigh. I think it should base on some canonical list of what the initial atoms of the system are ... the above seems to be non-optimal (also meaningless in the case of an AUTOLOAD, but SUBR's that have been snarfed don't seem like they oughta be SYSP. --kmp  Date: 20 JUN 1978 2238-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Loading one of my files is now getting a Fasload-ish message saying that I am redefining some system function called QMARK. As far as I can tell, (QMARK) returns the atom "?" ... sigh. What is it for?  Date: 20 JUN 1978 1858-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC CC: JM at MIT-MC, MRG at MIT-MC, JPG at MIT-MC, KMP at MIT-MC MRG, JM, and myself discussed the problem of COMPLEX and DOUBLE precision this morning, and came to the conclusion that 1) COMPLEX with arbitrary-valued components are what is required, and the operations on two complices will have to be done with the generic rational operations (since BIGNUMs or FLONUM could occur). This seems to be acceptible especially since we are not now planning to open-compile the COMPLEX arithmetic. For a discussion why, see me. 2) On all new machines, there will be only one FLONUM type, namely what the machine will reasonably support. Generally this means 50 to 100 bits. Whatever is less is generally unsatisfactory, and all new winning machines do floating-point operations on quantities of this size just as fast as on smaller-sized operands (modulo a little epsilon). The retrofit to the KL10 for this would probalby take about 4-6 man months since it would mean completely changeing the FLONUM format; and even though this could be done in a way that only wasted space (the second word would merely be a waste on the KA10s since they dont really have Doubleprecision instructions - the loader having converted from DFBSR to FBSR) we still dont think the retrofit is worth it. So for the PDP10 series we will admit the new data type DOUBLE, which will be closed-compiled. At least some of the benefit of the KL10 floating-point hardware will be realized. Since standard flonums will compile as at present, then most of the IMSL stuff will still compile adequately.  Date: 20 JUN 1978 1829-EDT From: JONL at MIT-MC (Jon L White) Subject: RMS and the problem of macro-expansion during compilation To: (BUG LISP) at MIT-MC Indeed, as GLS says 19 JUN 1978 1919-EDT, **if** the DISPLACE/DISPLACED scheme were to become instutionalized, the compiler could hack it specially. But it still could not know whether the result was macro-produced or original native code. This problem does concern several people (see PSZ@ML, RICH@AI) who have alternative shcemes for macro-expansion management. After having talked with RICH for some time, I agree that all of these schemes are good for their purpose, and we probably cant institutionalize any one of them now. But, DISPLACE is another matter, for **all** of the other schemes use a simple-minded SUBR DISPLACE. As to users being consternated at the multiple expansion of macros during compilation (for whatever purpose), there are some who have clever macros with weird side effects, (and memoizing is one side effect) among whom is KEN@AI. May I also take this opportunity again to remind the community that my mail file is growing exponentially since my re-arrival in cambridge. A short glance at my directory seems to indicate that I receive as many characters every two weeks now as I did the entire first quarter. PLEASE, try not to resend a big piece of mail when you reply to a point; can the point be made clear with a few words? could it be understood from the (local) context of the LISP MAIL file? Especially ludicrous is the reply to reply to reply . . . that includes a copy of all previous correspondence. This is n-squared in the number of replies, and there are probably 30 people who receive this junk. All of this applies to the LISP MAIL file equally.  Date: 20 JUN 1978 1813-EDT From: JONL at MIT-MC (Jon L White) Subject: Labelled PROGs (and DOs) To: (BUG LISP) at MIT-MC CC: NIL at MIT-MC The suggestion has come to me recently to use as an identifying label for a PROG merely the first prog label in that prog. This is completely retrofittable without any worry for existing code, and since it is attacking a lexical problem, there is no need to worry about "what if some one wants to name one PROG 'foo' and has another PROG with a tag 'foo' . . .". For example, the prog (PROG (X Y) FOO (SETQ X (MUMBLE)) . . . (RETURN Y)) CAN EASILY BE TRANSFORMED, AT ANY TIME, TO (PROG (X Y) UNIQUE-LABEL-1 FOO (SETQ X (MUMBLE)) ... (DO < ... > (GO UNIQUE-LABLE-1)) (RETURN Y)) Thus I propose to extend the syntax of GO as follows 1) flush computed GOs, possibly introducing a new primitive for this [foolish] purpose, and advertising CASEQ 2) permitting an identifying tag as second arg, which would uniquely identify the prog level at which to GO Also the same point as (2) would be done for RETURN, thereby causing the multiple-return mechanism to have another name and format. This is acceptable, since it doesn't involve any large body of existing code (such as for the PDP10), and on the LISPM, if such a decision were made, then probably a TECO macro could find all instances of (RETURN . . . ) for n > 1, and convert them to (MRETURN 'prog_id . . .)  Date: 19 JUN 1978 2322-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: NIL at MIT-MC, (BUG LISP) at MIT-MC I have read NIL;SHAPE >. COncurrently, I had been writing a tentative list of data types for NIL/S1 (say, what are we really going to call the NIL variants anyway??), which I have FTP'd over as NIL;DTYPES S1. Comments solicited. -- Quux  DDM@MIT-AI 06/19/78 22:05:53 To: (BUG LISP) at MIT-AI Could someone please remind me what the good reason was that precipitated the flushing of implicit calls like this: (defun bar () ...) (setq foo 'bar) (foo ...) I'm beginning to miss them. tnx. Dave McDonald  Date: 19 Jun 1978 1654-PDT From: GLS at SU-AI (Guy Steele) Subject: "Inline-able" To: bug-lisp at MIT-MC, nil at MIT-MC I object to the introduction of the jargon "inline-able" into the language. While it is fine for internal use, it is one more thing to have to explain to the outside world. Moreover, it is syntactically incorrect, for "inline" (or rather, "in-line") is not a verb. Finally, it is a misnomer: ANY expr is potentially integrable (the standard term, though I don't much like it either), and the use of DEFUN-ILE or whatever serves merely as advice to the compiler that such integration is *desirable* rather than *possible*. Indeed, it may be useful to have a form of local declaration (which logically ought to be called INTEGRATE, but that has obvious drawbacks!) which would specify that the code for given procedures is to be integrated where referenced in the scope of the declaration. While I recall having earlier been convinced that this declared property should be attached to the procedure and not to its name, now I am not so sure. -------  Date: 19 JUN 1978 1919-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: RMS To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC Date: 17 JUN 1978 1449-EDT From: JONL at MIT-MC (Jon L White) Subject: RMS To: (BUG LISP) at MIT-MC The poooooor compiler must intercept any flavor of DISPLACE and imitate it without actually doing the RPLAC's, but rather by copying. The reason is that ocasionally the complr likes to "back-up", and any munging of the original code (as read in) would be bad. Even if there are multiple pointers to a given cell in code, it would not be bad to run the macro expander twice or more, since the macro-expansion occurs only once per instance in code (rather than once per use in normal lisp running enviromnent). Apparently the expansion of macros more than once (due to the "backing-up") has caused some consternation to some people, so it is apparently something a compiler user will have to live with, or else use read-time macros (instead of eval-time macros which BLAIR calls "meta-composition"). It seems to me that the compiler could back up properly by noticing the DISPLACED form, if DISPLACE/DISPLACED were institutionalized. On the othher hand, there are other goood reasons why re-performing a macro shouldn't cause screewwage.  Date: 19 JUN 1978 1853-EDT From: GLS at MIT-MC (Guy L. Steele, Jr.) To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC Date: 19 JUN 1978 0730-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC It would probably be a win if SORT would not set the thing you pass it until it knows if the predicate you have given it wins. Case in point: (SETQ I (SORT I 'ALPHLESSP)) ;ALPHLESSP UNDEFINED FUNCTION OBJECT ;BKPT UDF-FNC-OBJ ^G QUIT I (B) Apparently you immediately have the thing passed get re-assigned in some way, but could you leave the original list intact until at least one check is done? (If this would be grossly inefficient, then don't worry about it, but if it is not, then you would probably save some people like me occasional grief - I expect it to clobber my list, but that's ok if I have new list to play with -- in this case however am left with nothing -- yes, i should have defined the function while in the breakpoint, but I didn't think I would get scrod if I just aborted and started over spelling it right. Sigh.) --kmp The answer is that if you aren't sure, you should make a copy of the list ifrst.  Date: 19 JUN 1978 0730-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC It would probably be a win if SORT would not set the thing you pass it until it knows if the predicate you have given it wins. Case in point: (SETQ I (SORT I 'ALPHLESSP)) ;ALPHLESSP UNDEFINED FUNCTION OBJECT ;BKPT UDF-FNC-OBJ ^G QUIT I (B) Apparently you immediately have the thing passed get re-assigned in some way, but could you leave the original list intact until at least one check is done? (If this would be grossly inefficient, then don't worry about it, but if it is not, then you would probably save some people like me occasional grief - I expect it to clobber my list, but that's ok if I have new list to play with -- in this case however am left with nothing -- yes, i should have defined the function while in the breakpoint, but I didn't think I would get scrod if I just aborted and started over spelling it right. Sigh.) --kmp  HIC@MIT-MC 06/19/78 07:15:48 GSB@MIT-ML 06/19/78 07:11:45 Re: Proposed change to ARRAYDIMS To: HIC at MIT-MC From: HIC at MIT-MC (Howard I. Cannon) Subject: Proposed change to ARRAYDIMS Proposed change to ARRAYDIMS: Currently, ARRAYDIMS returns (T ...) for any array S-expression array, including those which were created with NIL. Are there any objections to changing ARRAYDIMS to return NIL if the array was created with NIL as its type? Interesting, i was under the impression that that was what it was supposed to do, and did... obviously, i haven't used NIL type arrays in a while. It certainly should return NIL as the type.  MILLER@MIT-AI 06/19/78 06:18:32 Re: Getddtsym To: HIC at MIT-MC CC: (BUG LISP) at MIT-AI, MILLER at MIT-AI thanks. -- mark  Date: 19 JUN 1978 0255-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: NAMESTRINGS To: KMP at MIT-MC, (BUG LISP) at MIT-MC Quoted spaces were not handled correctly -- this has been fixed in the source.  Date: 19 JUN 1978 0244-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, JOHAN at MIT-AI JOHAN@MIT-AI 06/14/78 13:43:49 To: (BUG LISP) at MIT-AI ^x inside a break point seems to lose input stream. -------- I am sorry to say that I don't understand what you mean....could you please give specific example? Thanks, Howard  Date: 19 JUN 1978 0243-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Getddtsym To: (BUG LISP) at MIT-MC, MILLER at MIT-AI MILLER@MIT-AI 06/15/78 05:34:04 Re: Getddtsym To: (BUG LISP) at MIT-AI Apologies: besides GETCOR and SACONS, CFIX1 and 2DIMF are needed for TK-TV graphics if loading symbols is to be avoided. I think that's really it this time. Do you mind adding those, too? -- Mark ------ These have been added in the source and will be available in the next released LISP....  Date: 19 JUN 1978 0154-EDT From: MOON at MIT-MC (David A. Moon) Subject: Lisp suddenly reading RMAIL To: KMP at MIT-MC, (BUG LISP) at MIT-MC CC: (BUG DDT) at MIT-MC I doubt that this really happened. Probably PEEK somehow was confused. That seems more probable than Lisp reading such a file for no reason.  Date: 19 JUN 1978 0115-EDT From: HIC at MIT-MC (Howard I. Cannon) To: JONL at MIT-MC, (BUG LISP) at MIT-MC CC: KMP at MIT-MC Date: 17 JUN 1978 2238-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC SYSP fails to give the right answer for any of the AUTOLOADable functions (like GETMIDASOP, SORT, SPRINTER etc.) because if they are already loaded, then SYSP is faked out by the SUBR property in BPORG space. It should first look for an AUTOLOAD property, and if found, determine if that is SYSP (according to the prior definition.) ------- If the SUBR has a system autoload property, then AUTOLOAD will be returned even if there is a SUBR property. This is in the source.  Date: 19 JUN 1978 0058-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC, GSB at MIT-ML GSB@MIT-ML 06/16/78 07:06:02 To: (BUG LISP) at MIT-ML suspend with 2 args should open some dummy name and do a renmwo when done; any device which will support pdump is certainly going to support that. -------- Fixed in source.  Date: 19 JUN 1978 0052-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: Proposed change to ARRAYDIMS To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, JPG at MIT-MC To: MRG at MIT-MC, DRB at MIT-MC, GSB at MIT-MC Proposed change to ARRAYDIMS: Currently, ARRAYDIMS returns (T ...) for any array S-expression array, including those which were created with NIL. Are there any objections to changing ARRAYDIMS to return NIL if the array was created with NIL as its type?  Date: 19 JUN 1978 0027-EDT From: HIC at MIT-MC (Howard I. Cannon) Subject: GC printing out garbage To: (BUG LISP) at MIT-MC, GSB at MIT-ML GSB@MIT-ML 06/16/78 06:44:05 Re: GC printing out garbage To: (BUG LISP) at MIT-ML is coming from inside of the STGPNT routine inside the GCPNT2 loop. What happens is that IFORCE clobbers F - STRT saves it, so that never cause any problems; it only happens when IFORCE gets entered while the gc is printing one of the numbers (either the words free or the percent-free.) ---------- Fixed in the source. Thanks for your analysis.  Date: 18 JUN 1978 1744-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC LISP;BUG MAIL has been renamed to LISP;BUG 2 A new BUG MAIL file has been started.