Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Nov 85 17:37:59 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Nov 85 14:29:37 PST Received: ID ; Sat 23 Nov 85 17:29:29-EST Date: Sat, 23 Nov 1985 17:29 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Stanley Shebs Cc: common-lisp@SU-AI.ARPA Subject: Misc Queries In-reply-to: Msg of 23 Nov 1985 16:53-EST from David A. Moon I agree with Moon's analysis of your queries. Not only is the Spice implementation not the definition of the language, but it has never been exhaustively tested for compliance with the manual -- it is hard to get part-time undergrads (and overworked faculty members) to do such tedious things, and we have never had sufficient funding to hire people specifically to do testing. So Spice Lisp is useful as an implementors kit (the best one I know of that you can get for free) but nobody should be too surprised if it contains occasional errors in odd corners. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Nov 85 17:05:33 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 13:55:37 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361434; Sat 23-Nov-85 16:54:13-EST Date: Sat, 23 Nov 85 16:53 EST From: David A. Moon Subject: Misc Queries To: Stanley Shebs cc: common-lisp@SU-AI.ARPA In-Reply-To: <8511231713.AA22920@utah-orion.ARPA> Message-ID: <851123165317.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 23 Nov 85 10:13:25 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) While working on PCLS, we've encountered some situations which are probably trivial, but which I don't recall having been brought up: 1) What should (export nil) do? The CLM says that the first argument is either a symbol or list of symbols, but doesn't tell how to handle nil. Personally, I would prefer having nil mean an empty list, but Spice code assumes you want to export the symbol nil. The second sentence of the last paragraph on page 182 is quite explicit. The Spice implementation is not the definition of the language. 2) The definition of macroexpand is that it does macroexpand-1 repeatedly, while (for instance) PSL macroexpand tries to find all macros in a form and expand them. Is CL macroexpand defined correctly? What the book says is "correct" by definition. Whether it's the best possible language definition is another matter. If so, is an exhaustive macroexpander considered a compiler thing (because of the need for special form knowledge)? Yes. It's a useful thing to have, but it isn't the same as the macroexpand function. It's necessary to have something more general than this to implement setf correctly, so I expect most implementations have this capability. 3) What is the general theory of destructive operations during lambda list processing (such as by initforms)? For instance, how much structure should be shared by an &rest binding and &key bindings? This would be clearer if you gave an example. If you're thinking of something like (defun disgust (&rest r &key (a (setq r nil)) b) (list a b)) (disgust :b 2) or even worse (defun disgust (&rest r &key (a (setf (second r) nil)) b) (list a b)) (disgust :b 2) I don't think we anticipated that anybody would try this when we were designing the language. I'd be happy to say that each of these is an error. I wasn't able to come up with any problematic examples that didn't involve modifying the &rest argument. Did you have others in mind? 4) What should happen if one does a defun with a documentation string included, then later redefines the same function, but without specifying a doc string? Should the old one go away? Spice Lisp seems to leave it alone. It should go away; think about what happens if you changed the function so that it no longer conforms to what the old documentation said. The Spice implementation is not the definition of the language.  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Nov 85 16:56:17 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 13:45:42 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361428; Sat 23-Nov-85 16:43:13-EST Date: Sat, 23 Nov 85 16:49 EST From: Daniel L. Weinreb Subject: Minor typo To: common-lisp@SU-AI.ARPA Message-ID: <851123164942.5.DLW@CHICOPEE.SCRC.Symbolics.COM> There seems to be a minor typo on page 23, second paragraph of 2.2.4, second line, in which an existential qualifier symbol appears where there ought to be a numeral "3".  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Nov 85 12:22:48 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 09:13:24 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA08458; Sat, 23 Nov 85 10:13:27 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA22920; Sat, 23 Nov 85 10:13:25 MST Date: Sat, 23 Nov 85 10:13:25 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8511231713.AA22920@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Misc Queries While working on PCLS, we've encountered some situations which are probably trivial, but which I don't recall having been brought up: 1) What should (export nil) do? The CLM says that the first argument is either a symbol or list of symbols, but doesn't tell how to handle nil. Personally, I would prefer having nil mean an empty list, but Spice code assumes you want to export the symbol nil. 2) The definition of macroexpand is that it does macroexpand-1 repeatedly, while (for instance) PSL macroexpand tries to find all macros in a form and expand them. Is CL macroexpand defined correctly? If so, is an exhaustive macroexpander considered a compiler thing (because of the need for special form knowledge)? 3) What is the general theory of destructive operations during lambda list processing (such as by initforms)? For instance, how much structure should be shared by an &rest binding and &key bindings? 4) What should happen if one does a defun with a documentation string included, then later redefines the same function, but without specifying a doc string? Should the old one go away? Spice Lisp seems to leave it alone. stan shebs  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 20:56:21 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 17:39:25 PST Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" Subject: LET-IF To: robbins%bach.decnet@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS Message-ID: <[MIT-MC.ARPA].729508.851122.GJC> Funny you should mention that, I'm considering flushing quite a few special forms in the LMI system and replacing them with macros, LET-IF is one, and the following definition seems right: (defmacro let-if (pred bindings &body body) (let ((f (gentemp "f))) `(flet ((,f () ,@body)) (if ,pred (let ,bindings (,f)) (,f))))) The are similar constructions that conditionally bind dynamic things of various kinds that are already implemented by taking advantage of lexical scoping, CONDITION-BIND-IF (conditionally binding error handling) is one fairly common form: (condition-bind-if (not *debugging*) (x) (form) (error x)) for example. Anyway, FLET is an ideal tool for avoiding what you describe as "I don't want to have to double the size of the function by having the body twice" Or, as Mr Roberts would say, "can you say... CLOSURE," yes boys and girls...  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 20:54:28 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 17:38:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 223229; Fri 22-Nov-85 20:36:20-EST Date: Fri, 22 Nov 85 20:36 EST From: David A. Moon Subject: Sigh on recursive printing. To: "BACH::GREEK" cc: common-lisp In-Reply-To: The message from "BACH::GREEK" Message-ID: <851122203606.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 0 0 00:00:00 EST From: "BACH::GREEK" Perhaps you folks aren't reading our mail because of the screwed up date (although why your mail readers care about our date I'll never understand). Never? I like being able to sort conversations into chronological order so I have a hope of understanding them when I read them. Unpredictable network delays frequently cause messages to get out of order.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 20:42:14 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 17:33:01 PST Date: 0 0 00:00:00 EST From: "BACH::ROBBINS" Subject: LET-IF To: "common-lisp" cc: robbins Reply-To: "BACH::ROBBINS" Both Jonathan and Scott have suggested methods to deal with the situation that I posed. While LET-IF is certainly not required I still think it would be worth having in the language. Sigh. -- Rich ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 20:31:57 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 17:22:29 PST Date: Fri, 22 Nov 85 20:24:55 EST From: "George J. Carrette" Subject: Recursive printing proposal To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Fri 22 Nov 1985 16:51 EST from Scott E. Fahlman Message-ID: <[MIT-MC.ARPA].729486.851122.GJC> One way to deal with printer extensions is to make them a bit more formal, like the SETF extension mechanism which is less general then macro definition but gets the intended job done with less duplicated work. In the implementations that people have now I venture to say they could look at the way that circular-print is handled, and build at least PRINT-DEPTH handling into that. Maybe we should adopt a "programmable printer" like that of Hawkinson, or a cleaned-up version of Waters?  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 20:01:28 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 14:29:27 PST Received: ID ; Fri 22 Nov 85 17:28:39-EST Date: Fri, 22 Nov 1985 17:28 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "BACH::ROBBINS" Cc: common-lisp Subject: LET-IF In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS (defvar *flag*) (defun f () (let-if (some-condition-that-may-be-satisfied-several-times) ((*flag* nil)) ;; large body that will call f recursively and possibly set *flag* (when *flag* ;; perform special processing ))) It's hard for me to see exactly what is intended here, since I think you've got some bugs in your example. If that condition isn't true, *flag* stays unbound and the WHEN form gets an error. It looks to me like you're trying to establish some sort of handler whenever you find the hairy condition to be true, so that when you emerge from the body you will do something at this level (only) whenever the flag has been set. But in the code you give, the "special processing" will occur at all calls to F between the place where flag is set and the innermost surrounding F where the condition was true. I think that in most cases I would be inclined to handle this upward communication by the return value rather than by side-effecting some conditionally bound variable. It's less confusing that way. But if you must do something like this, I see no reason not to use PROGV. It shouldn't be any more inefficient than any other way of binding a special, as long as the list of variables is a quoted constant at compile time. If your local compiler generates lousy code for PROGV, it should be easy to add an optimization to handle the constant-variable-list case as efficiently as any other binding of a special. If you don't like the looks of PROGV, then you can easily write your own LET-IF macro in terms of PROGV, as long as you restrict this form to binding special variables only. I perhaps mistakenly assumed that the "overkill" you referred to earlier was in being forced to use a special variable when you wanted a lexical one, but that is not the case in your example. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 19:57:42 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 14:18:33 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Sigh on recursive printing. To: "common-lisp" Reply-To: "BACH::GREEK" Passing around the current depth is NOT a reasonable solution. Perhaps you folks aren't reading our mail because of the screwed up date (although why your mail readers care about our date I'll never understand). Anyway, the solutions in order of cleanliness seem to me: 1. Add a recursive-p argument to ALL the printing functions. 2. Implement some kind of TOP-LEVEL-PRINT macro. 3. Add a depth argument to ALL the printing functions. Why are you assuming that top-level prints only affect the depth? They may do all sorts of other things. Since we aren't likely to accept 1 or 3 because we can't add arguments to functions, then it looks like 2. - Paul ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 19:45:53 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 16:30:24 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361025; Fri 22-Nov-85 19:29:11-EST Date: Fri, 22 Nov 85 19:35 EST From: Daniel L. Weinreb Subject: Sigh on recursive printing. To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA In-Reply-To: The message from "BACH::GREEK" Message-ID: <851122193538.9.DLW@CHICOPEE.SCRC.Symbolics.COM> From: "BACH::GREEK" Perhaps you folks aren't reading our mail because of the screwed up date (although why your mail readers care about our date I'll never understand). Since you've mentioned this more than once: Zmail doesn't get broken in any way by your messages. It understands that the header is illegal and displays the message anyway. I am sending this message using the Zmail "reply" command, and it had no trouble reversing the addresses. We are receiving all your mail.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 18:26:41 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 13:52:04 PST Received: ID ; Fri 22 Nov 85 16:51:36-EST Date: Fri, 22 Nov 1985 16:51 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: Recursive printing proposal In-reply-to: Msg of 22 Nov 1985 15:58-EST from Kent M Pitman The right way to fix this is to give the user some way to obtain the current depth (the structure printing stuff already has this), and some way to pass the depth to use as an optional or keyword argument to Write (and maybe to the other printing thingies). This seems much simpler to me than adding printer continuations and such to the language. The other suggestions were merely for quick and dirty fixes that might fall within the current language spec, but I guess we'd better not play that game lest such things get locked in. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 18:24:37 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 14:42:46 PST Date: Fri, 22 Nov 85 17:45:05 EST From: Jonathan A Rees Subject: LET-IF To: robbins%bach.decnet@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS Message-ID: <[MIT-MC.ARPA].729122.851122.JAR> What's wrong with (defmacro let-if (test bindings &body body) (let ((f (gensym))) `(flet ((,f () ,@body)) (if ,test (let ,bindings (,f)) (,f))))) ?  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:44:33 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 13:28:54 PST Received: ID ; Fri 22 Nov 85 16:28:09-EST Date: Fri, 22 Nov 1985 16:28 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp Subject: LET-IF In-reply-to: Msg of 22 Nov 1985 15:05-EST from David A. Moon What if the variable is unbound? Well, in that case it usually does no harm to rebind the thing unconditionally. The code would then look like (let ((foo (if (boundp foo) foo foo-default))) ...) I grant that a user might want to use a macro to abbreviate the above idiom if it is used a lot, but it is probably not something that is used enough to belong in the langauge proper. Are there other common uses of LET-IF that would not be captured adequately by something like the above? -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:42:33 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 13:23:20 PST Received: ID ; Fri 22 Nov 85 16:22:42-EST Date: Fri, 22 Nov 1985 16:22 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Subject: Fill-pointers and sequences In-reply-to: Msg of 22 Nov 1985 15:36-EST from David A. Moon I do not feel strongly about which way this issue is resolved, but I agree that it should be tied down. I mildly favor a strict interpretation. Okay, but I have to ask what we gain by making the user go through this 5-line rigamarole when a simple call to FILL would suffice if the language were defined the other way. To me, the fill-pointer is simply the current length and doesn't mean that the rest of the vector does not exist in any sense (see the note on p.295 that vector elements not in the active region are still part of the vector). I guess the language is going to be ugly either way. I also want to repeat my query which no one addressed yet: Does the answer depend on whether the sequence function in question is one that writes (like FILL or REPLACE) or one that reads (like POSITION or REMOVE)? We've got two data abstractions going here: the sequence and the vector which implements it. I am suggesting that the stuff beyond the fill pointer is in the vector, but not in the sequence. What we gain is a nice clean image of what the sequence is, without a lot of special cases. In my opinion, the read/write distinction should not matter -- generic sequence functions should not read or write beyond the current boundaries of the sequence, though vector/array primitives like AREF and SVREF may do so. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:36:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 13:05:48 PST Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360771; Fri 22-Nov-85 15:57:13-EST Date: Fri, 22 Nov 85 15:58 EST From: Kent M Pitman Subject: Recursive printing proposal To: Fahlman@C.CS.CMU.EDU cc: robbins%bach.decnet@HUDSON.DEC.COM, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851122155820.2.KMP@DUPAGE.SCRC.Symbolics.COM> Date: Fri, 22 Nov 1985 14:26 EST From: "Scott E. Fahlman" I think this would have to be a special form and not a macro, since it cannot be implemented using existing forms. It could be introduced as a function which took a printer continuation. A macro could then be written by anyone who didn't like functional notation. It might be better to add a function to sense and setf the current print depth, and implement your own macro in terms of that. I'd agree with adding such primitives, but I don't think this is a good way to think about a toplevel printing abstraction. What if some day we decide there is more to toplevel printing than just noticing when the depth gets reset to zero. Better to have an abstraction which does "any necessary setup" for printing a toplevel object. I'm not sure that this is a good abstraction to have, but if we have it, I think that these thoughts are relevant. I do know that I think we should have had an INVOKE-TOPLEVEL-READER abstraction rather than passing around recursive-p information. I guess I'd be willing to consider a function like the following: PRINT-OBJECT-TOPLEVEL OBJECT &KEY FUNCTION STREAM which could be described to do something roughly like the following, plus any system-specific stuff which didn't interfere with the basic idea ... whatever that means (sigh) ... (DEFUN PRINT-OBJECT-TOPLEVEL (OBJECT &KEY FUNCTION STREAM) (LET ((*STANDARD-OUTPUT* (OR STREAM *STANDARD-OUTPUT*))) (LET ((OLD-DEPTH (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*))) (UNWIND-PROTECT (PROGN (SETF (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*) 0) (FUNCALL (OR FUNCTION #'PRIN1) OBJECT)) (SETF (CURRENT-PRINT-DEPTH *STANDARD-OUTPUT*) OLD-DEPTH)))))  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:32:49 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 13:21:12 PST Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360792; Fri 22-Nov-85 16:05:11-EST Date: Fri, 22 Nov 85 16:06 EST From: Kent M Pitman Subject: adjust-array with :initial-elements and fill pointers To: DLW@SCRC-QUABBIN.ARPA, KMP@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <851122145536.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <851122160610.3.KMP@DUPAGE.SCRC.Symbolics.COM> Date: Fri, 22 Nov 85 14:55 EST From: Daniel L. Weinreb Date: Fri, 22 Nov 85 11:55 EST From: Kent M Pitman Given: (setq a (make-array 5 :fill-pointer 3)) (setf (aref a 0) 'x) (setf (aref a 2) 'z) (adjust-array a 7 :initial-element 'b) Which of the following are you proposing: 1. A = [ X ? Z ? ? B B ] 2. A = [ X ? Z B B B B ] 3. A = [ X B Z B B B B ] 4. A = [ B B B B B B B ] 5. Other (please specify) I am assuming that "in the bounds" means "less than 5". Therefore, I am advocating choice number 1. See the definition of :initial-element on page 297. Oh, ok. I couldn't imagine that you were suggesting #1. I'm glad I asked. #1 sounds fine to me. CLtL doesn't seem to say what happens to the fill pointer if there was no fill pointer specified in the ADJUST-ARRAY call but there was one specified to MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS or Scott should correct me if I'm wrong). DLW, I am not clear on whether you are suggesting that it it be reset (ie, that it be the same as specifying :FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate? I am also assuming that the fill pointer remains 3. I would be curious to hear an elaboration of your motivation. The feeling is that the programmer would reasonably expect this code to initialize the elements beyond the fill pointer, so that when the fill pointer is increased, instead of finding unpredictable junk in the array, the contents will be what was specified by :initial-elements. It seems like the most useful definition. Although, interestingly, in this example, elements 3 and 4 will (rightly) contain unpredictable junk. I think we agree even though I don't think what you said in this paragraph is true. I believe what you meant is that in the case of: (setq a (make-array 5 :fill-pointer 3 :initial-element 'q)) ;added this (setf (aref a 0) 'x) (setf (aref a 2) 'z) (adjust-array a 7 :initial-element 'b) he has a right to expect that information beyond element 2 will not be junk (ie, slots 3 and 4 will contain non-junk from the MAKE-ARRAY and slots 5 and 6 will contain non-junk from the ADJUST-ARRAY).  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:16:20 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 13:04:10 PST Date: 0 0 00:00:00 EST From: "BACH::ROBBINS" Subject: LET-IF To: "common-lisp" cc: robbins Reply-To: "BACH::ROBBINS" I will give an example to illustrate why I think that we need LET-IF. If there is a clean way to get around my need for a conditional bind, then please let me know. (defvar *flag*) (defun f () (let-if (some-condition-that-may-be-satisfied-several-times) ((*flag* nil)) ;; large body that will call f recursively and possibly set *flag* (when *flag* ;; perform special processing ))) I don't want to have to double the size of the function by having the body twice. I can't use catch and throw when the event happens because I only wish to note that the event has happened, not terminate processing. The function f is to be called very frequently and I want it to be as fast as possible, hence PROGV seems like overkill. Binding *flag* to a mutable object ... (let ((*flag* (if (condition) (cons nil nil) *flag*))) ... seems like a real hack. -- Rich ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:15:35 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 13:03:46 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Common LISP is too big? To: "common-lisp" Reply-To: "BACH::GREEK" I'm not sure I understand everyone's attitude about Common LISP being too big. Dave Moon has a construct he likes so much that he absolutely believes it ought to be in Symbolics Common LISP but doesn't want anyone else to have it. Perhaps he just thinks that for compatability with ZetaLisp, which I guess makes some sense. You know, we could certainly prevent the language from gaining weight by leaving out an error handling system, an object system, windows, etc. If we don't want to make the language larger than it is today, we should have made it smaller in the first place. But we didn't. - Paul ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:03:46 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:52:56 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360754; Fri 22-Nov-85 15:46:04-EST Date: Fri, 22 Nov 85 15:45 EST From: David A. Moon Subject: TYPEP and arrays of (SATISFIES F) To: Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: <851118163500.9.GLS@THINK-HILARION.ARPA> Message-ID: <851122154519.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 18 Nov 85 16:35 EST From: Guy Steele Bob Rorschach has raised the following question: what is the result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10))) supposed to be? Consider these special cases: (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER) '(ARRAY (SATISFIES FIXNUMP) (10))) (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM) '(ARRAY (SATISFIES FIXNUMP) (10))) We can easily dismiss the first case, because clearly an array specialized to hold integers is not necessarily the same as one specialized to hold fixnums. The second is more difficult. It happens to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type specifiers, but in many implementations SUBTYPEP cannot discern this fact (and indeed is not required to). When TYPEP sees a plain old SATISFIES specifier, it can just call the function, but not so when it is the element type of an ARRAY specifier. Returning NIL for (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10))) seems consistent with the discussion on page 45 of the manual. Referring to the last line on that page, in an implementation without a specialized array type for elements of type (SATISFIES F), no object can pass that test. I guess it's still an open question whether every implementation should be required to return T for (EQUAL-TYPEP 'FIXNUM '(SATISFIES FIXNUMP)) and hence T for (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE 'FIXNUM) '(ARRAY (SATISFIES FIXNUMP) (10))). Yes, I know EQUAL-TYPEP is not a standard Common Lisp function, but I think you get what I mean by it. I don't think it would be a good idea to require this, because you quickly open the door to questions like "well, what about (SATISFIES SMALL-INTEGER-P) where somewhere in the program it says (DEFUN SMALL-INTEGER-P (X) (FIXNUMP X))". One way out (proposed language change) is to define TYPEP to be like SUBTYPEP, in that it returns two values; if the first value is NIL, the second value says whether that's a "no" or a "maybe". So for the first special case above TYPE would return either NIL T or NIL NIL, depending on the cleverness of the implementation, and for the second special case would return either NIL NIL or T T. I don't think we need to change the language.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 16:01:14 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:49:22 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360737; Fri 22-Nov-85 15:37:13-EST Date: Fri, 22 Nov 85 15:36 EST From: David A. Moon Subject: Fill-pointers and sequences To: Guy Steele cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <851121104241.1.GLS@FAUSTINUS.THINK.COM> Message-ID: <851122153632.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 21 Nov 85 10:42 EST From: Guy Steele There are two other passages you might consider. First, page 246, last paragraph, states that the :start and :end arguments should be integer indices "into the sequence"; is an index larger than the fill pointer "into the sequence" or merely "into the vector"? Second, page 291 notes that "aref is unusual among the functions that operate on arrays in that it completely ignores fill pointers". If we really believed the book to be careful and accurate, we might infer that other functions not specifically documented to be in this unusual category may not access beyond the fill pointer; but in the actual event this inference is shaky at best. I think I would be inclined to write the code in this manner: (setq a (make-array 10 :fill-pointer 3)) (let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a)))) (fill a nil :start (fill-pointer a) :end (array-dimension a 0)) (setf (fill-pointer a) old-fill-pointer)) or, for the truly worried, (let ((old-fill-pointer (array-total-size a))) (unwind-protect (progn (setf (fill-pointer a) (array-total-size a)) (fill a nil :start (fill-pointer a) :end (array-dimension a 0))) (setf (fill-pointer a) old-fill-pointer))) I do not feel strongly about which way this issue is resolved, but I agree that it should be tied down. I mildly favor a strict interpretation. Okay, but I have to ask what we gain by making the user go through this 5-line rigamarole when a simple call to FILL would suffice if the language were defined the other way. To me, the fill-pointer is simply the current length and doesn't mean that the rest of the vector does not exist in any sense (see the note on p.295 that vector elements not in the active region are still part of the vector). I guess the language is going to be ugly either way. I also want to repeat my query which no one addressed yet: Does the answer depend on whether the sequence function in question is one that writes (like FILL or REPLACE) or one that reads (like POSITION or REMOVE)?  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 15:55:48 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:43:46 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360717; Fri 22-Nov-85 15:28:35-EST Date: Fri, 22 Nov 85 15:27 EST From: David A. Moon Subject: :Structure-Print and *print-level* To: Scott E. Fahlman , Guy Steele , "BACH::GREEK" , Dan Hoey , "BACH::ROBBINS" , Rob MacLachlan cc: common-lisp@SU-AI.ARPA In-Reply-To: , <851121112509.7.GLS@FAUSTINUS.THINK.COM>, <501445600/hoey@nrl-aic>, , <501463108/hoey@nrl-aic>, The message from "BACH::ROBBINS" , , The message from "BACH::GREEK" Message-ID: <851122152746.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Introducing magic hidden variables and kludgey recursive-p arguments to control them is inviting disaster. I'm strongly opposed to this. We've had some experience with this in Zetalisp and it is not good. It is always better to pass this kind of state around as explicit arguments than to put it in hidden variables. I fail to see what was wrong with the suggestion in Fahlman's original message of adding a :DEPTH argument to WRITE, which defaults to 0 but can be supplied by a structure's print function if it so desires. I should think the answer to the question of whether a structure's print function should increment the depth that it received as an argument before passing it on to WRITE is perfectly obvious: it depends on whether the print function printed any left parentheses before calling WRITE. I think the fact that the print system has no reasonable way to tell whether the print function printed any left parentheses, other than the print function telling it so, counters Greek's argument that the old thing should be automatic. Suppose the print function uses brackets as part of its syntax and wants them treated as equivalent to a level of parentheses for depth-abbreviation purposes. I'm not concerned about the case of print functions that call FORMAT. FORMAT is a convenient abbreviation mechanism for writing code to do simple forms of formatting quickly. If you need to do something more complicated, you don't add a new feature to FORMAT, you use Lisp instead of the FORMAT string language.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 15:35:39 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:24:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360684; Fri 22-Nov-85 15:06:01-EST Date: Fri, 22 Nov 85 15:05 EST From: David A. Moon Subject: LET-IF To: Scott E. Fahlman cc: robbins%bach.decnet@HUDSON.DEC.COM, common-lisp In-Reply-To: Message-ID: <851122150515.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 22 Nov 1985 14:41 EST From: "Scott E. Fahlman" Is there a good reason why we don't have a ZetaLisp style LET-IF special form? Using PROGV to bind an item based on some trivial condition seems like overkill to me. What would you use this for? Why not just rebind the variable to its old value and then conditionally change it? Common Lisp is big enough without adding special forms that would only be used only very rarely. What if the variable is unbound? Not that I am advocating adding this to Common Lisp. There are things that I firmly believe belong in Symbolics Common Lisp and equally firmly believe do not belong in the Common Lisp language standard, which as you say is quite large already.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 15:34:45 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 12:07:45 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360668; Fri 22-Nov-85 14:49:16-EST Date: Fri, 22 Nov 85 14:55 EST From: Daniel L. Weinreb Subject: adjust-array with :initial-elements and fill pointers To: KMP@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <851122115545.9.KMP@DUPAGE.SCRC.Symbolics.COM> Message-ID: <851122145536.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Fri, 22 Nov 85 11:55 EST From: Kent M Pitman Given: (setq a (make-array 5 :fill-pointer 3)) (setf (aref a 0) 'x) (setf (aref a 2) 'z) (adjust-array a 7 :initial-element 'b) Which of the following are you proposing: 1. A = [ X ? Z ? ? B B ] 2. A = [ X ? Z B B B B ] 3. A = [ X B Z B B B B ] 4. A = [ B B B B B B B ] 5. Other (please specify) I am assuming that "in the bounds" means "less than 5". Therefore, I am advocating choice number 1. See the definition of :initial-element on page 297. CLtL doesn't seem to say what happens to the fill pointer if there was no fill pointer specified in the ADJUST-ARRAY call but there was one specified to MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS or Scott should correct me if I'm wrong). DLW, I am not clear on whether you are suggesting that it it be reset (ie, that it be the same as specifying :FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate? I am also assuming that the fill pointer remains 3. I would be curious to hear an elaboration of your motivation. The feeling is that the programmer would reasonably expect this code to initialize the elements beyond the fill pointer, so that when the fill pointer is increased, instead of finding unpredictable junk in the array, the contents will be what was specified by :initial-elements. It seems like the most useful definition.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 15:31:51 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 10:43:09 PST Date: 0 0 00:00:00 EST From: "BACH::ROBBINS" Subject: LET-IF To: "common-lisp" cc: robbins Reply-To: "BACH::ROBBINS" Is there a good reason why we don't have a ZetaLisp style LET-IF special form? Using PROGV to bind an item based on some trivial condition seems like overkill to me. -- Rich ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 15:09:00 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 11:54:16 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: TOP-LEVEL-PRINT macro. To: "common-lisp" Reply-To: "BACH::GREEK" I'm not sure why a TOP-LEVEL-PRINT macro would have to be a special form. It just generates whatever code the print system needs to realize this is a top-level print. For example, it could bind a special variable to zero and then execute the body. It only has to set the state of the world so that the print system knows it's a top-level print. Don't want to restrict anything by saying there is something to fetch and SETF, or whatever. There is no need to know how the print system deals with TOP-LEVEL-PRINT. - Paul ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 15:05:48 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 09:33:20 PST Date: 0 0 00:00:00 EST From: "BACH::ROBBINS" Subject: Recursive printing proposal To: "common-lisp" cc: robbins Reply-To: "BACH::ROBBINS" I propose that we add the following macro: TOP-LEVEL-PRINT &BODY BODY The macro is responsible for ensuring that any printing within BODY will be started as a top level print. This achieves what having RECURSIVE-P arguments to printing functions would without breaking existing source code and without requiring any changes to FORMAT. I think that while we should specify that the printer automatically handles depth abbreviation, we should not specify how it is to be implemented. -- Rich ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 14:53:35 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 11:42:46 PST Received: ID ; Fri 22 Nov 85 14:41:52-EST Date: Fri, 22 Nov 1985 14:41 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: robbins%bach.decnet@HUDSON.DEC.COM Cc: common-lisp Subject: LET-IF In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS Is there a good reason why we don't have a ZetaLisp style LET-IF special form? Using PROGV to bind an item based on some trivial condition seems like overkill to me. What would you use this for? Why not just rebind the variable to its old value and then conditionally change it? Common Lisp is big enough without adding special forms that would only be used only very rarely. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 14:37:35 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Nov 85 11:27:38 PST Received: ID ; Fri 22 Nov 85 14:26:37-EST Date: Fri, 22 Nov 1985 14:26 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "BACH::ROBBINS" Cc: common-lisp Subject: Recursive printing proposal In-reply-to: Msg of 0 0 00:00:00 EST from BACH::ROBBINS I think this would have to be a special form and not a macro, since it cannot be implemented using existing forms. It might be better to add a function to sense and setf the current print depth, and implement your own macro in terms of that. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 13:37:06 EST Date: 22 Nov 85 1015 PST From: Dick Gabriel Subject: Reminder about the Common Lisp Meeting To: Common-lisp@SU-AI.ARPA I would like to remind you about the Common Lisp meeting, which will be Monday, Tuesday, Wednesday, Decembers 9, 10, and 11; at: Boston Marriott Hotel Copley Place 110 Huntington Avenue Boston, Massachusetts 02117 (617)236-5800 The room will be ours from 8:30am until 6:00pm each of those days. There is a block of rooms at that hotel set aside for us. I understand that it is a fancy hotel, and the rooms are not cheap, even with the discount I got for the meeting. The rooms are $100 single and $115 double, which is $60 off the regular rate. When you make your reservations, specifically mention the Common Lisp meeting. Here is an important piece of information: ************************************************************************ * * * The block of rooms will be held for us until November 25, and * * they can be booked for the evenings of Decemeber 8, 9, 10. * * * ************************************************************************ The usual caveats apply to this hotel: a reservation without a guarantee will only hold the room until 6:00pm of the evening of your arrival. A guarantee is usually an American Express card number. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 12:10:33 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 08:56:12 PST Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360471; Fri 22-Nov-85 11:54:46-EST Date: Fri, 22 Nov 85 11:55 EST From: Kent M Pitman Subject: adjust-array with :initial-elements and fill pointers To: DLW@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <851122103647.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <851122115545.9.KMP@DUPAGE.SCRC.Symbolics.COM> Date: Fri, 22 Nov 85 10:36 EST From: Daniel L. Weinreb Consider the following forms: (setq a (make-array 5 :fill-pointer 3)) (adjust-array a 7 :initial-element 'b) What should happen? On page 297, it says "The elements of the new array that are not in the bounds of array are initalized to the :initial-element". The question is whether the elements that follow the fill pointer are considered to be within the "bounds of the array". The sentence on page 295, "Nearly all functions that operate on the contents of a vector will operate only on the active elements", is what makes this issue less than perfectly clear. Our recommendation is that the entire new array be initialized, despite the presence of the fill pointer, and that adjust-array be clearly designated as one of the exceptions to the "nearly all" phrase. Given: (setq a (make-array 5 :fill-pointer 3)) (setf (aref a 0) 'x) (setf (aref a 2) 'z) (adjust-array a 7 :initial-element 'b) Which of the following are you proposing: 1. A = [ X ? Z ? ? B B ] 2. A = [ X ? Z B B B B ] 3. A = [ X B Z B B B B ] 4. A = [ B B B B B B B ] 5. Other (please specify) CLtL doesn't seem to say what happens to the fill pointer if there was no fill pointer specified in the ADJUST-ARRAY call but there was one specified to MAKE-ARRAY. I assume the implication is that the fill pointer remains 3. (GLS or Scott should correct me if I'm wrong). DLW, I am not clear on whether you are suggesting that it it be reset (ie, that it be the same as specifying :FILL-POINTER NIL or :FILL-POINTER T). Can you elaborate? I would be curious to hear an elaboration of your motivation. In my mind, there are reasons for believing any of these are reasonable -- depending on the application, which suggests to me that finer control (ie, more keywords) rather than some arbitrary decision may be the really right thing. Of course, the default must be clarified in any case.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 11:39:01 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Nov 85 08:25:56 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Apology for our brain-damaged mailer. To: "common-lisp" Reply-To: "BACH::GREEK" This is an apology from us DECies for our newly-acquired Wollongong Group Arpanet mailer. The VAX LISP group doesn't manage the Arpanet software, but we'll keep telling those who do about the problems. I suppose the mail heading breaks ZMail and Babyl and other software. Sorry. - Paul ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Nov 85 10:51:48 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Nov 85 07:33:03 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 360372; Fri 22-Nov-85 10:30:23-EST Date: Fri, 22 Nov 85 10:36 EST From: Daniel L. Weinreb Subject: adjust-array with :initial-elements and fill pointers To: common-lisp@SU-AI.ARPA Supersedes: <851122103625.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <851122103647.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Consider the following forms: (setq a (make-array 5 :fill-pointer 3)) (adjust-array a 7 :initial-element 'b) What should happen? On page 297, it says "The elements of the new array that are not in the bounds of array are initalized to the :initial-element". The question is whether the elements that follow the fill pointer are considered to be within the "bounds of the array". The sentence on page 295, "Nearly all functions that operate on the contents of a vector will operate only on the active elements", is what makes this issue less than perfectly clear. Our recommendation is that the entire new array be initialized, despite the presence of the fill pointer, and that adjust-array be clearly designated as one of the exceptions to the "nearly all" phrase.  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 22:31:07 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 19:03:58 PST Date: 0 0 00:00:00 EST From: "BACH::ROBBINS" Subject: Recursive printing. To: "common-lisp" cc: robbins Reply-To: "BACH::ROBBINS" Dan is right. It would be nice if people did not have to scatter RECURSIVE-P's throughout their PRINT functions. It would also be nice if they did not have to scatter them throughout their READ functions. However, they are needed in both instances, unfortunately, they are only defined for READ. The proposal: " ... that a depth be maintained for every stream, and that WRITE to a stream should increment that stream's depth at entry and restore the depth on exit" assumes that it is never the case that someone will want to start a new top level print on a stream when there is printing in progress. Incrementing a counter upon entry to WRITE will not handle the situation where someone interrupts pretty printing and enters a break loop. Printing done during the break loop should not be done as if it were nested within the pretty print, it should be done as though it were at top level. How can this be expressed without explicitly initiating a new top level print? Without a way of explicitly starting a new top level print some heuristic must be used to attempt to determine when a new top level print is started within a recursive print. A good rule of thumb is that the use of a new stream signals the start of a new top level print. Dan's two astronaut print provides an example where the stream switch heuristic fails. The break loop case provides an example where incrementing the internal depth counter whenever WRITE is entered fails. The problem is that we lack a mechanism for explicitly stating that a new top level print is desired. Adding RECURSIVE-P give us this mechanism (although it does not address the problem presented by FORMAT). --Rich ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 20:16:20 EST Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 17:03:15 PST Date: 21 Nov 1985 18:18:28 EST (Thu) From: Dan Hoey Subject: Re: Recursive printing. To: "BACH::GREEK" Cc: Common-lisp@su-ai.ARPA Message-Id: <501463108/hoey@nrl-aic> In-Reply-To: "BACH::GREEK"'s message of 0 0 000000 EST Date: 0 0 00:00:00 EST From: "BACH::GREEK" What exactly is Hoey's proposal? It seems to be twofold. 1. Depth abbreviation is performed automatically by WRITE. 2. A top-level print is started when you print to a different stream from the last print. Is this correct? No, that isn't what I proposed. Point 1 is the rationale for the proposal. I would like to avoid forcing people to scatter :RECURSIVELY-P's throughout their print functions. I proposed that a depth be maintained for every stream, and that WRITE to a stream should increment that stream's depth at entry and restore the depth on exit. Your point 2, if I understand it correctly, is that there be some notion of the current stream, and a single depth that applies to whatever stream is current. A WRITE to the current stream increments the depth; a WRITE to another stream sets the depth to 1 and sets the current stream to that stream. Both depth and current stream are restored on exit from WRITE. Both proposals work for the normal case, when the user's printing function does no output except for the object being printed. Both proposals work for the case I am most concerned about, where printing an object involves normal output on another stream. Where the proposals differ is when printing an object involves output on another stream, and the output on the other stream involves output on the first stream. For instance, with (defun astronaut-print-fn (obj s depth) (format s "[ ~S in space ]" (or (astro-name obj) (progn (format (astro-control obj) "My buddy is ~S. Who am I?~%" (astro-buddy obj)) (read (astro-control obj)))))) if two anonymous astronauts are each other's buddies, they will try to print each other to their respective name servers. If the name servers are different, your proposal does not allow a depth cutoff, whereas mine does. I can't think of any reason why we should prefer one proposal over the other, but they are different. Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 17:15:10 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 13:59:08 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Recursive printing. To: "common-lisp" Reply-To: "BACH::GREEK" What exactly is Hoey's proposal? It seems to be twofold. 1. Depth abbreviation is performed automatically by WRITE. 2. A top-level print is started when you print to a different stream from the last print. Is this correct? ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 16:35:50 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Nov 85 13:24:44 PST Received: ID ; Thu 21 Nov 85 16:24:31-EST Date: Thu, 21 Nov 1985 16:24 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Dan Hoey Cc: common-lisp@SU-AI.ARPA Subject: :Structure-Print and *print-level* In-reply-to: Msg of 21 Nov 1985 13:26-EST from Dan Hoey Hoey's proposal sounds good to me, at least as a pretty good way to handle all this until we can modify the language to give the user more explicit control. Maybe we should suggest this as the preferred thing for an implementation to do, as the language stands now. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 16:28:46 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 13:09:16 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Recursive printing. To: "common-lisp" Reply-To: "BACH::GREEK" Apologies if you got an abbreviated version of this message. Dan Hoey has certainly hit upon some of the problems with recursive printing. And he has suggested, as we have, that depth abbreviation could be handled automatically. The right way to decide if a print is recursive is not by using heuristics (like switching streams or entering break loops), but by explicitly specifying it with recursive-p. The heuristics will only be a hack. However, it certainly isn't clear how to add recursive-p to all the appropriate functions. Perhaps we can agree that depth abbreviation is to be done automatically, but let's not specify how to do it. ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 15:30:35 EST Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 21 Nov 85 12:09:40 PST Date: 21 Nov 1985 13:26:40 EST (Thu) From: Dan Hoey Subject: Re: :Structure-Print and *print-level* To: Guy Steele Cc: common-lisp@SU-AI.ARPA Message-Id: <501445600/hoey@nrl-aic> In-Reply-To: Guy Steele's message of Thu, 21 Nov 85 1125 EST The idea I had had in mind was that the defstruct printing function would look something like (defun astronaut-print-fn (obj s depth) (format s "[***>>> ASTRONAUT! Name: ") (write (astro-name obj) :stream s :level (- *print-level* depth)) (format s " <<<***]")) However, this is not quite the right thing if the originally specified :level argument had not defaulted to the value of *print-level*. Which arises if the printed representation of an astronaut can contain the p. r. of another astronaut. But the real problem with this method is that it confuses the two notions of print level and of print depth. I see no problem with the hidden variable representing the depth in printing functions. My expectation is that this variable should always be incremented on entry to the function WRITE, and restored on exit. In this way a user's printing functions that call PRINT or WRITE behave the same way that WRITE does when it calls itself recursively. One thing that may not be immediately apparent is that the depth should be specific to each stream, so that a printing function that uses WRITE on another stream (presumably as part of determining what its output should be) is not affected by the depth of the stream that it is to print its object on. The assumption here is that during the period when a WRITE to a stream is in progress, any recursive call to WRITE on that stream is for the purpose of printing a part of the object for which the first WRITE was issued. I can imagine cases for which this assumption might not be appropriate: -- some sort of random access scheme with an automatically-maintained index of astronauts in some other part of the file, or -- a debugging trap or trace output that occurs during printing, where some extraneous material will appear in the middle of the printed representation of the object, but I think that both of these uses can be implemented in ways that do not need to know how to access the hidden variable. Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 14:04:13 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Nov 85 10:28:20 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Recursive print & depth abbreviation To: "common-lisp" Reply-To: "BACH::GREEK" We really have two issues here. First of all we need a recursive-p argument to the print functions, including PRINT et al and FORMAT. This is for precisely the same reasons as the read functions -- in order to print an object I may have to use print functions recursively. It's not clear that there's a good way to add recursive-p, especially since FORMAT already takes an &rest argument. (Excluding FORMAT for some religious reason would be wrong.) The second issue is that of print depth. We never should have passed the level to a structure print function. Instead we should have said that the print system worries about print depth in some automatic fashion. After all, the structure print function is going to utilize the print system to print the structure, so the print system ought to be able to do the depth abbreviation just fine. An example of how to do this is given by Dick Waters' PP facility, which implements all abbreviation more or less automatically. Another case in which a top-level versus recursive print must be distinguished is when the printing system buffers output. If you interrupt it in the middle of a print and enter a break loop, clearly a new set of buffers is required so that the original print can continue undaunted later on. The break loop needs to start a new top-level print. Hey, it's just like reading! Passing a level or depth argument to the WRITE function is going to add even more confusion (particularly given our silly definitions of level vs. depth). Anyway, why have we demoted PRINT, PRINC, PRIN1, and FORMAT to second class functions? Hell, everybody uses FORMAT in a structure print function. ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 13:18:46 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85 08:45:40 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1958; Thu 21-Nov-85 11:24:58-EST Date: Thu, 21 Nov 85 11:25 EST From: Guy Steele Subject: :Structure-Print and *print-level* To: Fahlman@CMU-CS-C.ARPA, RAM@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-ID: <851121112509.7.GLS@FAUSTINUS.THINK.COM> Many thanks to Scott for illuminating this issue. The idea I had had in mind was that the defstruct printing function would look something like (defun astronaut-print-fn (obj s depth) (format s "[***>>> ASTRONAUT! Name: ") (write (astro-name obj) :stream s :level (- *print-level* depth)) (format s " <<<***]")) However, this is not quite the right thing if the originally specified :level argument had not defaulted to the value of *print-level*. One suggestion is to redefine the third argument to a structure print function to be "depth remaining", to be compared against zero. Then one would write (defun astronaut-print-fn (obj s depth) (format s "[***>>> ASTRONAUT! Name: ") (write (astro-name obj) :stream s :level (- depth 1)) (format s " <<<***]")) In retrospect, I think it was not defined this way because in MacLISP I had frequently found it very convenient, when faced with a large (possible infinite) printout, to do a break, set PRINLEVEL to some finite value, and then resume, whereupon the printout would quickly cut itself off, allowing computation to resume. The second treatment shown above would not respond to dynamic changes in *PRINT-LEVEL*. Is this important? --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 12:12:02 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85 07:41:17 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1935; Thu 21-Nov-85 10:42:42-EST Date: Thu, 21 Nov 85 10:42 EST From: Guy Steele Subject: Fill-pointers and sequences To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <851121104241.1.GLS@FAUSTINUS.THINK.COM> There are two other passages you might consider. First, page 246, last paragraph, states that the :start and :end arguments should be integer indices "into the sequence"; is an index larger than the fill pointer "into the sequence" or merely "into the vector"? Second, page 291 notes that "aref is unusual among the functions that operate on arrays in that it completely ignores fill pointers". If we really believed the book to be careful and accurate, we might infer that other functions not specifically documented to be in this unusual category may not access beyond the fill pointer; but in the actual event this inference is shaky at best. I think I would be inclined to write the code in this manner: (setq a (make-array 10 :fill-pointer 3)) (let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a)))) (fill a nil :start (fill-pointer a) :end (array-dimension a 0)) (setf (fill-pointer a) old-fill-pointer)) or, for the truly worried, (let ((old-fill-pointer (array-total-size a))) (unwind-protect (progn (setf (fill-pointer a) (array-total-size a)) (fill a nil :start (fill-pointer a) :end (array-dimension a 0))) (setf (fill-pointer a) old-fill-pointer))) I do not feel strongly about which way this issue is resolved, but I agree that it should be tied down. I mildly favor a strict interpretation. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 10:55:19 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 21 Nov 85 07:41:17 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1935; Thu 21-Nov-85 10:42:42-EST Date: Thu, 21 Nov 85 10:42 EST From: Guy Steele Subject: Fill-pointers and sequences To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <851121104241.1.GLS@FAUSTINUS.THINK.COM> There are two other passages you might consider. First, page 246, last paragraph, states that the :start and :end arguments should be integer indices "into the sequence"; is an index larger than the fill pointer "into the sequence" or merely "into the vector"? Second, page 291 notes that "aref is unusual among the functions that operate on arrays in that it completely ignores fill pointers". If we really believed the book to be careful and accurate, we might infer that other functions not specifically documented to be in this unusual category may not access beyond the fill pointer; but in the actual event this inference is shaky at best. I think I would be inclined to write the code in this manner: (setq a (make-array 10 :fill-pointer 3)) (let ((old-fill-pointer (shiftf (fill-pointer a) (array-total-size a)))) (fill a nil :start (fill-pointer a) :end (array-dimension a 0)) (setf (fill-pointer a) old-fill-pointer)) or, for the truly worried, (let ((old-fill-pointer (array-total-size a))) (unwind-protect (progn (setf (fill-pointer a) (array-total-size a)) (fill a nil :start (fill-pointer a) :end (array-dimension a 0))) (setf (fill-pointer a) old-fill-pointer))) I do not feel strongly about which way this issue is resolved, but I agree that it should be tied down. I mildly favor a strict interpretation. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Nov 85 10:16:07 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Nov 85 07:02:50 PST Received: ID ; Thu 21 Nov 85 10:02:39-EST Date: Thu, 21 Nov 1985 10:02 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: :Structure-Print and *print-level* In-reply-to: Msg of 19 Nov 1985 03:56-EST from Rob MacLachlan The current depth in printing is an argument to defstruct structure printing functions. If the print function calls print recursively, should print start over again at zero, or do something else? If the depth in printing is preserved across the call to the structure-print function, should it be the same in the recursive call, or one greater? Rob I was hoping that someone who had thought a lot about printing issues would jump up and take a crack at this, but since nobody has, I'll give it a try. I haven't dealt with printer issues much, so if somebody sees a deep bogosity in my analsysis, please step forward. When built-in data structures are being printed, each level of recursion into sub-structure bumps some hidden counter by 1, and when this value exceeds *print-level*, the printing becomes terse. This facility is not accessible to the user in any way that I can see -- either there is some special internal call to print that takes a current-depth argument or print looks at some undocumented special to get this sort of behavior. The user-accessible Print function, as it is currently defined, would seem always to set the print-depth back to zero when called explicitly. At least, in my quick scan of the manual I didn't see any way of doing this. The obvious intent in structure printing is that we want users to be able to write print functions that mimic the behavior of built-in print methods -- in this way, we hope to make the user-defined structures act like built-in data types. So the right thing to do would be to let these print functions access the current depth, and let them call the print functions, explicitly passing on the depth argument, usually incremented by one. Well, I think we blew it, since user-code has no way of calling Print and friends with an explicit depth argument, incremented or not. It would be possible to add some magic kludge whereby Print and friends realize that they are being called recursively within a structure-print routine and somehow figure out what the current depth ought to be. That stikes me as being very confusing and dangerous. I would suggest that Print and friends continue to reset the depth to zero when called explicitly, but that sometime soon we should provide a way of slipping some non-zero current depth to these functions explicitly. This should probably be done with an additional optional or keyword arg to the existing print functions (or maybe just to Write). -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 20:41:51 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Nov 85 17:29:27 PST Received: ID ; Wed 20 Nov 85 20:29:15-EST Date: Wed, 20 Nov 1985 20:29 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Subject: Fill-pointers and sequences In-reply-to: Msg of 20 Nov 1985 17:14-EST from David A. Moon It seems to me that this is a question of what abstraction we want to associate with the concept of a "sequence": when a vector is treated as a sequence, is the sequence only that part of the vector up to the fill pointer, or the whole thing? I think that we have pretty consistently adhered to the former view. The :start and :end defaults suggest this, as do the definitions for functions like Length. Aref is allowed to reference past the fill pointer, but this is noted in the manual as an exceptional case. So if we want to be consistent and minimize confusion, I would argue that sequence functions should signal an error (or at least that it should "be an error") if we try to make such functions access past the fill pointer. This supports the abstraction that moving the fill pointer changes the legnth of the sequence. I think that's what we had in mind when we put this stuff in, though of course we might not all have had the same things in mind. As an additional argument, on page 295 of the manual it says the following: "Nearly all functions that operate on the contents of a vector operate only on the active elements. An important exception is Aref ..." A good lawyer could wiggle out of this, but it seems that this is trying to tell us that vanilla sequence functions should not be allowed to do things to elements past the fill pointer. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 17:47:30 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:32:27 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222529; Wed 20-Nov-85 17:28:39-EST Date: Wed, 20 Nov 85 17:28 EST From: David A. Moon Subject: CATCH-ALL To: Rem%IMSSS@SU-SCORE.ARPA cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS Message-ID: <851120172830.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 19 Nov 1985 1641-PST From: Rem@IMSSS MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too. CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form). But the ZetaLisp manual says if you think you need this you probably want UNWIND-PROTECT instead. Just to set the record straight, Zetalisp does not contain CATCH-ALL.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 17:44:59 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:29:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222527; Wed 20-Nov-85 17:27:43-EST Date: Wed, 20 Nov 85 17:27 EST From: David A. Moon Subject: CATCH-ALL To: Rem@IMSSS cc: KESSLER%UTAH-20.ARPA@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS Message-ID: <851120172724.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 19 Nov 1985 1641-PST From: Rem@IMSSS MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too. CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form). But the ZetaLisp manual says if you think you need this you probably want UNWIND-PROTECT instead. Just to set the record straight, Zetalisp does not contain CATCH-ALL.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 17:43:33 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:28:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222525; Wed 20-Nov-85 17:26:48-EST Date: Wed, 20 Nov 85 17:26 EST From: David A. Moon Subject: Universal Catch To: Robert R. Kessler cc: common-lisp@SU-AI.ARPA In-Reply-To: <12160573501.22.KESSLER@UTAH-20.ARPA> Message-ID: <851120172629.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue 19 Nov 85 14:45:20-MST From: Robert R. Kessler One of the "features" of PSL is that if the tag of a catch is NIL, then that catch will catch any throw. This feature is especially nice when writing top loops and similar functions that you want to permit arbitrary interaction with throws. Please don't confuse THROW with ERROR. They are different functions for different purposes. I realize it's difficult, because Common Lisp hasn't yet acquired an error-handling system, only a (primitive) error-signalling system. That happened because of deadline pressure in getting out the original language specification. Good proposals have been made, they only need to be finished. I hope this deficiency of Common Lisp can be rectified in finite time; all it takes is someone to write a complete proposal and an institutional context for creating a revised language specification. Does CL provide a similar functionality (I haven't seen anything similar in the manual)? Is it an extension that might be included in CL-86 (or whatever we call it)? Comments? Early versions of Common Lisp contained primitives called CATCH-ALL and UNWIND-ALL. After discussion, they were removed. They definitely should not be put back in.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 17:31:38 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 14:15:57 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 222518; Wed 20-Nov-85 17:14:20-EST Date: Wed, 20 Nov 85 17:14 EST From: David A. Moon Subject: Fill-pointers and sequences To: Common-Lisp@SU-AI.ARPA Message-ID: <851120171407.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Consider this code: (setq a (make-array 10 :fill-pointer 3)) (fill a nil :start (fill-pointer a) :end (array-dimension a 0)) Is this correct Common Lisp? In our implementation this signals an error that you are accessing outside the bounds of the sequence, but I believe that is not correct. It is accessing outside the bounds of the sequence, defined by its fill-pointer, but it is not accessing outside the bounds of the array. An example application would be filling the part of a array past its fill-pointer with its initial-element, so the garbage collector doesn't have to preserve objects referenced by leftover array contents there. I checked the Common Lisp manual carefully, and it never says what the legal values for the :start and :end arguments to a sequence function are, except that :start must not be > than :end. :end defaults to the fill-pointer, but it is not clear that it is an error for :end to be specified larger than the fill-pointer. Perhaps the answer depends on exactly how we are to interpret the use of the word "subsequence" in the first sentence of the last paragraph on page 246. Does the answer depend on whether the sequence function in question is one that writes (like FILL or REPLACE) or one that reads (like POSITION or REMOVE)? Does anyone have an opinion to offer?  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 15:03:29 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 11:48:04 PST Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 358764; Wed 20-Nov-85 12:42:13-EST Date: Wed, 20 Nov 85 12:45 EST From: Bernard S. Greenberg Subject: CATCH-ALL To: Rem@IMSSS, KESSLER%UTAH-20.ARPA@SU-SCORE.ARPA cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 19 Nov 85 19:41-EST from Rem@IMSSS Message-ID: <851120124522.4.BSG@CONCORD.SCRC.Symbolics.COM> Date: 19 Nov 1985 1641-PST From: Rem@IMSSS MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too. CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form). But the ZetaLisp manual says if you think you need this you probably want UNWIND-PROTECT instead. Perhaps what we really need is an extra feature in UNWIND-PROTECT, whereby the cleaup forms can find out why they are being called. Some global variable can be SETQ'd by the unwinding mechanism, to NIL in the case of falling out of the main form nomally, to ERROR in the case of an error signal that is being passed up to an errset, or to the tag if a THROW is happening. This would give the cleanup form the opportunity to intercept certain tags in the same way CATCH-ALL did in MacLISP, but maybe be a bit cleaner? Or maybe we really need CATCH-ALL because it woul be cleaner than the enhanced UNWIND-PROTECT. Esthetic opinion anybody? ------- I think this is all pretty disgusting, and a blatant controversion of modularity. I'd like to hear the proposed use of CATCH-ALL, or whatever. Please don't confuse it with a need to catch all -errors-, which is a function of an error system, not catch/throw semantics.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 14:50:05 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 20 Nov 85 09:11:27 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1727; Wed 20-Nov-85 10:18:21-EST Date: Wed, 20 Nov 85 10:18 EST From: Guy Steele Subject: Extra paren in example on p.430 To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 19 Nov 85 16:00-EST from S Sridhar Message-ID: <851120101831.3.GLS@FAUSTINUS.THINK.COM> Date: Tuesday, 19 Nov 85 13:00:45 PST From: S Sridhar The fourth line in the definition of the function command-dispatch, the book shows (funcall fn)) it should be (funcall fn) --sridhar Right you are. Thank you. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 12:25:48 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 20 Nov 85 09:11:27 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1727; Wed 20-Nov-85 10:18:21-EST Date: Wed, 20 Nov 85 10:18 EST From: Guy Steele Subject: Extra paren in example on p.430 To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 19 Nov 85 16:00-EST from S Sridhar Message-ID: <851120101831.3.GLS@FAUSTINUS.THINK.COM> Date: Tuesday, 19 Nov 85 13:00:45 PST From: S Sridhar The fourth line in the definition of the function command-dispatch, the book shows (funcall fn)) it should be (funcall fn) --sridhar Right you are. Thank you. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Nov 85 04:00:26 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Nov 85 00:47:16 PST Received: from tektronix by csnet-relay.csnet id ab08617; 20 Nov 85 3:38 EST From: S Sridhar To: common-lisp@su-ai.ARPA Fcc: cl-mail Received: from tekchips by tektronix with smtp ; 19 Nov 85 13:14:59 PST Date: Tuesday, 19 Nov 85 13:00:45 PST Subject: Extra paren in example on p.430 The fourth line in the definition of the function command-dispatch, the book shows (funcall fn)) it should be (funcall fn) --sridhar  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 22:55:32 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 19:40:06 PST Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 19 NOV 85 21:52:51 EST Date: Tue 19 Nov 85 21:48:59-EST From: "Rodney A. Brooks" Subject: Re: Universal Catch To: kessler%utah-orion@UTAH-CS.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <8511200136.AA07391@utah-orion.ARPA> Message-ID: <12160628778.50.BROOKS@MIT-OZ> From: kessler%utah-orion@utah-cs.arpa (Robert Kessler) Message-Id: <8511200136.AA07391@utah-orion.ARPA> To: RWK@scrc-yukon.arpa Subject: Re: Universal Catch Cc: common-lisp@su-ai.arpa Yes, a catch barrier is what I am thinking about. My top loop analogy was just that, you want to be able to keep any errors or extraneous throws from leaving your top loop. One does need to be able to get the value of the tag though. I suppose that one could use a really disgusting hack with unwind-protect where instead of exiting in the cleanup forms, the code could recursively call the top loop. Geez that would be a real hack ;-) Bob. You don't need a recursive call. Below will keep doing forever. (loop (block toplevel (unwind-protect (return-from toplevel nil)))) Of course it doesn't give you access to the tag that was thrown to. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 22:38:02 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 19:25:15 PST Date: Tue, 19 Nov 85 22:27:38 EST From: "Glenn S. Burke" Subject: catching To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].724785.851119.GSB> NIL contains two undocumented special operators CATCHALL and CATCH-BARRIER. CATCHALL takes an argument list (function &body body). It evaluates and saves function, then evaluates the body as a progn. If a THROW is performed through this construct, the function gets invoked on two arguments: the tag being thrown to, and the value being thrown. Obviously this is incorrect wrt throwing multiple values; the obvious correction is to make the function get called on all of the values being thrown. The idea is, however, that one can inspect the tag and repeat the throw as if nothing had happened. Normal return, and abnormal returns that do not use THROW (we have a force-return-from-function-call-frame operation in NIL for use by the debugger) do not invoke the catchall function, even though they would invoke the cleanup forms of an unwind-protect. And, there are NO special catch tags; they are objects compared with EQ. CATCH-BARRIER is just like CATCH, except that it effectively makes all established CATCH tags outside of its dynamic scope invisible. I.e., (catch 'foo (catch-barrier 'bar (throw 'foo t))) will complain that FOO is an unseen catch tag. ^_  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 21:06:58 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 17:36:49 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA17394; Tue, 19 Nov 85 18:36:48 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA07391; Tue, 19 Nov 85 18:36:45 MST Date: Tue, 19 Nov 85 18:36:45 MST From: kessler%utah-orion@utah-cs.arpa (Robert Kessler) Message-Id: <8511200136.AA07391@utah-orion.ARPA> To: RWK@scrc-yukon.arpa Subject: Re: Universal Catch Cc: common-lisp@su-ai.arpa Yes, a catch barrier is what I am thinking about. My top loop analogy was just that, you want to be able to keep any errors or extraneous throws from leaving your top loop. One does need to be able to get the value of the tag though. I suppose that one could use a really disgusting hack with unwind-protect where instead of exiting in the cleanup forms, the code could recursively call the top loop. Geez that would be a real hack ;-) Bob.  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 20:10:50 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 16:57:15 PST Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 172000; Tue 19-Nov-85 19:56:36-EST Date: Tue, 19 Nov 85 19:53 EST From: Robert W. Kerns Subject: Universal Catch To: Robert R. Kessler cc: common-lisp@SU-AI.ARPA In-Reply-To: <12160573501.22.KESSLER@UTAH-20.ARPA> Message-ID: <851119195331.3.RWK@CROW.SCRC.Symbolics.COM> Date: Tue 19 Nov 85 14:45:20-MST From: Robert R. Kessler One of the "features" of PSL is that if the tag of a catch is NIL, then that catch will catch any throw. This feature is especially nice when writing top loops and similar functions that you want to permit arbitrary interaction with throws. Does CL provide a similar functionality (I haven't seen anything similar in the manual)? Is it an extension that might be included in CL-86 (or whatever we call it)? Comments? I don't understand how this helps write "top loops". It sure makes it hard to figure out why your program suddenly quit to top level because somewhere you misspelled HEIRARCHY in a THROW. It's much more useful if it is an error. I can think of other arbitrary interactions you could permit with THROW; why is this one any better? ;-) I think what you are really looking for here is a "catch-barrier", which says "never throw above here", so you don't accidentally throw out of your breakpoint or debugger? I think that's better, but it makes it harder to deliberatly continue by throwing out to some tag. If I remember right, I think NIL has such a feature.  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 19:58:55 EST Received: from IMSSS by SU-AI with PUP; 19-Nov-85 16:45 PST Date: 19 Nov 1985 1641-PST From: Rem@IMSSS Subject: CATCH-ALL To: KESSLER%UTAH-20.ARPA@SCORE cc: COMMON-LISP@SU-AI MacLISP and ZetaLisp (Symbolics LISP Machine) had/have that feature too. CATCH-ALL was/is a macro that generates the appropriate (:CATCH NIL form). But the ZetaLisp manual says if you think you need this you probably want UNWIND-PROTECT instead. Perhaps what we really need is an extra feature in UNWIND-PROTECT, whereby the cleaup forms can find out why they are being called. Some global variable can be SETQ'd by the unwinding mechanism, to NIL in the case of falling out of the main form nomally, to ERROR in the case of an error signal that is being passed up to an errset, or to the tag if a THROW is happening. This would give the cleanup form the opportunity to intercept certain tags in the same way CATCH-ALL did in MacLISP, but maybe be a bit cleaner? Or maybe we really need CATCH-ALL because it woul be cleaner than the enhanced UNWIND-PROTECT. Esthetic opinion anybody? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 16:59:26 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 19 Nov 85 13:46:40 PST Date: Tue 19 Nov 85 14:45:20-MST From: Robert R. Kessler Subject: Universal Catch To: common-lisp@SU-AI.ARPA Message-ID: <12160573501.22.KESSLER@UTAH-20.ARPA> One of the "features" of PSL is that if the tag of a catch is NIL, then that catch will catch any throw. This feature is especially nice when writing top loops and similar functions that you want to permit arbitrary interaction with throws. Does CL provide a similar functionality (I haven't seen anything similar in the manual)? Is it an extension that might be included in CL-86 (or whatever we call it)? Comments? Bob. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Nov 85 04:08:18 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Nov 85 00:56:36 PST Received: ID ; Tue 19 Nov 85 03:56:29-EST Date: Tue, 19 Nov 1985 03:56 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: :Structure-Print and *print-level* The current depth in printing is an argument to defstruct structure printing functions. If the print function calls print recursively, should print start over again at zero, or do something else? If the depth in printing is preserved across the call to the structure-print function, should it be the same in the recursive call, or one greater? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Nov 85 16:47:04 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 18 Nov 85 13:31:02 PST Received: from THINK-HILARION.ARPA by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 1220; Mon 18-Nov-85 16:35:19-EST Date: Mon, 18 Nov 85 16:35 EST From: Guy Steele Subject: TYPEP and arrays of (SATISFIES F) To: common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA Message-ID: <851118163500.9.GLS@THINK-HILARION.ARPA> Bob Rorschach has raised the following question: what is the result of (TYPEP (MAKE-ARRAY 10) '(ARRAY (SATISFIES F) (10))) supposed to be? Consider these special cases: (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE INTEGER) '(ARRAY (SATISFIES FIXNUMP) (10))) (TYPEP (MAKE-ARRAY 10 :ELEMENT-TYPE FIXNUM) '(ARRAY (SATISFIES FIXNUMP) (10))) We can easily dismiss the first case, because clearly an array specialized to hold integers is not necessarily the same as one specialized to hold fixnums. The second is more difficult. It happens to be the case that FIXNUM and (SATISFIES FIXNUMP) are equivalent type specifiers, but in many implementations SUBTYPEP cannot discern this fact (and indeed is not required to). When TYPEP sees a plain old SATISFIES specifier, it can just call the function, but not so when it is the element type of an ARRAY specifier. One way out (proposed language change) is to define TYPEP to be like SUBTYPEP, in that it returns two values; if the first value is NIL, the second value says whether that's a "no" or a "maybe". So for the first special case above TYPE would return either NIL T or NIL NIL, depending on the cleverness of the implementation, and for the second special case would return either NIL NIL or T T. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Nov 85 12:57:55 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Nov 85 09:43:45 PST Received: from Cabernet.ms by ArpaGateway.ms ; 11 NOV 85 09:34:42 PST Date: 11 Nov 85 09:34 PST Sender: Kahn.pa@Xerox.ARPA Subject: RE: Steele's programming style To: COMMON-LISP@SU-AI.ARPA From: bobrow.pa@Xerox.ARPA, kahn.pa@Xerox.ARPA LineFold: No Message-ID: <851111-093442-1201@Xerox> I suppose that this is one of the "subtly witty" things that Winston had in mind (see the quote on the back cover). The entire point is that it isn't clear. Then again it is: it says that the astronaut has a sex, but doesn't say which. (HAL, in the movie 2001, is an examples of an astronaut that has no sex.) I'm sorry you don't like it. It certainly is not exemplary of god programming style. Maybe we should change it in the next edition. --Guy " not exemplary of god programming style " We suppose god would never simply affirm sex, but would be more explicit.  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Nov 85 21:38:44 EST Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 10 Nov 85 18:27:55 PST Date: Sun 10 Nov 85 18:28:42-PST From: Evan Kirshenbaum Subject: Pointers to vax/unix version To: common-lisp@SU-AI.ARPA I've been trying (unsuccessfully) for a while to track down a version of Common Lisp (or even a reasonable subset) that runs under 4.2BSD Unix. This is a very elusive animal, as everyone has heard rumours of one, but nobody has every quite seen it. Any pointers anyone could give would be most helpful and much appreciated. Evan Kirshenbaum ARPA: evan@SU-CSLI UUCP: {ucbvax | decvax}!decwrl!glacier!evan P.S. This is urgent. I'm doing a prototype using Hedrick's TOPS-20 version, and if you don't come through, they're going to make me translate it into franz!!! -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Nov 85 19:20:51 EST Date: 09 Nov 85 1606 PST From: Dick Gabriel Subject: Meeting: The Details To: common-lisp@SU-AI.ARPA After much hassle and complaint, terror and theats; after a month of ill-feelings and fights, I've scheduled the Common Lisp meeting for specific days, at a specific place, and I am sending out the message essentially 1 month ahead of time. I know some of you will not like the details I have settled on. The meeting will be Monday, Tuesday, Wednesday, Decembers 9, 10, and 11; at: Boston Marriott Hotel Copley Place 110 Huntington Avenue Boston, Massachusetts 02117 (617)236-5800 The room will be ours from 8:30am until 6:00pm each of those days. There is a block of rooms at that hotel set aside for us. I understand that it is a fancy hotel, and the rooms are not cheap, even with the discount I got for the meeting. The rooms are $100 single and $115 double, which is $60 off the regular rate. When you make your reservations, specifically mention the Common Lisp meeting. The block of rooms will be held for us until November 25, and they can be booked for the evenings of Decemeber 8, 9, 10. The usual caveats apply to this hotel: a reservation without a guarantee will only hold the room until 6:00pm of the evening of your arrival. A guarantee is usually an American Express card number. The meeting room will hold 250 easily, but I understand that up to 350 could fit. The sessions will be sequential, not parallel. There is a non-zero chance that DARPA will not be able to pay for the meeting room; the hotel doesn't seem to want to give it to us free if we fill up 75 rooms, which is unusual - they claim they need closer to 200 filled by us to give us such a large meeting room. In the event DARPA will not help us out, I will be approaching the vendors for contributions towards the meeting room. For now, Lucid is fronting the money. We can get coffee and pastry delivered to the meeting room in the mornings, but it will also cost us. To do that would cost about $7.75 per person. Is there an interest in this happening? If so, I will go ahead with the arrangements, and perhaps you'll be dunned later. The major topics as I see them are: 1. Charter 2. Adoption of changes discussed on this list 3. Plans for a second edition 4. Public Domain/Online manual 5. Object-oriented programming 6. Windows 7. Error Handling 8. Validation I expect specific proposals to be discussed for topics 1, 5, 6, 7, and 8. Vendors and implementation groups are allowed to send 2 voting individuals (3 official repesentatives altogether), user groups are allowed to send 1 voting individual (2 official representatives altogether), and individuals of standing in the community are allowed to attend and possibly vote. Groups that are not implementing a Common Lisp, but who are proposing a standard in some area which they intend to implement, are allowed to send 2 voting members for that session only. Any one of Scott Fahlman, Guy Steele, or myself is allowed to grant an individual standing in the community for the purposes of attending the meeting as a voting individual. I will allow into the room any observers up to a number which, added to the voting and accessory repesentatives, leaves the room comfortable. Thus, a vendor can send more than 3 people, but only 3 will be guaranteed spots in the room. In general, only the official representatives and the qualified voting individuals will be allowed to speak. I hope we have a pleasant and productive meeting. See you all in 1 month. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Nov 85 14:25:21 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Nov 85 11:13:45 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 351262; Sat 9-Nov-85 14:15:43-EST Date: Sat, 9 Nov 85 14:20 EST From: Daniel L. Weinreb Subject: Suggested addition to the index of CLtL To: common-lisp@SU-AI.ARPA Message-ID: <851109142016.5.DLW@CHICOPEE.SCRC.Symbolics.COM> We've had several users who tried to figure out how to copy an array in Common Lisp, and could not find a function in CLtL to do it. The function is COPY-SEQ, but if you set off trying to find a function to copy an array, you can miss it pretty easily. Perhaps an index entry for "copying arrays" could be added to the index in the next edition, to direct the programming to COPY-SEQ. ("Copying list", too, couldn't hurt.) Thanks.  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Nov 85 01:56:13 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 22:43:57 PST Date: Sat, 9 Nov 1985 01:47 EST Message-ID: From: PGS%MIT-OZ@MIT-MC.ARPA To: Guy Steele Cc: common-lisp@SU-AI.ARPA, sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA Subject: astronaut example on p.313 In-reply-to: Msg of 8 Nov 1985 14:17-EST from Guy Steele Date: Friday, 8 November 1985 14:17-EST From: Guy Steele Date: Thursday, 7 Nov 85 11:56:33 PST From: S Sridhar On p.313, we've (setq x (make-astronaut :name 'buzz :age 45 :sex t :helmet-size 17.5)) I don't like this :sex t. It would be perhaps more appropriate to have :sex 'm or :sex 'f or ... I suppose that this is one of the "subtly witty" things that Winston had in mind (see the quote on the back cover). The entire point is that it isn't clear. Then again it is: it says that the astronaut has a sex, but doesn't say which. (HAL, in the movie 2001, is an examples of an astronaut that has no sex.) I'm sorry you don't like it. It certainly is not exemplary of god programming style. Maybe we should change it in the next edition. Gee, I always read it as an allusion to the joke in which a job applicant, filling out an employment application form, chews over the SEX: ____ question for a while, and then writes in "Occasionally."  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Nov 85 20:23:07 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 8 Nov 85 17:05:38 PST Received: from hplabs by csnet-relay.csnet id ah07165; 8 Nov 85 8:25 EST Received: by HP-VENUS id AA06577; Thu, 7 Nov 85 16:34:35 pst Message-Id: <8511080034.AA06577@HP-VENUS> Date: Thursday, November 7, 1985 08:41:25 From: snyder%hplabs.csnet@CSNET-RELAY.ARPA Subject: compiler-let (clarification needed) To: common-lisp@su-ai.arpa X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Source-Info: From (or Sender) name not authenticated. The definition of COMPILER-LET (page 112) states that when executed by the "Lisp interpreter", COMPILER-LET behaves exactly like LET (with all the variable bindings implicitly declared SPECIAL). However, on page 143 it states that a Common Lisp implementation might, for example, expand macros in a DEFUN at the time the DEFUN is executed. Since the primary purpose of COMPILER-LET is to provide for the communication of information at macro expansion time, I believe that if an implementation (even when "interpreting") expands macros before run-time, then it should process a COMPILER-LET at that same time, in which case COMPILER-LET is NOT the same as LET. The definition of COMPILER-LET should be changed to make this clear. Alan Snyder ------- -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Nov 85 20:08:19 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 8 Nov 85 16:49:31 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 8 Nov 85 14:37:01 est Date: Fri, 8 Nov 85 14:38 EST From: Guy Steele Subject: Common Lisp manual online? To: Fahlman@C.CS.CMU.EDU, Masinter.pa@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <851108143815.3.GLS@THINK-DESIDERIUS.ARPA> I can report that Dr. Toru Ishida of Nippon Telephone and Telegraph requested of Digital Press permission to acquire a machine-readable copy of the manual for research purposes (research into developing an on-line query system), and this permission was granted relatively quickly (a month or so). So that's one precedent. It's not the same as a precedent for making the manual available on-line for commercial use. Maybe someone would like to help establish one promptly? The way lawyers are, I can push all I want for a policy from a theoretical point of view, but you won't get action until there is an actual instance for them to chew on. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Nov 85 20:07:38 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 8 Nov 85 16:50:17 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 8 Nov 85 14:16:28 est Date: Fri, 8 Nov 85 14:17 EST From: Guy Steele Subject: astronaut example on p.313 To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 7 Nov 85 14:56-EST from S Sridhar Message-Id: <851108141743.2.GLS@THINK-DESIDERIUS.ARPA> Date: Thursday, 7 Nov 85 11:56:33 PST From: S Sridhar On p.313, we've (setq x (make-astronaut :name 'buzz :age 45 :sex t :helmet-size 17.5)) I don't like this :sex t. It would be perhaps more appropriate to have :sex 'm or :sex 'f or ... --sridhar I suppose that this is one of the "subtly witty" things that Winston had in mind (see the quote on the back cover). The entire point is that it isn't clear. Then again it is: it says that the astronaut has a sex, but doesn't say which. (HAL, in the movie 2001, is an examples of an astronaut that has no sex.) I'm sorry you don't like it. It certainly is not exemplary of god programming style. Maybe we should change it in the next edition. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Nov 85 20:05:31 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Nov 85 16:46:07 PST Received: ID ; Fri 8 Nov 85 19:18:24-EST Date: Thu, 7 Nov 1985 22:06 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: REM@MIT-MC.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: Language spec should be public domain In-reply-to: Msg of 1985 Nov 07 15:27:32 PST (=GMT-8hr) from Robert Elton Maas Before CL can ever become very widely used (like ASCII for example), it must become an ANSI/CCITT/ISO standard... I disagree totally with this view. Lots of things are widely used that are not blessed by these particular bureaucracies. But I do agree with the view that the proprietary nature of the document is hurting us, and is hurting some more than others. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Nov 85 20:03:22 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Nov 85 16:46:36 PST Received: ID ; Fri 8 Nov 85 19:18:25-EST Date: Thu, 7 Nov 1985 22:10 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: S Sridhar Cc: common-lisp@SU-AI.ARPA Subject: astronaut example on p.313 In-reply-to: Msg of 7 Nov 1985 14:56-EST from S Sridhar On p.313, we've (setq x (make-astronaut :name 'buzz :age 45 :sex t :helmet-size 17.5)) I don't like this :sex t. It would be perhaps more appropriate to have :sex 'm or :sex 'f or ... --sridhar A deliberate joke on Guy's part, I believe. A more amusing value might be 7.3, however... -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Nov 85 19:10:53 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 7 Nov 85 15:44:29 PST Received: from tektronix by csnet-relay.csnet id ad02319; 7 Nov 85 18:38 EST From: S Sridhar To: common-lisp@su-ai.ARPA Fcc: cl-mail Received: from tekchips by tektronix with smtp ; 7 Nov 85 12:04:51 PST Date: Thursday, 7 Nov 85 11:56:33 PST Subject: astronaut example on p.313 On p.313, we've (setq x (make-astronaut :name 'buzz :age 45 :sex t :helmet-size 17.5)) I don't like this :sex t. It would be perhaps more appropriate to have :sex 'm or :sex 'f or ... --sridhar  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Nov 85 18:40:06 EST X-Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Nov-07 15:28:54 PST (=GMT-8hr) X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP Date: 1985 November 07 15:27:32 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132450245066.G0361 From: Robert Elton Maas To:COMMON-LISP@SU-AI.ARPA Subject:Language spec should be public domain Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA Before CL can ever become very widely used (like ASCII for example), it must become an ANSI/CCITT/ISO standard, which requires the text describing the standard not be protected by a private copyright. Are there any plans to produce a public-domain machine-readable version of the text of the language specification for Common-LISP any time soon?  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Nov 85 18:27:00 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Nov 85 15:14:20 PST Received: ID ; Thu 7 Nov 85 18:16:38-EST Date: Thu, 7 Nov 1985 18:16 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Masinter.pa@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA Subject: Common Lisp manual online? In-reply-to: Msg of 7 Nov 1985 17:23-EST from Masinter.pa at Xerox.ARPA I believe that making and distributing an online version of CLTL would, technically, run afoul of the Digital Press copyright. However, I recall Guy saying awhile back that Digital Press was willing to grant permission for others to make online versions -- that they were only interested in the book rights. I'm not sure whether Digital Press had in mind some sort of blanket permission or just case-by-case permission. The latter would undoubtedly involve a year-long delay while DEC's lawyers ponder each case individually. Maybe Guy can fill us in on where things stand as of today. I have gradually come around to the belief (earlier expressed by Fateman, Masinter, and others) that the Common Lisp community somehow needs to produce a new version of the manual that would describe the same language we all know and love (!), but that would be public domain or owned by the Common Lisp Association (if we ever get such a thing set up). We could then all agree that, in the case of any disagreement, this new version is definitive. We could print this version cheaply, distribute it at cost, and license its use to any manufacturer who agrees to use it in ways that will not distort the language definition. Digital Press has behaved as well as could be expected, except for their incredible slowness in granting requests to reprint the book in various forms, but things like this keep coming up and other manufacturers are understandably reluctant to use a manual that says "Digital" all over it. It was clearly (in retrospect) a bad decision to publish the definitve manual as a normal book from a normal publisher, especially one tied to a computer company. By now, Digital Press has received ample reward for the risks of publishing such a book, so I don't think there are any issues of fairness here, just legal issues. The problem, of course, is in finding someone with both the time and ability to write the new manual in not-for-profit mode, and in trying to describe the same Common Lisp with the same degree of precision while not infringing on the Digital Press copyright. That's a very tall order. I don't think Guy could do this, even if he wanted to, since Digital Press has the rights to any subsequent editions of the original work done by him (though he could probably be a co-author). -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Nov 85 17:34:44 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 7 Nov 85 14:21:07 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 NOV 85 14:23:30 PST Date: 7 Nov 85 14:23 PST From: Masinter.pa@Xerox.ARPA Subject: Common Lisp manual online? To: Common-Lisp@SU-AI.ARPA Message-ID: <851107-142330-1487@Xerox> I'd really like to get Common Lisp The Language online. It would help to be able to interactively look things up, build a better index, etc. Is this sort of thing likely to be tangled up in DEC's copyright? (E.g., only DEC can publish an online manual or some such nonsense?)  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Nov 85 13:51:27 EST Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 7 Nov 85 10:36:06 PST Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000224; 7 Nov 85 2:48 GMT From: Jeff Dalton Date: Thu, 7 Nov 85 02:45:44 GMT To: common-lisp , rpg Subject: Common Lisp Meeting Has the date (& place) been set? I remember a message saying it was about to be finalized, but I haven't seen anything since then. Cheers, Jeff  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Nov 85 12:59:06 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 6 Nov 85 09:47:35 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 6 Nov 85 12:49:40 est Date: Wed, 6 Nov 85 12:51 EST From: Guy Steele Subject: CL erratissimo To: Meehan@YALE.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <8511061530.AA07724@Yale-Bulldog.YALE.ARPA> Message-Id: <851106125102.4.GLS@DESIDERIUS.THINK.COM> Date: Wed, 6 Nov 85 10:33:11 EST From: Jim Meehan Section 7.9.2, Rules Governing the Passing of Multiple Values, is indexed under "multiple values," sub-indexed under "rules governing parsing of." ^ (Not exactly your random typo.) ------- Snows me. Good eye! --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Nov 85 12:16:30 EST Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 09:04:12 PST Received: by glacier with Sendmail; Wed, 6 Nov 85 09:05:50 pst Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7) id AA14102; Wed, 6 Nov 85 07:03:44 pst Received: by escargot.UUCP (4.12/4.7) id AA06129; Wed, 6 Nov 85 07:02:16 pst Date: Wed, 6 Nov 85 07:02:16 pst From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8511061502.AA06129@escargot.UUCP> To: Glacier!isrlist@tove.umd.edu Cc: SOLEY@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Nick Papadakis's message of Tue, 5 Nov 85 12:36:00 EST Subject: defvar, defparameter, :unbound This doesn't seem important enough to become a language feature; one of advantages of lisp is that you could have written a DOCVAR macro that does what you want for this one particular application, and then just done (docvar foo "Foo is unbound") instead of (defvar foo :unbound "Foo is unbound")  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Nov 85 11:03:47 EST Received: from YALE.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 07:37:52 PST Received: by Yale-Bulldog.YALE.ARPA; 6 Nov 85 10:30:50 EST (Wed) Message-Id: <8511061530.AA07724@Yale-Bulldog.YALE.ARPA> Date: Wed, 6 Nov 85 10:33:11 EST From: Jim Meehan Subject: CL erratissimo To: common-lisp@SU-AI Section 7.9.2, Rules Governing the Passing of Multiple Values, is indexed under "multiple values," sub-indexed under "rules governing parsing of." ^ (Not exactly your random typo.) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Nov 85 07:37:52 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 04:27:25 PST Date: Wed, 6 Nov 85 07:29:27 EST From: "George J. Carrette" Subject: functions that return nonstandard extra values To: DLW@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA In-reply-to: Msg of Mon 4 Nov 85 22:35 EST from Daniel L. Weinreb Message-ID: <[MIT-MC.ARPA].707467.851106.GJC> Date: Mon, 4 Nov 85 22:35 EST From: Daniel L. Weinreb To: GJC at MIT-MC.ARPA cc: common-lisp at SU-AI.ARPA, AS%hplabs.csnet at CSNET-RELAY.ARPA Re: functions that return nonstandard extra values Date: Mon, 4 Nov 85 22:00:48 EST From: "George J. Carrette" If a user was really interested in efficiency he wouldnt use the hairy system-provided hash table implementations anyway. This is completely the opposite of our point of view, which is that it is the job of the system to provide usable and efficient tools. Oh, I love your use of the royal WE/OUR here. Lets not make this into a OUR-COMPANY (RA RA!!!) vs others kind of thing. I'm talking about what lispmachine systems provide NOW. Remember how long it took the lispmachine crew to adopt semantically correct SETF, long after other implementations had done so. The track record is not good. In fact, the track record is one of unabated changes that continously break major applications packages in minor ways, diverting resources, and all in the name of progress. (RA RA). If your soapbox stand is that it is my(i.e. LMI's) view that the system does not have to provide usable and efficient tools then a retraction of your statement is in order. But the Common-Lisp system lacks many useful basic tools. Functions for manipulating circular queues, or recursive alists (like TRI's), or resolution nets. It lacks a DEFSTRUCT that can deal with the same kind of data that STRUCT in C deals with. (Disk Controller blocks, Filesystem records, network packets defined by programmers in the non-lisp world, etc). There are many things a user will have to build himself.  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Nov 85 07:09:18 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Nov 85 04:00:19 PST Date: Wed, 6 Nov 85 07:02:23 EST From: "George J. Carrette" Subject: (GETHASH X Y) ==> (CDR (GETHASH X Y)) To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA In-reply-to: Msg of Tue 5 Nov 85 10:34 EST from David C. Plummer Message-ID: <[MIT-MC.ARPA].707437.851106.GJC> It is ridiculous to assume that users program via QUERY-REPLACE in EMACS, or through the "looks productive" CONTROL-K CONTROL-Y method. More likely it is the case that: (DEFUN DATABASE-LOOKUP (...) (GETHASH ...) ... (PUTHASH ....)) For one thing the user might consider GETHASH to be a silly name.  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 20:11:37 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 16:55:29 PST Date: Tue 5 Nov 85 17:57:57-MST From: SANDRA Subject: Re: queries about *query-io* To: HENRIK@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].706637.851105.HENRIK> Message-ID: <12156938550.9.LOOSEMORE@UTAH-20.ARPA> I'm afraid this approach would not work very well in a multi-user environment. In VMS, for example, the user can submit a job to a batch queue and then log off the interactive terminal and go away for a week. It would not be looked upon very kindly by other users to have this batch job sitting indefinitely waiting for the user to log back on again so it can ask him/her a question, and all the while consuming cpu time and clogging up the batch queue. And the problem is not unique to VMS -- one can do similar things under Unix and probably other operating systems as well. -Sandra -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 18:42:59 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 15:15:27 PST Date: Tue, 5 Nov 85 18:17:28 EST From: "Lawrence A. DeLuca, Jr." Subject: queries about *query-io* To: LOOSEMORE@UTAH-20.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].706637.851105.HENRIK> I guess the closest analogy to "batch mode" the lisp machine offers is a deexposed window with a process running in it. In this case, when a process wants to type out or needs input the user is sent a message that the window requires attention, a la: Process SUPDUP1 Wants to type out. The process can continue to output, and the text will be displayed the next time the user exposes the window. When typein is required, the process will wait until the required input is supplied. It would probably be most reasonable to have the output of *query-io* go to *standard-output*. As to the question of (y-or-n-p ... ), most batch processes are only going to use some such construct to signal an unusual event, so it would probably be better to have the process wait for input (assuming there is some method to "attach" to the process provided) as opposed to merely signaling and error and returning, or worse, aborting. larry...  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 16:18:12 EST Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 5 Nov 85 11:54:25 PST Received: by tove.umd.edu (5.5/4.7) id AA01113; Tue, 5 Nov 85 12:36:00 EST Date: Tue, 5 Nov 85 12:36:00 EST Message-Id: <8511051736.AA01113@tove.umd.edu> From: Nick Papadakis To: SOLEY@MIT-MC.ARPA Cc: common-lisp@SU-AI.ARPA In-Reply-To: Richard Mark Soley's message of Sun, 3 Nov 85 10:21:19 EST Subject: defvar, defparameter, :unbound I disagree. (defvar foo :unbound), to me, reads "set the value of the symbol 'foo' to the symbol 'unbound' in the keyword package. I think (defvar foo) is more readable. -- Richard What if you want to use the optional documentation argument, as in (defvar foo :unbound "I am initially unbound.") ??? How can you document it and yet leave it unbound too? The problem initially arose when re-writing some code that made heavy use of (unless (boundp 'foo) ... as a means of insuring that variables were initialized. The variables were NOT initialized in the defvar itself since re-initialization was frequent and interactive. - nic  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 15:52:26 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 12:38:57 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 348169; Tue 5-Nov-85 15:41:25-EST Date: Tue, 5 Nov 85 15:44 EST From: David C. Plummer Subject: defvar, defparameter, :unbound To: Guy Steele , GSB@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <851105125319.3.GLS@DESIDERIUS.THINK.COM> Message-ID: <851105154455.3.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Tue, 5 Nov 85 12:53 EST From: Guy Steele Date: Mon, 4 Nov 85 23:18:59 EST From: "Glenn S. Burke" From: Daniel L. Weinreb Date: Sat, 2 Nov 85 23:55:45 EST From: Nick Papadakis On the lispmachines, defvar will take a second argument of :unbound, meaning that the variable will be initialized to an unbound state. I'm not sure which Lisp machine this message is supposed to apply to, but just for the record, the Symbolics system does not do this. This hack was added to NIL. My personal feeling is that the special case value is just asking to screw some poor user whose code just happens to naively use :UNBOUND to mean something... But i added the defvar hack anyway, because the ability to do both the defvar and specify the documentations string in a single form seemed worth it. Doing (defvar *foo*) (setf (documentation '*foo* 'variable) "Documentaiton string") looks pretty crufty. Keyworded defvar, anyone? One idea that was discussed previously was (defvar *foo* *foo* "Documentation string") which self-evidently means "declare *foo* and initialize to its existing value", but by special dispensation it arranges to work even when *foo* is already unbound, i.e., it leaves it alone. This is fine for DEFVAR, but is less appealing for DEFPARAMETER. Recall that DEFPARAMETER's initial value is not optional, with implied (perhaps stated) semantics that it must always have a value.  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 15:26:34 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 12:13:52 PST Date: Tue 5 Nov 85 13:16:24-MST From: SANDRA Subject: queries about *query-io* To: common-lisp@SU-AI.ARPA Message-ID: <12156887294.22.LOOSEMORE@UTAH-20.ARPA> What should *query-io* be bound to when running Lisp in "batch mode" where normal input comes from a script file and there is not necessarily a terminal or interactive process associated with the Lisp process? For the purposes of y-or-n-p, it might be reasonable to bind *query-io* to the script file, since these are questions expected by the user and the answers could be included in the script file. However, for unexpected questions asked via yes-or-no-p, this approach would almost certainly fail. Or, *query-io* could be left unbound or it could be bound to an empty stream. This leads to the second problem: what should y-or-n-p and yes-or-no-p do if *query-io* is unbound or has an end-of-file condition? Since there is no way to specify a default value to be returned, I think signalling an error is about the only reasonable thing to do. Comments? -Sandra Loosemore -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 12:59:55 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 5 Nov 85 09:49:47 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 5 Nov 85 12:51:56 est Date: Tue, 5 Nov 85 12:53 EST From: Guy Steele Subject: defvar, defparameter, :unbound To: GSB@MIT-MC.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <[MIT-MC.ARPA].705297.851104.GSB> Message-Id: <851105125319.3.GLS@DESIDERIUS.THINK.COM> Date: Mon, 4 Nov 85 23:18:59 EST From: "Glenn S. Burke" From: Daniel L. Weinreb Date: Sat, 2 Nov 85 23:55:45 EST From: Nick Papadakis On the lispmachines, defvar will take a second argument of :unbound, meaning that the variable will be initialized to an unbound state. I'm not sure which Lisp machine this message is supposed to apply to, but just for the record, the Symbolics system does not do this. This hack was added to NIL. My personal feeling is that the special case value is just asking to screw some poor user whose code just happens to naively use :UNBOUND to mean something... But i added the defvar hack anyway, because the ability to do both the defvar and specify the documentations string in a single form seemed worth it. Doing (defvar *foo*) (setf (documentation '*foo* 'variable) "Documentaiton string") looks pretty crufty. Keyworded defvar, anyone? One idea that was discussed previously was (defvar *foo* *foo* "Documentation string") which self-evidently means "declare *foo* and initialize to its existing value", but by special dispensation it arranges to work even when *foo* is already unbound, i.e., it leaves it alone. This is fine for DEFVAR, but is less appealing for DEFPARAMETER. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 12:50:09 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 5 Nov 85 09:41:06 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 5 Nov 85 12:41:19 est Date: Tue, 5 Nov 85 12:42 EST From: Guy Steele Subject: functions that return nonstandard extra values To: DLW@SCRC-QUABBIN.ARPA, GJC@MIT-MC.ARPA Cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <851104223554.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <851105124241.2.GLS@DESIDERIUS.THINK.COM> Date: Mon, 4 Nov 85 22:35 EST From: Daniel L. Weinreb Date: Mon, 4 Nov 85 22:00:48 EST From: "George J. Carrette" If a user was really interested in efficiency he wouldnt use the hairy system-provided hash table implementations anyway. This is completely the opposite of our point of view, which is that it is the job of the system to provide usable and efficient tools. My feeling exactly. If implementations are such that users find it desirable to ignore most of the built-in functions and roll their own, then we have failed: we might as well have used a smaller dialect, such as SCHEME or PSL. Common Lisp took the direction it did precisely because we thought that all the built-in functions would be useful to users. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Nov 85 10:43:03 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Nov 85 07:34:06 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347879; Tue 5-Nov-85 10:31:04-EST Date: Tue, 5 Nov 85 10:34 EST From: David C. Plummer Subject: functions that return nonstandard extra values To: George J. Carrette , DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA In-Reply-To: <[MIT-MC.ARPA].705135.851104.GJC> Message-ID: <851105103431.9.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 4 Nov 85 22:00:48 EST From: "George J. Carrette" On the bright side, the existence of a standard helps system maintainers to resist users continually asking for changes to the language that have but minor benefit, such as this gethash thing. With only a minor change in efficiency the user could store (CONS ) in the hash table, and get what he wanted, the EQ'ified key and the value. This is no longer a simple hash table, as GETHASH doesn't get the value. Instead, the user must do (CDR (GETHASH ...)), and MUST do it in all places. There are other problems with this solution. PUTHASH over an existing entry will change the key, forcing the user to do a GETHASH first. This is almost MODIFY-HASH, which is an efficiency item missing from CL. If a user was really interested in efficiency he wouldnt use the hairy system-provided hash table implementations anyway. I agree with DLW's reply to this statement.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 23:26:21 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 20:16:59 PST Date: Mon, 4 Nov 85 23:18:59 EST From: "Glenn S. Burke" Subject: defvar, defparameter, :unbound To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].705297.851104.GSB> From: Daniel L. Weinreb Date: Sat, 2 Nov 85 23:55:45 EST From: Nick Papadakis On the lispmachines, defvar will take a second argument of :unbound, meaning that the variable will be initialized to an unbound state. I'm not sure which Lisp machine this message is supposed to apply to, but just for the record, the Symbolics system does not do this. This hack was added to NIL. My personal feeling is that the special case value is just asking to screw some poor user whose code just happens to naively use :UNBOUND to mean something... But i added the defvar hack anyway, because the ability to do both the defvar and specify the documentations string in a single form seemed worth it. Doing (defvar *foo*) (setf (documentation '*foo* 'variable) "Documentaiton string") looks pretty crufty. Keyworded defvar, anyone?  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 23:16:21 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 19:34:06 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347683; Mon 4-Nov-85 22:33:07-EST Date: Mon, 4 Nov 85 22:35 EST From: Daniel L. Weinreb Subject: functions that return nonstandard extra values To: GJC@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA In-Reply-To: <[MIT-MC.ARPA].705135.851104.GJC> Message-ID: <851104223554.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 4 Nov 85 22:00:48 EST From: "George J. Carrette" If a user was really interested in efficiency he wouldnt use the hairy system-provided hash table implementations anyway. This is completely the opposite of our point of view, which is that it is the job of the system to provide usable and efficient tools.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 22:34:33 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 19:23:48 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347679; Mon 4-Nov-85 22:26:17-EST Date: Mon, 4 Nov 85 22:29 EST From: Daniel L. Weinreb Subject: Declaring Functions To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8511012045.AA07112@utah-orion.ARPA> Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Fri, 1 Nov 85 13:45:55 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) The notion of a function type is mentioned in two places: p. 47 of the CLM, where the (function ...) type specifier is defined, and p. 158-159, where (ftype ...) and (function ...) are defined as options to declare. Are they intended to be the same? Read page 159 more carefully. It explains that they have the same meaning, but are syntactically different. "function" has the disadvantage that you can only declare one thing per clause, unlike most other declarations, but the advantage that it looks mildly like "defun". If so, then the second definition should say that keywords and a (values ...) type specifier are allowed. If by keywords you mean &optional and friends, it isn't strictly necessary to repeat that, although it would sure clear things up if there were a cross reference in the book. However, there appears to be a typo on page 159. The form following the phrase "entirely equivalent to", which currently reads (ftype (function arglist result-type1 result-type2 ...) name) ought to read (ftype (function arglist (values result-type1 result-type2 ...)) name) in order to be consistent with page 47.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 22:09:42 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 18:58:47 PST Date: Mon, 4 Nov 85 22:00:48 EST From: "George J. Carrette" Subject: functions that return nonstandard extra values To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, AS%hplabs.csnet@CSNET-RELAY.ARPA In-reply-to: Msg of Mon 4 Nov 85 19:25 EST from David C. Plummer Message-ID: <[MIT-MC.ARPA].705135.851104.GJC> On the bright side, the existence of a standard helps system maintainers to resist users continually asking for changes to the language that have but minor benefit, such as this gethash thing. With only a minor change in efficiency the user could store (CONS ) in the hash table, and get what he wanted, the EQ'ified key and the value. If a user was really interested in efficiency he wouldnt use the hairy system-provided hash table implementations anyway.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 21:29:26 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 16:19:43 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347618; Mon 4-Nov-85 19:22:09-EST Date: Mon, 4 Nov 85 19:25 EST From: David C. Plummer Subject: functions that return nonstandard extra values To: Alan Snyder , common-lisp@SU-AI.ARPA In-Reply-To: <8511041744.AA02886@HP-VENUS> Message-ID: <851104192526.3.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon 4 Nov 85 09:43:53-PST From: Alan Snyder Why not use the traditional solution of giving these nonstandard functions different names? Then you don't have to worry about them becoming incompatible should the standard be extended to have more return values. Because code that does a GETHASH but wants an extra value will have a wart called GETHASH-MAGIC (or whatever, but not GETHASH), which could conceivably double the number of functions in the superset. If CL changes, and it does so slowly because it is a standard, extensions are expected to become compatible with the new standard and applications that used the old extensions must be modified. Note they would have to be modified anyway in order to take advantage of the change to CL.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 18:10:29 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 15:00:16 PST Received: from hplabs by csnet-relay.csnet id af03268; 4 Nov 85 17:56 EST Received: by HP-VENUS id AA10185; Mon, 4 Nov 85 14:24:06 pst Message-Id: <8511042224.AA10185@HP-VENUS> Date: Monday, November 4, 1985 14:21:50 From: perdue%hplabs.csnet@CSNET-RELAY.ARPA Subject: Re: free variable references in interpreter. To: common-lisp@su-ai.arpa In-Reply-To: Your message of 1-Nov-85 14:37:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Source-Info: From (or Sender) name not authenticated. Scott Fahlman's comments on permissibility of warning and error messages when not called for by the Common LISP definition look good to me. Portably written code should port without hassles, and drawing the line between warnings and errors looks right. Warning messages for legal code are OK sometimes as default behavior, but signalling errors is not. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 17:57:42 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 14:47:25 PST Received: from hplabs by csnet-relay.csnet id ab03268; 4 Nov 85 17:50 EST Received: by HP-VENUS id AA02886; Mon, 4 Nov 85 09:44:50 pst Message-Id: <8511041744.AA02886@HP-VENUS> Date: Mon 4 Nov 85 09:43:53-PST From: Alan Snyder Subject: functions that return nonstandard extra values To: common-lisp@su-ai.arpa Source-Info: From (or Sender) name not authenticated. Why not use the traditional solution of giving these nonstandard functions different names? Then you don't have to worry about them becoming incompatible should the standard be extended to have more return values. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 15:52:38 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 12:40:00 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 347463; Mon 4-Nov-85 15:41:20-EST Date: Mon, 4 Nov 85 15:44 EST From: Daniel L. Weinreb Subject: defvar, defparameter, :unbound To: common-lisp@SU-AI.ARPA In-Reply-To: <8511030455.AA00775@tove.umd.edu> Message-ID: <851104154406.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sat, 2 Nov 85 23:55:45 EST From: Nick Papadakis On the lispmachines, defvar will take a second argument of :unbound, meaning that the variable will be initialized to an unbound state. I'm not sure which Lisp machine this message is supposed to apply to, but just for the record, the Symbolics system does not do this.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 13:33:45 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 10:22:24 PST Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 NOV 85 13:23:37 EST Date: Mon, 4 Nov 85 13:23 EST From: Soley@MIT-MC.ARPA Subject: free variable references in interpreter. To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM In-Reply-To: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <851104132305.1.SOLEY@CHERRY.MIT.EDU> Date: Mon, 4 Nov 85 11:49 EST From: David C. Plummer Subject: free variable references in interpreter. To: Scott E. Fahlman , George J. Carrette , Richard Mark Soley , David C. Plummer cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM I disagree with what GJC said, because of the reasons Soley gave, but I disagree with Soley's counter on aesthetic reasons. Suppose there were a magic switch. What would the end of GETHASH look like? (return-from gethash (if *pure-cl* (values entry got-it-p) (values entry got-it-p key-stored-in-hash-table))) That doesn't appeal to me. Meta-point: I don't think we should care whether the IMPLEMENTATION code is appealing or not, but whether code written in Common Lisp itself is appealing. I think the form above is fine. I think that the usual way such a switch would be used would be used would be one of: (1) Some macro, like (IN-LOCAL-CL-DIALECT-SUPERSET (gethash . . .)) (2) "-*- Dialect: Symbolics-Common-Lisp -*-" in the file's attribute list. (3) A global proclamation: (PROCLAIM '(SUPER-WINNING-LOCAL-DIALECT T)). -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 13:33:07 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 10:21:55 PST Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 NOV 85 13:23:14 EST Date: Mon, 4 Nov 85 13:23 EST From: Soley@MIT-MC.ARPA Subject: free variable references in interpreter. To: DCP@SCRC-QUABBIN.ARPA, Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM In-Reply-To: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <851104132305.1.SOLEY@CHERRY.MIT.EDU> Date: Mon, 4 Nov 85 11:49 EST From: David C. Plummer Subject: free variable references in interpreter. To: Scott E. Fahlman , George J. Carrette , Richard Mark Soley , David C. Plummer cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM I disagree with what GJC said, because of the reasons Soley gave, but I disagree with Soley's counter on aesthetic reasons. Suppose there were a magic switch. What would the end of GETHASH look like? (return-from gethash (if *pure-cl* (values entry got-it-p) (values entry got-it-p key-stored-in-hash-table))) That doesn't appeal to me. Meta-point: I don't think we should care whether the IMPLEMENTATION code is appealing or not, but whether code written in Common Lisp itself is appealing. I think the form above is fine. I think that the usual way such a switch would be used would be used would be one of: (1) Some macro, like (IN-LOCAL-CL-DIALECT-SUPERSET (gethash . . .)) (2) "-*- Dialect: Symbolics-Common-Lisp -*-" in the file's attribute list. (3) A global proclamation: (PROCLAIM '(SUPER-WINNING-LOCAL-DIALECT T)). -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Nov 85 11:56:50 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 4 Nov 85 08:44:12 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 217507; Mon 4-Nov-85 11:45:30-EST Date: Mon, 4 Nov 85 11:49 EST From: David C. Plummer Subject: free variable references in interpreter. To: Scott E. Fahlman , George J. Carrette , Richard Mark Soley , David C. Plummer cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM In-Reply-To: , <[MIT-MC.ARPA].703111.851103.GJC>, <[MIT-MC.ARPA].703168.851103.SOLEY> Message-ID: <851104114947.1.DCP@NEPONSET.SCRC.Symbolics.COM> I disagree with what GJC said, because of the reasons Soley gave, but I disagree with Soley's counter on aesthetic reasons. Suppose there were a magic switch. What would the end of GETHASH look like? (return-from gethash (if *pure-cl* (values entry got-it-p) (values entry got-it-p key-stored-in-hash-table))) That doesn't appeal to me, and neither does (multiple-value-call #'values (values entry got-it-p) (if *pure-cl* (values) (values key-stored-in-hash-table))) I suppose this could be packaged as macros, but then I ask you: is it reasonable for people to have to bind *pure-cl* to NIL (presumably it has to default to to) in order to get extra values? How is this really different from GJC's request-is-via-optional-arguments-on-the-call-side? A couple more random points of information. I think multiple-value-call is a poor name. It should be called multiple-value-funcall. The symbolics system has a special form called sys:%multiple-value-call-n which looks like (sys:%multiple-value-call-n fun vals1 n1 vals2 n2 ...) which is more-or-less a highly optimized (multiple-value-call #'fun (multiple-value-bind (v1 v2 ... vn1) vals1 (values v1 v2 ... vn1)) (multiple-value-bind (v1 v2 ... vn2) vals2 (values v1 v2 ... vn2)) ...) In other words, fun is unquoted (for esoterit historical reasons I can never remember), and the pairs of values-count say effectively "evaluate valsM for nM values." This win about this special form is that it is insensitive to extra values because the caller explicitly says how many values are requested.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Nov 85 10:31:51 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 07:24:06 PST Date: Sun, 3 Nov 85 10:26:06 EST From: Richard Mark Soley Subject: extra features/values To: GJC@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU, gls@AQUINAS.THINK.COM, DCP@SCRC-QUABBIN.ARPA In-reply-to: Msg of Sun 3 Nov 85 08:12:39 EST from George J. Carrette Message-ID: <[MIT-MC.ARPA].703168.851103.SOLEY> Date: Sun, 3 Nov 85 08:12:39 EST From: George J. Carrette To: DCP at SCRC-QUABBIN.ARPA cc: common-lisp at SU-AI.ARPA, Fahlman at C.CS.CMU.EDU, gls at AQUINAS.THINK.COM Re: extra features/values How about (gethash key hash-table :give-me-extra-stuff t). This solves the GETHASH problem, but not the general problem (there are likely to be many more functions from which a particular implementation wants to return more values). And I don't think adding the :give-me-extra-stuff keyword to every one of them helps. I think the one, central, *ARE-WE-IN-PURE-COMMON-LISP-YET?* switch should control extra return value behavior, to help the poor user who codes (nth 2 (append (multiple-value-list (gethash key1 hasht1)) (multiple-value-list (gethash key2 hasht2))) -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Nov 85 10:27:30 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 07:19:17 PST Date: Sun, 3 Nov 85 10:21:19 EST From: Richard Mark Soley Subject: defvar, defparameter, :unbound To: isrlist@TOVE.UMD.EDU cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Sat 2 Nov 85 23:55:45 EST from Nick Papadakis Message-ID: <[MIT-MC.ARPA].703165.851103.SOLEY> Date: Sat, 2 Nov 85 23:55:45 EST From: Nick Papadakis To: common-lisp at su-ai.ARPA Re: defvar, defparameter, :unbound On the lispmachines, defvar will take a second argument of :unbound, meaning that the variable will be initialized to an unbound state. This occaisionally convenient feature should probably be added to common-lisp, and defparameter should be extended to handle it as well. I disagree. (defvar foo :unbound), to me, reads "set the value of the symbol 'foo' to the symbol 'unbound' in the keyword package. I think (defvar foo) is more readable. -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Nov 85 08:16:25 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Nov 85 05:10:40 PST Date: Sun, 3 Nov 85 08:12:39 EST From: "George J. Carrette" Subject: extra features/values To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU, gls@AQUINAS.THINK.COM In-reply-to: Msg of Fri 1 Nov 85 17:59 EST from David C. Plummer Message-ID: <[MIT-MC.ARPA].703111.851103.GJC> How about (gethash key hash-table :give-me-extra-stuff t).  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Nov 85 23:59:11 EST Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 2 Nov 85 20:52:38 PST Received: by tove.umd.edu (5.5/4.7) id AA00775; Sat, 2 Nov 85 23:55:45 EST Date: Sat, 2 Nov 85 23:55:45 EST Message-Id: <8511030455.AA00775@tove.umd.edu> From: Nick Papadakis To: common-lisp@su-ai.ARPA Subject: defvar, defparameter, :unbound On the lispmachines, defvar will take a second argument of :unbound, meaning that the variable will be initialized to an unbound state. This occaisionally convenient feature should probably be added to common-lisp, and defparameter should be extended to handle it as well. - nic  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Nov 85 20:29:39 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Nov 85 17:21:28 PST Received: ID ; Fri 1 Nov 85 20:22:41-EST Date: Fri, 1 Nov 1985 20:22 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: free variable references in interpreter. In-reply-to: Msg of 1 Nov 1985 17:59-EST from David C. Plummer I think that it is OK for an implementation to take extra args and keywords on the built-in functions. I can't think of any reasonable ways in which this breaks correct Common Lisp programs, though it might make trouble if the Common Lisp standard is later extended to allow additional arguments that are not the same as the ones this implementation has chosen. I think that extra multiple values are another thing that ought to be legal, but unfortunately there are ways in which these would break certain legal but odd programs, as you point out. I think we blew the language design here -- we just weren't thinking of this issue when we nailed down the multiple-value stuff. So, I suppose that in order to be 100% legal, an implementation should not return extra values, unless perhaps they can be turned off with a switch. As deviations go, however, this is a pretty harmless class of them, breaking only rather odd code. So if there is a really good reason to return extra values as an extension, it might be reasonable to go ahead and do this, as long as this minor deviation from the standard is carefully documented as such. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Nov 85 18:38:34 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 15:29:19 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 346455; Fri 1-Nov-85 17:57:03-EST Date: Fri, 1 Nov 85 17:59 EST From: David C. Plummer Subject: free variable references in interpreter. To: Scott E. Fahlman , Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851101175928.6.DCP@NEPONSET.SCRC.Symbolics.COM> Talking about supersets... It seems obvious that supersets can extend functions by allowing more optional arguments or additional keywords to those already specified in CLtL. For example, Symbolics' make-array can take a :displaced-conformally keyword to do multidimensional displacement in a slightly different way than specified. That's all well and good for the function calling direction, but what about the receiving direction? That is, we have had requests to have GETHASH return three values instead of two, the third being the key as stored in the hash table, which might be EQUAL but not EQ to the given to GETHASH. This third value seems OK since most applications will only be looking for one or two values. But what about subtle cases like (multiple-value-list (gethash key hash-table)) or (multiple-value-call #'list (gethash key1 hash-table) (gethash key2 hash-table)) where the difference is readily apparent. Therefore, I have two questions: Do we all agree that extra optional arguments or additional keyword arguments are an upward compatible extension and that programs that do not use these extensions should run on other implementations? What about the extra values problem? Note that CLtL does not have a way to say I want values as a result of executing this form. Again, programs that do not use the extra values will run on all implementations, except for those places (such as the above examples) where the extra values are visible.  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Nov 85 15:51:55 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 1 Nov 85 12:41:22 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA20713; Fri, 1 Nov 85 13:45:59 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA07112; Fri, 1 Nov 85 13:45:55 MST Date: Fri, 1 Nov 85 13:45:55 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8511012045.AA07112@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Declaring Functions The notion of a function type is mentioned in two places: p. 47 of the CLM, where the (function ...) type specifier is defined, and p. 158-159, where (ftype ...) and (function ...) are defined as options to declare. Are they intended to be the same? If so, then the second definition should say that keywords and a (values ...) type specifier are allowed. If not, then what is the point of a function type specifier, since you can't feed it to typep anyway? Also, what is the intended syntax for lambda lists with keywords in a type specifier? Somehow, (deftype make-seq-type () '(function (type integer &key initial-element t) sequence)) doesn't look quite right... Has anybody done anything but punt on function declarations? stan shebs  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Nov 85 14:50:37 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Nov 85 11:36:04 PST Received: ID ; Fri 1 Nov 85 14:37:33-EST Date: Fri, 1 Nov 1985 14:37 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: free variable references in interpreter. In-reply-to: Msg of 1 Nov 1985 11:49-EST from Guy Steele I don't believe there is anything in the Common Lisp book that explicitly states that a Common Lisp implementation may not signal errors in any situations not explicitly defined in the book to be errors. On tbe other hand, I think there is at least an implicit expectation that a purely computational section of a valid Common Lisp program will execute without requiring the user to hit a "resume" key every three seconds. I am not sure what we can say in the book about this without unduly contraining experimentation with programming environments and debugging tools. If Common Lisp is to be of any value at all as a standard promoting portable software, the following assumption has to be true (or as close to true as we can possibly make it): If an implementation claims to be a Common Lisp or a superset of Common Lisp, any legal program that conforms to what is in the manual and uses nothing that is not in the manual ought to run in that implementation. "Run" means "run without signalling any errors". I'm not sure we need Guy's hedge about "purely computational"; I don't know what he means by that, but if he means "not involving user-interface or system-interface" issues, I think we have excluded most of that from the current language spec, and have indicated the range of permissible variation in the remaining cases. Of course, this is more a goal than an iron-clad rule, since the manual is ambiguous and incomplete in some areas. Still, I think that we should state this explicitly and strive to achieve it. I thought that we already had stated this or something close to it, but maybe not. On the question of how we say this without unduly constraining experimentation, I don't see that as a problem. People should feel free to experiment all they want, but if they knowingly violate the standard they should point that out and not claim to be a Common Lisp (in those specific respects). Manufactuers would be well-advised to provide a mode that that is strictly kosher Common Lisp -- as close as they can come, anyway -- and if they want to experiment with incompatible improvements, these should be enabled by a switch of some sort. Ideally, it should be straightforward to get at the strict Common Lisp; you should not have to poke around setting 53 undocumented switches, some of them guarded by people with guns, in order to get behavior that conforms to the standard. Given the above, I think I can answer all of Guy's queries with a single statement of principle: When operating as a strict Common Lisp, the system should run any legal Common Lisp program without signalling any ERRORS. If the system wants to mumble warnings and critiques of my style, that's fine -- the more, the better -- as long as these warnings are of a sort that I am free to turn them off or at least ignore them. If the warnings require some explicit action in order for me to proceed, or if they cause my compilation not to complete properly, then that is not OK, unless this is an optional behavior that I can easily get rid of. I don't mind the intereter mumbling warnings (into some separate stream, so that they don't mess up what my legal but unstylish program is trying to print), though customers will have varying opinions about how much they want to pay for such criticism at runtime. Doesn't that cover it? I think that Guy threw us a curve by asking whether warnings were OK in various situations, while saying that these "warnings" might or might not require some explicit action -- to me, that is the critical issue. Of course, a few of Guy's examples are so outlandish that I would find the warnings in question irritating. Perhaps we need several levels: Error, Warning, Style Critique, Friendly Advice, Kibitz. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Nov 85 11:54:17 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 1 Nov 85 08:46:17 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Fri, 1 Nov 85 11:48:22 est Date: Fri, 1 Nov 85 11:49 EST From: Guy Steele Subject: free variable references in interpreter. To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <851101114946.2.GLS@DESIDERIUS.THINK.COM> I don't believe there is anything in the Common Lisp book that explicitly states that a Common Lisp implementation may not signal errors in any situations not explicitly defined in the book to be errors. On tbe other hand, I think there is at least an implicit expectation that a purely computational section of a valid Common Lisp program will execute without requiring the user to hit a "resume" key every three seconds. I am not sure what we can say in the book about this without unduly contraining experimentation with programming environments and debugging tools. Here is a set of thought experiments about a LISP system. Question: in each case, is it or is is not consistent with the letter and/or the spirit of Common Lisp? There are two subcases for each experiment, according to whether the interpreter or compiler is involved. I will use the noun "system" to refer to either the interpreter of the compiler, and I will use "warning" to mean any action that draws the user's attention to a message (and that may or may not require explicit user action before continuing with the computation). Some of these examples are intentionally outlandish. (1) You refer to a function without declaring it first, and the system gives you a warning. (Note that I said "declaring", not "defining". Consider the compiler especially.) (2) You refer to a special variable without declaring it, and the system gives you a warning. (3) You write "(+ x (cons y z))" and the system warns you that CONS cannot produce (or has not produced) a value that is valid as an argument to +. (4) You write (COND ((ATOM X) 'A) (T 'C) ((BAZ X) 'D)) and the system warns you that the last COND clause is unreachable. (5) You write (COND ((ATOM X) 'A) ((CONSP X) 'C) ((BAZ X) 'D)) and the system warns you that the last COND clause is unreachable. (6) You write (MULTIPLE-VALUE-BIND (A B C) (FLOOR X Y) ...) and the system warns you that FLOOR returns only two values. (7) You use several GO's in a PROG, and the system warns you that this code will probably be very hard to maintain. (8) You write (DEFUN FIB (N) (COND ((<= N 1) 1)) ;Note parenthesis error! (T (+ (FIB (- N 1)) (FIB (- N 2))))) and the system warns you that your code is not properly indented. (9) You write (DEFUN FIB (N) (COND ((<= N 1) 1) (T (+ (FIB (- N 1)) (FIB (- N 2)))))) and the system warns you that your code is not properly indented. (10) You write a DO loop, and the system warns you that it could have been expressed more simply and efficiently by using a call to RASSOC with the :TEST-NOT and :KEY options. (11) You write two nested DO loops, and the system warns you that the SORT primitive is much better than the bubble sort that you wrote. (12) You write (DEFUN FIB (N) (IF (ZEROP N) 1 (* N (FIB (- N 1))))) and the system warns you that your function FIB is computing factorials and not Fibonacci numbers. Is there some generalization we can derive from these thought experiments, or others, that is worth putting in the book? --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Oct 85 22:45:46 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Oct 85 18:20:39 PST Received: ID ; Thu 31 Oct 85 21:22:43-EST Date: Thu, 31 Oct 1985 21:22 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: common-lisp@SU-AI.ARPA, MLY@MIT-MC.ARPA Subject: free variable references in interpreter. In-reply-to: Msg of 31 Oct 1985 18:53-EST from George J. Carrette But what justifies your too disparaging tone "at least they provide a switch...?" Give us some credit here where credit is due, it is rather that "OF COURSE THEY PROVIDE A SWITCH!!" This is a minor stylistic difference we have here, not something to get yourself worked up about, bordering on insult. I wasn't trying to insult anybody. (When I am trying to insult someone, I generally do a better job of it than this.) I just didn't want people seeing this exchange to assume that the behavior you and MLY described was legal Common Lisp, and that it really is an error to reference an undeclared special. Your post gave that impression, and MLY compounded the problem by saying that the switch in question was only to be used for backwards compatibility. So my statement was that the default behavior you described was not, strictly speaking, legal Common Lisp. I also said that "at least" your system provided a switch in it that would turn on the legal behavior, though MLY had just said that anyone using that switch should be shot. The "at least" meant "at least the switch is there, though some believe that it shouldn't be used." I happen to agree that it is lousy style to reference undeclared specials, and I think it is a useful feature in a Common Lisp implementation to have a mode available where such things get flagged. I personally would not make this the default, but that is a minor issue. The more important question is to what extent we should encourage small improvements that happen to violate the Common Lisp standard, such as it is. I have no quarrel with any manufacturer who wants to stand up and say clearly in their documentation that "we have chosen to deviate from the Common Lisp standard in the following N ways because we feel that these changes are improvements". Maybe LMI has done this; I haven't seen their documentation. But if such small deviations, however well-meaning, are made without proper acknowledgement, they constitute a real threat to the standardization of the language. That's why I try to flag these things when I see them. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Oct 85 22:09:17 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 18:58:46 PST Date: Thu, 31 Oct 85 22:00:45 EST From: "Glenn S. Burke" Subject: free variable references in interpreter. To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].700561.851031.GSB> In NIL we had at least two years of experience with automatic special declarations of free variables. What used to happen was a free reference would cause, on the first occurrence, a warning message to be printed, and a special proclamation to be performed. This was a big pain and caused a fair amount of grief. Now, what happens is that a free variable reference generates a free-variable-reference error. The result of this is that the user gets to choose (via the debugger) to globally declare the variable special, to just use the special value "just this once" (i.e., the error will occur again), or any other general debugger action. It seems fair to me that you should be warned about a free variable which is not declared within the current lexical scope. Remember that the compiler cannot tell what dynamic scope the function will be called in, so (in the interpreter) blindly and silently using whatever dynamic value is around doesn't seem to me to be such a hot idea. And, "OF COURSE IT'S CONTROLLED BY A SWITCH!!!" -- si::*interpreter-special-warn*. And, as MLY said, we also have special dispensation for the toplevel null lexical environment to utilize free variables without this interference, so that one can do things like (setq x ...) without globally corrupting the usage of X. (If you want to, you use defparameter instead.) ---------------- I would appreciate it if other people would refrain from describing what NIL does when they are at all unfamiliar with the development version. It is unfortunate that the latest public NIL release came out 1.5 years ago and the published benchmarks for some reason were those for the version before that, so i don't need any additional help in the spread of misinformation.  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Oct 85 19:00:45 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 15:51:34 PST Date: Thu, 31 Oct 85 18:53:27 EST From: "George J. Carrette" Subject: free variable references in interpreter. To: Fahlman@C.CS.CMU.EDU cc: MLY@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-reply-to: Msg of Thu 31 Oct 1985 12:48 EST from Scott E. Fahlman Message-ID: <[MIT-MC.ARPA].700350.851031.GJC> The purpose of the interpreter behavior was to be compatible with compiler behavior that has been the accepted standard for years, to warn or give some indication on UNDECLARE SPECIAL VARIABLES. This should be obvious. It has been an invaluable aid in tracking down problems in code being converted to common-lisp and I recommend it as an option for everybody. The default-behavior issue has nothing to do with advertising, it has to do with the mechanics of customer support. There are two possible settings, T and NIL. If set to NIL then users will quickly find problems in their code relating to undeclared variables that are both globally set and lambda bound. If set to T then most of these common problems with scoping become more subtle, and instead turn into lengthy phone calls. In the more rare cases you find someone that really wants to do (SET 'FOO ) then (EVAL ). This might happen in a production rule system for example. In these cases we get the chance to advise people to put in the call to PROCLAIM. But serious folks. There is a lot more to find disturbing about MLY than his sentiments. Maybe we'll all get a chance to take our shots at the next common-lisp meeting. Let me propose one of my sentiments: Any lispmachine company that would advertise their machine just: "AS A COMMON LISP" would be underselling it severely. lispmachine companies generally seem to be saying things along the lines of "SUPPORTS COMMON LISP" or "RUNS CODE CONFORMING TO THE ..." But what justifies your too disparaging tone "at least they provide a switch...?" Give us some credit here where credit is due, it is rather that "OF COURSE THEY PROVIDE A SWITCH!!" This is a minor stylistic difference we have here, not something to get yourself worked up about, bordering on insult. There is the letter of the law here vs the intent. One of the major intents of CL was to have interpreter/compiler compatibility. The purpose of the LMI switch was merely along these lines. Isn't much better in the long run to view the CL book as a constitution rather than as a statement of dogma?  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Oct 85 12:58:00 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 31 Oct 85 09:46:36 PST Received: ID ; Thu 31 Oct 85 12:48:36-EST Date: Thu, 31 Oct 1985 12:48 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Richard Mlynarik Cc: common-lisp@SU-AI.ARPA Subject: free variable references in interpreter. In-reply-to: Msg of 31 Oct 1985 11:49-EST from Richard Mlynarik The default behavior of the LMI/MIT version of the Lisp Machine code, as described by MLY and GJC, is not legal Common Lisp as I understand the manual (page 55). In Common Lisp, references to variables not lexically bound in the current environment are supposed to refer to the special value of that variable, and should not generate an error (unless the special variable has no current value). This is true whether or not the reference occurs at top level. One can argue about whether the LMI behavior is better, but it is not Common Lisp. At least they provide a switch which makes the system conform to Common Lisp in this matter, but I find disturbing the sentiment that anyone setting this switch, except when dealing with "crufty old code" should be shot, at least if LMI is advertising their system as a Common Lisp. In that case, I think that Common Lisp compatibility should be the default. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Oct 85 11:59:11 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Oct 85 08:47:35 PST Date: Thu, 31 Oct 85 11:49:30 EST From: Richard Mlynarik Subject: free variable references in interpreter. To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].699862.851031.MLY> GJC has somewhat misstated what happens both in NIL and in the MIT (lmi) lisp machine interpreters. The initial decision about whether a free variable reference should be considered "an error" is made by looking at the environment in which the form was evaluated, not at a magic variable. "Top-level" evaluation (the sort of thing the user types at a lisp listener) passes EVAL an environment object which says `just silently take any free variable references to be a reference to the special value of that variable' (which is exactly the same as the mechanism of function lookup, incidentally) On the other kettle of fish, "normal" evaluation, made in the null lexical environment, (EVAL's default) signals an error when a free variable reference occurs. (The variable GJC mentioned, si::*mumble-free-mumble-reference-mumble-special, is used to override this for the use truly crufty old code which nobody wants to invest any time in improving. Anybody else seen binding it should be shot with a gun) The result of this is that a user may type "(setq foo *)" and "(funcall (frob foo) 1)" at a lisp listener without being harrassed too unduly, but that compiler-style detection of wild references happens for "(eval '(setq foo *))" and so forth. [The older way in which NIL's evaluator dealt with this situation, (explicitly doing a (PROCLAIM '(SPECIAL ...)) and printing a warning to *ERROR-OUTPUT* whenever the interpreter saw a free reference) was flushed some time ago in favour of the above scheme] [Another hack is that that the environment object in the lisp machine implementation can also flag that -all- variable references are special. This was intended to be used when people were converting code which ran with the old dynamic interpreter. As it happened, not much seemed to require this sort of degenerate backwardness]  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Oct 85 17:53:40 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 12:25:26 PST Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 165515; Wed 30-Oct-85 15:28:22-EST Date: Wed, 30 Oct 85 15:25 EST From: Robert W. Kerns Subject: Default scope of references To: Dan Hoey cc: Common-lisp@SU-AI.ARPA In-Reply-To: <499475345/hoey@nrl-aic> Message-ID: <851030152528.6.RWK@CROW.SCRC.Symbolics.COM> Date: 29 Oct 1985 18:09:05 EST (Tue) From: Dan Hoey (DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL) (SETQ FOO VAL)) (SET-FOO NIL))) (eval *test-1*) ==> NIL foo ==> NIL (DEFVAR *TEST-2* '(PROGN (SET 'FOO T) (DEFUN GET-FOO () FOO) (GET-FOO))) (eval *test-1*) ==> NIL foo ==> NIL in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that (EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was accessing a variable that was neither declared special nor lexically bound. According to CLtL, however, ``The general rule is that if the symbol occurs textually within a program construct that creates a *binding* for a variable of the same name, then the reference is to the variable specified by the binding; if no such program construct textually contains the reference, then it is taken to refer to the special variable of that name.'' [p. 55] Thus these forms are supposedly legally evaluable. Is this what was intended? Yes. Should evaluation of these forms be or signal an error? No. I would certainly hope that the answer is the same for both tests. It is. (DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*)) (DEFUN LEX-TEST () (LET ((FOO T)) (SET-FOO NIL) FOO)) (LEX-TEST))) (eval *test-3*) ==> T foo ==> NIL (DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*)) (COMPILE 'LEX-TEST) (LEX-TEST))) (eval *test-4*) ==> T foo ==> NIL I believe the "best" alternative is what VAX/NIL does; namely give a warning like the compiler. (It would be best if it did it only once for a given form). However, this might be unpopular with users if this warning interferes with their interaction. Of course, the real conclusion to draw from this is to use the compiler. Most compilers give you a lot of static error checking that you won't see interpreted. For example, if your compiler does wrong-number-of-args checking, it will check the number of arguments even on parts of your function that are only called once in a blue moon.  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Oct 85 17:05:43 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 11:42:20 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 344503; Wed 30-Oct-85 14:42:51-EST Date: Wed, 30 Oct 85 14:44 EST From: Daniel L. Weinreb Subject: Default scope of references To: hoey@NRL-AIC.ARPA, Common-lisp@SU-AI.ARPA In-Reply-To: <499475345/hoey@nrl-aic> Message-ID: <851030144425.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 29 Oct 1985 18:09:05 EST (Tue) From: Dan Hoey In Symbolics Common Lisp, *test-1* returns NIL, *test-2* returns T, *test-3* returns T, and *test-4* returns T. No errors are signalled. As far as I understand the definition of the language, this is correct.  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Oct 85 13:25:47 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 10:13:10 PST Date: Wed, 30 Oct 85 13:15:05 EST From: Jonathan A Rees Subject: absence of (declare (unspecial ...)) To: Common-Lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].698338.851030.JAR> While we're on the subject of lexical versus special, I'd like to ask if anyone remembers why there's no UNSPECIAL declaration in Common Lisp. It seems important enough that there must have been some compelling reason for its omission.  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Oct 85 09:41:09 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 06:31:16 PST Date: Wed, 30 Oct 85 09:33:12 EST From: "George J. Carrette" Subject: Default scope of references To: hoey@NRL-AIC.ARPA cc: Common-lisp@SU-AI.ARPA In-reply-to: Msg of 29 Oct 1985 18:09:05 EST (Tue) from Dan Hoey Message-ID: <[MIT-MC.ARPA].698107.851030.GJC> In the LMI Systems that you have the behavior of your test cases is controlled by the variable SI::*ALL-FREE-INTERPRETER-VARIABLE-REFERENCES-SPECIAL*, which defaults to NIL. With this default setting both cases *TEST-1* and *TEST-2* signal errors as you wish. There was some discussion about getting rid of this option, or at least defaulting it to T. In DOE-MACSYMA for example the setting of this variable must be T, because of the unrestricted use of EVAL in the pattern matcher code. The VAX-NIL system system took a different tack, prefering to be somewhat like the usual compiler approach. An undeclared (SETQ FOO ...) will generate a warning, and then a "FOO assumed special." This also has its drawbacks. There is the issue of how correct to be vs how much trouble to cause users with old habits. Many users of the LMI system set the variable controlling the behavior to T. Your reported results are not consistent with the behavior of LMI systems in either setting. Both variable reference and variable setting are caught, but you report that variable setting is not caught. Perhaps you evaluated (SET-FOO) in a lisp-listener instead of as (EVAL '(SET-FOO)). These have different behaviors because the system is trying to be more forgiving to top-level calls than to constructs inside programs. -gjc  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Oct 85 08:52:47 EST Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 30 Oct 85 05:45:14 PST Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000666; 30 Oct 85 12:26 GMT From: Jeff Dalton Date: Tue, 29 Oct 85 19:18:29 GMT To: RPG@su-ai.arpa, common-lisp@su-ai.arpa Subject: Re: Tentative Schedule for the Common Lisp Meeting |Date: 26 Oct 85 1315 PST |From: Dick Gabriel |Subject: Tentative Schedule for the Common Lisp Meeting | |I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts, |for December 16, 17, and 18 for the meeting (not for accommodations). |Are these dates acceptable? I must have a firm answer by monday. | -rpg- I know this is after monday, but I'm going to send it anyway. For flying transatlantic, the 16-18 have the advantage of being over a month away so that it's possible to buy a reasonable ticket. But they are almost certainly into the busy (and expensive) season. (Last year fares went up the 13th and then down again around the 27th.) Still, this way I need stay only a week to be home for Christmas. The dates are acceptable, though. Cheers, Jeff Dalton AIAI, University of Edinburgh  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Oct 85 19:58:51 EST Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 29 Oct 85 16:48:53 PST Date: 29 Oct 1985 18:09:05 EST (Tue) From: Dan Hoey Subject: Default scope of references To: Common-lisp@SU-AI.ARPA Message-Id: <499475345/hoey@nrl-aic> I would like some protection against accidental references to dynamically bound variables in interpreted code. Compilers typically complain about such lossage. When I heard that Common Lisp defaulted to lexical binding, I thought that was what was meant. For instance, given (DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL) (SETQ FOO VAL)) (SET-FOO NIL))) (DEFVAR *TEST-2* '(PROGN (SET 'FOO T) (DEFUN GET-FOO () FOO) (GET-FOO))) in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that (EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was accessing a variable that was neither declared special nor lexically bound. According to CLtL, however, ``The general rule is that if the symbol occurs textually within a program construct that creates a *binding* for a variable of the same name, then the reference is to the variable specified by the binding; if no such program construct textually contains the reference, then it is taken to refer to the special variable of that name.'' [p. 55] Thus these forms are supposedly legally evaluable. Is this what was intended? Should evaluation of these forms be or signal an error? I would certainly hope that the answer is the same for both tests. The CL interpreters I have seen signal an error in (EVAL *TEST-1*); they are happy to let (EVAL *TEST-2*) modify the global value of FOO. A funnier situation occurs when we have (DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*)) (DEFUN LEX-TEST () (LET ((FOO T)) (SET-FOO NIL) FOO)) (LEX-TEST))) I have actually seen an implementation for which (EVAL *TEST-3*) yields NIL, but that is clearly erroneous. Other implementations happily evaluate *TEST-3* to T, setting the global value of FOO to NIL. A stranger situation occurs with (DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*)) (COMPILE 'LEX-TEST) (LEX-TEST))) In the implementations I have tested, (EVAL *TEST-4*) will signal an error when SET-FOO attempts to change the value of FOO. Unfortunately, my access to Common Lisp implementations is confined to one vendor's Beta release and two other implementations to which I have no hands-on access. Rather than disparage anyone's implementation on such slender evidence, I would like to hear from implementors on the results of evaluating the four tests in the most current versions of their implementations. Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Oct 85 21:11:34 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 28 Oct 85 14:45:15 PST Received: from desiderius by GODOT.THINK.COM via CHAOS; Mon, 28 Oct 85 16:07:57 est Date: Mon, 28 Oct 85 16:09 EST From: Guy Steele Subject: Uniqueness of &rest arguments To: OLDMAN@USC-ISI.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <[USC-ISI.ARPA]28-Oct-85 15:32:44.OLDMAN> Message-Id: <851028160902.2.GLS@THINK-DESIDERIUS.ARPA> Date: 28 Oct 1985 15:32-EST From: OLDMAN@USC-ISI.ARPA Are &rest arguments guaranteed to be copied? Consider the following: (defmacro m (&rest args) `',(nreverse args) ; Destructive reverse ) (setq x '(m a b c d)) (eval x) What is the final value of x? I think that I would argue that it is undefined since args may or may not be a copy of the original form. Is there anything in Cttl that clarifies this? -- Dan I cannot find any place in the manual that addresses this point. The text describing APPLY alludes to appending the last argument to APPLY to a list of all other arguments (except the function, of course), and so one might think, referring to the definition of APPEND, that the resulting list of arguments might contain actual cons cells from the list that is the last argument to APPLY. However, nothing addresses whether a &REST argument might share with this list. My own opinion is that indeed the args might not be a copy of the original form, but I regard this as a non-trivial clarification worthy of discussion. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Oct 85 20:23:47 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 17:15:46 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 343009; Mon 28-Oct-85 20:14:50-EST Date: Mon, 28 Oct 85 20:15 EST From: David A. Moon Subject: Tentative Schedule for the Common Lisp Meeting To: Dick Gabriel cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 26 Oct 85 16:15-EDT from Dick Gabriel Message-ID: <851028201531.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 26 Oct 85 1315 PDT From: Dick Gabriel I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts, for December 16, 17, and 18 for the meeting (not for accommodations). Are these dates acceptable? They appear to be okay for me. I must have a firm answer by monday. By when? You can't have meant today if you sent mail on Saturday. Do you mean next Monday?  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Oct 85 20:20:36 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 17:11:43 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 343004; Mon 28-Oct-85 20:06:37-EST Date: Mon, 28 Oct 85 20:07 EST From: David A. Moon Subject: Uniqueness of &rest arguments To: Guy Steele cc: OLDMAN@USC-ISI.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <851028160902.2.GLS@THINK-DESIDERIUS.ARPA> Message-ID: <851028200712.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 28 Oct 85 16:09 EST From: Guy Steele Date: 28 Oct 1985 15:32-EST From: OLDMAN@USC-ISI.ARPA Are &rest arguments guaranteed to be copied? Consider the following: (defmacro m (&rest args) `',(nreverse args) ; Destructive reverse ) (setq x '(m a b c d)) (eval x) What is the final value of x? I think that I would argue that it is undefined since args may or may not be a copy of the original form. Is there anything in Cttl that clarifies this? I cannot find any place in the manual that addresses this point. The text describing APPLY alludes to appending the last argument to APPLY to a list of all other arguments (except the function, of course), and so one might think, referring to the definition of APPEND, that the resulting list of arguments might contain actual cons cells from the list that is the last argument to APPLY. However, nothing addresses whether a &REST argument might share with this list. None of this applies to macros anyway, since they aren't invoked with APPLY. My own opinion is that indeed the args might not be a copy of the original form, but I regard this as a non-trivial clarification worthy of discussion. I hope it doesn't take a whole lot of discussion. It's pretty clear to me that if the manual doesn't guarantee explicitly that the user can freely bash the &rest argument, then the user can only sensibly assume that it is not safe to bash it. I also can't see any significant advantage to the user to be gained requiring implementations to make copies of &rest arguments. Note that if there are implementations that can't avoid making a copy (but not for macros!), they can easily have a compiler optimizer to remove calls to copy-list, so there can be no argument from efficiency.  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Oct 85 15:58:04 EST Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 12:32:12 PST Date: 28 Oct 1985 15:32-EST Sender: OLDMAN@USC-ISI.ARPA Subject: Uniqueness of &rest arguments From: OLDMAN@USC-ISI.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[USC-ISI.ARPA]28-Oct-85 15:32:44.OLDMAN> Are &rest arguments guaranteed to be copied? Consider the following: (defmacro m (&rest args) `',(nreverse args) ; Destructive reverse ) (setq x '(m a b c d)) (eval x) What is the final value of x? I think that I would argue that it is undefined since args may or may not be a copy of the original form. Is there anything in Cttl that clarifies this? -- Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Oct 85 15:18:24 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 Oct 85 08:55:10 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 OCT 85 08:57:08 PST Date: 28 Oct 85 09:03 PST From: masinter.pa@Xerox.ARPA Subject: Re: Tentative Schedule for the Common Lisp Meeting In-reply-to: Dick Gabriel 's message of 26 Oct 85 13:15 PDT To: RPG@SU-AI.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <851028-085708-2075@Xerox> What happened to the week of December 3? You changed the date without a lot of discussion....  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Oct 85 16:23:12 EDT Date: 26 Oct 85 1315 PDT From: Dick Gabriel Subject: Tentative Schedule for the Common Lisp Meeting To: common-lisp@SU-AI.ARPA I have tentatively booked the Hotel Sonesta in Cambridge, Massachusetts, for December 16, 17, and 18 for the meeting (not for accommodations). Are these dates acceptable? I must have a firm answer by monday. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Oct 85 17:42:14 EDT Date: 25 Oct 85 1337 PDT From: Dick Gabriel Subject: Meeting To: common-lisp@SU-AI.ARPA I am at this very moment in negotiations with hotels and the like in the Boston area regarding the exact dates for the meeting. I expect to get some definitive answer to the question of ``when?'' by Monday or Tuesday. As it happens, it is not always possible to pick the exact days only 1.5 months in advance. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Oct 85 14:35:08 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Oct 85 09:40:19 PDT Date: Thu, 24 Oct 85 12:42:03 EDT From: "George J. Carrette" Subject: WITHOUT-INTERRUPTS To: greek@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Wed 23 Oct 85 13:25:24 EDT from greek at DEC-HUDSON Message-ID: <[MIT-MC.ARPA].691403.851024.GJC> Comment: Remailed at SU-AI after delay caused by distribution list error. Without-Interrupts can be very confusing. On the LISPM for example it is possible to call, knowingly or unknowingly, PROCESS-WAIT from within a Without-Interrupts, this can then allow a process switch, which may or may not defeat the purpose of the without-interrupts. On the VAX, in VAX-NIL which I'm most familiar with, I would be worried about critical sections of code from the point of view of AST handlers and such. However, I know that in NIL, by default, any straight line sequence of code without a function call is exectuted without testing for the interrupt polling BIT, or, while writing (or compiling lisp to) LMI-LAMBDA microcode there are similar considerations, therefore I can take advantage of this condition in writing code that has possible interlocking dangers. But conditions are so different in the different lisps that a simple-looking PORTABLE construct such as CRITICAL-SECTION would not work. Those very people who would want to use it are probably those that couldnt understand the underlying mechanisms sufficiently to write such code correctly and portably. Instead, maybe a few primitive datastructures, such as QUEUE's with properly interlocked manipulation primitives could be introduced into the language. That is to say, what kinds of things are you wanting to use CRITICAL-SECTION for anyway?  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Oct 85 13:52:20 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 24 Oct 85 08:38:32 PDT Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 24 Oct 85 11:40:21 edt Date: Thu, 24 Oct 85 11:42 EDT From: Guy Steele Subject: WITHOUT-INTERRUPTS: my last message To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 23 Oct 85 16:04-EDT from greek@DEC-HUDSON Message-Id: <851024114209.1.GLS@THINK-JEHOSEPHAT.ARPA> Comment: Remailed at SU-AI after delay caused by distribution list error. Date: Wed, 23 Oct 85 16:04:59 EDT From: greek@DEC-HUDSON I too promise that this is my last message. Me, too. Mr. Moon is right -- VMS certainly couldn't promise to lock out other processes that might touch a shared section. Sure it could... if it wanted to. Alternatively, the LISP could simply refuse to share. On the third hand, suppose I want to swap the names of two files, so I do (critical-section (rename-file "foo" "temp") (rename-file "bar" "foo") (rename-file "temp" "bar")) Assuming that files foo and bar both existed to begin with, am I guaranteed that at no time can any other process get the value NIL for (and (probe-file "foo") (probe-file "bar")) ? That would be an awfully nice property to have. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 18:49:51 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85 10:19:09 PDT Date: Wed, 23 Oct 85 13:25:24 EDT From: greek@DEC-HUDSON Subject: WITHOUT-INTERRUPTS To: common-lisp@su-ai Mr. Greenberg is certainly correct when he says we don't understand all the locking mechanisms that exist. However, unless I'm off base here, it seems to me that CRITICAL-SECTION could be specified as locking out ANY possible contention from other tasks, interrupt handlers, processors, etc. If a particular implementation needs additional kinds of locking macros, they can add them. Perhaps we should define CRITICAL-SECTION as follows: CRITICAL-SECTION (&key options) &body body and say that, without options, it locks out "everything". On the other hand, perhaps "everything" is simply too nebulous. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 18:48:20 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 07:23:16 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 162582; Wed 23-Oct-85 10:02:46-EDT Date: Wed, 23 Oct 85 10:07 EDT From: Bernard S. Greenberg Subject: WITHOUT-INTERRUPTS To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 22 Oct 85 12:45-EDT from greek@DEC-HUDSON Message-ID: <851023100741.6.BSG@CONCORD.SCRC.Symbolics.COM> Date: Tue, 22 Oct 85 12:45:43 EDT From: greek@DEC-HUDSON I think if we abandon the name WITHOUT-INTERRUPTS, which has all kinds of vague conotations, and adopt the name CRITICAL-SECTION, we might get further in understanding what it ought to do. - Paul No, it hides the issue rather than clarifies it. On a certain class of simple systems, CRITICAL-SECTION means "without interrupts". When multiprocessing and other complications are introduced, then "without interrupts" is not only not sufficiently adequate, but not sufficiently -specific- as to exactly what must be locked out. "CRITICAL-SECTION" makes no claim to asserting exactly what must be locked out, but in no way addresses the problem that this is a complicated set, either.  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 18:46:29 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85 08:22:02 PDT Date: Wed, 23 Oct 85 11:28:22 EDT From: greek@DEC-HUDSON Subject: WITHOUT-INTERRUPTS To: common-lisp@su-ai Mr. Greenberg has pointed out that I've only hidden the problem by suggesting CRITICAL-SECTION instead of WITHOUT-INTERRUPTS. That's exactly what I intended to do. WITHOUT-INTERRUPTS is too specific, and deals only with interrupt questions, not with memory lockout or other strange things that may occur on multiprocessors. CRITICAL-SECTION, I believe, suggests what it is that we are trying to accomplish, without being specific. On a simple processor running a LISP without its own tasking or interrupts, it would be a nop. With interrupts, it would lock them out. With tasks, it would also prevent task switches. On a multiprocessor it might also do some kind of memory lockout to prevent the other processors from stomping on things. Who knows -- and that's exactly the point. Perhaps the problem is that there are so many classes of things we want to lock out that we need multiple macros or options to the one macro. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 16:56:37 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 10:30:21 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339575; Wed 23-Oct-85 13:31:08-EDT Date: Wed, 23 Oct 85 13:32 EDT From: David A. Moon Subject: WITHOUT-INTERRUPTS To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 23 Oct 85 11:28-EDT from greek@DEC-HUDSON Message-ID: <851023133207.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I seem to have come in in the middle of this discussion. Perhaps there was some earlier mail that I missed for some reason. I think WITHOUT-INTERRUPTS, or any other multiprocessing primitive, is much too implementation-dependent to be appropriate for the portable Common Lisp language. I don't see any point in discussing it, because there is no possible primitive that will meet the needs of all multiprocessing implementation techniques. Date: Wed, 23 Oct 85 11:28:22 EDT From: greek@DEC-HUDSON On a simple processor running a LISP without its own tasking or interrupts, it would be a nop. With interrupts, it would lock them out. With tasks, it would also prevent task switches. On a multiprocessor it might also do some kind of memory lockout to prevent the other processors from stomping on things. So what we have is that on some uniprocessors WITHOUT-INTERRUPTS or CRITICAL-SECTION, it matters not at all what you call it, is meaningless, on other uniprocessors it makes sense, and on large multiprocessors it is so expensive to implement that no one will ever use it. If instead you decide to make a primitive that specifies more precisely what synchronization is required, so that the implementation will not be so expensive, you will have to build in assumptions about some particular multiprocessor architecture. There are an enormous number of possible architectures, many of them advocated as the best by people of strong convictions, and no agreement at present on unifying general principles. Who knows -- and that's exactly the point. Mine too. This issue is simply outside the scope of what Common Lisp can hope to address.  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 16:37:27 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 11:10:08 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339615; Wed 23-Oct-85 14:07:38-EDT Date: Wed, 23 Oct 85 14:08 EDT From: David A. Moon Subject: WITHOUT-INTERRUPTS To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 23 Oct 85 13:25-EDT from greek@DEC-HUDSON.ARPA Message-ID: <851023140830.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 23 Oct 85 13:25:24 EDT From: greek@DEC-HUDSON Mr. Greenberg is certainly correct when he says we don't understand all the locking mechanisms that exist. However, unless I'm off base here, it seems to me that CRITICAL-SECTION could be specified as locking out ANY possible contention from other tasks, interrupt handlers, processors, etc. If a particular implementation needs additional kinds of locking macros, they can add them. Perhaps we should define CRITICAL-SECTION as follows: CRITICAL-SECTION (&key options) &body body and say that, without options, it locks out "everything". On the other hand, perhaps "everything" is simply too nebulous. Let me just ask you to think about one thing and then I promise not to send any more mail. In Lisp on VAX/VMS, will CRITICAL-SECTION stop VMS from scheduling any processes that have shared global sections mapped into their address space that are also mapped into the address space of this Lisp?  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 16:25:28 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 Oct 85 12:58:35 PDT Date: Wed, 23 Oct 85 16:04:59 EDT From: greek@DEC-HUDSON Subject: WITHOUT-INTERRUPTS To: common-lisp@su-ai I too promise that this is my last message. Mr. Moon is right -- VMS certainly couldn't promise to lock out other processes that might touch a shared section. Somehow that doesn't bother me, however. We can't worry about other processes that have nothing to do with LISP -- that's too implementation specific. Yeah, sure, this is getting ridiculous. I begin to agree that WITHOUT-INTERRUPTS is hopeless for a portable language. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Oct 85 16:10:46 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 Oct 85 09:47:37 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 339514; Wed 23-Oct-85 12:25:47-EDT Date: Wed, 23 Oct 85 12:31 EDT From: Bernard S. Greenberg Subject: WITHOUT-INTERRUPTS To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 23 Oct 85 11:28-EDT from greek@DEC-HUDSON.ARPA Message-ID: <851023123157.6.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed, 23 Oct 85 11:28:22 EDT From: greek@DEC-HUDSON Mr. Greenberg has pointed out that I've only hidden the problem by suggesting CRITICAL-SECTION instead of WITHOUT-INTERRUPTS. That's exactly what I intended to do. WITHOUT-INTERRUPTS is too specific, and deals only with interrupt questions, not with memory lockout or other strange things that may occur on multiprocessors. CRITICAL-SECTION, I believe, suggests what it is that we are trying to accomplish, without being specific. On a simple processor running a LISP without its own tasking or interrupts, it would be a nop. With interrupts, it would lock them out. With tasks, it would also prevent task switches. On a multiprocessor it might also do some kind of memory lockout to prevent the other processors from stomping on things. Who knows -- and that's exactly the point. As you hint in the next paragraph, it's not a question of "who knows", but an issue of different kinds of outlocking being appropriate at different times, on a more complicated system Perhaps the problem is that there are so many classes of things we want to lock out that we need multiple macros or options to the one macro. Exactly, if we decide that the problem has to be addressed by the language at all. Unless CRITICAL-SECTION has a bunch of options, it addresses -no- problems. It is not clear to me that the conceptual options can be stated in a system-independent way. I am not willing to say that I know about all the tasking and processor-sharing paradigms that have been, or might be invented. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Oct 85 22:15:55 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 22 Oct 85 15:50:26 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 22 Oct 85 12:41:38 edt Date: Tue, 22 Oct 85 12:43 EDT From: Guy Steele Subject: Report on trip to Japan To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <851022124308.1.GLS@THINK-DESIDERIUS.ARPA> Well, my face is red. I did not get to Japan after all. When I presented my passport at the airport gate in Seattle, I was informed that the passport contained no visa for travel to Japan. Japan requires that a visa be obtained in advance of travel. I didn't know this (none of the European countries I have visited has required a visa), and none of the many people helping me (and who did many other things to make the trip possible) thought to advise me to get a visa. My problem occurred on a Saturday morning, and no Japanese consulate would be open until Monday, which would be too late; and so my trip was cancelled. Too bad. This is especially disappointing to me as I had hoped to have some discussions about means of international cooperation in the development of Common Lisp. I may be able to try again next spring. Nevertheless, I am grateful to all of you who supplied me with implementation data for the survey I conducted in preparation for the trip. I think the survey was well worth doing. I have distributed it to this mailing list. Since then a couple more entries have come in, and I will distribute this addendum in a few days. (Any more out there?) It was suggested to me that it might be useful to publish this survey in some forum such as SIGPLAN Notices or the SIGART newsletter. However, I made a specific statement up front about the uses to which I would put the collected data, and I would not feel right about publishing it without first checking back with all of you who supplied the data. Questions: (1) Do you feel it would be useful to publish the collected survey data? (2) If you supplied data, would you consent to using the data for this purpose? (Perhaps you may wish to supply a corrected version now that you have seen all the entries together?) There remains the question of whether such a journal would wish to publish the list, but that's another matter.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Oct 85 19:06:36 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 22 Oct 85 15:50:26 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Tue, 22 Oct 85 12:41:38 edt Date: Tue, 22 Oct 85 12:43 EDT From: Guy Steele Subject: Report on trip to Japan To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <851022124308.1.GLS@THINK-DESIDERIUS.ARPA> Well, my face is red. I did not get to Japan after all. When I presented my passport at the airport gate in Seattle, I was informed that the passport contained no visa for travel to Japan. Japan requires that a visa be obtained in advance of travel. I didn't know this (none of the European countries I have visited has required a visa), and none of the many people helping me (and who did many other things to make the trip possible) thought to advise me to get a visa. My problem occurred on a Saturday morning, and no Japanese consulate would be open until Monday, which would be too late; and so my trip was cancelled. Too bad. This is especially disappointing to me as I had hoped to have some discussions about means of international cooperation in the development of Common Lisp. I may be able to try again next spring. Nevertheless, I am grateful to all of you who supplied me with implementation data for the survey I conducted in preparation for the trip. I think the survey was well worth doing. I have distributed it to this mailing list. Since then a couple more entries have come in, and I will distribute this addendum in a few days. (Any more out there?) It was suggested to me that it might be useful to publish this survey in some forum such as SIGPLAN Notices or the SIGART newsletter. However, I made a specific statement up front about the uses to which I would put the collected data, and I would not feel right about publishing it without first checking back with all of you who supplied the data. Questions: (1) Do you feel it would be useful to publish the collected survey data? (2) If you supplied data, would you consent to using the data for this purpose? (Perhaps you may wish to supply a corrected version now that you have seen all the entries together?) There remains the question of whether such a journal would wish to publish the list, but that's another matter.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Oct 85 18:56:51 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Oct 85 15:34:38 PDT Date: Tue, 22 Oct 85 12:45:43 EDT From: greek@DEC-HUDSON Subject: WITHOUT-INTERRUPTS To: common-lisp@su-ai I think if we abandon the name WITHOUT-INTERRUPTS, which has all kinds of vague conotations, and adopt the name CRITICAL-SECTION, we might get further in understanding what it ought to do. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Oct 85 19:22:50 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Oct 85 16:17:08 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 335376; Wed 16-Oct-85 19:19:19-EDT Date: Wed, 16 Oct 85 19:18 EDT From: Robert W. Kerns Subject: SETF of pathname components To: Glenn S. Burke cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].680489.851015.GSB> Message-ID: <851016191817.5.RWK@CROW.SCRC.Symbolics.COM> Date: Tue, 15 Oct 85 18:23:24 EDT From: Glenn S. Burke Date: Tue, 15 Oct 85 15:25 EDT From: Robert W. Kerns For uniformity we could extend this to other read-only accessors like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as useful in the former case, and it's pretty strange in the later (and probably indicative of a woefully ineffecient program). I agree with Moon's analysis, but i disagree that on these grounds SETF should handle pathname components like LDB handles integers. I don't think pathnames appear to be sufficiently non-structured that the read-only-ness of the components should be taken advantage of in order to permit this hack. I didn't understand this at first, but let me take a stab at guessing (and explaining) what you mean. SETF of LDB replies on the fact that you "obviously" can't store into integers to make it clear that the side effect must be happening not to the integer but to the location containing the integer. However, using the "SETF of LDB" technique can be confusing: Consider what happens when you have, say, a pathname, stored in two variables *FOO* and *BAR*. You do (SETQ *FOO* (SETQ *BAR* (MAKE-PATHNAME :HOST "CROW"))) (SETF (PATHNAME-NAME *FOO*) "YOW") What would you expect (PATHNAME-NAME *BAR*) to return? In this regard, I guess SETF of LDB is a wart on the language, really an entirely different syntactic entity using the same syntax. Expanding this overlap can only add to the problem. The same goes for symbol-name. As for denominator, it sounds sufficiently ludicrous that i think it also should be left out, but only because it seems perverse. Actually, I think my interpretation of your argument above applies here, too. Is this what you were arguing?  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Oct 85 15:05:14 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Oct 85 11:57:38 PDT Date: Wed, 16 Oct 85 14:56:42 EDT From: Alan Bawden Subject: TAGBODY To: DLW@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].681476.851016.ALAN> Date: Wed, 16 Oct 85 13:22 EDT From: Daniel L. Weinreb Subject: TAGBODY There was some recent discussion of TAGBODY among a few of us here, and I'd like to pass along the gist of it to the full Common-Lisp mailing list. ... The problem is that TAGBODY is defined to always return NIL.... So there's no elegant way to make your new special form return its useful value. As far as we can tell, you are forced to GENSYM a block name and establish a block around the TAGBODY. Since the whole idea of TAGBODY was to let you get at tags and go-to's without establishing a block, this seems somewhat inelegant. As I recall it, the point was that TAGBODY let you have tags and go's without establishing -unnamed- blocks (the kind that plain RETURN would return from). And I don't see any problem with gensyming up a tag myself. Especially since I, at least, think of TAGBODY as something for macros to expand into, rather than as something that appears directly in source code. Had TAGBODY been defined to return the value of its last form, this problem would be solved. Anyone who wanted the current behavior could always just write (PROGN (TAGBODY ...) NIL). It's easy to write the existing TAGBODY in terms of the alternative one; unfortunately, it's hard to write the alternative one in the current language. The problem with defining TAGBODY to return the value of its last form is that there isn't always a last form. What is the value of: (tagbody (princ "dog") (if (= x 1) (go done)) (princ "s") done) After you all have finished arguing about whether this -particular- case should return NIL, T, no values, or whatever, I'll opine that I liked the original simpler definition much better. I consider this a good example of what can happen if you introduce a new, untested idea into a language standard. This particular case is not the world's biggest problem, but I hope it illustrates how hard it is to design a language feature in your head, and I hope it makes everyone think twice before we standardize on more untested ideas. Yes indeed, it does seem to be hard to understand the consequences of anything in your head.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Oct 85 14:52:40 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Oct 85 11:43:12 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 335022; Wed 16-Oct-85 14:40:34-EDT Date: Wed, 16 Oct 85 14:40 EDT From: David A. Moon Subject: TAGBODY To: Common-Lisp@SU-AI.ARPA In-Reply-To: <851016132223.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <851016144055.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Just for the record, I do not agree that the alternate definition of TAGBODY would be better. It invites confusion between the last thing in the body being a GO tag and the last thing in the body being a variable whose value is to be returned. Perhaps when Steele returns from travelling he will remind us what the motivation was; unfortunately the motivation did not get included in the book. I don't think it's necessary to start a long discussion about this.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Oct 85 13:45:59 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Oct 85 10:35:59 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334993; Wed 16-Oct-85 13:21:34-EDT Date: Wed, 16 Oct 85 13:22 EDT From: Daniel L. Weinreb Subject: TAGBODY To: common-lisp@SU-AI.ARPA Message-ID: <851016132223.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI There was some recent discussion of TAGBODY among a few of us here, and I'd like to pass along the gist of it to the full Common-Lisp mailing list. The logic behind introducing TAGBODY into Common Lisp was to separate out the pieces of what PROG does, so that these pieces would be individually available to programmers, and to macro-writers in particular. PROG was broken up into three components: one to handle the variable binding, one to handle the creation of the block, and one to handle the tags and go-to's. The intention was to let programmers build new special forms that had some of the traits of PROG but not all of them. So far, so good. Now, suppose you want to write a special form that does handle tags and go-to's, and returns a useful value, but does not establish a named block. There appears to be no elegant way to do this. The problem is that TAGBODY is defined to always return NIL. Unlike any other special form in the language, TAGBODY neither sets up a block nor returns the value of the last form in its body. So there's no elegant way to make your new special form return its useful value. As far as we can tell, you are forced to GENSYM a block name and establish a block around the TAGBODY. Since the whole idea of TAGBODY was to let you get at tags and go-to's without establishing a block, this seems somewhat inelegant. Had TAGBODY been defined to return the value of its last form, this problem would be solved. Anyone who wanted the current behavior could always just write (PROGN (TAGBODY ...) NIL). It's easy to write the existing TAGBODY in terms of the alternative one; unfortunately, it's hard to write the alternative one in the current language. I consider this a good example of what can happen if you introduce a new, untested idea into a language standard. This particular case is not the world's biggest problem, but I hope it illustrates how hard it is to design a language feature in your head, and I hope it makes everyone think twice before we standardize on more untested ideas.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Oct 85 18:33:08 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 15:20:25 PDT Date: Tue, 15 Oct 85 18:23:24 EDT From: Glenn S. Burke Subject: SETF of pathname components To: RWK@SCRC-YUKON.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].680489.851015.GSB> Date: Tue, 15 Oct 85 15:25 EDT From: Robert W. Kerns . . . For uniformity we could extend this to other read-only accessors like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as useful in the former case, and it's pretty strange in the later (and probably indicative of a woefully ineffecient program). I agree with Moon's analysis, but i disagree that on these grounds SETF should handle pathname components like LDB handles integers. I don't think pathnames appear to be sufficiently non-structured that the read-only-ness of the components should be taken advantage of in order to permit this hack. The same goes for symbol-name. As for denominator, it sounds sufficiently ludicrous that i think it also should be left out, but only because it seems perverse.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Oct 85 15:57:44 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 12:47:29 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334265; Tue 15-Oct-85 15:26:34-EDT Date: Tue, 15 Oct 85 15:25 EDT From: Robert W. Kerns Subject: Re: pathnames. To: Richard L. Bryan cc: Moon@SCRC-STONY-BROOK.ARPA, schumacher%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <851015142135.3.RLB@PETREL.SCRC.Symbolics.COM> Message-ID: <851015152519.4.RWK@CROW.SCRC.Symbolics.COM> Date: Tue, 15 Oct 85 14:21 EDT From: Richard L. Bryan Perhaps SETF of pathname components should work the same way as SETF of LDB. As former pathnamemeister for Symbolics (theoretically retired) I concur with Moon's analysis and RLB's suggestion. For uniformity we could extend this to other read-only accessors like SYMBOL-NAME, and DENOMINATOR although it's hard to see it as useful in the former case, and it's pretty strange in the later (and probably indicative of a woefully ineffecient program).  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Oct 85 14:32:16 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Oct 85 11:19:31 PDT Received: from PETREL.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 334182; Tue 15-Oct-85 14:21:51-EDT Date: Tue, 15 Oct 85 14:21 EDT From: Richard L. Bryan Subject: Re: pathnames. To: Moon@SCRC-STONY-BROOK.ARPA, schumacher%hplabs.csnet@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <851011232700.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <851015142135.3.RLB@PETREL.SCRC.Symbolics.COM> Date: Fri, 11 Oct 85 23:27 EDT From: David A. Moon Date: Friday, October 11, 1985 08:53:50 From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA Date: Thu, 10 Oct 85 20:42 EDT From: "David C. Plummer" Date: Thu 10 Oct 85 16:06:07-PDT From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA The manual doesn't state explicitly that the accessor functions for pathname objects are setf'able. Is this an oversight on my part, the manuals part, or is there some justification for this. Admittedly the desired effect can be achieved using make-pathname with the current pathname as the :default and the desired change specified as a keyword arg, but this seems sort of strange ... Symbolics interns our pathnames. Is SYMBOL-NAME setf'able? I'm not sure I understand this statement (question?). Are you interning the namestring of the pathname ? Perhaps I should have been more specific: given a path name (setq foo (pathname "foo.bar")) I want to change the type field of pathname foo to be "jnk". Is it legal cl to say (setf (pathname-type foo) "jnk") ? If this isn't legal then it seems that the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)). Is that any clearer ? Perhaps I can clarify. In Common Lisp it is not legal to change the components of a pathname, for the same reasons that it is not legal to change the name of a symbol and not legal to change the denominator of a ratio. In Symbolics' implementation, every time you ask for a pathname with the same components, you get the same object, so that pathname equality can be tested with EQ. This is what DCP was pointing out. However, this is irrelevant. Even in a system that didn't "intern" or "canonicalize" pathnames in this way, it would be inappropriate to perform side-effects on a pathname because it might be in use by someone else. That's the basis for the language design; unfortunately it isn't explained in the manual. You're correct that the way to get a pathname that is like another pathname but with one component different is to call make-pathname. Perhaps SETF of pathname components should work the same way as SETF of LDB.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Oct 85 23:33:51 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 20:25:09 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 332541; Fri 11-Oct-85 23:28:00-EDT Date: Fri, 11 Oct 85 23:27 EDT From: David A. Moon Subject: Re: pathnames. To: schumacher%hplabs.csnet@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <8510111617.AA04620@HP-VENUS> Message-ID: <851011232700.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Friday, October 11, 1985 08:53:50 From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA Date: Thu, 10 Oct 85 20:42 EDT From: "David C. Plummer" Date: Thu 10 Oct 85 16:06:07-PDT From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA The manual doesn't state explicitly that the accessor functions for pathname objects are setf'able. Is this an oversight on my part, the manuals part, or is there some justification for this. Admittedly the desired effect can be achieved using make-pathname with the current pathname as the :default and the desired change specified as a keyword arg, but this seems sort of strange ... Symbolics interns our pathnames. Is SYMBOL-NAME setf'able? I'm not sure I understand this statement (question?). Are you interning the namestring of the pathname ? Perhaps I should have been more specific: given a path name (setq foo (pathname "foo.bar")) I want to change the type field of pathname foo to be "jnk". Is it legal cl to say (setf (pathname-type foo) "jnk") ? If this isn't legal then it seems that the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)). Is that any clearer ? Perhaps I can clarify. In Common Lisp it is not legal to change the components of a pathname, for the same reasons that it is not legal to change the name of a symbol and not legal to change the denominator of a ratio. In Symbolics' implementation, every time you ask for a pathname with the same components, you get the same object, so that pathname equality can be tested with EQ. This is what DCP was pointing out. However, this is irrelevant. Even in a system that didn't "intern" or "canonicalize" pathnames in this way, it would be inappropriate to perform side-effects on a pathname because it might be in use by someone else. That's the basis for the language design; unfortunately it isn't explained in the manual. You're correct that the way to get a pathname that is like another pathname but with one component different is to call make-pathname.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Oct 85 19:00:28 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 15:49:11 PDT Received: from hplabs by csnet-relay.csnet id ag23808; 11 Oct 85 18:38 EDT Received: by HP-VENUS id AA04620; Fri, 11 Oct 85 09:17:59 pdt Message-Id: <8510111617.AA04620@HP-VENUS> Date: Friday, October 11, 1985 08:53:50 From: schumacher%hplabs.csnet@CSNET-RELAY.ARPA Subject: Re: pathnames. To: hplabs!DCP%scrc-quabbin.arpa@csnet-relay.arpa Cc: common-lisp@su-ai.arpa In-Reply-To: Your message of 10-Oct-85 20:42:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Source-Info: From (or Sender) name not authenticated. Date: Thu, 10 Oct 85 20:42 EDT From: "David C. Plummer" Date: Thu 10 Oct 85 16:06:07-PDT From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA The manual doesn't state explicitly that the accessor functions for pathname objects are setf'able. Is this an oversight on my part, the manuals part, or is there some justification for this. Admittedly the desired effect can be achieved using make-pathname with the current pathname as the :default and the desired change specified as a keyword arg, but this seems sort of strange ... Symbolics interns our pathnames. Is SYMBOL-NAME setf'able? I'm not sure I understand this statement (question?). Are you interning the namestring of the pathname ? Perhaps I should have been more specific: given a path name (setq foo (pathname "foo.bar")) I want to change the type field of pathname foo to be "jnk". Is it legal cl to say (setf (pathname-type foo) "jnk") ? If this isn't legal then it seems that the only way to do this is (setq foo (make-pathname :type "jnk" :defaults foo)). Is that any clearer ? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Oct 85 15:52:36 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 12:42:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 332245; Fri 11-Oct-85 15:32:50-EDT Date: Fri, 11 Oct 85 15:32 EDT From: David A. Moon Subject: oversight? To: wagner@GSWD-VMS.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Oct 85 10:47-EDT from wagner@GSWD-VMS Message-ID: <851011153205.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 11 Oct 85 09:47:43 CDT From: wagner@GSWD-VMS On page 418 of CLtL, concerning the OPEN function: "The filename ...may be a string, a pathname, or a stream." May it not also be a symbol, and shouldn't the spec say so? Same for WITH-OPEN-FILE, etc.? (The underlying pathname functions work with symbols.) It's true that most places in the manual say that symbols are acceptable where pathnames are required, and are parsed as namestrings. I don't understand why this feature is in there; it seems like asking for trouble. What about implementations (yes they exist) where some streams are implemented as symbols? How do you tell whether a symbol was supposed to be a stream or supposed to be a string? What if NIL is accidentally used where a pathname was expected, do you really want to get a file named "NIL"? It's possible that the feature of allowing symbols as pathnames was blindly copied from an old version of Zetalisp, which used to allow that. A couple of bad ideas got into Common Lisp that way, in spite of significant effort by the committee to try to keep it from happening. Zetalisp allowed symbols for compatibility with an old version of pdp-10 Maclisp that didn't have strings.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Oct 85 10:58:51 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 11 Oct 85 07:48:00 PDT Date: Fri, 11 Oct 85 09:47:43 CDT From: wagner@GSWD-VMS Subject: oversight? To: common-lisp@su-ai.arpa Cc: wagner On page 418 of CLtL, concerning the OPEN function: "The filename ...may be a string, a pathname, or a stream." May it not also be a symbol, and shouldn't the spec say so? Same for WITH-OPEN-FILE, etc.? (The underlying pathname functions work with symbols.) Fran Wagner Gould CSD-Urbana  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Oct 85 20:50:01 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 17:39:20 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 331605; Thu 10-Oct-85 20:42:16-EDT Date: Thu, 10 Oct 85 20:42 EDT From: David C. Plummer Subject: pathnames. To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA cc: freeze@hplabs.CSNET In-Reply-To: <8510102306.AA02649@HP-VENUS> Message-ID: <851010204203.2.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Thu 10 Oct 85 16:06:07-PDT From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA The manual doesn't state explicitly that the accessor functions for pathname objects are setf'able. Is this an oversight on my part, the manuals part, or is there some justification for this. Admittedly the desired effect can be achieved using make-pathname with the current pathname as the :default and the desired change specified as a keyword arg, but this seems sort of strange ... Symbolics interns our pathnames. Is SYMBOL-NAME setf'able?  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Oct 85 20:39:05 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 17:26:41 PDT Received: from hplabs by csnet-relay.csnet id ac14781; 10 Oct 85 20:25 EDT Received: by HP-VENUS id AA02649; Thu, 10 Oct 85 16:06:27 pdt Message-Id: <8510102306.AA02649@HP-VENUS> Date: Thu 10 Oct 85 16:06:07-PDT From: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA Subject: pathnames. To: common-lisp@su-ai.arpa Cc: freeze@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. The manual doesn't state explicitly that the accessor functions for pathname objects are setf'able. Is this an oversight on my part, the manuals part, or is there some justification for this. Admittedly the desired effect can be achieved using make-pathname with the current pathname as the :default and the desired change specified as a keyword arg, but this seems sort of strange ... Lee Schumacher -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Oct 85 20:19:12 EDT Received: from TOVE.UMD.EDU by SU-AI.ARPA with TCP; 10 Oct 85 17:05:23 PDT  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Oct 85 08:36:33 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Oct 85 05:28:10 PDT Date: Thu, 10 Oct 85 08:31:06 EDT From: George J. Carrette Subject: Response to CL Meeting Announcement To: RPG@SU-AI.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 09 Oct 85 1018 PDT from Dick Gabriel Message-ID: <[MIT-MC.ARPA].674959.851010.GJC> I think parallel sessions are fine as long as there are not more than two at once.  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Oct 85 13:34:10 EDT Date: 09 Oct 85 1018 PDT From: Dick Gabriel Subject: Response to CL Meeting Announcement To: common-lisp@SU-AI.ARPA Friends: There has been some concern expressed about parallel sessions. When you respond to me regarding the proposed schedule, please also indicate your preference for parallel sessions over 2 days versus sequential sessions over 3 days. Also, would the week after December 5 - namely, December 9, 10, 11 - be open for you as well? Some people mentioned a problem with December 5 and 6. Thank you. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Oct 85 12:29:00 EDT Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 8 Oct 85 09:17:17 PDT Date: 8 Oct 1985 12:18-EDT Sender: OLDMAN@USC-ISI.ARPA Subject: UNIX terminal io incompatibility From: OLDMAN@USC-ISI.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[USC-ISI.ARPA] 8-Oct-85 12:18:11.OLDMAN> Data General Common LISP also has redirectable output. execute lisp/I=infile/O=outfile/E=errorfile The presence of any of these switches causes the default bindings of the standard streams to change. *terminal-io* is still attached to the console if one is available. If one is not available (such as when you are running in batch mode), we have a slightly crazy set of rules that "do the right thing". -- Dan Oldman  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Oct 85 14:11:57 EDT Date: 07 Oct 85 1054 PDT From: Dick Gabriel To: common-lisp@SU-AI.ARPA, Squires@USC-ISI.ARPA, Ohlander@USC-ISI.ARPA Common Lisp Meeting Here is a summary of the responses I got to the suggestion of a Common Lisp meeting and some suggestions I have on its organization: 1. The meeting will be held either at MIT or at a local convention center in the Boston Area. 2. The meeting will last 2 days. 3. The dates are, Thursday and Friday, Decemeber 5 and 6. 4. The schedule of events will be: Thurs 8:30am Welcome, registration, and coffee 9:00am Charter Discussion Noon Lunch (brought in) [Informal discussion and lobbying] 1:00pm Charter Discussion Fri 8:30am Coffee 9:00am Parallel discussions on: Object-oriented programming Errors Validation ANSI Windows Noon Lunch (brought in) 1:00pm Parallel Discussion 5:00pm Hit the Road During the Charter discussion, the following topics will be discussed: Inclusion of the recent minor changes and errata to the Common Lisp specification Methods for updating the book (second edition) Publishing problems - some vendors wish to have a language manual for their Common Lisp and desire to publish it themselves. Making decisions during the parallel sessions on Friday Administrative format of validation * * * Suggested Administrative Format of the Charter Discussion [Please note: these are my suggestions and do not represent an edict.] At the start of each session, including the Charter session, the chairman of the committee will review the state of the discussion under his purview. Each organization - company or university - doing an implementation of Common Lisp may send 2 representatives who can comment and vote during the Charter discussion. Each organization representing a significant user community may send 1 individual who can comment and vote during the Charter discussion. Interested individuals of standing in the Lisp community may also attend and vote; however, some votes may be taken in which implementors only may vote. In addition, each organization doing an implementation may send 2 people to each of the parallel discussions, but only 1 of those may vote. Each organization representing a significant user community may send 1 person to each of the parallel discussions. Individuals may attend the parallel discussions, but they might be restricted from voting in some cases as in the Charter Discussion. Each discussion will be run approximately according to Robert's Rules of Order to keep things under control. I assume only Guy Steele knows these rules, so perhaps he should help run the Charter discussion so that the other chairmen will learn how to do it. I know this sounds silly, but remember the madhouse at Monterey. I would like to get a list of the proposed attendees for planning purposes. I would also like to solicit one of our friends for the Boston Area to arrange for the meeting rooms. Once I have a count of attendees, I will pass the information on to that person. I propose that the meeting rooms, morning coffee, and the lunches be paid for by DARPA. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Oct 85 18:57:58 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Oct 85 15:48:34 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 327115; Fri 4-Oct-85 18:49:36-EDT Date: Fri, 4 Oct 85 18:48 EDT From: Daniel L. Weinreb Subject: implicit blocks To: common-lisp@SU-AI.ARPA cc: BSG@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, Margulies@SCRC-YUKON.ARPA, mbell@SCRC-YUKON.ARPA, bug-compiler@SCRC-YUKON.ARPA Message-ID: <851004184805.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI From our reading of the manual, it appears that while functions defined by DEFUN have an implicit BLOCK around them, functions defined by FLET and LABELS do not. Several people here have been discussing this, and the concensus seems to be that FLET and LABELS functions really ought to set up such a block implicitly, both for uniformity with DEFUN and for the same reasons that DEFUN does so in the first place. I don't recall ever hearing this issue discussed. I don't think that omitting the implicit BLOCK from FLET and LABELS was intentional. If I'm wrong about these points, please let me know. If we develop a procedure for making small language definition changes, I think this one ought to be made. Fortunately, it seems highly unlikely that the change would break any existing programs.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Oct 85 22:20:51 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Oct 85 19:07:46 PDT Received: ID ; Thu 3 Oct 85 22:08:40-EDT Date: Thu, 3 Oct 1985 22:08 EDT Message-ID: From: Rob MacLachlan To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: Without-Interrupts In-reply-to: Msg of 3 Oct 1985 17:54-EDT from David C. Plummer It is true that WITHOUT-INTERRUPTS could mean a number of things, but that doesn't mean that it has no place in portable code. The primary use is in protecting code which modifies data structures so that the update appears atomic as far as the user is concerned. No matter where he types ^G, the data structures of his program won't get trashed. Although Common Lisp doesn't require asynchronous interrupts from the user, any reasonable implementation will have them, and good software must deal with that fact somehow. Note that Common Lisp only defines a single-thread environment, thus the behavior of WITHOUT-INTERRUPTS in a multiple-thread Lisp implementation wouldn't be a proper part of its Common Lisp specification. In a multi-thread environment, it should probably freeze out all other threads during the execution of the body. This makes it very expensive in a multiprocessor, and therefore probably useless, but then nobody ever said that writing software for a multiprocessor was easy. I believe that the Lisp machine interpretation is about right, although it is silly to talk about "inhibiting scheduling" in a single-thread implementation. WITHOUT-INTERRUPTS shouldn't have anything to do with real hardware interrupts, it affects "software interrupts". Although some systems might get upset if you ran without interrupts for minutes, programmers who use WITHOUT-INTERRUPTS in a "reasonable" fashion shouldn't have to worry about trashing the system. WITHOUT-INTERRUPTS should nest properly, which means that (without-interrupts xxx) can't turn into (interrupts-off) xxx (interrupts-on) Spice Lisp (and Zetalisp, I believe), implement WITHOUT-INTERRUPTS by binding a special variable which the low-level interrupt handling mechanism looks at before deciding to actually service an interrupt. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Oct 85 18:19:40 EDT Date: 03 Oct 85 1436 PDT From: System Files Subject: Arguments and values to get. Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 14:36:29 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207346; Thu 3-Oct-85 17:40:11-EDT Date: Thu, 3 Oct 85 17:39 EDT From: David C. Plummer Subject: Arguments and values to get. To: Gregor.pa@XEROX.ARPA, Scott E. Fahlman , Kent M Pitman , Common-Lisp@SU-AI.ARPA cc: cl-object-oriented-programming@SU-AI.ARPA In-Reply-To: <850919-174345-1059@Xerox>, , <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <851003173940.1.DCP@NEPONSET.SCRC.Symbolics.COM> Consider (incf (get foo bar)) when the property does not exist. INCF would die adding to NIL. Thus, to maintain simple style, you need (incf (get foo bar 0)) I think this is a LOT prettier than (setf (get foo bar) (multiple-value-bind (value valid-p) (get foo bar) (if valid-p (1+ value) 1))) and the programmer doesn't have to worry about multiple evaluation of FOO and BAR, since INCF is supposed to take care of that.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Oct 85 18:18:28 EDT Date: 03 Oct 85 1451 PDT From: System Files Subject: Discouraged programming practices Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 14:50:55 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 207354; Thu 3-Oct-85 17:54:34-EDT Date: Thu, 3 Oct 85 17:54 EDT From: David C. Plummer Subject: Discouraged programming practices To: Rob MacLachlan , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851003175412.2.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 25 Sep 1985 22:12 EDT From: Rob MacLachlan Another discouraged programming practice is to write (without-interrupts (loop)) as it may be difficult to terminate the execution of this form. WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be. :-)? On the serious side, what exactly does WITHOUT-INTERRUPTS mean? Does it mean WITHOUT-SCHEDULING, as it does on a variety of Lisp Machines? Does it mean WITHOUT-SCHEDULING-AND-WITHOUT-IO-DEVICES, which is what it could mean on a 68000, PDP-11 or variety of other machines. Does it mean WITHOUT-OPERATING-SYSTEM (which on a time sharing system would be very anti-social). On a multi-processor (tightly coupled, loosely coupled, or in between doesn't matter), does it mean some of the above for the processor executing it, or does it mean WITHOUT-ANY-OTHER-PROCESSOR. Does spawning of sub-tasks to other processors inherit the WITHOUT-INTERRUPTS. In other words, WITHOUT-INTERRUPTS is much to vague to put in Common Lisp.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Oct 85 18:16:35 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 3 Oct 85 15:04:08 PDT Date: Thu, 03 Oct 85 17:03:50 CDT From: wagner@GSWD-VMS Subject: CLtL binding To: common-lisp@su-ai.arpa Cc: wagner Concerning binding...no, not of variables, of the book! My copy of CLtL is falling apart after a few months of hard use because of the "perfect" binding. I'd pay a few extra dollars for sewn signatures in the next edition. Fran Wagner Gould CSD-Urbana  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Oct 85 21:10:17 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 18:00:29 PDT Received: from MIT-CCC by MIT-MC.ARPA via Chaosnet; 2 OCT 85 20:15:04 EDT Date: 2 Oct 1985 19:47:40-EDT From: uucp@MIT-CCC From gjc@cap Wed Oct 2 15:05:08 1985 remote from LMI-CAPRICORN Received: from LMI-LAMBDA-6 by LMI-LAMBDA-3 with CHAOS-MAIL; Wed 2-Oct-1985 15:03:28-EDT Date: Wednesday, 2 October 1985, 15:03-EDT From: George Carrette Subject: lisp listings To: mitccc!common-lisp%su-ai%mc@cap I'll send this directly to the whole mailing list to give people a chance to point out anything I've left out. Here are two listings: (1) MIT-LISPMACHINE SYSTEM, or MIT-ZETALISP, MIT-SYSTEM 99 (2) implemented at MIT AI LAB (3) MIT-CADR, LMI-CADR, SYMBOLICS-LM2 (4) now (5) full (6) in fact a couple numerical functions such as complex ACOS seem to be missing. (7) no commercial support. (8) Systemic: Flavors, ZMACS editor, chaosnet protocols on chaos or ethernet hardware. File-System. Applications: check through the AI LAB memos. (1) ZETALISP-PLUS(tm) (2) Lisp Machine Inc. (3) LMI-LAMBDA(tm), LMI-LAMBDA-E(tm), TI-EXPLORER(tm). (4) now. (5) full. (7) Lisp Machine Inc 6 Tech Drive Andover MA 01810 671-689-3554, or 1-800-USA-LISP for customer service. (8) Systemic: Flavors, ZMACS editor, chaosnet and tcp-ip protocols on ethernet hardware. File-System. ObjectLisp(tm) alternative object oriented programming system. Applications: PICON(tm) Industrial Process Control System. DOE-MACSYMA, symbolic algebra system. VISTA(tm) 3-D generic graphics system and window-system extensions implemented in ObjectLisp(tm). KEE(tm), ART(tm). The applications are of course mainly in the Zetalisp we all know and loved, so even though one could come up with an impressively long list of lispmachine software applications that could be misleading, in that that not all those applications were in fact in "Common-Lisp." The ObjectLisp(tm) package is the closest (Objectlisp(tm) uses LOOP at this time) to being common lisp, running on the Symbolics, LMI, and MIT VAX-NIL implementations.  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Oct 85 18:15:32 EDT Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 2 Oct 85 15:04:26 PDT Received: by glacier with Sendmail; Wed, 2 Oct 85 15:03:59 pdt Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7) id AA03750; Wed, 2 Oct 85 14:35:10 pdt Received: by escargot.UUCP (4.12/4.7) id AA00772; Wed, 2 Oct 85 14:33:32 pdt Date: Wed, 2 Oct 85 14:33:32 pdt From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8510022133.AA00772@escargot.UUCP> To: gls@THINK-AQUINAS.ARPA Cc: common-lisp@SU-AI.ARPA In-Reply-To: Guy Steele's message of Wed, 2 Oct 85 11:09 EDT Subject: Another printing bug in CLtL Now that a few common lisp implementations exist, maybe someone should take all the examples in the book and execute them. This wasn't possible when the book was written, but it is now...  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Oct 85 17:36:28 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 2 Oct 85 08:08:40 PDT Received: from yon by GODOT.THINK.COM via CHAOS; Wed, 2 Oct 85 11:09:52 edt Date: Wed, 2 Oct 85 11:09 EDT From: Guy Steele Subject: Another printing bug in CLtL To: Steiner@RED.RUTGERS.EDU, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 2 Oct 85 02:33-EDT from Dave Message-Id: <851002110940.1.GLS@YON.THINK.COM> Date: 2 Oct 85 02:33:00 EDT From: Dave On p. 396 in the examples of using ~G for format, one of the examples is: (foo 3.14E12) => "*********|314.2$+10|0.314E+13| 3.14L+12" ^ ^ | | | shouldn't this be E? | shouldn't this be a 0? ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS ------- Right you are. Thank you very much. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Oct 85 02:42:07 EDT Received: from RED.RUTGERS.EDU by SU-AI.ARPA with TCP; 1 Oct 85 23:33:14 PDT Date: 2 Oct 85 02:33:00 EDT From: Dave Subject: Another printing bug in CLtL To: common-lisp@SU-AI.ARPA On p. 396 in the examples of using ~G for format, one of the examples is: (foo 3.14E12) => "*********|314.2$+10|0.314E+13| 3.14L+12" ^ ^ | | | shouldn't this be E? | shouldn't this be a 0? ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Oct 85 18:54:39 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 15:45:44 PDT Date: Tue, 1 Oct 85 18:48:29 EDT From: George J. Carrette Subject: UNIX terminal io incompatibility To: ANDY@SU-SUSHI.ARPA cc: common-lisp@SU-AI.ARPA, gray@GSWD-VMS.ARPA In-reply-to: Msg of Tue 1 Oct 85 10:57:17-PDT from Andy Freeman Message-ID: <[MIT-MC.ARPA].665347.851001.GJC> VMS also has redirectable input/output. $ define/user sys$output ... $ define/user sys$input ... $ define/user sys$error ... $ define/user sys$command ... one might wonder what DEC COMMON LISP does in this case.  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Oct 85 15:00:43 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 11:47:36 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 324445; Tue 1-Oct-85 14:41:44-EDT Date: Tue, 1 Oct 85 14:40 EDT From: Daniel L. Weinreb Subject: Re: disassemble and compile questions To: bs%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA cc: bs@hplabs.CSNET In-Reply-To: <8509301829.AA12153@HP-VENUS> Message-ID: <851001144005.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Mon, 30 Sep 85 11:28:47 pdt From: Bob Shaw Is it allowable to have a function object that is specified by a lambda-expression but is not stored as a lambda-expression or compiled code? In other words, does Common Lisp allow intermediate, iterpretable representations? If it is possible to have such a function object, is there a mechanism by which it can be later compiled? In my opinion, this is the correct answer: Any Common Lisp implementation is allowed to have its own, non-standard (not in CLtL), additional kinds of functions. Programs written in such a way as to make this additional thing visible might not end up being portable. So in your case, the answer is yes, it's OK for you to put in your own additional (intermediate, or whatever) representation, but programs that want to be portable will have to not depend on its existence. If I interpret "may" as "must" in the preceding statement, then, for such an intermediate form, (apply 'f 1 2 3) is legal, but (apply (symbol-function 'f) 1 2 3) is not. I don't understand how you conclude this. The latter form is also legal. After all, it is defined that what happens when you apply a symbol is that the object in the symbol's function cell is applied instead (see 2.13 again).  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Oct 85 14:16:44 EDT Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 11:05:50 PDT Date: Tue 1 Oct 85 10:57:17-PDT From: Andy Freeman Subject: Re: UNIX terminal io incompatibility To: gray@GSWD-VMS.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from "gray@GSWD-VMS" of Tue 1 Oct 85 10:37:56-PDT Unix isn't the only operating system with redirectable output. (TOPS-20, believe it or not, does also; probably Tenex does as well. .priin and .priou are similar to stdin and stdout. The reason you've never heard of it is that they couldn't figure out a decent exec syntax.) If one is going to attach *standard-output* and *standard-input* to stdout and stdin respectively, *error-output* should be attached to stderr. I don't know about *trace-output*. -andy -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Oct 85 13:32:50 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 1 Oct 85 10:21:49 PDT Date: Tue, 01 Oct 85 12:21:30 CDT From: gray@GSWD-VMS Subject: UNIX terminal io incompatibility To: common-lisp@su-ai.arpa Cc: gray Common Lisp maps poorly onto UNIX(tm) in the area of terminal io. On pages 328 and 329 of CLtL it says: "*standard-input*, *standard-output*, *error-output*, *trace- output*, *query-io*, and *debug-io* are initially bound to synonym streams that pass all operations on to the stream that is the value of *terminal-io*." Earlier on, the specification describes *query-io* and *debug-io* as always being interactive streams. These requirements cause problems under UNIX when you redirect the output of a program, specifically when you redirect the output of a Lisp session. For example: clisp > FOO If we follow the specification and attach *terminal-io* to UNIX stdin/stdout file descriptors and leave all the other streams bound to *terminal-io*, output from *debug-io* will also be redirected to the file, not to the terminal. If we attach *terminal-io* to /dev/tty and leave the other streams bound to *terminal-out*, then UNIX redirection doesn't work. Our proposed solution is to attach *terminal-io* to /dev/tty, then attach *standard-in* to UNIX stdin and *standard-out* to UNIX stdout (not to *terminal-io*). All the other io streams remain bound to *terminal-io*. This permits the user to redirect stdin and stdout, and output from *debug-io*, etc., still appears on the terminal. Although this does not abide by the standard, it is useful enough that we propose it as a UNIX-specific addition. Anne Jane Gray Gould CSD, Urbana, IL.  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Sep 85 20:42:36 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 30 Sep 85 17:33:54 PDT Received: ID ; Mon 30 Sep 85 20:34:52-EDT Date: Mon, 30 Sep 1985 20:34 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Bob Shaw Cc: Common-Lisp@SU-AI.ARPA Subject: disassemble and compile questions The language spec says nothing about what a compiled-code object looks like, so it seems perfectly reasonable to me that an implementation could have several internal compiled code formats, some (a lot) more compiled than others. Also, many implementations do a little work on the lambda expression that would otherwise be produced by DEFUN before storing it in a function cell, at least to the extent of making that implicit BLOCK explicit. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Sep 85 20:34:56 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 30 Sep 85 17:23:52 PDT Received: from hplabs by csnet-relay.csnet id bb17699; 30 Sep 85 20:17 EDT Received: by HP-VENUS id AA12153; Mon, 30 Sep 85 11:29:45 pdt Message-Id: <8509301829.AA12153@HP-VENUS> Date: Mon, 30 Sep 85 11:28:47 pdt From: Bob Shaw Received: by HP-MARS id AA23741; Mon, 30 Sep 85 11:28:47 pdt To: common-lisp <@CSNET-RELAY.ARPA,@hplabs.CSNET:common-lisp@su-ai.arpa> Subject: Re: disassemble and compile questions Cc: bs@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. Well, I essentially shot myself in the foot with the wording of my question about compiling things other than lambda-expressions. Lexical closures were a convenient example, not the real concern. Let me make another attempt. Is it allowable to have a function object that is specified by a lambda-expression but is not stored as a lambda-expression or compiled code? In other words, does Common Lisp allow intermediate, iterpretable representations? If it is possible to have such a function object, is there a mechanism by which it can be later compiled? In section 5.3.1 it states, "Evaluating a defun form causes the symbol name to be a global name for the function specified by the lambda- expression ... ." This doesn't seem to preclude an intermediate form. In section 2.13 it states, "A function is anything that may be correctly given to the funcall or apply function, and is to be executed as code when arguments are supplied." Funcall is defined in terms of functions (section 7.3) and apply (section 7.3) states, "function may be a compiled-code object, or a lambda-expression, or a symbol ... ." If I interpret "may" as "must" in the preceding statement, then, for such an intermediate form, (apply 'f 1 2 3) is legal, but (apply (symbol-function 'f) 1 2 3) is not. Thanks for any help.