Date: 16 JUL 1980 1639-EDT From: JONL at MIT-MC (Jon L White) Subject: Getting to the bottome of it To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, PSZ at MIT-MC Date: 14 July 1980 12:05-EDT From: George J. Carrette Subject: suggested compiler feature. (compiler-unwind-protect
) The semantics of this are simple, during alpha conversion is the expression which is the *value*, but the are evaluated even if the alpha conversion of causes some error. My opinion: Can't hurt anyone, and probably useful to some. Next case, please. Also: atomic-macro-of-the-first-kind. Which would have the following actions given that has such a property: A free => (setq X) => (setf (expansion of FOO> X) ((lambda () ) X) => dissables the macro property of during the expansion of . i.e. LAMBDA is a truely transparent. If one wants to (BIND (( ...)) ...) then some special BIND form must be used. This is of course incompatible with the existing semantics of special variables, but perhaps special variables should be changed. One motivation: for these things in maclisp and lmlisp is an implementation of closures with lexically scoped instance variables. Be careful of letting a giant into the house to swat a fly. I share the general skeptcism shown by PSZ and ALAN about this feature, particularly since it looks an awful lot like the discredited idea of READER symbol macros. Almost all good from the latter can be accomplished by the READER character macro idea -- case in point is QUUX's suggestion a year or two ago to use things like &#FOO to mean things like an instance of the variable FOO, but with various declarations available for various values of the character "#". (e.g., &%FOO might mean "LOCAL" by having LAMBDA-list processing look for things like "(&LOCAL FOO)" whereever a variable is permitted). But more to the point: Writing things like (DEFUN FOO (x) (DECLARE (ACTOR x VAR1 VAR2 ...)) (LIST VAR1 VAR2)) is a little more tasteful than (DEFUN FOO (x) (LIST (INSTANCE-MACRO x VAR1) (INSTANCE-MACRO x VAR2))) but the right way to accomplish the former is not by admitting any kind of atomic-macros (as PSZ said, "let hear the case for atomic-macros" -- I don't think local closures is that case). RWK wrote a transformation package to accomplish this kind of conversion in MACLISP, and both SCHEME and NIL have a more subtle mechanism for lexically-local variables. In fact, how soon NIL implements the syntax which permits instance variables to look like lexically locals depends on whether the lack of this feature is a bottleneck holding back system development, or just a minor inconvience. Another misdirected line of commentary concerns LET; whether one likes the name or not, the destructuring features seem to be popularly useful. Recently RMS had an interesting idea about extending the kind of destructuring specification to be a program rather than a data-pattern, and a "hairy" atomic-macro scheme will spoil either one. E.g; (RMS-LET ((`(FOO ,x ,y) Z)) ...) is like (RMS-LET (((LIST 'FOO X Y) Z)) ...), which acts like ((LAMBDA (X Y) ...) (CADR Z) (CADDR Z)) or, in the current data-pattern style destructuring (LET (( (() X Y) Z )) ... ) which acts the same way. Since the atomic-macro idea really isn't the "context-free" idea of a reader macro, it would open a miasma of expansion/evaluation questions for these several destructuring contexts. Another suggested application of atomic-macros has been for "symbolic constants" -- perhaps partly alluded to in HIC's comment (defatomicmacro MAGIC-VARIABLE ...) Indeed, SYMBOLIC-CONSTANT is a declaration available in NIL, which just setq's a variable as a global variable in the interpreter (and marks it on its property list at toplevel), but which is handily converted by the compiler into a constant (rather than a special variable reference). See MC:NIL;INCUSE > for a description of how to use the NIL compiler, and the examples under SYMBOLIC-CONSTANT. The reason that this works so well, is that the evaluation context of a SYMBOLIC-CONSTANT is the same as a variable: (DECLARE (SYMBOLIC-CONSTANT PI 3.14159)) (DEFUN (X PI Y) ...) and (DEFUN (X) (SETQ PI ...) ...) ==> detectable errors (DEFUN FOO () (//$ PI 2)) ==> (DEFUN FOO () 1.570795) during compilation  Date: 16 JUL 1980 0226-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Funny symbols/strings To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, NIL at MIT-MC What would people think of having #\\RETURN, #\\LINEFEED, etc. turn into the char designated... or can someone suggest a better way to get the effect of #.(ASCII #\RETURN) which is what I am resorting to now? There doesn't seem to me any reason that the alist which #\ uses can't include entries like (... (RETURN . #.(ASCII 13.)) (LINEFEED . #.(ASCII 10.)) ...). Yes, I am interested in this returning a symbol I can PUTPROP to -- even on machines that have character objects available. I realize that there may be some discussion on this point. Perhaps a different set of keys which would return char objects if the Lisp had them and something else on the more primitive Lisps. Comments? -kmp ps apologies in advance for duplications of this message  Date: 16 JUL 1980 0117-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: Atomic Macros To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, GJC at MIT-MC To: HIC at MIT-MC, PSZ at MIT-MC CC: LIL at MIT-MC Perhaps we should be working towards a "Fusion Macro"? Seriously, I would like to offer some arguments about atomic macros. First let me say that I am opposed to adding atomic macros to MacLisp or LispMachine lisp. My reasons for this are probably similar to PSZs: although the feature has some merit, it is really not something that can be added to the language at this point without causing complete and total upheaval. SET and PROGV are one problem. Another: suppose we say that (LET ((X 0)) ...) atomicmacroexpands the X to see if it is going to expand into another symbol. What if it expands into (MUMBLE 'X)? Do we continue to macroexpand, or do we stop and destructure? (I don't like destructuring either, but there it is.) If you think we should continue to macroexpand then suppose the guy wrote (LET (((MUMBLE 'X) 0)) ...) in the first place? If you think we should destructure then by what right do you differentiate between X => (MUMBLE 'X) =>Y and X => Y ("=>" indicates one level of macroexpansion)? Perhaps you can solve these problems, (I just thought of a way out myself) but there are going to be others you haven't thought of yet. In particular you have just screwed every macro writer who ever did (ATOM FOO) to determine if it was safe to substitute the value of FOO directly into some code that might evaluate it twice. ("But nobody in their right mind would define an atomic macro whose expansion evaluated with side effects" I can hear several people yelling... I know.) I bet I can think up more. I bet nobody is willing to put the effort into implimenting them. I bet we can continue to live without them. Now, for those of you who are wondering why I put atomic macros into LIL if I think they are such losers: 1) In LIL we have no destructuring. 2) LIL has no interpreter where there are symbols that can be passed as arguments to things like SET and PROGV. 3) We don't let atomic macros do anything in LETs, it is an error to do (LET ((X 0)) ...) if X is an atomic macro. This is so that we can do the right thing when we decide what that is. I tend to think that the HIC solution (GJC's "atomic macro of the second kind") is the right one at the moment. 4) Since LIL is growing from the ground up, we have no commitment to any other past features that might screw us. 5) We have no users with existing code that this might break. Basically the point is that this atomic macro thing is a good idea, but only as something you have in mind from day 1, not something that you add in 10 years later when you first think of it.  Date: 16 July 1980 00:42-EDT From: George J. Carrette Subject: Bad ideas To: PSZ at MIT-ML cc: HIC at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 07/15/80 23:22:16 From: PSZ at MIT-ML To: hic cc: (BUG LISP) at MIT-ML, (BUG LISPM) at MIT-ML, GJC at MIT-ML Re: Bad ideas My a priori belief shows through in my phrasing, but I am by no means immune to a good argument. I was really just expressing a desire for some consensus on it before it gets installed and I begin to see (dread the thought) things like my perfectly reasonable (setq space 3000) turn behind my back into (setq 40 3000), as I think it likely that such "expanding constants" will be one plausible use of the facility you are planning. Please note that I am not yet prepared to argue the details (e.g., whether expansion should happen in quoted contexts, implicitly quoted contexts, whether it should be lexically or dynamically specified, or any such meaty issues). I am still searching for a good case to be made for the fundamental idea. Although I have at times had cravings for just such a feature, some reflection has so-far dissuaded me (like some cravings for giant anchovy pizzas). Someone please step forward and demonstrate a program in which having this feature is a big win, outweighing the disadvantage of further weakening the transparency of Lisp. Well, what I was doing (just so happens in maclisp), was implementing closures with lexically scoped instance variables, as apposed to the special variables which the lisp machine uses. (defclosure foo (a b c d) ((sum 0)) ; def-struct like specs. ...body ...) (setq q (make-foo-closure ... defstruct-like specifications ...)) (call q 1 2 3) => (lsubrcall t (pointer-slot q) (data-slot q) 1 2 3) simple eh? What actually gets defined for FOO is an lsubr which takes as its first argument a HUNK with the environment. Since SUM is an instance variable you want SUM to expand into (CXR <17> DATA) and (SETQ SUM FOO) to go to (SETF (CXR <17> DATA) FOO). The defstruct-like instance variable specs are actually used as a defstruct to define the variable structure. (A HUNK in haclisp, oops, I mean maclisp) However, if in the body we have (LET ((SUM 34)) we DON'T want that to be (LET (((CXR 3 DATA) 34) ...) !!!! To further complicate things, I want the so-called ATOM-MACRO properties to be in effect LOCAL to the BODY only. They do not want to be global properties. I know that using these atomic-macros-of-the-first-kind DOES NOT INTERFERE WITH THE TRANSPARENCY OF LISP. Note: any SETQ of a special variable does not qualify as being transparent lisp programming anyway. HIC may want to use atomic-macros-of-the-SECOND-kind, and so might I for other purposes. I don't think that one excludes the other. Although the ones I want would be harder to implement.  PSZ@MIT-ML 07/15/80 23:22:16 Re: Bad ideas To: hic at MIT-MC CC: (BUG LISP) at MIT-ML, (BUG LISPM) at MIT-ML, GJC at MIT-ML My a priori belief shows through in my phrasing, but I am by no means immune to a good argument. I was really just expressing a desire for some consensus on it before it gets installed and I begin to see (dread the thought) things like my perfectly reasonable (setq space 3000) turn behind my back into (setq 40 3000), as I think it likely that such "expanding constants" will be one plausible use of the facility you are planning. Please note that I am not yet prepared to argue the details (e.g., whether expansion should happen in quoted contexts, implicitly quoted contexts, whether it should be lexically or dynamically specified, or any such meaty issues). I am still searching for a good case to be made for the fundamental idea. Although I have at times had cravings for just such a feature, some reflection has so-far dissuaded me (like some cravings for giant anchovy pizzas). Someone please step forward and demonstrate a program in which having this feature is a big win, outweighing the disadvantage of further weakening the transparency of Lisp.  Date: 15 July 1980 23:51-EDT From: Howard I. Cannon Subject: suggested compiler feature. To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC The reasoning behind expanding atomic macros in lambda lists (in my mind) is that you might define something like: (defatomicmacro MAGIC-VARIABLE ) and you could then use MAGIC-VARIABLE all over the place and have it be replaced automatically (this could be great for macro packages and the like, I suspect). Anyway, that's the basic theory.  Date: 15 July 1980 23:41-EDT From: Howard I. Cannon Subject: suggested feature. To: PSZ at MIT-ML cc: GJC at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC I think that people perceive symbols when used as special variables as having some "character" that they carry around with them (much like declared identifiers in other languages). If you implement atomic macros, then you have these symbols that have this character of expanding into something else when mentioned. Now, you might argue that even though that is true, symbols when QUOTED don't retain any special meaning, and symbols in lambda lists and setq's are implictly quoted. Therefore, they should not expand into atomic macros (I am not proposing that explicitly QUOTEd symbols expand, though there might be something pleasing about this). I do not agree with this. Though it is true that symbols in those positions are not EVALUATED, they are certainly looked at specially (for specialness, for example, at least by the compiler). I therefore think that for consistancy they should expand if they are atomic macros. This may of course produce erroneous results in some circumstances (probably most!). So what. Personnally, I don't like destructuring LET either, and I don't use it (I call it something different if that is the functionality I want). On the other hand, I don't see atomic macros as being the same thing at all (of course, I believe treating each thing individually on the basis of its meri makes sense). My proposal also makes SET' different from SETQ, which is probably ok (though I supose there might be some sort of symmetry argument against the atomic macro thing here). But, I don't know why I bother explaing this, since you "hate to see Lisp get cluttered up with bad ideas", you must have already decided that atomic macros is a bad idea. --Howard  PSZ@MIT-ML 07/15/80 22:32:15 Re: suggested feature. To: GJC at MIT-MC, HIC at MIT-MC CC: (BUG LISP) at MIT-ML, (BUG LISPM) at MIT-ML I am having a hard time following the argument about how atom-macros ought to be treated in lambda lists because I have yet to see any interesting demonstration that they are at all useful and defensible. I hate to see Lisp get cluttered up with bad ideas (e.g., the recent intrusion of automatic destructuring in many macro packages -- forcing one into explicit dependence on the precise layout of various data structures) without more of a discussion of what is to be gained. Would someone care to present the needed case for this?  Date: 15 July 1980 22:43-EDT From: George J. Carrette Subject: suggested compiler feature. To: HIC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 15 July 1980 16:13-EDT From: Howard I. Cannon To: GJC cc: BUG-LISP, BUG-LISPM Re: suggested compiler feature. I meant to imply in my previous message that I think that GJC's lambda-list sggstion is also wrong. I might have to agree with you on that. The reason that I suggested that LAMBDA push away atomic macro properties is to meet the objection of EB, that is, that (SETQ ...) only mean to setq a variable. In the case of a lexically apparent variable EB could be confident that (SETQ ...) meant only a very efficient and simple thing. SETQ of a special variable would be another thing entirely. Implementing the lambda-list suggestion in the interpreter would be non-trivial. All lambda expressions would have to have a pointer to the lexical contour in which they where created. Anyway, what is the right thing to do in lambda-lists?  Date: 15 JUL 1980 1658-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC INPUSH of an SFA complains of a wrong type arg.  Date: 15 July 1980 16:13-EDT From: Howard I. Cannon Subject: suggested compiler feature. To: GJC at MIT-MC cc: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC I meant to imply in my previous message that I think that GJC's lambda-list sggstion is also wrong.  Date: 15 July 1980 16:11-EDT From: Howard I. Cannon Subject: suggested compiler feature. To: EB at MIT-AI cc: GJC at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC I think that SETQ should know about atomic macros -- at least it should give you a warning. One of the major ideas behind atomic macros is that you can use the atom without knowing whether or not it will expand. Note that the problem also arises when yo use an atomic macro in a lambda-list.  Date: 14 July 1980 14:28-EDT From: Jonathan A. Rees Subject: Errors To: EB at MIT-AI cc: BUG-LISP at MIT-MC Date: 07/11/80 15:19:56 From: EB at MIT-AI To: (BUG LISP) cc: JAR Date: 10 JUL 1980 1940-EDT From: JAR at MIT-MC (Jonathan A. Rees) The reason for this is that ERROR was called with no interrupt channel argument while *RSET was (). That is a RUDE thing for ANY error detection code to do. Why? Seems controversial to me. If you don't want errors like that to go immediately to top level, don't run with *RSET nil. Don't jump to the conclusion that I was running with *RSET nil. I hardly ever do, and wasn't doing so in this case. I do, however, have to use Jonl's system code which has the nasty habit of BINDING *RSET to nil within certain functions, like the one that caused my grief. Wouldn't giving an interrupt channel argument typically make the error correctable, while the whole point of using ERROR might be that a semantically uncorrectable error has occurred? I had no intention of correcting the error! I only wanted to look at my execution context at the point where the error occurred! And according to your argument, the right thing to do would be to do a (QUIT), since throwing to top level is itself a form of "recovery." Also, note that errors written as calls to FERROR will give no interrupt channel argument (unless I am mistaken); does that mean that FERROR is a RUDE function for ANY error detection code to call? No, it means that there's some bug in the implementation of FERROR you refer to. (What version is that, btw? The kludgey version defined by LSPSRC; EXTEND/EXTMAC - not that I want to recommend or defend it - at least uses the FAIL-ACT channel by default, prior to bombing out completely.)  gls@MIT-AI (Sent by GJS@MIT-AI) 07/14/80 13:48:02 Re: FERROR To: (BUG lisp) at MIT-MC CC: GLS at MIT-AI, EB at MIT-AI Yes, FERROR is pretty rude. CERROR is the thing to use. Actually, I get fairly ticked when people (that includes me, too, friend) just stick in a call to FERROR instead of thinking for 2.5 seconds about how to arrange the code so that it's correctable. Laziness I guess.  Date: 14 July 1980 14:00-EDT From: Edward Barton Subject: suggested compiler feature. To: GJC at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 14 JUL 1980 1205-EDT From: GJC at MIT-MC (George J. Carrette) Also: atomic-macro-of-the-first-kind. Which would have the following actions given that has such a property: A free => (setq X) => (setf (expansion of FOO> X) ((lambda () ) X) => dissables the macro property of during the expansion of . i.e. LAMBDA is a truely transparent. If one wants to (BIND (( ...)) ...) then some special BIND form must be used. This is of course incompatible with the existing semantics of special variables, but perhaps special variables should be changed. I'd like to cast a vote against making (SETQ ) do anything except SETQ a variable.  Date: 14 JUL 1980 1205-EDT From: GJC at MIT-MC (George J. Carrette) Subject: suggested compiler feature. To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC (compiler-unwind-protect ) The semantics of this are simple, during alpha conversion is the expression which is the *value*, but the are evaluated even if the alpha conversion of causes some error. Also: atomic-macro-of-the-first-kind. Which would have the following actions given that has such a property: A free => (setq X) => (setf (expansion of FOO> X) ((lambda () ) X) => dissables the macro property of during the expansion of . i.e. LAMBDA is a truely transparent. If one wants to (BIND (( ...)) ...) then some special BIND form must be used. This is of course incompatible with the existing semantics of special variables, but perhaps special variables should be changed. One motivation: for these things in maclisp and lmlisp is an implementation of closures with lexically scoped instance variables. The claimed need for "compiler-unwind-protect" is that it is not kosher for macros to call the compilers macro-expander. -gjc  Date: 12 JUL 1980 1648-EDT From: JONL at MIT-MC (Jon L White) Subject: Error printing, and "silent" BREAK loops To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, BMT at MIT-MC Date: 12 July 1980 16:23-EDT From: Kent M. Pitman I propose that if MSGFILES is () that the error be forced to the terminal if Lisp wants to do that, but if MSGFILES is non-(), it should only go to there. That will let us create an SFA to gobble all error messages and behave appropriately. -kmp Sounds good - I've just made that patch. I believe that there is only one place, in ERRPRINT, where the "inhibit-forcing-the-TTY" bit is set, relevant to this problem.  Date: 12 July 1980 16:23-EDT From: Kent M. Pitman Subject: Error printing, and "silent" BREAK loops To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, BMT at MIT-MC I propose that if MSGFILES is () that the error be forced to the terminal if Lisp wants to do that, but if MSGFILES is non-(), it should only go to there. That will let us create an SFA to gobble all error messages and behave appropriately. -kmp  Date: 12 JUL 1980 1040-EDT From: JONL at MIT-MC (Jon L White) Subject: Error printing, and "silent" BREAK loops To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC, BMT at MIT-MC Date: 12 July 1980 04:51-EDT From: Kent M. Pitman Does it seem reasonable to anyone that (LET ((MSGFILES NIL) (^R NIL) (^W T) (OUTFILES NIL) (ECHOFILES NIL)) (+ 'A 'B)) prints ;NON-NUMERIC VALUE on the terminal? How many more files do I have to turn off? Of course not. I took the liberty of making the two-line patch to the ERROR file to fix this. But what you forgot to do was do that random test twice, and report on the disastrous results of the second such attempt -- A FATAL CRASH TO DDT WITH PURPG! The problem is that the error leaves you in the break loop set up by the particular WRNG-TYPE-ARG error handler, and by shutting off printing (or *almost* shutting it off) one has no idea that he has run into an error and is currently stalled in the break loop. At least with my little patch, the bomb-out to DDT won't occur, but I pose the question: SHOULD THE DEFAULT ERROR HANDLERS BE PERMITTED TO GO INTO A "SILENT" BREAK LOOP?  Date: 12 JUL 1980 0451-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: BMT at MIT-MC Does it seem reasonable to anyone that (LET ((MSGFILES NIL) (^R NIL) (^W T) (OUTFILES NIL) (ECHOFILES NIL)) (+ 'A 'B)) prints ;NON-NUMERIC VALUE on the terminal? How many more files do I have to turn off?  Date: 11 JUL 1980 1646-EDT From: dr at MIT-MC (David M. Raitzin) Subject: unsave and includef To: (BUG LISP) at MIT-MC CC: KMP at MIT-MC when i loaded ((dsk liblsp)save fasl) , then did (setq save-verbose t) and then finally (unsave filename), where this filename had includef's, apparently unsave didn't read in from the "includef" files, or in any event, all the functions from these files turned out to be undefined.  EB@MIT-AI 07/11/80 15:19:56 Re: Errors To: (BUG LISP) at MIT-MC CC: JAR at MIT-MC Date: 10 JUL 1980 1940-EDT From: JAR at MIT-MC (Jonathan A. Rees) The reason for this is that ERROR was called with no interrupt channel argument while *RSET was (). That is a RUDE thing for ANY error detection code to do. Why? Seems controversial to me. If you don't want errors like that to go immediately to top level, don't run with *RSET nil. Wouldn't giving an interrupt channel argument typically make the error correctable, while the whole point of using ERROR might be that a semantically uncorrectable error has occurred? Also, note that errors written as calls to FERROR will give no interrupt channel argument (unless I am mistaken); does that mean that FERROR is a RUDE function for ANY error detection code to call?  Date: 10 July 1980 23:28-EDT From: Glenn S. Burke To: ALAN at MIT-MC cc: BUG-LISP at MIT-ML Date: 10 JUL 1980 2241-EDT From: ALAN at MIT-MC (Alan Bawden) In the new FORMAT the colon flag doesn't effect the way ~ acts anymore. ---- Fixed, will be installed shortly.  Date: 10 JUL 1980 2241-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC In the new FORMAT the colon flag doesn't effect the way ~ acts anymore. This means that there is no longer any way to keep the carrage return but flush the following whitespace (this used to be the default, the colon flag kept the whitespace, now it ALWAYS keeps the whitespace). Unless I go and re-edit all my files, I am going to go crazy looking at lines that have too much indentation and wrap around as a result.  Date: 10 JUL 1980 1940-EDT From: JAR at MIT-MC (Jonathan A. Rees) Subject: Bug in STRING's error handling To: (BUG LISP) at MIT-MC I recently got an error in the STRING package's function STR:COMPRESS-SPACE, "STRING bug detected by STR/:COMPRESS-SPACE". Now I didn't mind getting this message, since I was doing some awful things anyhow, like continuing after GC-LOSSAGE breakpoints, and my Lisp was pretty ill by that time; the error itself wasn't the problem. What got me pissed off was that after the error was reported, I was thrown out to top level, losing the entire context I had so carefully established! The reason for this is that ERROR was called with no interrupt channel argument while *RSET was (). That is a RUDE thing for ANY error detection code to do.  Date: 9 JUL 1980 1205-EDT From: JONL at MIT-MC (Jon L White) Subject: "user-atoms" To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Date: 8 July 1980 11:13-EDT From: George J. Carrette If you compile with the (-k) option a file which using +internal-/"-macro ala "foo bar", then you loose. LAP doesn't have squids I suppose? Who cares right? Right, there is no provision now for LAP to hack these "user-atoms", but there could be, with a little effort. On the other hand, you could also use the more primitive definition of the " macro - just let it turn strings into symbols.  Date: 8 JUL 1980 1238-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, CPR at MIT-EE (STATUS SITE) on EE returns TOPS-20. I need this to return EE or MIT-EE in order to get things like the Macsyma BUG and MAIL commands working correctly. Can this please be fixed? Thanks. -kmp  Date: 8 JUL 1980 1113-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC If you compile with the (-k) option a file which using +internal-/"-macro ala "foo bar", then you loose. LAP doesn't have squids I suppose? Who cares right?  Date: 3 JUL 1980 0235-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: LISP and DDT symbols To: EB at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC To: (BUG MIDAS) at MIT-MC The problem is a LISP bug, which I analyzed and reported some time ago. I thought JONL fixed it, but perhaps my memory deceives me.  GSB@MIT-ML 07/03/80 01:29:31 Re: new format installed To: (BUG LISP) at MIT-ML with various minor fixes & twiddlings, including obarray insensitivity for single character operators.  Date: 30 JUN 1980 2154-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC It seems that lexpr-funcall has problems with array objects: (setq a (*array nil t 10)) #T-10-70764 (apply a '(7)) NIL (lexpr-funcall a '(7)) ;((NIL 7) (NIL . 0)) TOO MANY ARGUMENTS SUPPLIED - APPLY ;BKPT WRNG-NO-ARGS I have also gotten some MPVs, but I can't seem to reproduce them.  Date: 29 JUN 1980 0829-EDT From: JONL at MIT-MC (Jon L White) Subject: FORMAT stores information on plist os single-character symbols. To: JAR at MIT-MC CC: (BUG LISP) at MIT-MC I agree this is a loss. Why cant FORMAT just have a large table/array indexed by the ascii value of the dispatch char?  Date: 29 JUN 1980 0827-EDT From: JONL at MIT-MC (Jon L White) Subject: FORMA To: JAR at MIT-MC CC: (BUG LISP) at MIT-MC  Date: 29 JUN 1980 0352-EDT From: JAR at MIT-MC (Jonathan A. Rees) To: (BUG LISP) at MIT-MC FORMAT stores information on the plists of single-character symbols. This has caused me some pain, and leaves me feeling generally uneasy, due to obarray/package screws. Can this be changed? A more concrete example of lossage can be constructed, if that would be helpful.  Date: 28 June 1980 17:38-EDT From: Edward Barton To: BUG-DDT at MIT-AI, BUG-LISP at MIT-AI, BUG-MIDAS at MIT-AI Consider the following file: if1,.insrt lisp;.fasl defs .fasl foobar==1 .global foobar fasend If it is assembled with MIDAS and loaded into LISP with SYMBOLS set to T, the error DDT BUG: PLEASE DO :BUG DDT DESCRIBING CIRCUMSTANCES occurs.  Date: 28 JUN 1980 0108-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC For the second time: The fact that GRINDEF and his friends SPRINTER and SPRIN1 only know about new-style DO is a loss. I don't want to start the pointless argument about flushing old-style DO again. You can't do that. So since we will continue to support old-style DO can we please have it grind properly? Please??  Date: 27 June 1980 17:08-EDT From: "Guy L. Steele, Jr." Subject: AAAARRRRRrrrggggghhhhhhh!!!!!!! To: BUG-LISPM at MIT-AI cc: BUG-LISP at MIT-AI, GLS at MIT-AI, GJS at MIT-AI, nil at MIT-MC In system 29.95 NWS, with microcode 669, on LISP Machine Eight: RETURN-FROM is incorrectly implemented, I claim. Consider this piece of code: (DEFUN FOO () (PROG () (PRINT 'A) (PROG T () (PRINT 'B) (RETURN-FROM T (PROGN (PRINT 'C) (RETURN))) (PRINT 'D)) (PRINT 'E))) The LISP Machine Manual claims that a PROG with name T is invisible to the RETURN function, and can be returned from only with RETURN-FROM T. Therefore, I would expect FOO to print the symbols A, B, and C, and then return from the outer PROG. However, it prints A, B, C, and E! Evidently the fact that RETURN occurs within an argument to RETURN-FROM T causes it to exit the inner PROG, not the outer. This is an **enormous** screw, and wasted over an hour of my time. I have a macro, which I believe is written according to the approved stype, using PROG T: (defmacro select! (item . clauses) `(prog t (%%item%%) (setq %%item%% ,item) retry-select! (select %%item%% ,@(forlist (clause clauses) `(,(car clause) (return-from t (progn ,@(cdr clause))))) (otherwise (setq %%item%% (cerror t () ':wrong-type-argument "The selector ~S was not found in a SELECT! construct." %%item%%)) (go retry-select!))))) This is a version of SELECT that provides its own OTHERWISE clause and arranges to retry with a correctable error if the key is not known. I need a PROG to make a loop. However, if a RETURN occurs in a clause to SELECT!, I want it to return from whatever PROG surrounds SELECT! In the interpreter, the problem is that RETURN-FROM binds RETPROGDESC and then cretinously calls EVAL, giving it a consed-up RETURN form. Of course, if the argument to the consed-up RETURN form contains a RETURN, as here, things get really fouled up. The fix is that RETURN-FROM should evaluate its argument **first**, before binding RETPROGDESC, and then cons up a form (RETURN ') to eval if it must be done that kludgy way. I have no idea how the compiler manages to screw up the same way.  Date: 27 JUN 1980 1354-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC In *rset T mode you shouldn't be allowed to take the car of a hunk of size 1.  Date: 27 JUN 1980 1003-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC Why does DEFVAR turn into a PROGN, the next-to-last line of which is essentially (EVAL 'FOO) when defvar'ing variable FOO? the return val of the PROGN is just 'FOO.  GSB@MIT-ML 06/26/80 09:00:30 Re: wrng-no-args error (actually, lack thereof) To: (BUG LISP) at MIT-ML (fillarray some-array 1 2 3 4 5 6 7 8 9) gives an uncorrectable error. This sucks.  Date: 26 June 1980 00:29-EDT From: David Hodgson Dennis Subject: ferror? To: BUG-LISP at MIT-AI cc: DHD at MIT-AI (ferror) ;FERROR UNDEFINED FUNCTION OBJECT ;BKPT UNDEF-FUNCTN (load '((lisp) format)) 153677 (ferror) ((FERROR) (2 . 776)) TOO FEW ARGUMENTS SUPPLIED - APPLY ;ah hah! (ferror t "This is ~A." "something") ;SIGNAL UNDEFINED FUNCTION OBJECT QUIT * (format t "This is ~A." "something")This is something. NIL ; so it's ferror; the definition must have been taken too ;literally from the LISP machine.  Date: 25 JUN 1980 1205-EDT From: RLB at MIT-MC (Richard L. Bryan) To: (BUG LISP) at MIT-MC FORMAT doesn't get a VERSION property after loading.  psz@MIT-ML (Sent by GSB@MIT-ML) 06/24/80 12:32:54 Re: printing single character objects To: (BUG LISP) at MIT-ML Making something a single-char object causes print to do the wrong thing. E.g. (setsyntax '/* 'single nil) ... '* /* '/*a /*A 'A/* A/* This is fine for the last two cases, but wrong for the first. The whole point of single character objects is that they be usable as such. Thus, the * should only be slashed when part of a longer pname. The print mechanism thus has to check the single-char-object flag(s) before checking the slash-first-char and slash-non-first-char flags when deciding to slashify or not.  Date: 24 JUN 1980 0618-EDT From: JONL at MIT-MC (Jon L White) Subject: gc overflow To: WJL at MIT-MC CC: (BUG LISP) at MIT-MC WJL@MIT-ML 06/23/80 10:21:31 Lisp 1997 won't load my big list, 1917 and whatever we were using last week loads it fine. (I tried 1917 today, so it's not the file.) The list is wjl1;doseq 5 and when I load it into 1997 with just my init (wjl;wjl lisp) it gives a list storage capacity exceeded error. I just loaded up wjl1;doseq 5 into 1997, but omitted the part of your init file which loads in LIBLSP;GCDEMN. I suspect there is some untoward action with this particular DAEMON - if you do you own pre-alloc, say, (ALLOC '(LIST (28000. 32000.) FLONUM (3100. 3500.))) you will win.  Date: 24 June 1980 05:04-EDT From: Glenn S. Burke Subject: FORMAT To: EB at MIT-AI, BUG-LISP at MIT-AI Fixed, new format installed on ITS.  Date: 24 June 1980 04:46-EDT From: Edward Barton Subject: FORMAT To: BUG-LISP at MIT-AI In LISP 1997, FORMAT 413 behaves ungracefully as follows: (format tyo nil) MPV; 124655>>SKIPA 1,400000 1/0 400000/ ??  WJL@MIT-ML 06/23/80 10:21:31 To: (BUG LISP) at MIT-ML Lisp 1997 won't load my big list, 1917 and whatever we were using last week loads it fine. (I tried 1917 today, so it's not the file.) The list is wjl1;doseq 5 and when I load it into 1997 with just my init (wjl;wjl lisp) it gives a list storage capacity exceeded error.  Date: 22 June 1980 01:47-EDT From: Robert W. Kerns To: EB at MIT-MC cc: BUG-LISP at MIT-MC NIL is not assumed as the EOF value for IN, NIL says NO EOF VALUE WAS SUPPLIED. This is an important distinction. NIL is not a FIXNUM, and thus is not a legal EOF value for a fixnum function such as IN. Your guess is correct; you should give an error if NIL is supplied and EOF has been reached.  Date: 21 June 1980 14:55-EDT From: "Guy L. Steele, Jr." To: BUG-LISPM at MIT-AI cc: GLS at MIT-AI, BUG-LISP at MIT-AI, nil at MIT-MC I have made two changes to FORMAT for the LISP Machine only. The changes have been documented in LMMAN;FD.STR >, and in the FORMAT documentation string in the code. (1) ~:| performs a :CLEAR-SCREEN operation on the output stream, if that stream supports that operation. Otherwise it behaves just like ~|, outputting n formfeeds. (This at the request of HES.) (2) In the ~<...~:;...~> construction, if a second numeric parameter is given to the ~:;, it is the width of the line and is used instead of the stream's claimed line width, if any. (Recall that the first numeric parameter is a number to be subtracted from the width before doing the comparison.) Also, to make this work, I modified FORMAT-STRING-STREAM to support the READ-CURSORPOS operation in a half-assed way: it just searches back from the end of the string-so-far for a return, linefeed, or form, and calls that distance the x cursorpos, and always says y=0. This makes ~<...~:;...~> to a string work. Tabs will mess everything up, however; it isn't smart. Also, to make this work when you are dribbling to a file, I modified the code for DRIBBLE-IO to support READ-CURSORPOS also, by passing the buck to the previous I/O stream. Both FORMAT and DRIBBL have been recompiled.  Date: 21 June 1980 07:06-EDT From: Edward Barton Subject: Previous IN message -- my fault? To: BUG-LISP at MIT-AI My misunderstanding, I guess -- since IN doesn't take an EOF argument, NIL is always assumed as its EOF value. I should thus give my own error rather than returning NIL, whenever NIL is supplied as the EOF value. Is this guess correct?  EB@MIT-AI 06/21/80 06:40:19 Re: IN on SFA'S To: (BUG LISP) at MIT-MC The SFA mechanism does not handle EOF for the IN operation correctly. Documentation from MC:LISP;SFA >: "D) IN The value returned should be a fixnum that is the next binary value in the input stream. The argument is the EOF value." Behavior from LISP: (setq sfa (sfa-create '(lambda (sfa op arg) (cond ((eq op 'which-operations) '(in)) (t arg))) ;; i.e. IN ==> EOF always 0 'foo)) (in sfa) ;NIL NON-FIXNUM VALUE  Date: 21 June 1980 02:23-EDT From: David Hodgson Dennis To: BUG-LISP at MIT-AI Is there any particular reason why DEFSTRUCT can't turn into a DEFVST form for LISPM compatibility (i.e. why it can't be a subset of LISPM's DEFSTRUCT until someone gets around to implementing the full thing)?  Date: 20 JUN 1980 2150-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: INHIBIT To: (BUG LISP) at MIT-MC, GSB at MIT-MC, HIC at MIT-MC I have patched this and installed it.  Date: 20 June 1980 08:18-EDT From: Kent M. Pitman Sender: ___041 at MIT-AI Subject: NAMELIST To: BUG-LISP at MIT-AI cc: JPG at MIT-AI (namestring '((DSK KMP) |.FOO| BAR)) on Tweneces should return |DSK:.FOO.BAR| rather than just |DSK:.FOO.BAR| which it now does. Macsyma cannot write to .SAVE. OUPUT any more and win. It would be nice to have namelist form be as implementationally independent as possible. Also, as a side-note, (namestring '((DSK KMP) |,FOO| BAR)) on ITS just returns |DSK:KMP;,FOO BAR| which is a problem for things that want to valret filenames, etc. Most of the programs on the system treat , as a special character in filenames. -kmp  Date: 20 JUN 1980 0622-EDT From: GSB at MIT-MC (Glenn S. Burke) To: (BUG LISP) at MIT-MC BTW, I fixed it in the source. (These last two notes from HIC, btw, so don't blame GSB for all the flaming. You all know he doesn't have it in him...)  Date: 20 JUN 1980 0622-EDT From: GSB at MIT-MC (Glenn S. Burke) To: (BUG LISP) at MIT-MC The INHIBIT set to -1,,0 was caused by the symbol "KMPLOSES" being incompetently computed. AND WHY DID SOMEONE CALL THIS SYMBOL BY THIS STUPID NAME? It's hard enough getting symbols to be understandable at all -- that one wins the record for all time least understandable...even when understood...  Date: 20 JUN 1980 0436-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: INHIBIT and user interrupt frames To: GSB at MIT-MC, (BUG LISP) at MIT-MC, EB at MIT-MC The .VALUE is because it gets an error while INHIBIT is set. This is why autoloading from an interrupt handler often .VALUEs as well. This has to be unrelated to the bug in FRETURN that I just fixed, since I know the autoload bug has been there for a while. The bug I fixed was that my patch changed the value of UISAVT, which is referenced exactly twice, both times in UIBRK, which I fixed. I have to believe this is a separate bug. JONL, I tend to think this one is yours, can you look at it?  Date: 20 June 1980 04:16-EDT From: Edward Barton To: KMP at MIT-MC cc: BUG-LISP at MIT-AI Date: 20 JUN 1980 0413-EDT From: KMP at MIT-MC (Kent M. Pitman) Date: 20 June 1980 02:52-EDT From: Edward Barton Subject: INHIBIT restoration bug To: BUG-LISP at MIT-AI Also happens when UNWIND-PROTECT is used instead of *CATCH. Well, UNWIND-PROTECT, in the case of normal return, UNWIND-PROTECT is supposed to ... ie, it works something like (DEFUN UNWIND-PROTECT FEXPR (BODY) (PROG1 (EVAL (CAR BODY)) (LET ((+INTERNAL-WITHOUT-INTERRUPTS T)) ;Bind INHIBIT, etc (MAPC 'EVAL (CDR BODY))))) when no non-local returns happen ... does this account for your bug? If not, please give us an example of what you mean... No, this doesn't account for the bug. Example: (setq tty-return '(lambda (x) (unwind-protect nil nil)(undefined-function))) ^Z $P does a .VALUE after it is OUTSIDE the unwind-protect. I hope someone can fix this; I took out all the CATCHes in my code and it still happens sporadically.  Date: 20 JUN 1980 0413-EDT From: KMP at MIT-MC (Kent M. Pitman) To: EB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 20 June 1980 02:52-EDT From: Edward Barton Subject: INHIBIT restoration bug To: BUG-LISP at MIT-AI Also happens when UNWIND-PROTECT is used instead of *CATCH. Well, UNWIND-PROTECT, in the case of normal return, UNWIND-PROTECT is supposed to ... ie, it works something like (DEFUN UNWIND-PROTECT FEXPR (BODY) (PROG1 (EVAL (CAR BODY)) (LET ((+INTERNAL-WITHOUT-INTERRUPTS T)) ;Bind INHIBIT, etc (MAPC 'EVAL (CDR BODY))))) when no non-local returns happen ... does this account for your bug? If not, please give us an example of what you mean...  Date: 20 June 1980 02:52-EDT From: Edward Barton Subject: INHIBIT restoration bug To: BUG-LISP at MIT-AI Also happens when UNWIND-PROTECT is used instead of *CATCH.  GSB@MIT-ML 06/20/80 02:03:07 Re: someone is confused To: (BUG LISP) at MIT-ML It appears that when a catch is exited when inside of a user interrupt it restores INHIBIT (and presumably the other related variables, it was set via a BLT) from the value it had OUTSIDE the call to the interrupt. For example, do: (setq tty-return '(lambda (x) (*catch 'foo 'do-nothing) (undefined-function))) then ^Z and $P the lisp while it is waiting for input.  Date: 19 June 1980 23:05-EDT From: Robert W. Kerns Subject: FRETURN To: BUG-LISP at MIT-MC, GJS at MIT-MC, JAR at MIT-MC, GSB at MIT-MC Has been fixed. The bug was mine, an odd interaction with a patch I'd forgotten about to fix a bug that had been introduced in WITHOUT-INTERRUPTS to fix another bug .... Hopefully, the bugs stop here.  Date: 19 JUN 1980 0306-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC (ODDP 3.4E+30) complains ;3.4E+30 NON-FIXNUM VALUE and yet the correct error message would be something like NOT FIXED POINT. Bignums seem to be perfectly acceptable to ODDP.  Date: 18 JUN 1980 2151-EDT From: BUDD at MIT-MC (Phil Budne) Subject: MAClisp on BOTS-10. To: (BUG LISP) at MIT-MC Recently I commented that LISP was doing at SETSTS (SETSTatus) on device tty: with erroneis arguments; SETSTS CH,6 where the 6 should be indirect. this was deduced by the fact rthat surrounding operations had to do with reg. 6, and 6 is an ilegal TTY data mode. however thees locations are sometimes given obcenely large and useless values in R6 sugguuesting larger problems. (prdon my typing)  GSB@MIT-ML 06/17/80 19:29:33 Re: freturn loses To: (BUG LISP) at MIT-ML Freturn gets memory errors of one type or another (it seems) when it exits through a user interrupt frame.  Date: 17 June 1980 02:11-EDT From: Edward Barton To: BUG-LISP at MIT-AI (setq j (create-job nil nil 'foo)) ;LOADING HUMBLE 41 (INFERIOR #JOB-|USR:EB FOO|-70764) (select-job (cadr j)) (REOWNED #JOB-|USR:EB FOO|-70764) Shouldn't that be (INFERIOR ...) instead of (REOWNED ...) in the SELECT-JOB? Is the source of the confusion perhaps the fact that the specified job is already current??  Date: 15 June 1980 01:57-EDT From: Gerald Jay Sussman To: BUG-LISP at MIT-AI return in debug (use of R command) causes PURPG; 64105>>PUSH 16,10 10/ -1,,13575  Date: 13 June 1980 17:28-EDT From: Kent M. Pitman Subject: suspend To: BUG-LISP at MIT-MC Date: 13 June 1980 13:12-EDT From: David M. Raitzin Re: suspend I think there is something wrong with the "suspend" function... When I try to run it, I get an error that i/o is in progress and that I can't suspend, even though the only i/o that is in progress is to the tty... ----- He had a LISPT holding I/O open, so wasn't our bug. -kmp  DICK@MIT-ML 06/13/80 17:07:11 To: (BUG LISP) at MIT-ML If you re-enter lisp from hactran, the fn bound to TTY-RETURN gets executed. this is great. However, if you have 2 TTYs (for example if you are working with a split screen), the TTY-RETURN fn gets executed twice, and there is no way to tell the two executions apart. You cannot tell which applies to which TTY or anything. Further the second call on the TTY-RETURN fn happens befor the second one even finishes. This all seems a bit bazar. I think there should either be just one tty-return no matter how many ttys you have, or else the tty involved should be another argument to the tty-return fn. The way things are now I kludge things by taking advantage of the fact that the second interrupt occures inside the first, by binding TTY-RETURN to nil to block the second execution. However this is a real kludge for sure. Dick Waters  Date: 13 JUN 1980 1312-EDT From: dr at MIT-MC (David M. Raitzin) Subject: suspend To: (BUG LISP) at MIT-MC I think there is something wrong with the "suspend" function. Here is a function that I wrote: (defun reduce-dump () (gc) (sstatus gctime 0) (suspend '|:pdump reduce;ts reduce/ :$all done$/ |) (begin)) When I try to run it, I get an error that i/o is in progress and that I can't suspend, even though the only i/o that is in progress is to the tty. Either it's a bug, or suspend should allow i/o to the tty.  Date: 13 June 1980 05:06-EDT From: Kent M. Pitman Subject: Autoload interrupts during INHIBIT/ -1,,0 To: BUG-LISP at MIT-MC Date: 10 June 1980 06:10-EDT From: RWK at MIT-MC, KMP at MIT-MC To: BUG-LISP The current LISP still has the new bug that I reported earlier where Autoload interrupts are queued up rather than being run if interrupts are deferred... KMP will try and track down a minimal case.... ----- Just for the record, the case I had of this disappears when I recompile the file in a more recent compiler. There is still reason to believe the bug exists, however, as it is generable by hand-setting interrupts from DDT and then calling an autoloadable function; we just don't have an available case of it happening in software-only form ... yet. So people should be on the watch for this type of error. -kmp  Date: 13 June 1980 04:53-EDT From: Kent M. Pitman Subject: bug in POP? -- additional notes ... cc: BUG-LISP at MIT-MC Date: 13 June 1980 0047-EDT From: Dave Touretzky at CMU-10A With *RSET set to T: (setq foo 'bar) => BAR (pop foo) => #130552 ;or some such random number foo => NIL Shouldn't POP cry "ILLEGAL DATUM", the way (CAR FOO) or (CDR FOO) would do? ----- Presumably, it should observe the settings of variables CAR and CDR, which they don't seem to. Btw, note also the following behavior ... (SETQ FOO 'BAR) => BAR (SETPLIST 'BAR '(A B)) => (A B) (POP FOO) => #74004 FOO => (A B) Thus, if the system PLIST function breaks for some reason, you can write your own that doesn't care about the global settings of CAR/CDR and yet doesn't have to waste precious time binding and unbinding them -- eg, (DEFUN MY-PLIST (X) (POP X) X) A little bit of creativity in these situations will make the problem seem a lot more livable. -kmp  Date: 13 June 1980 0110-EDT From: Dave Touretzky at CMU-10A Subject: bug with LISP device in CMU MacLisp To: bug-lisp at MIT-MC CC: Scott Fahlman at CMU-10A LOAD does not follow the convention of looking for a PPN property on the LISP symbol when passed that symbol as a device spec. This causes annoying lossage in CMU MacLisp because of packages like SETF and MACAID. SETF does (LOAD '((LISP) MACAID)) to get MACAID from [C380ML5P], but LOAD fumbles and generates an "IMPROPERLY FORMED NAMELIST" error. Similarly, MACAID tries to (LOAD '((LISP) MLMAC)) and fails.  Date: 13 June 1980 0047-EDT From: Dave Touretzky at CMU-10A Subject: bug in POP? To: bug-lisp at MIT-MC CC: Scott Fahlman at CMU-10A With *RSET set to T: (setq foo 'bar) BAR (pop foo) #130552 [or some such random number] foo NIL Shouldn't POP cry "ILLEGAL DATUM", the way (CAR FOO) or (CDR FOO) would do?  Date: 11 JUN 1980 0202-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC *CATCH does not do wrong-number of args check in the interpreter or the COMPILER. e.g. (*CATCH 'FOO) In the compiler this causes a %%%%%%%%%% COMPILER ERROR CALL JONL %%%%%%%%% BREAKPOINT BARF time thing. Nice diagnostic. -gjc  Date: 10 JUN 1980 0737-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Previous `bug' To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC Interestingly enough, (DEFUN FOO (X) (LET* ((X X) (X X)) (DECLARE (SPECIAL X)))) returns NIL in both interpreted and compiled code ... I don't know if that's a bug or a feature.  Date: 10 JUN 1980 0729-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: What a screw! To: (BUG COMPLR) at MIT-MC, (BUG LISP) at MIT-MC (DEFUN F (X) (DECLARE (SPECIAL X))) ---- (F 3) returns DECLARE interpreted and NIL running compiled.  Date: 10 JUN 1980 0657-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Symbol/String information propagation To: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC (EVAL-WHEN (EVAL COMPILE) (SSTATUS MACRO /" '+INTERNAL-/"-MACRO)) (DEFUN (FOO MACRO) (()) "Foo String") ---Different File, Different Compiler--- (EVAL-WHEN (EVAL COMPILE) (LOAD '(AFOREMENTIONED FILE))) (DEFUN BAR () (FOO)) Gives a COMPLR diagnostic: (COMMENT **** |Foo String| Undeclared - taken as SPECIAL in function BAR)  Date: 10 JUN 1980 0610-EDT From: RWK,KMP at MIT-MC Sent-by: KMP at MIT-MC To: (BUG LISP) at MIT-MC The current LISP still has the new bug that I reported earlier where Autoload interrupts are queued up rather than being run if interrupts are deferred. It seems to happen if INHIBIT is -1,,0 as well. KMP will try and track down a minimal case. Needless to say, it's completely useless for AUTOLOAD "interrupts" to be EVER deferred. If one is about to be deferred, it would be FAR, FAR better to immediately give an error. The only problem is that the error will also lose, as witness the UNDEFINED-AFTER-AUTOLOAD error that happens when the interrupt is queued. The old LISP did not have this bug. I'm reasonably sure I didn't change anything in the vicinity. Will whoever did so please look at it?  Date: 9 Jun 1980 1310-EDT From: BRoberts at BBN-TENEXG (Bruce Roberts) Subject: GCTIME To: bug-lisp at MIT-MC On Twenex, (status gctime) returns a large negative number. doing (sstatus gctime 0) sets it to 0 but subsequent GCs produce more negative numbers. (this is version 1998) -------  Date: 9 JUN 1980 0551-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: JIMP at MIT-MC, KMP at MIT-MC, (BUG LISP) at MIT-MC JPG@MIT-MC (for JIMP) 06/05/80 0059-EDT ~LISP or ~IMSL The following works in OLDA^K (Macsyma created in LISP 1914) but does the following in A^K (Essentially the same Macsyma created in LISP 1997): LOADFILE(JIMP,MACSYM,JIMP); BATCH(VARGA9,1,JIMP); LOADFILE(IMSL,FASL,SHARE2); CRANK(1,7); quits to DDT with MPV;11710>>HLRZM 7,(7) after < 30 secs. has been fixed in the current LISP and hence in the current MACSYMA by RWK.  Date: 9 JUN 1980 0512-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: HAL To: (BUG LISP) at MIT-MC BTW, I just wrote out the *LISP for LISP version 2000. Due to the way ASSLIS etc. work, this necessitated renaming it to be *LISP 000. Due to the way the ITS filesystem handles >, this necessitated renaming all the *LISPs for earlier versions to be something else, so I named then 0LISP nnn  Date: 9 JUN 1980 0326-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: EVAL-WHEN To: (BUG LISP) at MIT-MC, ALAN at MIT-MC, GSB at MIT-MC EVAL-WHEN now returns the last form EVALed, or () if none. DEFVAR now returns the variable being SETQ'ed.  Date: 9 June 1980 02:57-EDT From: Kent M. Pitman Subject: eval-when's return value To: GSB at MIT-MC, ALAN at MIT-MC cc: BUG-LISP at MIT-MC (1) Sigh, I agree the logic as shown was faulty, but the sentiment, I hope we agree was not. HOWEVER, if I ever saw (AND (STATUS FEATURE MUMBLE) (EVAL-WHEN (EVAL) ...) (NOT (EVAL-WHEN (COMPILE) ...)) ...) I think I'd probably never forgive you ... (2) I agree with GSB's reasoning about LEDIT/LISPT/UREAD wanting to print something useful.  Date: 9 June 1980 02:51-EDT From: Alan Bawden To: KMP at MIT-MC cc: BUG-LISP at MIT-MC Date: 9 June 1980 01:30-EDT From: Kent M. Pitman ... EVAL-WHEN is truly a special form. It has a functional definition only in the interpreter (ie, only (EVAL-WHEN (... EVAL ...) ...) ever really gets eval'd on its on merit). The COMPLR and FASLOAD, as near as I can tell empirically with TRACE, never call EVAL-WHEN -- I presume they do (AND (EQ (CAR form) 'EVAL-WHEN) (MEMQ interesting-state (CADR FORM)) ...) type things. "SETQ is truly a special form. It has a functional definition only in the interpreter. The COMPLR and FASLOAD, as near as I can tell empirically with TRACE, never call SETQ ..." OK, I am convinced, EVAL-WHEN (like SETQ) is a special form. Hence, EVAL-WHEN is *NOT* meaningful (read: `legal') except as a toplevel form. "Hence, SETQ is *NOT* meaningful except as a toplevel form." URK. Let us ignore the beginning of your note, since your conclusion (that EVAL-WHEN is probably only reasonable at toplevel) is valid, despite the faulty reasoning that got you there. But note please, that I never suggested otherwise. Hence, its return value should be of as little consequence as possible to discourage relying on it ... The only use for having it return T/NIL might be in tracing of EVAL-WHEN's consed up by macros, but that seems pretty marginal to me. I think I would advocate it always returning NIL. In any case, I believe this all to be site-dependent as I am pretty sure I didn't tell Bernie about T/NIL return-values when he was doing the Multics-flavored version of this a month or two ago. Well, in fact the Multics version also returns T/NIL just like the ITS version. But, so what? Nobody ever really cared what it returned as far as I could tell, so I suggested a reasonable change that would increase the elegance of the situation. (PROGN 'COMPILE ...) could also be looked upon as such an animal, and it returns its last value. For further `support' of this feeling, note that the compiler will not allow it in function definitions. -kmp Again, the toplevelness is not an issue here.  GSB@MIT-ML 06/09/80 01:32:48 Re: eval-when's return value To: KMP at MIT-ML CC: (BUG LISP) at MIT-ML It is nice to have eval-when return the value of the last thing in the interpreter simply for the benefit of those things which do a read-eval-print loop over something, like ledit or uread/^Q.  Date: 9 June 1980 01:30-EDT From: Kent M. Pitman To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Date: 8 June 1980 04:08-EDT From: Alan Bawden To: BUG-LISP EVAL-WHEN doesn't appear to be a PROGN... it would be nice if EVAL-WHEN returned the value of the last thing evaled (or NIL?). This would seem to be more flavorfull anyway. (BTW the definition of DEFVAR clearly indicates that whoever wrote it thought that is what EVAL-WHEN did.) ----- EVAL-WHEN is truly a special form. It has a functional definition only in the interpreter (ie, only (EVAL-WHEN (... EVAL ...) ...) ever really gets eval'd on its on merit). The COMPLR and FASLOAD, as near as I can tell empirically with TRACE, never call EVAL-WHEN -- I presume they do (AND (EQ (CAR form) 'EVAL-WHEN) (MEMQ interesting-state (CADR FORM)) ...) type things. Hence, EVAL-WHEN is *NOT* meaningful (read: `legal') except as a toplevel form. Hence, its return value should be of as little consequence as possible to discourage relying on it ... The only use for having it return T/NIL might be in tracing of EVAL-WHEN's consed up by macros, but that seems pretty marginal to me. I think I would advocate it always returning NIL. In any case, I believe this all to be site-dependent as I am pretty sure I didn't tell Bernie about T/NIL return-values when he was doing the Multics-flavored version of this a month or two ago. For further `support' of this feeling, note that the compiler will not allow it in function definitions. -kmp  GSB@MIT-ML 06/08/80 04:42:50 Re: pad characters in format. To: GJC at MIT-MC CC: (BUG LISP) at MIT-ML Character values as format parameters may be trivially specified by preceding the character by a single quote in a parameter position; eg, "~5,'0d" for using "0" as the pad character.  Date: 8 JUN 1980 0408-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC EVAL-WHEN doesn't appear to be a PROGN. It seems to return T or NIL depending on wether it did, or didn't, eval. Since top-level DEFmumbleing things sometimes want to act like defun and return the name of the thing defined it would be nice if EVAL-WHEN returned the value of the last thing evaled (or NIL?). This would seem to be more flavorfull anyway. (BTW the definition of DEFVAR clearly indicates that whoever wrote it thought that is what EVAL-WHEN did.)  Date: 8 JUN 1980 0131-EDT From: GJC at MIT-MC (George J. Carrette) Subject: pad characters in format. To: (BUG LISP) at MIT-MC, GSB at MIT-MC The fact that you have to specify the pad character to a command like D in the base-10 ascii value might even be a step backwards from, say, (tyo #/0). Is there a better way to specify these arguments?  Date: 7 JUN 1980 2116-EDT From: HIC at MIT-MC (Howard I. Cannon) To: (BUG LISP) at MIT-MC I changed ALLOC so that the init file is read in automatically on TOPS-20/TENEX if the file LISP.INI exists in the connected directory. I made this change as a binary patch at Schlumberger and it works, but have not tested the change in the source. Someone should check it out the next time they rebuild the tops-20 version. --Howard  Date: 5 JUN 1980 0059-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, MACSYM at MIT-MC, KMP at MIT-MC CC: JIMP at MIT-MC The following works in OLDA^K (Macsyma created in LISP 1914) but does the following in A^K (Essentially the same Macsyma created in LISP 1997): LOADFILE(JIMP,MACSYM,JIMP); BATCH(VARGA9,1,JIMP); LOADFILE(IMSL,FASL,SHARE2); CRANK(1,7); quits to DDT with MPV;11710>>HLRZM 7,(7) after < 30 secs.  Date: 4 JUN 1980 1727-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC On twenex version, (MERGEF '((*) FOO BAR) ...) will generate a losing '(|| ||) unless ... specifies the device and directory. It should generate '(* *) for that field [the device-directory field].  Date: 4 Jun 1980 1218-EDT From: BSMITH at BBN-TENEXG Subject: CHARPOS on input files in general, and on the TTY in particular To: BUG-LISP at MC cc: Bsmith In general, CHARPOS is apparently not defined on input files ("(CHARPOS TYI)" returns an error, for example). Since it would very useful for such tasks as writing parsers for formatted input, this seems unfortunate, especially since there doesn't seem to be any deep reason why reasonable and straightforward behaviour could not be defined (even if EXACTLY matching the assumed behaviour on a display device might be an impossible ideal). More anomalous, however, is its behaviour on the TTY: READ apparently updates what CHARPOS returns, whereas READCH and TYI don't. What is particularly odd is that TYI and READCH must update SOMETHING, since calls to READ following calls to TYI know the character position, including how it was modified by the TYI input. For example, if one executes: (progn (setq a (charpos t)) (tyi) (setq b (charpos t)) (read) (setq c (charpos t))) B is always the same as A, whereas C reflects the character position reached by BOTH the TYI input and the READ input (READCH and TYIPEEK are just like TYI in this respect). This seems simply odd: if TYI and READCH affect some indicator of character position to which READ is able to refer, shouldn't CHARPOS be expected to reflect it? My desire, of course, would be to have CHARPOS work on input files in general; a smaller request would be to have it behave more rationally on the TTY. Comments? -------  Date: 4 Jun 1980 1204-EDT From: BRoberts at BBN-TENEXG (Bruce Roberts) Subject: DUMPARRAYS To: bug-lisp at MIT-MC DUMPARRAYS loses on tops-20. The call to FILLARRAY in it causes a machine error trying to transfer from array to file. And in the case of a "T" type array, the function BLTARRAY complains about a wrong type array. -------  Date: 4 JUN 1980 0622-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: CWH at MIT-MC, JIM at MIT-MC, GJC at MIT-MC, JPG at MIT-MC JPG@MIT-MC 3 JUN 1980 1814-EDT To: (BUG LISP) at MIT-MC, CWH at MIT-MC, JIM at MIT-MC I was trying to compile MACSYMA source files in order to dump out a MACSYMA in the new LISP. Doing CL^K ^G (LOAD '|ALJABR;COMPLR|) (MAKLAP1 (GRIND > DSK MRG)) gives the error you see in MUNFAS;GRIND _UNFA_ . Bug in the new LISP or compiler? Someone introduce a bug in some MACSYMA macro file? The error msg is ;RY-INTEGER undefined function object. Sorry, MUNFAS;GRIND _UNFA_ got overwritten and is no longer. Anyway, the bug only happens when you try to compile more than one file with the same loading of COMPLR, and possibly requiring the MACSYMA ALJABR;COMPLR compilation scheme. Which function is claimed to be undefined varies from instance to instance but is always some form of gubbish. So it seems something is not getting reinitilialized properly. And sometimes you can compile more than one file with the same loading of COMPLR. I don't have a simple reproducible example at the moment, but I'll be on the lookout for one.  Date: 3 JUN 1980 1814-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC, CWH at MIT-MC, JIM at MIT-MC CC: JPG at MIT-MC I was trying to compile MACSYMA source files in order to dump out a MACSYMA in the new LISP. Doing CL^K ^G (LOAD '|ALJABR;COMPLR|) (MAKLAP1 (GRIND > DSK MRG)) gives the error you see in MUNFAS;GRIND _UNFA_ . Bug in the new LISP or compiler? Someone introduce a bug in some MACSYMA macro file? The error msg is ;RY-INTEGER undefined function object.  Date: 2 JUN 1980 0835-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC Many times, READLINE seems to ignore some "control-characters" in its input line - a good example is when inputting from the TTY: ABC or when inputting from any file ABC Possibly the tty-scanner does something disastrous with the ??  Date: 1 June 1980 2302-EDT From: Dave Touretzky at CMU-10A Subject: Re: Appending files from MacLisp To: Tom.Cooper at CMU-10A (A780TC50) CC: bug-lisp at MIT-MC, Scott Fahlman at CMU-10A In-Reply-To: <31May80 121047 TC50@CMU-10A> Tom, There is an APPEND mode in MacLisp that you can use with the OPEN function to append onto a file. Unfortunately, it appears not to work in the current TOPS-10 version of MacLisp. Doing (OPEN '|FOO.BAR| 'APPEND) acts as if OUT had been used, and STATUS FILEMODE shows OUT instead of APPEND. Sigh. This should be fixable though. I've CC'ed this message to the appropriate wizards. -- Dave  Date: 31 MAY 1980 2226-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: #\VT To: JPG at MIT-MC CC: (BUG LISP) at MIT-MC, CWH at MIT-MC Someone put in a duplicate entry in the table for #\VT, but without the decimal point. I deleted the entry that was wrong.  Date: 31 MAY 1980 1959-EDT From: JPG at MIT-MC (Jeffrey P. Golden) To: CWH at MIT-MC CC: JPG at MIT-MC, (BUG LISP) at MIT-MC JPG;SUPRV refers to #\VT in several places. Somehow #\VT is coming out as 9. rather than as 11. All the others like it appear to be correct. I will just replace #\VT by NVT in SUPRV until you see what gives here.  Date: 31 May 1980 19:03-EDT From: Howard I. Cannon To: BUG-LISP at MIT-AI I fixed QIO so that opening the TTY in image mode for output works (it should also work for input, but I haven't tested it). I built a new version of 1998 on XX, and it seems to do just fine. This should make CURSORPOS more implementable.  Date: 31 MAY 1980 0853-EDT From: JONL at MIT-MC (Jon L White) Subject: New macros standardized in COMPLR To: BYRON at MIT-MC CC: (BUG LISP) at MIT-MC, (FILE [MC:LISP;NEW RECENT]) at MIT-MC the file MC:LSPSRC;MLMAC > contains some "MacLisp MACros" which are being standardized for compatibility with LISPM and NIL: HERALD SELECTQ FBOUNDP IF PAIRP DEFVAR SETQ-IF-UNBOUND WITHOUT-INTERRUPTS WITH-INTERRUPTS WITHOUT-TTY-INTERRUPTS  Date: 30 MAY 1980 2330-EDT From: GJC at MIT-MC (George J. Carrette) To: (BUG LISP) at MIT-MC The file GJC;TTYRD > shows a bug in read. The SFA does rubout-processing by using a *THROW. After that, TYI behaves strangely. Do (tty-read)(this is a [bug] to get the bug. ( "[" has been set up as a read macro character). (this bug is in the interpreted version, but not the compiled one, however, sharpm is broken in either case by the *throw).  GSB@MIT-ML 05/30/80 17:42:26 Re: READ flushing atom delimiters To: jonl at MIT-MC CC: MOON at MIT-ML, (BUG lisp) at MIT-MC After some thought i decided that what LMS wants anyway is to treat space as a "special token" the way it treats certain other characters. What is being done is parsing some set of tokens, which include parens, symbols, and breaks, the last of which includes space, newline, and tab. Thus for it to check for space (or other breaks) with TYIPEEK can be claimed to be inconsistent. The COBOL parser would behave similarly. In any case, the dynamic use of the READ-PRESERVE-DELIMITERS switch would obviate the need for these changes. (Interestingly, i have yet a third thing which could be broken by the change but will not, since it "parses" space as a special token.) By the way, in case it wasn't mentioned, BREAK should bind the switch to NIL.  Date: 30 MAY 1980 1631-EDT From: MOON at MIT-MC (David A. Moon) Subject: READ flushing atom delimiters To: JONL at MIT-MC CC: (BUG LISP) at MIT-MC, gsb at MIT-ML Well, I discussed that very issue with GSB and decided that on the whole it was a little bit better to have a variable you could bind rather than a separate function or an additional optional argument to READ. It certainly would not be a win to globally setq the special variable "to make the whole Lisp work the old way", but my idea is that certain reader macros, e.g. the LMS open bracket, would bind it on and then their various internal calls to READ would be automatically changed. One example of where a problem occurs with the separate-function approach (which does not actually show up in LMS I believe) is if you have something which wants to see the delimiter and calls READ on an S-expression which turns out to be ' (single-quote) and an ATOM. The single-quote macro would have no way of knowing to call the other version of READ, and hence would swallow the space after the quoted atom, which presumably is not what the caller wants.  Date: 30 MAY 1980 0631-EDT From: JONL at MIT-MC (Jon L White) Subject: READ flushing atom delimiters To: MOON at MIT-MC CC: (BUG LISP) at MIT-MC, INFO-LISPM at MIT-MC Date: 30 May 1980 00:23-EDT From: David A. Moon . . . I f the delimiter is a "useless" or "whitespace" character, it will be thrown away, rather than being UNTYI'ed back into the stream so that it can be TYI'ed later. This will happen regardless of whether the symbol or number is seen at top level or is inside of an expression, . . . Certain programs, such as reader macros, may be broken by this. For them, a special variable which they may bind is provided. If READ-PRESERVE-DELIMITERS is bound non-NIL around a call to READ, all delimiters are preserved regardless of whether they are whitespace or meaningful characters. . . . I would like to request a compatible change to Maclisp, to avoid divergence and incompatibility on this point. As it happens, GSB and I made this change to one version of a recent XLISP, probably about version 1984 or so, but had to take it back when GSB found he didn't have the time to accomodate his LMS and COBOL code. What we were hoping to do was provide an additional function, say, READ-AND-BREAK-CHAR, which would return both the item read and the termination character. For backwards compatibility, someone may raise an objection to not haveing a "backwards-compatible-switch" (i.e. READ-PRESERVE-DELIMITERS), but for future use, the explicit request to return the termination character seems like a better approach for those very few programs which want it. Any comments?  Date: 30 May 1980 00:23-EDT From: David A. Moon Subject: Change to READ To: INFO-LISPM at MIT-AI cc: BUG-LISP at MIT-AI In the next Lisp machine system released, the way READ deals with delimiting characters for those S-expressions that need one (symbols, numbers) will be subtly changed. If the delimiter is a "useless" or "whitespace" character, it will be thrown away, rather than being UNTYI'ed back into the stream so that it can be TYI'ed later. This will happen regardless of whether the symbol or number is seen at top level or is inside of an expression, and regardless of whether input is being read from the keyboard or from a file. This was chosen after much consideration and dithering, because it is simpler and more understandable than a scheme where the delimiter is sometimes retained and sometimes discarded. Certain programs, such as reader macros, may be broken by this. For them, a special variable which they may bind is provided. If READ-PRESERVE-DELIMITERS is bound non-NIL around a call to READ, all delimiters are preserved regardless of whether they are whitespace or meaningful characters. I believe there are no programs other than LMS (which doesn't run on the Lisp machine currently) which care about this. However, if you have a problem with this change READ-PRESERVE-DELIMITERS should make it easy to fix your code. This change obviates most of the need for the function SI:READ-FOR-TOP-LEVEL, however that function is still around for the purpose of ignoring unmatched close parentheses and because there are many places that call it. I would like to request a compatible change to Maclisp, to avoid divergence and incompatibility on this point.  Date: Wednesday, 28 May 1980 18:52-PDT From: MACRAKIS at USC-ISIE To: Bug-Emacs at mc, Bug-Lisp at mc, MT at XX CC: Macrakis at USC-ISIE Subject: Is Maclisp .MCL or .LSP? The Twenex Tags program assumes that programs with a second file name of LSP are Interlisp, and that those with one of MCL are Maclisp. Emacs, however, only goes into Lisp mode with the LSP filename. (Won't Emacs Lisp mode be about right for Interlisp, anyway?) Maclisp uses a default second file name of LSP. Can Tags, Emacs, and Maclisp be brought into agreement on this? I would prefer LSP, but I suppose there are large bodies of Interlisp programmers ready to rebel, so MCL will do as long as it's applied consistently.  GSB@MIT-ML 05/28/80 05:54:01 Re: lap To: (BUG LISP) at MIT-ML If i happen to be working in a lisp for which ddt has symbols loaded, and i happen to read in some lap which happens to have a symbol which could possibly be construed to be a Lisp symbol in the first 6 characters, i get shafted because Lap will for example use the ddtsym for CURSOR when i have defined a tag named CURSORPOS-FAILURE.  Date: 26 May 1980 1622-EDT From: KLOTZ.GJC at MIT-EE Subject: RUBOUT on SFA's. To: BUG-LISP at MIT-MC RUBOUT does not know to send a RUBOUT message to SFA's, instead, it gives an error when called on one. -------  Date: 26 MAY 1980 0604-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC It is OK for garbage collection to close open files that no one still has a pointer to, however it is NOT ok for the GC to perform a uclose on a garbage job array. I suspect that this is what it DOES do, so someone should check it out and fix it if that is indeed the case.  Date: 24 MAY 1980 1043-EDT From: PIQUE at MIT-MC (Maurice Pique) To: (BUG LISP) at MIT-MC Hey, how come when I have an SFA-HANDLER that supports TYO but not TERPRI, it still gets passed a TERPRI message when I say (TERPRI ). Couldn't you just have lisp simulate the thing so I don't lose?  Date: 23 MAY 1980 0534-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC CC: WAM at MIT-MC, PSZ at MIT-MC GSB@MIT-ML 05/23/80 03:12:50 Re: MEMBER & user hunks in xlisp The MEMBR loop expects AR2A to be saved around the PUSHJ P,EQUAL. If there are user hunks it is not. I just patched the ITS versions, but have not yet edited in the correct change - just delete the "POP P,A" found at EQLHN5.  GSB@MIT-ML 05/23/80 03:12:50 Re: MEMBER & user hunks in xlisp To: (BUG LISP) at MIT-ML CC: PSZ at MIT-ML, WAM at MIT-ML The MEMBR loop expects AR2A to be saved around the PUSHJ P,EQUAL. If there are user hunks it is not.  Date: 22 MAY 1980 1802-EDT From: MOON at MIT-MC (David A. Moon) Subject: &IGNORE To: JONL at MIT-MC, CWH at MIT-MC, WGD at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC Why don't you simply fix the Ncomplr bug which causes code such as (defun foo (x y z) y ;y is ignored (frob x z)) to get a "bound but never used" error for y? This is the construct we use in the Lisp machine.  Date: 22 MAY 1980 1727-EDT From: JONL at MIT-MC (Jon L White) Subject: &IGNORE To: CWH at MIT-MC, WGD at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC Date: 21 May 1980 23:26-EDT From: Carl W. Hoffman Subject: Ugliness ... WGD@MIT-MC 05/21/80 06:32:07 Re: Ugliness ... I think this referencing of unused "vestigials" as opposed to . . . It should be pretty trivial to implement, in all systems (LMLisp, Multics maclisp, PDP10 maclisp) a simple DECLAREation for IGNORE, with the same scoping and utility of the current SPECIAL declaration; note that this is not the same as an & keyword. The distinction come when one consideres the rather optional, advisory nature of IGNORE (simply not see some warning message), and the "hard-core" nature of &OPTIONAL and &REST (etc.). While there is no conceivable purpose to be served by trying to bind (), and it should be permissible as an "ignored variable", the local declaration form allows ignored variables with mnemonic content; I'd be happy to do it in maclisp (has already been done in the NIL compiler) - would take hardly 10 minutes - would there be cooperation from the other places?  Date: 21 MAY 1980 2148-EDT From: KMP at MIT-MC (Kent M. Pitman) To: (BUG LISP) at MIT-MC Why does INCLUDEF have an args definition of (0 . 2) ...? It is documented to accept and seems happy with just one arg. -kmp  Date: 21 May 1980 12:10-EDT From: Kent M. Pitman To: ALAN at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 May 1980 17:33-EDT From: Alan Bawden To: BUG-LISP I seem to remember seeing this complaint before but: why is (VALRET) the same as (QUIT) ?? The only documentation I find for valret of no args is in the old Moonual, where it claims that (VALRET) was like (IOC Z) which certainly isn't (QUIT)! ----- There should exist a site-independent way of returning harmlessly to the monitor. RWK doesn't think that VALRET is the optimal name -- I think that the best name we could pick is one that would cause broken code to work again. Anyway, I have complained about this in the past and so finally just looked at the code. There is a label VLRT9 which it jumps to if no args were given. It should be jumping to VLRT9+1 (or call it VLRT10 for all I care) ... Other things like (VALRET '|.|) do jump to VLRT9, which is probably a good idea... I'd make the change but I don't know what is appropriate on non-ITS sites. Currently, it is at least consistently wrong (dies everywhere) ... -kmp  Date: 20 MAY 1980 1733-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC I seem to remember seeing this complaint before but: why is (VALRET) the same as (QUIT) ?? The only documentation I find for valret of no args is in the old Moonual, where it claims that (VALRET) was like (IOC Z) which certainly isn't (QUIT)!  Date: 19 May 1980 07:03-EDT From: Scott J. Kramer Subject: (CLOSE ) To: BUG-LISP at MIT-MC This doesn't reset the TTYSTS variable on ITS or JFN mode word on Twenex; seems like a bug to me. -sjk  Date: 17 MAY 1980 1329-EDT From: JONL at MIT-MC (Jon L White) Subject: varieties of "NETS" for catching To: CWH at MIT-MC, GSB at MIT-MC CC: NIL at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC Date: 15 May 1980 13:43-EDT From: Alan Bawden To: CWH at MIT-MC CWH@MIT-MC 05/15/80 01:45:26 (*CATCH '(A B C) (COMPUTE)) in MacLisp means to catch throws to any one of the tags A, B, C. Really? (Amazing, it really does work that way!) That is not an advertized feature as far as I can tell. Perhaps someone should document it somewhere. During the late summer of 1978, the NIL/MACLISP/LISPM community seemed to reach agreement about the names and functionalities of the various catchers. Although this included lists of tags, as well as a single atomic tag, as argument to CATCH and CATCH-BARRIER, it was never fully documented in maclisp's LISP NEWS. The general idea was that the name *CATCH was to be a temporary expedient until we could expunge all usages of the restrictive old-style CATCH. Then, we'd re-introduce the name CATCH with the new winning syntax (as in *CATCH) and advertise its "tag-list" extension. This has not yet been done for maclisp. NIL has all these features right now (along with a macro defintion for *CATCH which merely turns it into CATCH), and shortly then we'll be able to say that maclisp's catchers are a copy of NIL's. By the bye, CATCHALL was invented for just the reason which GSB pines for - to intercept all THROWs and inspect them. The idea was that if the "inspection test" fails, the CATCHALL function merely does a THROW (or is it a "*THROW"?) with the given tag and value, in order to continue the throwing. Admittedly this lets an unseen-throw-tag error occur higher in the stack than one would like, but . . .  Date: 17 MAY 1980 1236-EDT From: JONL at MIT-MC (Jon L White) Subject: New macro definers To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC, MACSYMA-I at MIT-MC Date: 15 May 1980 11:24-EDT From: George J. Carrette Subject: simple DEFMACROs Date: 15 MAY 1980 0425-EDT From: JONL at MIT-MC (Jon L White) try (DEFSIMPLEMAC FOO (X) `(LIST ,x ,x)) it will automatically "wrap" a LAMBDA around things for the sake of multiple occurrences of "x", if needed. A win. For even more winnage, can it arrange to be a SUBR in the interpreter? Say, I forgot to mention DEFBOTHMACRO and DEFCOMPLRMACRO. These, along with DEFSIMPLEMAC are defined in the file MC:NILCOM;MACAID >, and possibly can be understood from the (minimal) commentary appearing in their definitions. We've been intending to release a new LISP (XLISP ==> LISP) but one of the snags is the time to go thru and figure out all the things that need documenting. Anyway, briefly, DEFBOTHMACRO makes a SUBR definition, *along with* a macro-definition which is active only in the compiler; DEFCOMPLRMACRO makes a macro-definition which is active only in the compiler. Both of these look for the key word "SIMPLE" after the function/macro name, and if present, use the DEFSIMPLEMAC form instead of DEFMACRO form. Limitation: DEFSIMPLEMAC can only accept definitions of one argument, e.g. (DEFSIMPLEMAC FOO (X) `(AND ,X (FOO ,X))) but *not* (DEFMUMBLEMAC BAR (X Y) (LIST X Y))  Date: 15 May 1980 23:38-EDT From: Kent M. Pitman To: ALAN at MIT-MC cc: GJC at MIT-MC, BUG-LISP at MIT-MC Date: 15 May 1980 22:28-EDT From: Alan Bawden To: KMP cc: GJC, BUG-LISP Re: #.(TYIPEEK #\FORM) Why do it right when a kludge will suffice! Come to think of it a lot of things could be implemented by doing #.() like #.(or (status feature Multics) (read)) could replace #+Multics There is this problem that both these guys return a value that is left for read to return. (my thing should read "(progn (read) nil)" so as to do the right thing.) This is really all completely losing. ----- Oops. I stand corrected. You want #.(PROGN (TYIPEEK #\FORM) (READ)) if you are going to be (READ)'ing from the line before ... I am simply questioning the usefulness of your construct. I claim that comments of the form you describe are hard to recognize in the editor if the #; falls off the screen to the top and you are left only with the ostensibly commented-out part in view. Hence, I'd rather not give up a # char for that purpose. -kmp ps btw, for #+Multics you want #.(COND ((STATUS FEATURE MULTICS) (READ)) (T (READ) (READ)))  Date: 15 May 1980 22:28-EDT From: Alan Bawden Subject: #.(TYIPEEK #\FORM) To: KMP at MIT-MC cc: GJC at MIT-MC, BUG-LISP at MIT-MC Why do it right when a kludge will suffice! Come to think of it a lot of things could be implemented by doing #.() like #.(or (status feature Multics) (read)) could replace #+Multics There is this problem that both these guys return a value that is left for read to return. (my thing should read "(progn (read) nil)" so as to do the right thing.) This is really all completely losing.  Date: 15 MAY 1980 1502-EDT From: kmp at MIT-MC (Kent M. Pitman) Sent-by: ___136 at MIT-MC Subject: #; To: GJC at MIT-MC CC: (BUG LISP) at MIT-MC Is #.(TYIPEEK #\FORM) really that hard to type? -kmp  Date: 15 MAY 1980 1438-EDT From: GJC at MIT-MC (George J. Carrette) Subject: suggested # character. To: (BUG LISP) at MIT-MC How about #; being like ";" except that it gobbles to the next form-feed?  Date: 15 MAY 1980 1343-EDT From: ALAN at MIT-MC (Alan Bawden) To: CWH at MIT-MC CC: (BUG LISP) at MIT-MC CWH@MIT-MC 05/15/80 01:45:26 (*CATCH '(A B C) (COMPUTE)) in MacLisp means to catch throws to any one of the tags A, B, C. Really? (Amazing, it really does work that way!) That is not an advertized feature as far as I can tell. Perhaps someone should document it somewhere.  Date: 15 MAY 1980 0629-EDT From: JONL at MIT-MC (Jon L White) To: (BUG LISP) at MIT-MC ASSQ and many other functions seem willing to take in hunks and treat them as list, although the default settings of the switches are supposed to mean "distinguish" between hunks and lists? Even if the defaults change, ASSQ does'nt have the means to check right now.  Date: 14 MAY 1980 1240-EDT From: BUDD at MIT-MC (Phil Budne) Sent-by: ___053 at MIT-MC Subject: TOPS-10 and 1984 Lisp To: (BUG LISP) at MIT-MC The problem with setsts on the tty is caused by several missing ()'s ie; the code SETSTS TMPC,66 when the code should probobly be SETSTS TMPC,(6) Well Timeout is about to hit me.. Thanx..... Felicitations, Philip Budne  Date: 14 MAY 1980 1049-EDT From: JONL at MIT-MC (Jon L White) Subject: STRING-SEARCH-NOT-SET To: RWK at MIT-MC CC: (BUG LISP) at MIT-MC Date: 13 May 1980 22:38-EDT From: Robert W. Kerns (STRING-SEARCH-NOT-SET '(~f ~r) "foobarf") ==> 0 I.e. it isn't understanding character objects. RIGHT! The LISPM definition of this function requires the numeric representation.  SATIN@MIT-ML 05/14/80 10:36:21 Re: previous report on print-object To: (BUG LISP) at MIT-ML CC: PSZ at MIT-ML actually, it popj's to the third argument to PRINT-OBJECT. Someone isn't cleaning up the pdl before the early exit.  SATIN@MIT-ML 05/14/80 10:33:56 Re: print-object bug To: (BUG LISP) at MIT-ML CC: PSZ at MIT-ML If ^W is T and PRINT-OBJECT gets called with a stream argument of NIL, it appears to popj to TRUTH.  Date: 14 May 1980 07:51-EDT From: Grandiose System Building Subject: FORMAT Bugs To: CWH at MIT-MC cc: BUG-LISP at MIT-ML Date: 13 MAY 1980 2249-EDT From: CWH at MIT-MC (Carl W. Hoffman) 1) (FORMAT T "~3f" 3.14159) warns that F is not a known control character. When the term is over. I think "warn" rather euphemistic. 2) In the case where ~< is used with four arguments, the first argument is taken to be the pad character rather than the fourth, e.g. (FORMAT T ~80,0,1,';<...~>") pads with P's (ascii 80) rather than semis. Found it. Should be tested and installed shortly.  Date: 13 MAY 1980 2249-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC FORMAT bugs: 1) (FORMAT T "~3f" 3.14159) warns that F is not a known control character. 2) In the case where ~< is used with four arguments, the first argument is taken to be the pad character rather than the fourth, e.g. (FORMAT T ~80,0,1,';<...~>") pads with P's (ascii 80) rather than semis.  Date: 13 MAY 1980 2238-EDT From: RWK at MIT-MC (Robert W. Kerns) To: (BUG LISP) at MIT-MC (STRING-SEARCH-NOT-SET '(~f ~r) "foobarf") ==> 0 I.e. it isn't understanding character objects.  Date: 13 MAY 1980 2157-EDT From: RWK at MIT-MC (Robert W. Kerns) Subject: IN to SFA's To: (BUG LISP) at MIT-MC, JLK at MIT-MC $IN+12/ PUSHJ P,RST5M1 FXP,$> I've fixed this in the source and patched it on ITS (LISP and XLISP). EE is down due to no chilled water, so I haven't patched it there yet.  Date: 13 MAY 1980 2114-EDT From: JLK at MIT-MC (John L. Kulp) Sent-by: MEM at MIT-MC To: (BUG LISP) at MIT-MC Can someone verify for me that IN works on SFA'S ? I always get ILOPR's when I try it.  GSB@MIT-ML 05/11/80 02:26:21 To: (BUG LISP) at MIT-ML i installed a new FORMAT which purports to implement GLS's changes. Previous one is FORMAT OFASL & FORMAT OAUX on AI, MC, and ML.  Date: 10 MAY 1980 2134-EDT From: SJK at MIT-MC (Scott J. Kramer) Subject: More (CURSORPOS '-) To: (BUG LISP) at MIT-MC My mistake, it's actually (CURSORPOS '_) and does work properly. Twas hard to tell the difference without some context. -sjk  Date: 10 MAY 1980 1734-EDT From: BUDD at MIT-MC (Phil Budne) Subject: TOPS-10 and 1984 To: (BUG LISP) at MIT-MC Loading CGOL.FAS (and others) gives the following error ?ill data mode for device ttynn in routine sstty .RU LISP[nn,nn];foo.ini[12,34] the file is never found Trying to use CCLOAD.INI option 1 gives attempt to write into pur page after asking the location of the .fasl files Using option N of ccload gets as far as the line "Initializing" then the error ;LSUB undefined function in UUo call -Phil Budne If you need a Bots and can call NJ cheaply I will lend my accounts.  Date: 10 May 1980 16:28-EDT From: Robert W. Kerns Sender: ___023 at MIT-MC Subject: (CURSORPOS '-) To: SJK at MIT-MC cc: BUG-LISP at MIT-MC This only works if your terminal supports insert-delete character, and you hve %TOCID set. Does it not work under these conditions?  Date: 10 MAY 1980 1452-EDT From: SJK at MIT-MC (Scott J. Kramer) Subject: (CURSORPOS '-) To: (BUG LISP) at MIT-MC It's "delete character" and it doesn't work. -sjk  Date: 9 May 1980 18:15-EDT From: Richard M. Stallman To: BUG-LISP at MIT-AI Date: 8 May 1980 2257-EDT From: BUDNE at DEC-2136 Please do you have any suggestions? I have moved HSGORG on my Bots-10 assemblies up to 500K and LISP still complaind about being out of core after 100p regradless of the accouns's limit of core. reply to Budd@mc thanx 10e+06! Phil Budne -------  Date: 9 MAY 1980 1002-EDT From: JONL at MIT-MC (Jon L White) Subject: COMPLR dying upon load-up for certain UNAMEs To: GSB at MIT-MC CC: (BUG LISP) at MIT-MC, (BUG COMPLR) at MIT-MC, RIVEST at MIT-MC GSB@MIT-ML 05/05/80 23:54:59 Re: sharable frobs Is there a fix in store for the problem of Lisp's attempting to intern things before all the pages are in? If not, it would be proper to deinstall the current compiler so that random percentage of people whose (STATUS UDIR) interning gets an MPV don't continue to get scrod. I replied to this note a few days ago before having a chance to look at the problem, but now I've found it. XLISP, but not LISP, has all the system SITE symbols assembled into it, so there is no need to do interning of a new name upon load up (same binary and dump is now used on all three ITS systems). Although it would be possible to patch around the problem in LISP, it's not worth it since XLISP will become LISP next week. This your suggestion, to de-install the complr made up from SHARABLE (lisp version 1914), and just make it up from ordinary lisp, is right on. XCOMPLR, and COMPLR as of next week, will of course, be made up in SHARABLE.  Date: 9 MAY 1980 0949-EDT From: JONL at MIT-MC (Jon L White) To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC Date: 9 May 1980 08:07-EDT From: "Guy L. Steele, Jr." ALFL6B+1/ .IOT A a,>[Return] I.e., there's a channel number missing. Yea, thanks for finding this one - this is the reason why a JCL-specified "INIT" file which is missing caused LISP to undergo a "execution" death by DDT rather than a graceful "resignation". The real culprit was the fact that the label ALFL6B had been moved (who knows when?), for the channel number was to have been filled in by some other ALLOC code. The fix should really be %ALLOC+70/ DPB T,127614 [Tab] 270400,,ALFL6B Q+1[Return] I've patched the dumps, and edited the source.  Date: 9 May 1980 08:07-EDT From: "Guy L. Steele, Jr." To: BUG-LISP at MIT-AI ALFL6B+1/ .IOT A a,>[Return] I.e., there's a channel number missing.  Date: 8 MAY 1980 1552-EDT From: JONL at MIT-MC (Jon L White) Subject: Loss of Maclisp compiler To: (BUG LISP) at MIT-MC, MATHLAB at MIT-MC If by any chance, the dumped maclisp compiler should be "damaged" on any of the ITS systems, it is perfectly adequate merely to FTP the corresponding dump file from another ITS system. Currently, the two files of interest are: for COMPLR - COMLAP;CL.DMP > for XCOMLR - COMLAP;XC.DMP > Some existing code may need the facilities of the new XLISP/XCOMPLR in order to be successfully compiled and run. When in doubt, try the "Xperimental" system. XLISP will probably be turned into LISP next week.  Date: 8 MAY 1980 1531-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC JLK;CTEST > causes the compiler to die in some obscure way. I can't track it down further.  Date: 8 MAY 1980 1041-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC (DEFVAR X) expands into (EVAL-WHEN (EVAL LOAD COMPILE) (AND (STATUS FEATURE COMPLR) (SPECIAL X))) Doesn't this mean that if X is declared special in a macro package, and I load the macro package while compiling a different file, then X is declared special for that file as well? This also increases the size of fasl files. (DECLARE (SPECIAL X)) seems sufficient to me.  Date: 6 MAY 1980 1201-EDT From: psz at MIT-MC (Peter Szolovits) Sent-by: JONL at MIT-MC Subject: EQUAL To: (BUG LISP) at MIT-MC EQUAL should do a "EQ-FOR-EQUAL?" test before deciding not to send the 'EQUAL message to a USER-HUNK; also, it shold look at both args for being user-hunks.  Date: 6 MAY 1980 1200-EDT From: jonl,psz at MIT-MC Sent-by: JONL at MIT-MC Subject: PRINT calls FLATSIZE too often To: (BUG LISP) at MIT-MC At PRINLP, there is the test of the "TERPRI" condition, and if it isn't being used, there is no need to have called FLATSIZE. We should have each call to PRINLP do this test first before computating the flatsize - it makes a big difference in the use of USER-HUNKS, since the flatsize computation time may be quite large.  Date: 5 MAY 1980 2018-EDT From: JONL at MIT-MC (Jon L White) Subject: DOLIST To: (BUG LISP) at MIT-MC Has the same bug as DOTIMES had some time ago - namely a DECLARE as the firt "statement" is not being properly reconfigured into the DO. Also, should provide an automatic FIXNUM declaration for the index variable.  RIVEST@MIT-ML 05/05/80 01:32:21 To: (BUG LISP) at MIT-ML NCOMPLR seems to be broken on ML. It won't even start-up properly...  Date: 5 MAY 1980 0004-EDT From: HMR at MIT-MC (Harry M. Rath) To: (BUG LISP) at MIT-MC CC: DUFTY at MIT-MC Somebody must have changed something WRT autoloading and what happens when you get an autoload while interrupts are locked out. Right now in LISP 1991, what happens is the autoload is QUEUED!!! This, of course, is a completely useless thing to do with an AUTOLOAD! It does not queue the autoload in LISP, only in XLISP. Who's been poking around in that vicinity?  Date: 3 May 1980 22:24-EDT From: Kent M. Pitman To: JLK at MIT-MC cc: BUG-LISP at MIT-MC To BUG-LISP: You were spared most of the big argument that resulted. This is the tail end.... Well, I think that common macro and library bases is what LIBLSP is all about. I think IOTA is a real winner -- and other macros I have are pretty neat and general too -- but I can understand why people don't want them in the language for now. There are subtle differences of opinion and until a full concensus is reached, they shouldn't be given that sort of preference. LIBLSP is an integral part of the Lisp community -- and that people should make an effort there too at standardization; but I distinguish it from the language proper. Well, I guess that pretty much says it. As to LOOP, we'll have to wait and see what others feel on the issue. -kmp  Date: 1 May 1980 16:48-EDT From: John L. Kulp Subject: Autoload properties and stuff To: KMP at MIT-MC cc: RWK at MIT-MC, GSB at MIT-MC, REES at MIT-MC, BUG-LISP at MIT-MC Your comments are rather full of inconsistencies. Making a macro autoloadable does not make it part of the language. If a user provides his own definition of a macro, it does not affect other compiled code. It is certainly not the case that anywhere near everything that is autoloadable is documented in the manual (new or old), and there are many other things autoloadable which are not part of the language in any sense. I hope your argument about in-fix notation is not misinterpreted as an argument against keywords. Also, the trouble with control forms is that they do not naturally fit into the applicative notion of pure LISP. While I don't want to get in a position of defending in-fix notation, it seems that it is occassionally a lesser evil when compared to completely convoluted constructs one sometimes falls into with nested-list notation. To me it is more important for a program to be understandable, and I believe you can judiciously use both in-fix, keyword, prefix, and nested-list notations to achieve that. It is just as fallacious to claim that using in-fix notation results in less clarity as it is to claim that pure applicative style guarantees clarity. Both have to be used where it is appropriate, not where it results in confusion. You seem to have a rather arbitrary view of what should be in "primitive LISP". PROG, COND, and GO are adequate, so why have DO at all? The answer is obvious, as is the need for something like LOOP. I do not claim the LOOP is the ultimate win, but I have been screwed often enough by the restrictions of the so-called "generalized" DO, that I think we need something better. I also doubt that a clean syntax can be found using nested-lists that is as readable as one that uses keywords. I find that ambiguous notions like "LISP style" are abused almost as often as terms like "lexical scope". Pure LISP style, if it means anything, means a pure applicative style which allows for no special forms. If you allow special forms, then you need a theory of what makes one "pure" or not. It is not at all clear that "pure" is equivalent to "useful". Prefix notation and nested structure are useful where they help connote semantic meaning, and they are a burden where they inhibit it. Similarly, universality and simplicity are nice goals, especially for pedagogic situations, but they can also result in a sort of unstructured homogeneity. Your argument about English words is absurd. Anyone who writes code with short English words as names for functions deserves what he gets. I suggest just that opposite. All English single words should be reserved for the language, and the user should only use names with dashes or package prefices (or otherwise non-words in the human language sense). [This too is only half-serious...]  Date: 1 May 1980 13:18-EDT From: Kent M. Pitman Subject: Autoload properties and stuff To: JLK at MIT-MC, RWK at MIT-MC, GSB at MIT-MC, REES at MIT-MC, BUG-LISP at MIT-MC Hey, can I inject a couple of points here? (Too late, by the time you send in your 'no' reply, I'll already have sent this) ... I think it's fine to decide that something is useful but even if a large number of people use it I'm not sure if that should be the sole criterion for acceptance. There are issues of style coherence and other things like that that have to be taken into account... (1) What should be primitive? (a) Is making something autoload the same as making it primitive? Yes. It's a statement on the part of the implementors that if something goes wrong with it (barring commitments to NIL projects and silly things like that) that they will take a look at it. It's an implicit endorsement of the construct (how many times have you heard some novice say (eg, when you tell him not to use FEXPR's) ``But if I shouldn't use it then why is it in the language?'' (b) Why shouldn't LOOP be primitive? I believe that infix keywords have no place in primitive Lisp. People that want to have such things can do so. Putting them on on public directories so that others don't recreate the wheel if that's what they really want is also ok. But putting them in the language is just a violation of Lisp style. If people want infix-like primitives, let them use Algol or CGol. I don't believe in pretending that code is English. It gets you into bugs where you look at the code and can't figure out what's wrong with it because you're locked in a mode thinking that the wording is right so what is the matter? This doesn't always happen. It just can happen. It can happen to novices more than us and they're the ones most apt to use it because it will look simplest. And I think that's bad. I would rather teach them to get used to DO. I don't think that there is anything at all conceptually inelegant about the way DO does any of its things. (2) Why does the word LOOP not want to get locked down? I think we need to be careful about locking down namespaces to things that are not really primitive. If I ever want to use the word LOOP as a name, I will be stuck with redefining a system function (macro). I'll probably feel forced to pick another name. I think it's a bad idea for Lisp to lock down really common words for special-purpose applications. I resented the introduction of IF because I (like many others) had an incompatible use with the one that became standard; but I agree that it was a reasonable thing to have done anyway, because I think the IF notion which was introduced had sufficient generality that it was likely to be useful to everyone in the long run. People like to write programs that use short, mnemonic names. If you take all useful short names and make them do system things, then people start having to write code with long hairy names. I'm sure the LOOP implementors would feel the same if I showed them some of my LOOP macros and suggested that my stuff become standard. They would, I should hope, become indignant that they should have to give up their claim to such a nice name for the sake of system compatibility. I'd almost advocate not allowing English words to become Lisp builtins if no other short English synonyms for those words were going to be left for the user... (only half serious, but if you think hard you can probably extract what I really mean from the statement.) -kmp  Date: 1 May 1980 09:18-EDT From: John L. Kulp Subject: Autoload properties To: RWK at MIT-MC cc: BUG-LISP at MIT-MC, GSB at MIT-MC, REES at MIT-MC What is your criteria for this? It seems to me that if a substantial subcommunity uses a feature and it does not conflict with other built-in features, there is no reason not to include it. Speaking specifically about LOOP, I am surprised that there has not been more discussion in the recent flaming about DO concerning the various inflexibilities it manifests (e.g. awkwardness of initial clauses, inability to conveniently order multiple stepping clauses and end-tests, etc.). The only negative thing I have heard about LOOP is its keyword driven syntax (this being negative is certainly subject to debate since, as Moon recently pointed out, there are limitations to nested-list syntax in terms of one's ability to use and understand it). My figure of merit for such features is a combination of the ease with which I can specify the control I want and the ease with which I can understand code written with such constructs. ("ease" is mental effort + typing effort). Convenient iteration primitives are so basic to a programming environment that something like LOOP should be endorsed as a "standard" before long (note that LOOP doesn't necessarily obviate the need for simple, direct primitives such as DOTIMES, DOLIST, REPT, etc.). WRT FERROR and friends, I don't have an opinion on this yet other than the fact that it is important to have it.  Date: 1 May 1980 04:19-EDT From: Kent M. Pitman Subject: Finding largest integer To: CWH at MIT-MC cc: BUG-LISP at MIT-MC, KMP at MIT-MC, Dave.Touretzky at CMU-10A Date: 1 May 1980 02:48-EDT From: Carl W. Hoffman Date: 30 April 1980 1812-EDT From: Dave Touretzky at CMU-10A Is there any variable or status call in MacLisp that gives the maximum integer (excluding bignums) and minimum integer representable ... Date: 30 APR 1980 1830-EDT From: KMP at MIT-MC (Kent M. Pitman) Perhaps a (STATUS INFINITY)? A (STATUS WORDSIZE) would probably help... Assuming that two's complement arithmetic is being used, (ROT 1 -1) will give you the smallest fixnum, and (LSH -1 -1) will give you the largest fixnum. (HAULONG (ROT 1 -1)) will give you the number of bits in a fixnum. Outside of code that is a part of the Lisp system, there should be no need to know the actual wordsize of the machine. Bit vectors are available in both LMLisp and NIL. Well, as much as I am sure that we will never try to transport to a non-2's complement machine, I don't think it lends to code transparency to see this sort of hackery. We are talking about precisely very machine dependent things. Compilers may want to do things with word size. Constructs that return this information for real with no strings attached are really called for and I don't think they are just sugar. They may not get used often but the places where they do, you *really* want to be sure the right thing is happening. -kmp  Date: 1 May 1980 02:48-EDT From: Carl W. Hoffman Subject: Finding largest integer To: BUG-LISP at MIT-MC cc: MICHAEL HOROWITZ AT CMU-10A at MIT-MC, KMP at MIT-MC, Dave.Touretzky at CMU-10A Date: 30 April 1980 1812-EDT From: Dave Touretzky at CMU-10A Is there any variable or status call in MacLisp that gives the maximum integer (excluding bignums) and minimum integer representable on the machine? I know the answer, I just want to know if I can get MacLisp to tell me. Date: 30 APR 1980 1830-EDT From: KMP at MIT-MC (Kent M. Pitman) My FORTRAN stuff would love to know this, too. Perhaps a (STATUS INFINITY)? A (STATUS WORDSIZE) would probably help, but for languages like NIL that won't use all the bits for representing the number, both are really needed. Assuming that two's complement arithmetic is being used, (ROT 1 -1) will give you the smallest fixnum, and (LSH -1 -1) will give you the largest fixnum. (HAULONG (ROT 1 -1)) will give you the number of bits in a fixnum. Outside of code that is a part of the Lisp system, there should be no need to know the actual wordsize of the machine. Bit vectors are available in both LMLisp and NIL.  Date: 30 APR 1980 1830-EDT From: KMP at MIT-MC (Kent M. Pitman) Subject: Finding largest integer To: (BUG LISP) at MIT-MC CC: Dave.Touretzky at CMU-10A My FORTRAN stuff would love to know this, too. Perhaps a (STATUS INFINITY)? A (STATUS WORDSIZE) would probably help, but for languages like NIL that won't use all the bits for representing the number, both are really needed.  Date: 30 April 1980 1812-EDT From: Dave Touretzky at CMU-10A Subject: maxint and minint ? To: bug-lisp at MIT-MC CC: Michael Horowitz at CMU-10A Is there any variable or status call in MacLisp that gives the maximum integer (excluding bignums) and minimum integer representable on the machine? I know the answer, I just want to know if I can get MacLisp to tell me. -- Dave Touretzky  Date: 30 April 1980 18:11-EDT From: Robert W. Kerns Sender: ___037 at MIT-MC Subject: FERROR/CERROR & LOOP To: JLK at MIT-MC cc: BUG-LISP at MIT-MC, GSB at MIT-MC, REES at MIT-MC I do not think LOOP should be made autoloadable, at least at this time. At least not until I read the documentation (c'mon GSB, proselytize me!) ... Seriously, what implementation of FERROR/CERROR do you propose MacLisp autoload? There are several possible, from my SIGNAL package which converts various MacLisp errors into signals and throws you into a debugger, etc., to macros which turn into ERROR. If you refer to the version which is in EXTEND, that is a stopgap FERROR intended to be replaced by whatever more winning version the user has. It's there in case the user DOESN'T have ANY version. It loses. (Hmm, it should live in a separate file and be made to autoload, so that it can't clobber any definition the user has loaded BEFORE extend!)  Date: 30 APR 1980 1035-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC #o '(10 20 30) loses.  Date: 29 APR 1980 2259-EDT From: JLK at MIT-MC (John L. Kulp) To: (BUG LISP) at MIT-MC Request: make FERROR and LOOP autoloadable.  Date: 29 APR 1980 1609-EDT From: JONL at MIT-MC (Jon L White) Subject: UNWIND-PROTECT To: KMP at MIT-MC, RWK at MIT-MC CC: (BUG LISP) at MIT-MC On the 15th of Feb, KMP sent out a bug notice about UNWIND-PROTECT losing, for which I made the diagnosis that ERRSET was not saving and restoring the UNREAL flag. The test case is (DEFUN KMP-LOSES () (ERRSET (UNWIND-PROTECT NIL (OPEN '((DSK BOO) BAR BZ))))) Well, I found a way to fix ERRSET without taking more pdl positions, and the assembled code (already initialized) is on LISP;BBLISP 995QIO. If that really works, then we should dump this out as XLISP, and maybe think about holding off on the extended definition of WITHOUT- INTERRUPTS - i.e., merely go back for now to using the "clean-up" clauses of an UNWIND-PROTECT. Also, you will note that this new lisp (1995) has LEXPR-FUNCALL. Comments solicited.  Date: 29 APR 1980 1132-EDT From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC Compilation of (DEFUN F (X &AUX Y) (DECLARE (FIXNUM Y)) ...) warns that Y is being bound to NIL. This doesn't happen if Y is a prog variable.  Date: 29 APR 1980 0333-EDT From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC The error message: MATCHING EXPRESSION NOT FIXNUM OR SYMBOL doesn't explain very well what is going on. Specifically it should mention that CASEQ is the "function" that you have offended.  GSB@MIT-ML 04/28/80 20:21:22 Re: in xlisp To: (BUG LISP) at MIT-ML i believe SUBSTH should have MOVEI instead of MOVE  GSB@MIT-ML 04/28/80 05:03:48 Re: in xlisp To: (BUG LISP) at MIT-ML ahem..... ((lambda (^w) (print 'foo t)) t) still prints FOO. Is this a feature or not? If it's that difficult, why not just change the documentation back? After all, it is getting close to 1984.  Date: 27 APR 1980 2337-EDT From: ALAN at MIT-MC (Alan Bawden) Subject: EQ-ness of fixnums To: PSZ at MIT-ML CC: (BUG LISP) at MIT-MC PSZ@MIT-ML 04/27/80 22:00:19 Re: EQ-ness of fixnums I know that exactly which MacLISP fixnums are EQ varies with time and is not generally counted on. Is it considered tasteless to build code that figures this out and depends on it as an efficiency hack? Do LML, NIL, Multics Maclisp,... take any position on this? Would it be reasonable to define a NUMBER-TESTS-AS-EQ predicate (or equivalent)? I don't know about tasteless, but before you write any such code you should know that even for small fixnums EQness of numbers doesn't always work in compiled code. The situations are hard to explain briefly, but you should check out the issues before going any further. I believe there is a paper describing the way complr hacks fixed point aritmetic that will help you here. On the LispMachine you can always count on EQness of all fixnums (even in compiled code), and to do so is quite tastfull. On Multics EQness of all fixnums certainly works in the interpreter, and I don't think the compiler can violate it either, but I personally would consider such a use distastefull since the dialect of Lisp is supposed to still be MacLisp, and such a hack might not work on ITS. I don't know about NIL.  PSZ@MIT-ML 04/27/80 22:00:19 Re: EQ-ness of fixnums To: (BUG LISP) at MIT-ML I know that exactly which MacLISP fixnums are EQ varies with time and is not generally counted on. Is it considered tasteless to build code that figures this out and depends on it as an efficiency hack? Do LML, NIL, Multics Maclisp,... take any position on this? Would it be reasonable to define a NUMBER-TESTS-AS-EQ predicate (or equivalent)?  Date: 27 April 1980 11:32-EST From: John L. Kulp Subject: LISPT and EPRINT functions... To: KMP at MIT-MC cc: JONL at MIT-MC, BUG-LISP at MIT-MC These things all worked fine at one point. I haven't kept up with all the changes which keep breaking things.  Date: 26 APR 1980 2051-EST From: JONL at MIT-MC (Jon L White) Subject: Usage of "PURE" strings To: (BUG LISP) at MIT-MC CC: NIL-I at MIT-MC A number of bugs have arisen from trying to PURCOPY string (either in NILAID, NIL, or in a lisp with only the STRING package) - here's another to beware of: If you call PURIFY with first argument signaling a general clean-up and purification, then the system knows enough to close out any remaing pure consing areas *** except for the pure string areas. You must close this out "by hand", by doing (SETQ STR/:NO/.PWDSF 0). Remember that some "dumpers" will implicitly call PURIFY thusly; PURE-SUSPEND is one.  Date: 26 April 1980 14:41-EST From: Kent M. Pitman Subject: LISPT and EPRINT functions... To: JONL at MIT-MC cc: BUG-LISP at MIT-MC, JLK at MIT-MC So far as I know, printing from Lisp to inferior Teco has never worked. JLK would be the one who would know for sure. I think he finally just gave up on making this win. -kmp  Date: 26 APR 1980 0919-EST From: JONL at MIT-MC (Jon L White) Subject: LISPT To: (BUG LISP) at MIT-MC I think I've finally quashed that bug whereby LISPT tries to clobber some of its instructions in-line, thus preventing it from being stored in pure areas. However, it seems that none of the EPRINT functions work - those that print from LISP into the inferior TECO; has anyone successfully used these recently?  Date: 26 April 1980 09:07-EST From: Peter Szolovits Subject: TTYSCAN troubles--doing something wrong To: CWH at MIT-MC, ALAN at MIT-MC cc: PSZ at MIT-ML, BUG-LISP at MIT-MC The comment was made that if you are having side-effects at read-time you must be doing something wrong. Clearly, the reader already does so, but we tend not to think of extra interned atoms as a terrible problem. In my application, I am providing other, non-atomic, unique-ized expressions, which are also indexed to others of their kind. The only mechanism I know which supports this reasonably IN NOTATION is to use a reader macro which then SQUIDifies its result, so that expressions like (setq foo '(a b [c d] e)) where the [c d] will never get eval'd, work out right. Then, however, if I type [a [b c] d], the inner [b c] will be created and indexed before the expression is complete, and then I may rub it out. I agree that this case could be hacked by making the [b c] realize that it is inside another expression and not construct its meaning but merely indicate to the outer expression how to construct it when the outer one is done, but that is a rather filthy way to program. I like GSB's suggestion, of a global flag that says "don't care about the value" better, because it allows each function to decide locally what to do without having to understand another notation for what its subsidiaries want. (E.g., what about [a {b d} [e]]--God forbid.) I still think that if you are going to retain the current TTYSCAN mechanism, you ought at least to add to it the flexibility to handle everything but the "arbitrary macro character" case correctly. I'd bet that nearly all of what arbitrary read macros do can, for the purposes of prescanning, be described in terms of four or five standard schema (the small infinity theory of Waltz). My (partial) list: 1. initial string delimiter (e.g.,|;"), 2. initial of nested bracket pair (e.g., ([{<--possibly, though only ( in lisp now), 3. quote-like thing (e.g., '`#), 4. slash-like thing (e.g., /). Can anyone think of others? Each of these categories has uniform prescanning implications.  Date: 26 April 1980 08:48-EST From: Kent M. Pitman To: CWH at MIT-MC cc: BUG-LISP at MIT-MC Date: 20 April 1980 10:44-EST From: Carl W. Hoffman To: BUG-LISP It should work to put LAP definitions within PROGN 'COMPILE. ----- You want LAP-A-LIST. LAP works by READ. You know what the ramifications of having READ try to steal stuff from the Pratt-Stack would be -- too much hair... -kmp ps This note should have gone to BUG-COMPLR. (PROGN 'COMPILE ...) has nothing to do with the interpreter.  Date: 26 April 1980 08:42-EST From: Kent M. Pitman Subject: Autoload To: MILLER at MIT-AI cc: BUG-LISP at MIT-MC, KMP at MIT-MC I have been kind of out of it and am not sure if someone properly responded to you but it's is essential that AUTOLOADable things be FUNCALL-able and MACRO's are not. So no scheme for autoloading anything to be used by compiled code by appealing to a autoload-macro can work. -kmp  Date: 26 April 1980 08:32-EST From: Kent M. Pitman To: DCP at MIT-MC cc: BUG-LISP at MIT-MC Date: 25 April 1980 03:31-EST From: David C. Plummer To: BUG-LISP Now that carriage returns are no longer NO-OPS but real WHITESPACE, perhaps print should be told about this. I printed a bignum to a file, and PRINT inserted newlines,... ----- You were not using the default environment and/or you were doing this from a breakpoint. The autoterpri 'feature' is controlled by the variable TERPRI. Setting it to T makes it not autoterpri (don't ask me why not the other way around ...). There's a Lisp bug that makes TERPRI get rebound to NIL in breakpoints instead of T (which it defaultly is at toplevel). This is and has been for a while fixed in XLisp, so hang in there or start using XLisp in the interim ... -kmp  Date: 26 Apr 1980 0105-PST From: Dick Gabriel Subject: TTYSCAN and the programming Gestapo To: bug-lisp at MIT-MC Date: 25 APR 1980 2257-EST From: ALAN at MIT-MC (Alan Bawden) ... I my opinion, if you are doing some kind of non-repeatable side effect at readtime, then you are probably doing something wrong... Say, a latter day Yuri Geller: able to debug programs while they are sealed in a bell jar. I thought that Dijkstra and his co-Hoare-ts had an exclusive right to this holier-than-thou-ness. How about this for a radical idea: let the person writing the program - you know, the guy (or dame) who knows what the program is supposed to do - decide what's right and wrong with his (her) own work? -rpg-  Date: 26 April 1980 01:19-EST From: Carl W. Hoffman Subject: TTYSCAN troubles. To: ALAN at MIT-MC, PSZ at MIT-ML cc: BUG-LISP at MIT-MC Date: 25 APR 1980 2257-EST From: ALAN at MIT-MC (Alan Bawden) GSB's solution is the one used by the LispMachine reader (including a catch/throw scheme to prevent doing the read twice). No one has ever complained about the duplication of side effect issue. I my opinion, if you are doing some kind of non-repeatable side effect at readtime, then you are probably doing something wrong. This solution to rubout processing is the cleanest imaginable and it NEVER fails! (Users can write the hairyest reader macros imaginable and it works like a charm.) It isn't even all that expensive since it only happens during interactive READing and never when reading from a file. It sure is a shame that it is too late to do it the right way in MacLisp. The other advantage with this approach is that it works for any arbitrary "read" function, not just READ.  Date: 26 April 1980 00:40-EST From: Glenn S. Burke Subject: TTYSCAN troubles. To: PSZ at MIT-ML cc: BUG-LISP at MIT-MC I think i have an answer. It will unfortunately require a little cooperation from Lisp -- a flag which says that the READ is not really for "value" -- it is globally NIL, but when reading to drive a prescan it is bound to T, and BREAK (Maclisp interrupt-bind too?) binds it back to NIL. This requires that all pre-scanned reads be two-pass. This is already the case for the Maclisp interface. It is trivial to add to a tty-prescan of this type anyway, since the second pass is like pretending a rubout was typed after the s-expr is completely read (ie, start the read over again, with this flag set to NIL - the tty prescan initially binds it to T). The localized place which decides how to make up a data-object (which is also the place which decides to make a SQUID form instead) can check this flag and not make the data object. This requires that the form returned by the readmacro or whatever not be depended on to be anything in particular by surrounding forms. But this generally needs to be the case anyway, since in the compiler these will be SQUID forms. For example, "#O#,bporg" will lose in the Maclisp compiler because #O is doing a bit too much error checking.  Date: 25 APR 1980 2257-EST From: ALAN at MIT-MC (Alan Bawden) Subject: TTYSCAN troubles. To: PSZ at MIT-ML CC: (BUG LISP) at MIT-MC PSZ@MIT-ML 04/25/80 22:26:59 Re: TTYSCAN troubles. (long msg) ... One solution to this kind of problem that has been proposed (and implemented by GSB) is to abandon the notion of table-driven scanning schemes as unworkable, and to use an "inner" call to read which is a perfect predictor of when read will terminate on a particular string. This is, of course, wasteful, as the read is done twice (though perhaps some clever catch/throw scheme around the outer read could obviate the need for it... but that's another story). Worse yet, it has the nasty characteristic that any side-effects performed by the reader (e.g., interning atoms, read-time creation of data structure) are hard/impossible to undo, and even if some stuff is typed and then rubbed out, its effect remains. ... GSB's solution is the one used by the LispMachine reader (including a catch/throw scheme to prevent doing the read twice). No one has ever complained about the duplication of side effect issue. I my opinion, if you are doing some kind of non-repeatable side effect at readtime, then you are probably doing something wrong. This solution to rubout processing is the cleanest imaginable and it NEVER fails! (Users can write the hairyest reader macros imaginable and it works like a charm.) It isn't even all that expensive since it only happens during interactive READing and never when reading from a file. It sure is a shame that it is too late to do it the right way in MacLisp.  PSZ@MIT-ML 04/25/80 22:26:59 Re: TTYSCAN troubles. (long msg) To: (BUG LISP) at MIT-ML CC: PSZ at MIT-ML Having just spent the last week hacking a new language and notation in LISP, I have a problem with the TTYSCAN mechanism that I would like to describe and get some feedback on. The language extension I have been hacking involves use of nested bracketed expression using [...] and (...) brackets. I read the [...] kind by defining [ to have a reader macro which binds the readtable to whatever is appropriate within [...]'s, including defining ] to be a single-character object, so that (read) will retrieve it as an entity. What I find is the rubout processing then becomes essentially impossible. E.g., after "[foo ", the TTYSCAN function has been exited and I cannot rub out the space or before. Assuming that the description of the TTYSCAN function in LISP NEWS (~1976) is about right, the reason is easily found. The prescanner tries to maintain a "paren count" to decide whether it is inside an expression or not when interpreting whether a space-like character terminates the prescan. However, it checks for "open-syntax" after it checks for "macro syntax". Thus, there is no way to mark a character as a level-increasing "open paren-like object" if it also needs to invoke a reader macro. The actual lisp open-paren of course does not suffer from this problem because (read) knows how to read lists innately, without needing a character macro on ( to help it. One solution to this kind of problem that has been proposed (and implemented by GSB) is to abandon the notion of table-driven scanning schemes as unworkable, and to use an "inner" call to read which is a perfect predictor of when read will terminate on a particular string. This is, of course, wasteful, as the read is done twice (though perhaps some clever catch/throw scheme around the outer read could obviate the need for it... but that's another story). Worse yet, it has the nasty characteristic that any side-effects performed by the reader (e.g., interning atoms, read-time creation of data structure) are hard/impossible to undo, and even if some stuff is typed and then rubbed out, its effect remains. A second possibility is to stick with the readtable mechanism but to recognize explicitly what mechanisms are needed and to support them better. It is clear that rubout, slash, strings (un-nested), brackets (nested), spaces, single-char objects, and force-feed are the stuff of which a simple scanner is to be built. These components must have sufficient generality to be tailorable to just about anyone's taste. The task is not too hard, since only the end of a complete expression must be recognizable, not its internal structure. Only non-standard reader macros, which can have arbitrary demands, are impossible to handle this way. As a start, some equivalent of TTYSCAN-STRINGERS would be a welcome mechanism for dealing with nested brackets. I could then be happy making [ a macro character but assuring the prescanner that it and ] formed a level-preserving pair. The worst objection to this, as well as to the string handler, is that the use of special variables in addition to READTABLEs makes it harder to switch reader environments. The readtable ought, ideally, to be complete. I welcome any takers for the above suggestion, or rebuttals.  Date: 25 APR 1980 0948-EST From: Quux,DP at MIT-MC Sent-by: GLS at MIT-MC Subject: Last most final note on DO-NAMED and Lexical CATCH To: (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC, NIL at MIT-MC To: rpg at SU-AI, rod at SU-AI The latest poop: Date: 9 APR 1980 21:08-EST From: Daniel L. Weinreb Subject: Yet another note on lexical CATCH To: BUG-LISP) at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at the S-1 NIL compiler in fact implements a construct called PROG-BODY with precisely those semantics; PROG is then turned into a nested LET and PROG-BODY. This was done to concentrate all knowledge of variable bindings into one place -- the catch, and END ends it (but not in the usual sense!). ^_ Date: 16 April 1980 01:49-EST From: John L. Kulp Subject: Name for lexical CATCH To: GLS at MIT-MC Let's not flush old-stye DO, and let's not in the usual sense!). ^_ Date: 9 APR 1980 1935-EST From: JONL at MIT-AI> Subject: DO-NAMED To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-MC (David A. Moon) Subject: GLS would like the construct we're X) ...) isn't so bad... But since we're talking about it, has anyone given thought recently to actually flushing the old-style DO syntax? It certainly becomes less useful if you have DOTIMES and a couple orders of magnitude slower than the pop/jump sequence of a named prog and return. *THROWs outside the context where they should be BLOCK, with EXIT used to mean a lexical throw. Thus which could be called "*CATCH"; you could be called "*CATCH"; you could have merely one version of each special form, and then put a *CATCH around it if you need a named escape expression. This functionality in all these forms, either with different function names (DO versus DO-NAMED) or different syntaxes (DOTIMES or REPEAT, and old-style DO flushable? ^_ Date: 15 April 1980 13:51-EST From: MOON at MIT-MC (David A. Moon) Subject: GLS would like to push again for hairiferous DO To: GLS at MIT-MC (Robert W. Kerns) Sent-by: ___024 at MIT-MC Subject: Lexical Catch/*THROW instead? This means it must either punt or resort to keywords. I think even people who "would never ever use" LOOP would agree that LOOP, ask GSB for a copy of the documentation. As far as this argument degerate into an argument over names? ^_ Date: 15 April 1980 04:59-EST From: RWK at MIT-MC (Robert W. Kerns) Sent my feelings on this issue of how DO/PROG could be done in order this haggling, part of which I think comes out of the fact that these forms, why not "subroutinize out" the functionality into a new special form, which could be called "*CATCH"; you could have merely one way (named PROG and DO-NAMED) of saying it. I'm not sure that I would go so far as to take to have more than one way (named PROG and THROW was affected, so writing an automatic converter was trivial. ^_ Date: 9 April 1980 21:16-EST From: Richard M. Stallman Subject: Old-style DO flushable? Why don't we let this argument degerate into an the pop/jump sequence of a named prog and return. *THROWs outside the context where they should be allowed would find the *CATCH above them, unlike the construct we're: Lexical CATCH and named constructs ^_ Date: 15 APR 1980 0419-EST From: MOON at MIT-MC (David A. Moon) Subject: GLS would like a winner. I'm considering adding it to Rutgers Lisp under the name of maclisp CATCH and THROW. Is it time to introduce RPTQ (or REPEAT) and take to have more than one way (named PROG and DO-NAMED) of form if form returns normally or the value returned from it if that gives you any basis for comparison.) form1 form2 ...) like DO is now but doesn't allow return or the like for the associated throw, which is slightly distasteful. HOOK perhaps. Hmm. sounds good. ------- ^_ Date: 15 April 1980 23:49-EST From: "Guy L. Steele, Jr." Subject: Lexical CATCH and named constructs To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, nil at MIT-MC (David A. Moon) Subject: GLS would like to push again for hairiferous DO To: GLS at MIT-MC, (BUG LISP) at MIT-MC Maybe do it with various kinds of parentheses: [SETQ X {CAR (IF [OR (CAR (IF [OR (CAR X) (AND (CDR X) (RETURN-FROM "[" 3)) (RETURN-FROM "{" 5)] [RETURN-FROM specifying name (or just a RETURN-FROM "[" 3)) (RETURN-FROM "{" 5)] [RETURN-FROM: Kent M. Pitman Subject: DOTIMES But at least some, myself included, feel the future, each of which would have to have two versions for a very simple REPEAT syntax ^_ Date: 8 April 1980 20:43-EST From: Daniel L. Weinreb Subject: DO-NAMED To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI Let's not flush old-style DO-NAMED GORILLA ...) ^_ Date: 12 April 1980 21:08-EST From: Daniel L. Weinreb Subject: Multi-line JCL To: DCP at MIT-MC cc: BUG-LISP at MIT-MC The bug has been noted. There is no one maintaining Maclisp at this time, and the issue is really pretty low priority given the other things on the minds of those capable of making the change but I am sure they will keep it in mind when they get the time to look into it. -kmp  Date: 25 APR 1980 0331-EST From: DCP at MIT-MC (David C. Plummer) To: (BUG LISP) at MIT-MC Now that carriage returns are no longer NO-OPS bur real WHITESPACE, perhaps print should be told about this. I printed a bignum to a file, and PRINT inserted newlines, so if I tried to read it back in from the file, I would get several bignums. As I understand what the contract of PRINT is, you are supposed to READ anything PRINT does and get things that are EQUAL, except for GENSYMed variables.  Date: 25 APR 1980 0054-EST From: DCP at MIT-MC (David C. Plummer) To: (BUG LISP) at MIT-MC I noticed that DDT now allows a multi-line JCL. BUT... (status jcl) doesn't know what to do with it. Let's get compatible, PLEASE.  Date: 23 April 1980 15:23-EST From: V. Ellen Golden Subject: ^C on Tweneces To: KMP at MIT-MC, JPG at MIT-MC, BUG-LISP at MIT-MC Date: 23 APR 1980 1048-EST From: kmp at MIT-MC (Kent M. Pitman) Sent-by: ___023 at MIT-MC I vote that ^Z on Tops-20 should turn off GC messages. This would be consistent with the ^C/^Z swap that Emacs does ... -kmp --------------- I second the motion.  Date: 23 APR 1980 1048-EST From: kmp at MIT-MC (Kent M. Pitman) Sent-by: ___023 at MIT-MC Subject: ^C on Tweneces To: JPG at MIT-MC, ELLEN at MIT-MC, (BUG LISP) at MIT-MC I vote that ^Z on Tops-20 should turn off GC messages. This would be consistent with the ^C/^Z swap that Emacs does ... -kmp  Date: 23 APR 1980 0224-EST From: JPG at MIT-MC (Jeffrey P. Golden) To: (BUG LISP) at MIT-MC CC: JPG at MIT-MC, ELLEN at MIT-MC ELLEN@MIT-MC 04/23/80 02:03:42 Re: DEC20 MACSYMA ^D turns GC stats on, but ^C of course is a top level interrupt, so won't work to turn them off. How does LISP solve this problem? Does it assign the function of ^C to another character? Perhaps ^D could be a toggle on DEC20, if not in fact in all MACLISPs thereby solving this problem as well as freeing up ^C for other uses on ITSes?  GSB@MIT-ML 04/21/80 00:08:05 Re: STRING vs EXPLODEN To: (BUG LISP) at MIT-ML Using LISP;STRING in XLISP, (maknam (exploden "foo")) => |"foo"|, it should be |foo| (the same chars which would come from (princ "foo")). Not knowing how the interface works (is it ever going to be documented?) i don't know whose problem this is.  GSB@MIT-ML 04/20/80 23:31:06 Re: trace To: (BUG LISP) at MIT-ML I have slightly modified TRACE (on my directory). I would appreciate it if someone more into such things would evaluate the changes and possibly install it. The changes (noted in the file) are these (they only affect TRACE-INDENTER): TRACE-INDENTER will punt and do nothing if TRACE-OK-FLAG is NIL. This takes care of tracing functions which get called by user-printers. The series of calls to a user PRIN1 hook was changed to one call, giving it a list. This is in the eventuality that the prin1 hook attempts to do some formatting. (It can't do very much if it gets called near the right margin.) I added a flag TRACE-PRINT-TO-TTY, which makes TRACE-INDENTER bind both ^W and ^R to NIL. This is to keep from losing TRACE output because of other functions binding/setting them, and/or to make sure that the trace stuff doesn't go to OUTFILES. I don't care if the mechanism of this is changed, as long as i can force trace output to the terminal if necessary.  Date: 20 APR 1980 1830-EST From: EB at MIT-MC (Edward Barton) Subject: Autoload To: Miller at MIT-AI CC: (BUG LISP) at MIT-MC I don't understand how an AUTOLOADable function is anything at all like a macro, as suggested in your message of 20 April 1980 17:43-EST. Can you explain further? I especially cannot understand how autoloading can be accomplished at compile time....  GSB@MIT-ML 04/20/80 18:23:34 Re: lap To: CWH at MIT-ML CC: (BUG LISP) at MIT-ML Use LAP-A-LIST, ie (LAP-A-LIST '((LAP FOO SUBR) (ARGS FOO (NIL . 2)) ... NIL)) If you are really ambitious, you could even have macros return such forms.  Date: 20 April 1980 17:43-EST From: Mark L. Miller Subject: Autoload To: KMP at MIT-MC, BUG-LISP at MIT-MC It seems to me that there is very little conceptual difference between AUTOLOADable functions and macros. Indeed it might be preferable to have the value of the AUTOLOAD property BE a macro definition which would receive the calling form as its one input, and return a revised form for further evaluation. A built-in function AUTOLOAD would be the usual body, e.g.,: (defun GRIND macro (form) (autoload form '((com) grindef fasl))). where autoload was defined as something like: (defun AUTOLOAD (form file) (load file) (comment possibly remprop the macro defn here) form) -- just to make the current behavior trivial to implement; but one could then also do cleverer things instead. Would this sort of thing solve the problem? Has this sort of idea been considered and rejected already? Regards, Mark  Date: 20 April 1980 17:17-EST From: Mark L. Miller Subject: Automatic Conversion To: JPG at MIT-MC, JONL at MIT-MC cc: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, EJS at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC Why not a several stage conversion process as follows: 0. The current state of affairs (one DO supports both old and new). 1. Rename the current function POSSIBLE-OLD-STYLE-DO and keep supporting it. Users wanting automatic upwards-compatibility can use MM REPLACE to change their current code to that. (Using Query Replace, one could even optionally chose to NOT rename obviously-new-style DO's.) POSSIBLE-OLD-STYLE-DO would do what DO does now, but be autoloading and not necessarily efficient. Keep current DO also for a while. 2. Redefine DO to support only the new style after much warning. 3. Eventually delete the autoload property for POSSIBLE-OLD-STYLE-DO from the default environment. This sort of scheme might turn out to be useful for other changes as well. Regards, Mark  Date: 20 APR 1980 1044-EST From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC It should work to put LAP definitions within PROGN 'COMPILE.  Date: 19 April 1980 16:05-EST From: Kent M. Pitman Subject: Defun& To: JONL at MIT-MC cc: RLB at MIT-MC, BUG-LISP at MIT-MC Date: 19 April 1980 12:48-EST From: Jon L White To: RLB cc: BUG-LISP Re: defun& Date: 17 April 1980 12:52-EST From: Richard L. Bryan Subject: DEFUN& strikes again! Macroexpansion of the following code binds SUBRS to (), then does (DESETQ SUBRS (REVERSE SUBRS)) which is purely wrong... Indeed, any case like (DEFUN FOO (&OPT (BAR BAR)) ...) is not correctly handled - only if a variable is being being bound to *previous* variables in the varlist does it work right. This could be fixed, without loss of other optimizations, if anyone is really interested. ---- Yes, I am interested. I have this CODE-SUBST program I would like to release but am hesitant to do so until DEFUN& starts working as documented so that I can be compatible with something correct. -kmp  Date: 19 APR 1980 1248-EST From: JONL at MIT-MC (Jon L White) Subject: defun& To: RLB at MIT-MC CC: (BUG LISP) at MIT-MC Date: 17 April 1980 12:52-EST From: Richard L. Bryan Subject: DEFUN& strikes again! Macroexpansion of the following code binds SUBRS to (), then does (DESETQ SUBRS (REVERSE SUBRS)) which is purely wrong. This sounds suspiciously like one of those infamous "unsafe optimizations". (declare (special subrs VASL-stream)) (defun ap3 (filename &optional pkg-name module-name &aux (owho3 (status who3)) (subrs (reverse subrs)) VASL-stream) (list subrs filename pkg-name module-name)) Indeed, any case like (DEFUN FOO (&OPT (BAR BAR)) ...) is not correctly handled - only if a variable is being being bound to *previous* variables in the varlist does it work right. This could be fixed, without loss of other optimizations, if anyone is really interested.  Date: 17 APR 1980 1252-EST From: RLB at MIT-MC (Richard L. Bryan) Subject: DEFUN& strikes again! To: (BUG LISP) at MIT-MC Macroexpansion of the following code binds SUBRS to (), then does (DESETQ SUBRS (REVERSE SUBRS)) which is purely wrong. This sounds suspiciously like one of those infamous "unsafe optimizations". ;-*-LISP-*- (declare (special subrs VASL-stream)) (defun ap3 (filename &optional pkg-name module-name &aux (owho3 (status who3)) (subrs (reverse subrs)) VASL-stream) (list subrs filename pkg-name module-name)) (setq subrs (list 'fact))  Date: 16 April 1980 13:16-EST From: Kent M. Pitman To: RIVEST at MIT-MC cc: BUG-LISP at MIT-MC RWK typo'd in his message saying (DO () (T) ...) iterated forever. He meant: (DO () (NIL) ...) iterate forever. Exit test always fails. (DO () (T) ...) doesn't iterate at all. Exit test always succeeds. (DO () () ...) executes body exactly once. Special-cased. -kmp  Date: 16 April 1980 10:51-EST From: Robert W. Kerns Sender: ___066 at MIT-MC Subject: DO! To: RIVEST at MIT-MC cc: BUG-LISP at MIT-MC I'm not sure just what you mean by NIL being illegal as an iteration variable in your example of (DO () () (PRINT 'FOO)) ... you don't have any iteration variable in your example. Did you not realize this is recognized as a NEW style DO instead of an OLD style DO?  Date: 16 April 1980 10:46-EST From: Robert W. Kerns Sender: ___066 at MIT-MC Subject: DO To: RIVEST at MIT-MC cc: BUG-LISP at MIT-MC Looping forever is trivially obtained by doing (DO () (T) ...) It is defined (and much more useful) for (DO () () ...) to do it exactly once, since this case is also quite useful, and not so easily obtained otherwise.  RIVEST@MIT-ML 04/16/80 10:12:36 To: (BUG LISP) at MIT-ML Why doesn't (DO () () (print 'foo)) loop forever? Since NIL ought to be illegal as an iteration variable, this should be recognized as a NEW format iteration command... Ron  Date: 16 Apr 1980 0419-PST From: Scott at SRI-KL (Scott J. Kramer) Subject: Re: Lexical CATCH and named constructs To: QUUX at MIT-AI, BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, nil at MIT-MC In-Reply-To: Your message of 16-Apr-80 0131-PST Mail-from: ARPAnet host MIT-MC rcvd at 16-Apr-80 0414-PST Date: 16 April 1980 04:31-EST From: Quux Subject: Lexical CATCH and named constructs To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, nil at MIT-MC Maybe do it with various kinds of parentheses: [SETQ X {CAR (IF [OR (CAR X) (AND (CDR X) (RETURN-FROM "[" 3)) (RETURN-FROM "{" 5)] [RETURN-FROM "[" 6] LOSER)}] Bletch, that's the grossest looking code I've ever seen! -------  Date: 16 April 1980 04:31-EST From: Quux Subject: Lexical CATCH and named constructs To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, nil at MIT-MC Maybe do it with various kinds of parentheses: [SETQ X {CAR (IF [OR (CAR X) (AND (CDR X) (RETURN-FROM "[" 3)) (RETURN-FROM "{" 5)] [RETURN-FROM "[" 6] LOSER)}] Of course, you'd need a lot of different parentheses in general. Maybe Carl has some ideas about this. (This idea inspired by super-brackets -- use brackets to convey control, not just textual, "closing off".)  Date: 16 April 1980 01:49-EST From: John L. Kulp Subject: Name for lexical CATCH To: GLS at MIT-MC cc: BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC, NIL at MIT-MC Sorry, but I couldn't resist this: Call it BLETCH (Block and LExical caTCH)....  Date: 16 APR 1980 0139-EST From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: Name for lexical CATCH To: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, NIL at MIT-MC Well, I'd like to avoid puns like LATCH. A name which might even appeal to ALGOL types and help win them over to our wonderful way of doing things might be BLOCK, with EXIT used to mean a lexical throw. Thus (BLOCK CRUFT (GROSS OUT) (AND (LOSE) (EXIT CRUFT)) (AND WIN (EXIT CRUFT 43)) 19) The next suggestion is less serious, but if you can't stomach BLOCK, then why not confuse the world by using BEGIN and END? BEGIN begins the catch, and END ends it (but not in the usual sense!).  Date: 15 April 1980 23:49-EST From: "Guy L. Steele, Jr." Subject: Yet another note on lexical CATCH To: BUG-LISP at MIT-AI, BUG-LISPM at MIT-AI, NIL at MIT-MC Regarding Henry's note that he never uses named constructs, let me say that I haved used them about three times total ever. But when I need it, it's the right thing to have! (I've also used PROG about three times in the past year, and HAULONG about twice, if that gives you any basis for comparison.)  Date: 15 Apr 1980 1545-EST From: JoSH Subject: Lexical Catch To: bug-lisp at MIT-MC This sounds like a winner. I'm considering adding it to Rutgers Lisp under the name of LATCH. This would leave EYE-BOLT or the like for the associated throw, which is slightly distasteful. HOOK perhaps. Hmm. sounds good. -------  Date: 15 April 1980 13:51-EST From: Alan Bawden Subject: Lexical Catch To: RWK at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC I propose we name this construct LEXICAL-CATCH (what a novel thought!).  Date: 15 April 1980 08:59-EST From: Dan Brotsky Subject: GLS's DO suggestion To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC GLS's suggestion about parallel/sequential do interpretation seems wonderful to me, since I often find cooperating parallel and sequential assignments just what the doctor ordered. I'm not so happy with the update-defaults-to-init suggestion since it seems to introduce an arbitrariness motivated only by a desire to type less, but I could live with it. dan  Date: 15 APR 1980 0525-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Can I talk again yet? To: (BUG LISP) at MIT-MC CC: (BUG LISPM) at MIT-MC, H at MIT-MC, HENRY at MIT-MC, GLS at MIT-MC CC: EJS at MIT-MC I want ITERATE as a separate construct. Implementing it with GO is not satisfactory. People doing (ITERATE ...) will know they can put GO's and prog tags in the toplevel of that form. I would like to have a form which guarantees to my eye when scanning code that there will be no GO's or prog-tags there.  Date: 15 April 1980 04:59-EST From: Robert W. Kerns Sender: ___055 at MIT-MC Subject: Addendum To: GLS at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPMMEJS at MIT-MC, H at MIT-MC, HENRY at MIT-MC Of course, one also needs a PROG-BODY construct, so both to complete the primitive pantheon, so PROG can be built out of PROG-BODY, LAMBDA, and LEXICAL-CATCH.  Date: 15 APR 1980 0448-EST From: RWK at MIT-MC (Robert W. Kerns) Sent-by: ___024 at MIT-MC Subject: Lexical Catch To: GLS at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC To: EJS at MIT-MC, H at MIT-MC, HENRY at MIT-MC I'd hoped that the LEXICAL catch was the end of the debate. To help end it, let me add my voice to the consensus that a lexical catch is what is wanted. Why don't we let this argument degerate into an argument over names?  Date: 15 APR 1980 0419-EST From: MOON at MIT-MC (David A. Moon) Subject: GLS would like to push again for hairiferous DO To: GLS at MIT-MC, (BUG LISP) at MIT-MC, (BUG LISPM) at MIT-MC CC: EJS at MIT-MC, JONL at MIT-MC, H at MIT-MC, KMP at MIT-MC CC: HENRY at MIT-MC I don't think that it is at all syntactically clear what this yet-further-extended form of DO does. At some point you reach diminishing returns with doing all your syntax with parentheses, and must either punt or resort to keywords. I think even people who "would never ever use" LOOP would agree that LOOP is a greatly preferable way of saying the same things than your DO with 3 open parentheses. If you aren't familiar with LOOP, ask GSB for a copy of the documentation. As far as this much too protracted discussion of named constructs goes, my considered opinion is that the correct way of documenting it is as a lexically-scoped catch. It has the usual small efficiency and modularity advantages of lexical scoping over dynamic scoping. (The fact that the cost of dynamic CATCH is very much larger in pdp10 Maclisp is purely a historical artifact of the implementation and is not conceptually necessary; it -is- conceptually necessary that it be a little more expensive, as it is in the Lisp machine.) It was probably a mistake to have more than one way (named PROG and DO-NAMED) of saying it. I'm not sure that I would go so far as to take one of them out, although probably that would be best in the long run. I don't think it's necessary or useful to have function names for every possible combination of primitive operators.  Date: 15 April 1980 01:34-EST From: Kent M. Pitman To: BUG-LISP at MIT-MC cc: BKERNS at MIT-MC The grinder has a new 'feature'. Formerly the grind width to be used was computed from (LINEL (OR (CAR OUTFILES) T)). As this is prone to be heuristic, the variable GRLINEL (default UNBOUND) will have priority if it is given a value. ---- This change has been installed on all 4 ITS sites as GFN version 456. The above information is also available in MC:LISP;NEW RECENT for later inclusion into .INFO.;LISP NEWS by someone who knows how to do that. Can someone also install this on non-ITS's, sending me mail saying which ones it should be shipped to when such fixes are made? Thanks. -kmp  Date: 15 APR 1980 0049-EST From: JONL at MIT-MC (Jon L White) Subject: PROG-BODY To: GLS at MIT-MC CC: NIL at MIT-MC, (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC CC: HENRY at MIT-MC LISP370 employed a "PROG-SEQ" as a variable-less PROG, so that contours could be concentrated under one construct, LAMBDA. The generic- and VAX-specific NIL compiler also does this. As RMS earlier pointed out, a single named construct should suffice for all end-user purposes; we have it now in the slightly haired regular PROG. Also happy to hear first vote from HENRY that he uses no named constructs ever.  Date: 15 April 1980 00:40-EST From: "Guy L. Steele, Jr." Subject: What should we DO? To: BUG-LISP at MIT-MC, NIL at MIT-MC, BUG-LISPM at MIT-MC cc: KMP at MIT-MC, H at MIT-MC, HENRY at MIT-MC, RMS at MIT-MC, MOON at MIT-MC My personal feelings on this are that we should come up with consistent rules about these things. Documentation is much simpler if you could generalize in it. So I would prefer flushing old-DO in the longrun but it's probably unworkable at present. There's no reason to leave ourselves open to future problems of this sort by implementing something now without thinking first -- which is why I advocated not allowing (DOTIMES n ...). I was not advocating that (DOTIMES lab ...) be installed -- just allowing for that contingency. I now present my feelings on this issue of how DO/PROG could be done in order this haggling, part of which I think comes out of the fact that these return tags are tied up in PROG-ness and so on ... Suppose you had the following primitives in Lisp: (PROG-BODY ...) which evaluated all non-atomic stuff. Atoms were GO-tags. Returns () if you fall off the end. RETURN does not work from this form. (PROG-RETURN-POINT form name) name is not evaluated. Form is evaluated and if a RETURN-FROM specifying name (or just a RETURN) were executed, control would pass to here. Returns the value of form if form returns normally or the value returned from it if a RETURN or RETURN-FROM is executed. [Note: this is not a [*]CATCH because it is lexical in nature and optimized out by the compiler. Also, a distinction between NAMED-PROG-RETURN-POINT and UNNAMED-PROG-RETURN-POINT might be desirable -- extrapolate for yourself how this would change things -- I'll just present the basic idea here.] (ITERATE bindings test form1 form2 ...) like DO is now but doesn't allow return or goto. All forms are evaluated. GO does not work to get to any form in the iteration body. Seriously, folks, my own position on DO and friends is largely in agreement with KMP here. His PROG-RETURN-POINT is simply the lexical catch advocated by DLW, with allowances for how RETURN could be expressed in terms of that. It is of interest to note that the S-1 NIL compiler in fact implements a construct called PROG-BODY with precisely those semantics; PROG is then turned into a nested LET and PROG-BODY. This was done to concentrate all knowledge of variable bindings into one place -- the code that handles LAMBDA. The original intent was just to use this construct internally to the compiler, but indeed it may be a useful building-block for other macros.  Date: 15 April 1980 00:10-EST From: "Guy L. Steele, Jr." Subject: Named constructs To: JONL at MIT-MC cc: MOON at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, BUG-LISPM at MIT-MC, BUG-LISP at MIT-MC From: JONL at MIT-MC (Jon L White) Uh, don't these things only apply to prog-like constructs? things with GOs and RETURNs or loops in them? Why?  Date: 15 April 1980 00:09-EST From: Quux Sender: GLS at MIT-MC Subject: Inconsistency in various DOs cc: MOON at MIT-MC, JONL at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC Date: 12 APR 1980 1831-EST From: MOON at MIT-MC (David A. Moon) If you're going to promote named DOTIMES's, you might as well promote named CONS, named PLUS, named ADD1, etc. Two great minds... I guess MOON gets academic priority on this one.  Date: 15 April 1980 00:08-EST From: Quux Sender: GLS at MIT-MC Subject: Inconsistency in various DOs To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC cc: JONL at MIT-MC, MOON at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC From: JONL at MIT-MC (Jon L White) ... Speaking of issues, how important a loss is it that there has to be a DO-NAMED? How big a loss would it be to programmers if they had to type PROG-NAMED rather than PROG? Admittedly these "named" constructs are crucial to interpreters and compilers, but I'd be curious hear what proportion of DO/PROG usages by J. Random Loser actually use the "named" feature. If its extremely low (say, below 2%) then it would seem counter-productive to constrain the future language constructs just to save typeing a rare "-NAMED". The Vision people, the Constraints guys, and the ACTOR builders might be the logical ones to provide input here. I propose that ALL constructs be named. Thus one might do (SETQ-NAMED FOO X (CAR-NAMED BAR (IF (OR-NAMED FOO (CAR X) (AND (CDR X) (RETURN-FROM FOO 3)) (RETURN-FROM BAR 5)) (RETURN-FROM-NAMED FOO FOO 6) LOSER))) Three brownie points to whoever can tell me what this means.  Date: 14 April 1980 23:57-EST From: "Guy L. Steele, Jr." Subject: DOTIMES or REPEAT, and old-style DO flushable? To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC cc: EJS at MIT-MC, JONL at MIT-MC, H at MIT-MC, KMP at MIT-MC, HENRY at MIT-MC From: Eric J. Swenson I've long thought that the time had come to flush the old-style DO. I don't think it presents a substantial saving of coding space, and being as un-general as it it, is not worth keeping. From: Alan Bawden There is a saying about such ideas: "you're in charge!". I observe that the lexical distance between an old- and new-style DO is precisely six characters: "(())()": (DO x y z w . body) ==> (DO ((x y z)) (w) . body) But much as I would also like to flush it, I must agree with ALAN. Bletcherous idea: let (DO (NAME) ...) be the way to name a DO? By the way, guys, I want to push again for the additional interpretation (DO (((var11 init11 step11) (var12 init12 step12) ...) ((var21 init21 step21) ...) ... ((varn1 ...) ...)) (test ... retval) . body) where variables within each group are processed in parallel, but the groups are processed serially. Moreover, in the first group omitting a stepper means don't step (as now), but in other groups means the stepper form is the same as the init form. This allows one to do, for example: (DO (((X L (CDR X))) ((Y (CAR X)) (Z (CAAR X) (CDAR X)))) ((OR (NULL X) (EQ Z 'LOSE)) (BARF)) ...) I.e. Y is always the CAR of X, and Z is a function of X also. This is not the same as a LET in the body, as these computations get done before the endtest is evaluated each time.  Date: 14 APR 1980 2353-EST From: GLS at MIT-MC (Guy L. Steele, Jr.) Subject: Output CHTRAN To: KMP at MIT-MC CC: (BUG LISP) at MIT-MC SOrry -- I didn't mnake my claim clear, which is: output CHTRAN's don't exactly solve the posed problem, but solve a slightly different one which is closely related, and in a way that may be easier to implement compatibly with the current scheme of things. Indeed, |FOO| ==> FOO ==> foo, but then FOO and |FOO| are identically the same anyway. You'd have to know what output CHTRAN's do and use them wisely. Oh, well.  Date: 14 APR 1980 2346-EST From: JONL at MIT-MC (Jon L White) Subject: "Sorry, guys ..." To: GLS at MIT-MC CC: (BUG LISPM) at MIT-MC, (BUG LISP) at MIT-MC, H at MIT-MC Well, poor "H" getting all that response. Anyway, this particlar piece of mail left one misimpression, or at least so I think, and wonder if you concur. The potential syntax (DOTIMES ...) doesn't share the ambiguities of computed GOTO's, nor of the STATUS-MACRO kludge, but rather has the same case analysis of old/new style DO. On the other hand, the pointer to Interlisp's RPTQ was most welcome.  Date: 14 APR 1980 2342-EST From: KMP at MIT-MC (Kent M. Pitman) Subject: Inverse CHRTRN -- sorry, GLS, you're way off! To: GLS at MIT-MC CC: (BUG LISP) at MIT-MC, Dave.Touretzky at CMU-10A Not so! Let's suppose we downcase on input. Then Input Internal Output FOO foo foo foo foo foo |FOO| FOO |FOO| but if you downcase only on output then you get Input Internal Output FOO FOO foo foo foo foo |FOO| FOO foo Ie, you lose the information that something was |...|'d on input. That information should not get stored with the token as what needs to be /'d or |...|'d may change if reader syntax changes between input and output. The only right time that this decision can be made is at input. What is stored internally must be exactly reflected in the output -- it's too late to make a case decision at print time. It must be made at read time. or you'll get the bug on line 3 of my second example. -kmp  Date: 14 April 1980 23:33-EST From: "Guy L. Steele, Jr." Subject: DOTIMES cc: BUG-LISPM at MIT-AI, BUG-LISP at MIT-AI Date: 9 April 1980 13:24-EST From: Jack Holloway Besides the cogent argument in favor of a named DOTIMES (and it's too bad we can't flush old-style DO so we wouldn't need DO-NAMED), letting (DOTIMES X ...) mean (DOTIMES (G3453 X) ...) has the extremely nasty property that there is a context which wants a value in which you can only specify it by means of a variable, and not by an expression. This is like the old computed-GO or STATUS-MACRO kludge, only backwards. If you really want that, why not use the InterLISP name RPTQ or something? Or, (DOTIMES (IGNORE X) ...) isn't so bad... Sorry, guys -- this was from me. -- GLS  Date: 14 April 1980 23:28-EST From: "Guy L. Steele, Jr." Subject: more on lower case To: BUG-LISP at MIT-MC cc: Dave Touretzky at CMU-10A Why isn't there an "inverse CHTRAN" table for the printer? The same method by which LISP produces upper-case atoms on input could be used to lower-case them on output.  Date: 14 April 1980 23:27-EST From: "Guy L. Steele, Jr." To: KMP at MIT-MC cc: BUG-LISP at MIT-MC, EJS at MIT-MC, Dave.Touretzky at CMU-10A one additional note -- as much as i would like to change them, i'm not sure if it's a good idea to change lisp error messages ... there does exist code that does EQ checks for certain messages... Yech!  Date: 14 April 1980 23:25-EST From: "Guy L. Steele, Jr." Subject: Lowercase controversy To: EJS at MIT-MC, KMP at MIT-MC, BUG-LISP at MIT-MC, Dave.Touretzky at CMU-10A Date: 8 April 1980 19:37-EST From: Eric J. Swenson ... What we are advocating is not user-written error messages, but LISP interpreter error messages. Funny -- I like the fact that LISP system error messages are all upper case, because then I can maker mine lower case, and thus immediately tell whether an error was one detected by the system or by my program. But I agree -- lower case messages are more readabl, WHEN CORRECTLY CAPITALIZED AND PUNCTUATED!  Date: 14 APR 1980 1556-EST From: ALAN at MIT-MC (Alan Bawden) To: (BUG LISP) at MIT-MC It would be nice if GRINDEF knew about old-style DO.  Date: 14 April 1980 13:07-EST From: Richard L. Bryan Subject: *CATCH vs named PROG To: BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC One more vote for DLW's lexical catch. Not only do we get to flame about what to call the catch, but also about whether RETURN-FROM and friends are still acceptable names.  Date: 14 April 1980 11:56-EST From: Glenn S. Burke Subject: ARRAYCALL vs FUNCALL To: JONL at MIT-MC, CWH at MIT-MC cc: BUG-LISP at MIT-ML There are two solutions to the problem of evaluating an array reference of unknown type, without that huge macro with a dispatch, if the arrays are all array pointers. One is to have routines like AR-n and AREF, which can be simply open-coded into a pushj into the asar of the array, which is (i believe) effectively what FUNCALL does, but only after the uuo and hairy dispatch. The other (which JONL suggested some time ago) is similar, but differs in that the subscript(s) have already been mapped down to one dimension by the compiler. An internal entry in lisp (JSP presumably) would then do the type dispatch and fetch. AR-1 etc could also be open-coded into this. The third alternative, which is less optimal but trivially realized, is simply to have AR-1 etc defined as exprs. I'm not sure, but it is possible that even with type checking they might be faster than FUNCALL, but again, the array must be an array pointer.  Date: 14 APR 1980 1020-EST From: JONL at MIT-MC (Jon L White) Subject: ARRAYCALL vs FUNCALL To: CWH at MIT-MC CC: (BUG LISP) at MIT-MC An opencoded ARRAYCALL should take about 5-10 JonlJiffies of time, whereas a CALLF (the compilation of FUNCALL) would probably take at least 100 JJ's. I believe the reason PAULW used FUNCALL rather than ARRAYCALL is that he wasn't sure that all of his "arrays" were indeed arrays, or whetehr some of them were perhaps symbols with array properties. Maybe you could run a few tests, with all the (FUNCALL ...) turned into something like (IF (EQ (TYPEP ) 'ARRAY) (ARRAYCALL T ...) (BREAK PAULW-LOSES-ON-FUNCALL)) Indeed, the maclisp interpreter permits you to FUNCALL any kind of array, whether it be type T or FIXNUM or whatever; if this is the problem (instead of the potential for getting SYMBOLs as arrays), and if speed is of the essence, then modulo multiple evaluations of arguments (for which, see NILCOM;EVONCE >) you could write something like (DEFMACRO FULLARRAYCALL (&REST L &AUX (A (CAR L))) `(CASEQ (ARRAY-TYPE ,a) (FIXNUM (ARRAYCALL FIXNUM ,.l)) (FLONUM (ARRAYCALL FLONUM ,.l)) (T (ARRAYCALL T ,.l)))) Currently, "ARRAY-TYPE" is not a primitive maclisp funciton, although more than once we wish it were. It could be defined as (DEFMACRO ARRAY-TYPE (A) `(EQ (CAR (ARRAYDIMS ,a)) 'ARRAY)) but for speed and non-CONSibility, we should write this one as a hand-coded LAP subr.  Date: 13 APR 1980 1952-EST From: CWH at MIT-MC (Carl W. Hoffman) To: (BUG LISP) at MIT-MC, GSB at MIT-MC FORMAT should be taught about ~. Also, the error message it prints when encountering an unknown ~ command is very crypting.  GSB@MIT-ML 04/13/80 19:13:11 Re: winning features To: (BUG LISP) at MIT-ML It's always nice to know that if one attempts to do anything nifty with all the neato winning structure frobs that in the end when they load EXTEND in it bombs out because the currently installed lisp is "ancient".  Date: 13 April 1980 08:05-EST From: Kent M. Pitman Subject: Reply to RIVEST's MINUS/DIFFERENCE/- query To: BUG-LISP at MIT-MC I replied and put a copy of my reply in KMP;[MC]AR1:MINUS REPLY.