Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Apr 86 22:30:50 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 9 Apr 86 19:21:07 PST Received: ID ; Wed 9 Apr 86 22:21:52-EST Date: Wed, 9 Apr 1986 22:21 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Dave Moon's summary of EVAL-WHEN issues. In-reply-to: Msg of 4 Apr 1986 13:37-EST from Bobrow.pa at Xerox.COM I think that instead of worrying about changing the name, we need to completely replace the current Eval-When. We need to figure out what kinds of control we need over when things are to be evaluated, compiled, etc., and then we need good clean ways of expressing these directives in portable code files. This is all tied in with top-level forms and issues about what the compiler does to the compile-time and load-time environments. Once we know what sorts of operations we want to support, then we should worry about names. Assuming that these new controls are not equivalent to the current Eval-When, we will want new names for these things so that the cut-over fromt he old Eval-When can occur gradually. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Apr 86 12:30:55 EST Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 9 Apr 86 07:54:18 PST Date: Wed, 9 Apr 86 09:43 EST From: "Eric J. Swenson" Subject: Common Loops To: common-lisp@SU-AI.ARPA Message-ID: <860409144332.683474@CISL-SERVICE-MULTICS.ARPA> Are there any on-line documents on CommonLoops that are available to the ARPA community via FTP?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Apr 86 11:05:26 EST Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 9 Apr 86 07:54:18 PST Date: Wed, 9 Apr 86 09:43 EST From: "Eric J. Swenson" Subject: Common Loops To: common-lisp@SU-AI.ARPA Message-ID: <860409144332.683474@CISL-SERVICE-MULTICS.ARPA> Are there any on-line documents on CommonLoops that are available to the ARPA community via FTP?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Apr 86 09:33:50 EST Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 9 Apr 86 05:09:37 PST Received: by mit-ems.ARPA (4.12/4.8) id AA06539; Wed, 9 Apr 86 08:09:04 est Date: Wed, 9 Apr 86 08:09:04 est From: Steven Haflich Message-Id: <8604091309.AA06539@mit-ems.ARPA> To: Common-Lisp@SU-AI Subject: Re: What can I redefine? > From: David C. Plummer > > In addition, some systems know that CAR was not originally defined by > the user, and may complain if the user tries to redefine it. If the > user did say "Yes, it's OK." I wouldn't be at all surprised if the user > wouldn't immediately have to reload the Lisp system, as the system will > probably get very unhappy when CAR returns something other than the > first item of a list. A few months ago when I was about to reboot anyway I redefined CAR on a 3670. I played with the system for another ten minutes without finding anything that this broke. Even Chaos and the GC still worked. This isn't too surprising when you think about it. All this was discussed several months ago. It would appear the compiler is permitted to open code anything for which it can prove it knows the execution environment definition. I can see no reason why this should even exclude user-DEFUNed functions in the compilation environment for COMPILE, or functions DEFUNed in the same file for COMPILE-FILE. Whatever one thinks about this mess, the issue probably should be raised more explicitly in CLtL. Meanwhile, one can always write: (FUNCALL (SYMBOL-FUNCTION 'CAR) FOO) instead of (CAR FOO) and hope no one has redefined FUNCALL or SYMBOL-FUNCTION. Gag.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Apr 86 02:39:24 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Apr 86 23:25:24 PST Received: ID ; Wed 9 Apr 86 02:25:37-EST Date: Wed, 9 Apr 1986 02:25 EST Message-ID: From: Rob MacLachlan To: "BACH::GREEK" Cc: common-lisp Subject: EVAL-WHEN buried inside forms. In-reply-to: Msg of 8 Apr 1986 12:43-EST from BACH::GREEK I agree that CLTL doesn't adequately specify the semantics of non-top-level EVAL-WHEN's. This isn't surprising, since there evidently wasn't any attempt to. Multiple compile-time evaluation is a common characteristic of incorrect eval-when implementations, even when they don't attempt to handle non-top-level occurrences. In the Spice Lisp compiler, the Stuff in your example is only evaluated once. When the compiler initially evaluates the outer EVAL-WHEN, it binds a special indicating that the code within it has already been evaluated. The compiler doesn't evaluate non-top-level EVAL-WHEN's when this flag is true. The flag gets bound to NIL when the compiler encounters a form which isn't wasn't evaled, such as an EVAL-WHEN LOAD. The compiler also needs to communicate with the interpreter so that when the compiler evals a form, the interpreter evaluates EVAL-WHEN COMPILE's which it would otherwise ignore. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 22:33:56 EST Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 8 Apr 86 19:23:37 PST Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a003080; 8 Apr 86 22:55 BST From: Jeff Dalton Date: Tue, 8 Apr 86 18:28:29 GMT Message-Id: <3032.8604081828@aiva.ed.ac.uk> To: common-lisp@su-ai.arpa, diamant <@hplabs.arpa:diamant@hpfclp> Subject: Re: Symbol-function Can the value of SYMBOL-FUNCTION be anything or must it be a function? I seem to recall someone mentioning in the discussion about why the function value of a symbol was not just the variable value that the function value could be guaranteed to be something you could just transfer through rather than some random value that you had to check for function-ness. Of course, you could wrap the random value in something that could be transferred through, as is often done with non-compiled functions, so this doesn't really resolve the issue. - Jeff  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 21:54:41 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 18:45:51 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 458824; Tue 8-Apr-86 21:13:13-EST Date: Tue, 8 Apr 86 21:09 EST From: Robert W. Kerns Subject: Extent of function definition created by FLET/LABELS To: NGALL@G.BBN.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL> Message-ID: <860408210903.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 8 Apr 1986 18:06-EST From: NGALL@G.BBN.COM Is the following legal CL: Yes, it is quite legal. We do this extensively in our system code. (funcall (labels ((foo () (print "hello")) (bar () (foo))) #'bar)) If not, where is it forbidden? -- Nick P.S. It works in VaxLisp.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 21:04:22 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 17:54:15 PST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 458753; Tue 8-Apr-86 19:51:00-EST Date: Tue, 8 Apr 86 19:49 EST From: David C. Plummer Subject: Extent of function definition created by FLET/LABELS To: NGALL%G.BBN.COM@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL> Message-ID: <860408194941.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 8 Apr 1986 18:06-EST From: NGALL@G.BBN.COM Is the following legal CL: (funcall (labels ((foo () (print "hello")) (bar () (foo))) #'bar)) If not, where is it forbidden? -- Nick P.S. It works in VaxLisp. I'm very surprised CLtL does not say that the functions created by FLET and LABELS have lexical scope (I think it does say that) and indefinite extent (that's what it doesn't say). Page 37 does say "most Common Lisp data objects have indefinite extent." I think you will find most implementations will interpret FLET and LABELS to have indefinite extent.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 18:15:45 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 15:05:21 PST Date: 8 Apr 1986 18:06-EST Sender: NGALL@G.BBN.COM Subject: Extent of function definition created by FLET/LABELS From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM] 8-Apr-86 18:06:32.NGALL> Is the following legal CL: (funcall (labels ((foo () (print "hello")) (bar () (foo))) #'bar)) If not, where is it forbidden? -- Nick P.S. It works in VaxLisp.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 17:47:24 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 14:33:47 PST Date: 8 Apr 1986 17:34-EST Sender: NGALL@G.BBN.COM Subject: Re: EVAL-WHEN (really symbol-function) From: NGALL@G.BBN.COM To: gls@AQUINAS.THINK.COM Cc: common-lisp@SU-AI.ARPA, diamant@HPLABS.ARPA Message-ID: <[G.BBN.COM] 8-Apr-86 17:34:18.NGALL> In-Reply-To: <860407154604.4.GLS@GUIDO.THINK.COM> Date: Mon, 7 Apr 86 15:46 EST From: Guy Steele To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA Subject: Re: EVAL-WHEN (really symbol-function) In-Reply-To: <8604051547.AA06672@GODOT.THINK.COM> Message-ID: <860407154604.4.GLS@GUIDO.THINK.COM> Date: Sat, 5 Apr 86 07:44:35 pst From: hpfclp!diamant@hplabs.ARPA From: Guy Steele Date: 4 Apr 1986 09:35-EST From: NGALL@G.BBN.COM Date: Thu 3 Apr 86 22:52:12-EST From: "Rodney A. Brooks" There is no requirement in CLtL that it be legal for a symbol function cell to contain a lambda expression. ... This should definitely be pointed out on page 90. Also, exactly what objects may be the value in a setf of (symbol-function <>) should be clarified. I would contend that any Lisp object may be the value in a setf of (symbol-function ), and that a subsequent invocation of (symbol-function ) should retrieve exactly that object (or one EQL to it). However, this does not prevent implementations from wrapping that object in a closure internally on storing and unwrapping it again on fetching. --Guy ... It may be obvious, but it is also wrong. I apologize for the misleading terminology, but the term "function definition" is intended merely as a label for a certain attribute of a symbol that conventionally has a function as its value, but it is not meant to imply that that value is necessarily of type FUNCTION. Indeed, CLtL does not (I believe) say that a macro definition object is of type FUNCTION, and such objects are certainly allowed to be the value of the function definition of a symbol. Indeed, the fact that you have a NULL test in EVALUATE-FUN above indicates that you expect NIL to be a possible result of SYMBOL-FUNCTION, and NIL is not necessarily of type FUNCTION, is it? "Having a function definition" merely means "is FBOUNDP"; it doesn't mean "has an object of type FUNCTION as the function definition attribute". --Guy 1. How many implementations interpreted CLtL the way Guy intended? In other words, How many implementations allow, for example, (setf (symbol-function 'foo) 1.0d0). VaxLisp does not allow this. 2. How many implementations interpreted CLtL as implying that only objects that can be returned from the FUNCTION special form or objects that are returned by calling SYMBOL-FUNCTION with a symbol naming a special form or macro as its argument can legally be used as the value in a SETF of SYMBOL-FUNCTION? VaxLisp seems to have interpreted it this way. I bet that most implemetnations are closer to interpretation 2 than to 1. 3. Under interp 1. consider the following: (defun foo () (print "hello")) (setf (symbol-function 'bar) 'foo) Which of the following are legal?: (funcall 'bar) ; A (funcall #'bar) ; B (funcall (symbol-function 'bar)) ; C Case C is the only one I am sure is legal. The other two depend on the ambiguous description of function calling (pg. 58) and APPLY (pg. 107). I guess my point is that I think most implementors followed interpretation 2 which prevents the kind of confusion where C is legal but B is not; so we should clarify CLtL in that direction rather than towards interp 1. Whatever interp. is finally chosen, APPLY should be clarified so that we known exactly what can be applied (and if a symbol is applied, what exactly can be legally the function definition). -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 12:59:23 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 8 Apr 86 09:47:21 PST Date: 8 Apr 86 12:43:00 EST From: "BACH::GREEK" Subject: EVAL-WHEN buried inside forms. To: "common-lisp" Reply-To: "BACH::GREEK" Please keep in mind that this message assumes I understand how EVAL-WHEN is supposed to work, which I might not. I don't believe that the model for EVAL-WHEN takes into account uses at other than "top level". For example: (eval-when (compile load) (let (...) (eval-when (eval) ...stuff...) ...) ) The LET will be EVALed at compile-time by virtue of the compile situation in the outer EVAL-WHEN. Then, as the compiler begins to process the body of the LET, it will see the inner EVAL-WHEN and EVAL the stuff, then discard it. Oops, the stuff was EVALed twice! In order to deal with EVAL-WHEN forms anywhere, we need to improve the model. But it's not clear to me what some combinations mean. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 10:59:32 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 86 07:49:32 PST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 457920; Tue 8-Apr-86 10:43:27-EST Date: Tue, 8 Apr 86 10:42 EST From: David C. Plummer Subject: What can I redefine? To: Rob MacLachlan , Pavel.pa%XEROX.COM@SCRC-STONY-BROOK.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: References: <860407-151544-1636@Xerox>, Message-ID: <860408104204.5.DCP@FIREBIRD.SCRC.Symbolics.COM> [Excuse the possibly bogus mail addresses; our domain system doesn't deal with down domain servers very well.] In addition, some systems know that CAR was not originally defined by the user, and may complain if the user tries to redefine it. If the user did say "Yes, it's OK." I wouldn't be at all surprised if the user wouldn't immediately have to reload the Lisp system, as the system will probably get very unhappy when CAR returns something other than the first item of a list.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Apr 86 10:17:22 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 8 Apr 86 07:06:41 PST Date: 8 Apr 86 09:53:00 EST From: "BACH::GREEK" Subject: EVAL-WHEN buried inside a form. To: "common-lisp" Reply-To: "BACH::GREEK" Well, I have to agree with Rob that it would be restrictive to disallow EVAL-WHENs buried inside of arbitrary forms. Does the model for processing EVAL-WHEN given in CLtL take into account that they might not be at "top level"? - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Apr 86 19:56:59 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Apr 86 16:43:15 PST Received: ID ; Mon 7 Apr 86 19:44:08-EST Date: Mon, 7 Apr 1986 19:44 EST Message-ID: From: Rob MacLachlan To: Pavel.pa@XEROX.COM Cc: Common-Lisp@SU-AI.ARPA Subject: What can I redefine? In-reply-to: Msg of 7 Apr 1986 18:15-EST from Pavel.pa at Xerox.COM My interpretation of the consensus is that you can redefine anything which isn't a special form. The compiler is free to compile any standard function however it wants unless you make a NOTINLINE declaration, which forces the compiler to make a normal function call. This issue was brought up before, and there was fairly strong opposition to prohibiting redefinition. Redefining standard functions is part of the Lisp culture. I would have no objection to saying that redefining standard functions is an error. This is because no truly portable program can redefine any standard function, since it cannot know what the rest of the system expects of the implementation of that function. The usual Lisp environment allows multiple applications to coexist in the same Lisp; this cannot work if applications go around redefining things at random. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Apr 86 18:52:57 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Apr 86 15:40:14 PST Received: ID ; Mon 7 Apr 86 18:40:19-EST Date: Mon, 7 Apr 1986 18:40 EST Message-ID: From: Rob MacLachlan To: "BACH::GREEK" Cc: common-lisp Subject: Top-level EVAL-WHEN In-reply-to: Msg of 7 Apr 1986 09:17-EST from BACH::GREEK Date: Monday, 7 April 1986 09:17-EST From: BACH::GREEK Reply-To: BACH::GREEK To: common-lisp Re: Top-level EVAL-WHEN I didn't quite understand Rob's point, but no one is excluding EVAL-WHEN buried in a top-level PROGN (as is typically generated by complex macros). This is because all of the forms inside a top-level PROGN are "promoted" to top-level forms. If I define a macro DEF-FROB which has some code in its body, I want to be able to use this defining macro within a let: (let ((foo ...)) (def-frob my-frob (x) ...)) If non-top-level EVAL-WHEN's are prohibited, then users cannot define defining macros which expand into code containing EVAL-WHEN's unless those macros are only used at top level. I don't think that anyone considers the body of a let to be at top level; if they do, then where does top-level stop? One way to look at my proposal is as saying "everywhere is top-level." I see no need for defining the notion of top-level, and see good reasons not to. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Apr 86 18:45:04 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 7 Apr 86 15:31:15 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 86 15:15:44 PST Date: Mon, 7 Apr 86 15:15:37 PST From: Pavel.pa@Xerox.COM Subject: What can I redefine? To: Common-Lisp@SU-AI.ARPA Message-ID: <860407-151544-1636@Xerox> Consider the following code: (defun bar (y) (* y 2)) (defun foo (x) (+ (bar x) 1)) (compile 'foo) (defun bar (y) (* y 3)) (foo 7) I think (hope) that everyone would agree that the final function call returns 22. That is, it is expected that the compiler will not make use of the current definition of ``bar'' in generating code for ``foo''. But what about this case: (defun foo (x) (+ (car x) 1)) (compile 'foo) (defun car (y) (* y 3)) (foo 7) Surely every compiler in the world will open-code ``car'' without asking permission from the user. Thus this code should produce an error (or is at least has undefined effect under the standard). Is this considered ``correct'' behavior for the compiler? Is its behavior expected to be any different if the redefinition of ``car'' occurs before the compilation? That is, is the compiler supposed to check for the redefinition of constructs about which it has special knowledge? Do any of these answers change if I replace ``car'' by ``disassemble'' in the above example? The idea is that one might be surprised to find a compiler with special knowledge of the ``disassemble'' function and so perhaps one should be allowed to count on calls to it not being ``compiled away''. The silver book is, so far as I've seen, fairly silent on the issue of what things the user is allowed to redefine. The only reference I've found is this, from page 67: ``It is an error to attempt to redefine the name of a special form.'' I would like to see a statement in the standard that ``It is an error to attempt to redefine the name of any function, macro, or special form defined in this standard.'' Otherwise, I'll feel like I'm cheating if I use any special knowledge in my compiler without first checking somehow to be sure that no redefinition has taken place. Pavel  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Apr 86 16:02:04 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Apr 86 12:45:52 PST Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 7 Apr 86 15:44:40 est Date: Mon, 7 Apr 86 15:46 EST From: Guy Steele Subject: Re: EVAL-WHEN (really symbol-function) To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA Cc: diamant@HPLABS.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <8604051547.AA06672@GODOT.THINK.COM> Message-Id: <860407154604.4.GLS@GUIDO.THINK.COM> Date: Sat, 5 Apr 86 07:44:35 pst From: hpfclp!diamant@hplabs.ARPA From: Guy Steele Date: 4 Apr 1986 09:35-EST From: NGALL@G.BBN.COM Date: Thu 3 Apr 86 22:52:12-EST From: "Rodney A. Brooks" There is no requirement in CLtL that it be legal for a symbol function cell to contain a lambda expression. ... This should definitely be pointed out on page 90. Also, exactly what objects may be the value in a setf of (symbol-function <>) should be clarified. I would contend that any Lisp object may be the value in a setf of (symbol-function ), and that a subsequent invocation of (symbol-function ) should retrieve exactly that object (or one EQL to it). However, this does not prevent implementations from wrapping that object in a closure internally on storing and unwrapping it again on fetching. --Guy I have to disagree with you, Guy, for the following reason. The following piece of code is perfectly legal Common Lisp: (defun evaluate-fun (func &rest args) (if (or (null (symbol-function func)) (macro-function func) (special-form-p func)) (error "Not a function.") (apply (symbol-function func) args))) ; I know that the symbol-function ; is redundant here -- that isn't ; the point (evaluate-fun 'cons 'a 'b) ; should return (A . B) Note that (EVALUATE-FUN 'KDJSHFGDJSAHGFHJSADG) would signal an error (assuming that KDJSHFGDJSAHGFHJSADG in in fact not FBOUNDP). Here is what CLtL says (p. 90): "symbol-function returns the current global function definition named by symbol. An error is signalled if the symbol has no function definition; see fboundp. Note that the definition may be an object representing a special form or macro. In the latter case, it is an error to attempt to invoke the object as a function." Note that the only valid object which may be returned is something of type function (if the symbol has a global function definition). This is obvious from the last sentence in the paragraph above. It may be obvious, but it is also wrong. I apologize for the misleading terminology, but the term "function definition" is intended merely as a label for a certain attribute of a symbol that conventionally has a function as its value, but it is not meant to imply that that value is necessarily of type FUNCTION. Indeed, CLtL does not (I believe) say that a macro definition object is of type FUNCTION, and such objects are certainly allowed to be the value of the function definition of a symbol. Indeed, the fact that you have a NULL test in EVALUATE-FUN above indicates that you expect NIL to be a possible result of SYMBOL-FUNCTION, and NIL is not necessarily of type FUNCTION, is it? Since you claim any object can be stored and that the retrieved value must be EQL, then any object can be retrieved. This is totally contradictory to the quoted paragraph above. It very explicitly states in which cases it is an error to invoke the object as a function, and the case you are establishing is not covered. "Having a function definition" merely means "is FBOUNDP"; it doesn't mean "has an object of type FUNCTION as the function definition attribute". As far as allowing a lambda as the function cell, CLtL states that an implementation is at liberty to always compile its code. If the lambda must be left in its original state, then the implementation has to compile every time a function is called, rather than when one is defined! Non sequitur. It doesn't say that the code must be recompiled every time. You can compile it once, and the system interpreter can use that compiled code each time. It's just that the result of user-visible calls to SYMBOL-FUNCTION should be the LAMBDA expression. (We might want to change that, but that's how I read it now.) John Diamant Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs Fort Collins, CO --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Apr 86 09:27:21 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Apr 86 06:19:16 PST Date: 7 Apr 86 09:17:00 EST From: "BACH::GREEK" Subject: Top-level EVAL-WHEN To: "common-lisp" Reply-To: "BACH::GREEK" I didn't quite understand Rob's point, but no one is excluding EVAL-WHEN buried in a top-level PROGN (as is typically generated by complex macros). This is because all of the forms inside a top-level PROGN are "promoted" to top-level forms. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Apr 86 00:18:44 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Apr 86 21:01:40 PST Received: ID ; Mon 7 Apr 86 00:02:14-EST Date: Mon, 7 Apr 1986 00:02 EST Message-ID: From: Rob MacLachlan To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Subject: EVAL-WHEN In-reply-to: Msg of Thu 3 Apr 86 18:23 -EST from David A. Moon Date: Thu, 3 Apr 86 18:23 -EST From: David A. Moon To: Common-Lisp at SU-AI.ARPA Re: EVAL-WHEN A couple of other questions have been asked before and never really answered. Are EVAL-WHENs allowed down in the guts of a function or macro and what do they mean there? The discussion on page 66 that everybody hates was intended to rule out EVAL-WHEN inside the guts of a function or a macro. I cannot think of a meaningful interpretation of EVAL-WHEN in this position. We may have to come up with a meaningful definition for non-top-level EVAL-WHEN's. The reason is that the notion of a top-level form is fairly worthless once you allow definitions inside of LET's. Forbidding non-top-level EVAL-WHEN's would prohibit non-top-level use of all user defining macros which expand into EVAL-WHEN's. This is unacceptable since most hairy defining macros use EVAL-WHEN. It is possible to meaningfully define non-top-level EVAL-WHEN's. The LOAD and EVAL cases are easy: just compile or eval as PROGN (modulo the situation interaction hair). The problem arises with the COMPILE situation. The solution I suggest is to evaluate every EVAL-WHEN COMPILE at compile time, no matter where it appears. (1) The name of EVAL-WHEN leads to confusion since this special form is not actually related to the EVAL function. Should this problem be attacked by changing the name or by documenting it better? EVAL-WHEN is far too obscure to be completely understood by anyone who hasn't written it. Changing the name certainly won't help; better documentation might. (3) It would be useful to have a way to turn off the compiler's normal processing of a form. Some discussion of exactly what this means may be in order. I agree. I thing most of the "normal processing" can be modeled as implicit EVAL-WHEN COMPILE's. A possibility is to have a new situation LOAD-ONLY which is like LOAD except that it inhibits evaluation of all EVAL-WHEN COMPILE's (implicit or explicit) within its lexical scope. Compilation of code within LOAD-ONLY should have no effect on the compiler environment. If we make some changes along these lines, we can totally eliminate the notion of a top-level form from the language. I think this would be a big improvement. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 6 Apr 86 02:21:17 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 23:07:54 PST Received: by hplabs.ARPA ; Sat, 5 Apr 86 23:06:25 pst Date: Sat, 5 Apr 86 23:06:25 pst From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: Re: Symbol-function From: hplabs!preece%ccvaxa@gswd-vms (Scott E. Preece) I don't see any reason to read into the quoted text that those are the ONLY cases that may not be invokable. I read that last sentence as a You may be correct about the intended meaning of the last sentence. However, it would have been clearer to explicitly state that it is an error to invoke any value returned by symbol-function for any symbol which is not a function (I really mean a function here -- not that it has a global function definition), and in addition point out that special forms and macros fall in this category. In addition, if values are allowed for symbol-function which aren't functions (or macros or special forms), that should be stated explicitly. I don't agree with this rewording, however, because I don't believe that implementations should be required to allow anything other than a valid function to be setf'd by the user, and the requirement on the return value should only be that it is logically equivalent to what was passed in (that it will do "the right thing"). I already stated the reasons in my previous message (performance and usability of symbol-function). By the way, I just noticed that I dropped a vital part of the sentence in question when I quoted it. Look at the quote in my response below. cautionary example indicating that not everything residing in that slot will be executable. I agree with Guy that the nature of things put into that slot is implementation specific -- portable code should not assume anything about it. I have quoted Guy's comment below, and I don't see how what he said indicates that portable code can't count on what is in symbol-function. I think he is saying that symbol-function is required to act in a portable manner and that the implementation can have other (non-portable) mechanisms to get to the non-EQL values it uses internally. I agree with your statement above; I just don't think that is what Guy said! From: Guy Steele I would contend that any Lisp object may be the value in a setf of (symbol-function ), and that a subsequent invocation of (symbol-function ) should retrieve exactly that object (or one EQL to it). However, this does not prevent implementations from wrapping that object in a closure internally on storing and unwrapping it again on fetching. From: Daniel L. Weinreb Yes, it says that if the object is not a function, it is an error to attempt to invoke it. However, it doesn't say anywhere that if the It doesn't say that if the object is not a function, it is an error -- it says that if it is a macro or special form, it is an error. In particular, it says that "the definition may be a function or may be an object representing a special form or macro." In other words, it may be one of three things. It may NOT be a random object. If I say "I may be at home or at work," it is correct to assume that I will not be at the beach (assuming I don't live or work at the beach :-)). object is not a function, it is an error to call symbol-function. So there is no contradiction. See above. I still say there is a contradiction. What you say is "obvious" is not obvious at all, because of the fuzzy use of the word "valid". The use of the word valid was mine, not from CLtL, so it isn't the root of the problem. I think we can all agree that the wording of symbol-function is unclear, but I am more concerned about changing it so that the requirement Guy mentioned is NOT made. From: hplabs!Bobrow.pa@Xerox.COM The hidden wrapping mentioned earlier (or an implicit wrapping through a hash link from the expression) both allow first time compilation rather than every time. My comment regarding that was somewhat unclear. It is true that the wrapping method does allow an implementation to compile or preprocess in advance, but it means that the user doesn't really get the symbol-function when he asks for it. It means either that (apply (symbol-function 'foo)) and (apply 'foo) are different, or that (apply (copy-list (symbol-function 'foo))) and (apply (symbol-function 'foo)) are different (in the case of a lambda). There is also a matter of performance to consider. Making every function call require an extra hash lookup (or a test to decide whether to do a hash lookup) is expensive and doesn't really gain anything for you. What you are doing is making the function cell just another value cell. It isn't. It is for executable functions. Symbol-function ought to return the function cell and the function cell ought to contain what the implementation really uses to execute the function. Also, it should be an error to setf the function cell to anything which is not of type function. That would, in fact, eliminate the problem except for lambdas. John Diamant Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs Fort Collins, CO  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Apr 86 20:00:07 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Apr 86 16:51:09 PST Date: Sat, 5 Apr 86 19:53:14 EST From: "Lawrence A. DeLuca, Jr." Subject: common-lisp on vaxes under vms? To: Neches@ISI-VAXA.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 31 Mar 1986 1134-PST () from Neches at ISI-VAXA.ARPA Message-ID: <[MC.LCS.MIT.EDU].875107.860405.HENRIK> He should look into NIL, MIT Common Lisp. The contact person is Glenn Burke, GSB@MC. I believe the cost of a distribution tape is about $100 these days, but don't quote me on it. larry...  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Apr 86 18:24:08 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 15:13:34 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 456333; Sat 5-Apr-86 18:13:28-EST Date: Sat, 5 Apr 86 18:12 EST From: Daniel L. Weinreb Subject: Re: EVAL-WHEN (really symbol-function) To: hpfclp!diamant%hplabs@MIT-MC.ARPA, common-lisp@SU-AI.ARPA cc: diamant%hplabs@MIT-MC.ARPA In-Reply-To: The message of 5 Apr 86 10:44-EST from hpfclp!diamant@hplabs.ARPA Message-ID: <860405181258.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sat, 5 Apr 86 07:44:35 pst From: hpfclp!diamant@hplabs.ARPA "symbol-function returns the current global function definition named by symbol. An error is signalled if the symbol has no function definition; see fboundp. Note that the definition may be an object representing a special form or macro. In the latter case, it is an error to attempt to invoke the object as a function." Note that the only valid object which may be returned is something of type function (if the symbol has a global function definition). This is obvious from the last sentence in the paragraph above. Since you claim any object can be stored and that the retrieved value must be EQL, then any object can be retrieved. This is totally contradictory to the quoted paragraph above. It very explicitly states in which cases it is an error to invoke the object as a function, and the case you are establishing is not covered. Yes, it says that if the object is not a function, it is an error to attempt to invoke it. However, it doesn't say anywhere that if the object is not a function, it is an error to call symbol-function. So there is no contradiction. What you say is "obvious" is not obvious at all, because of the fuzzy use of the word "valid".  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Apr 86 17:52:00 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 5 Apr 86 14:25:15 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 APR 86 14:26:06 PST Date: 5 Apr 86 14:26 PST From: Bobrow.pa@Xerox.COM Subject: Re: Symbol-function To: COMMON-LISP@su-ai.arpa Message-ID: <860405-142606-3435@Xerox> I would contend that any Lisp object may be the value in a setf of (symbol-function ), and that a subsequent invocation of (symbol-function ) should retrieve exactly that object (or one EQL to it). However, this does not prevent implementations from wrapping that object in a closure internally on storing and unwrapping it again on fetching. --Guy This seems right to me. What is not stated in CTtL is whether an implementation has the right to check what is being put in there and cause an error at storage time. As far as allowing a lambda as the function cell, CLtL states that an implementation is at liberty to always compile its code. If the lambda must be left in its original state, then the implementation has to compile every time a function is called, rather than when one is defined! John Diamant The hidden wrapping mentioned earlier (or an implicit wrapping through a hash link from the expression) both allow first time compilation rather than every time.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Apr 86 15:32:25 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 12:23:38 PST Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA04856; Sat, 5 Apr 86 14:23:16 CST Message-Id: <8604052023.AA04856@gswd-vms.ARPA> Date: Sat, 5 Apr 86 14:21:38 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: EVAL-WHEN (really symbol-functio > From: hpfclp!diamant@hplabs.ARPA > Subject: Re: EVAL-WHEN (really symbol-function) > > Here is what CLtL says (p. 90): > > "symbol-function returns the current global function definition named > by symbol. An error is signalled if the symbol has no function > definition; see fboundp. Note that the definition may be an object > representing a special form or macro. In the latter case, it is an > error to attempt to invoke the object as a function." > > Note that the only valid object which may be returned is something of > type function (if the symbol has a global function definition). This > is obvious from the last sentence in the paragraph above. Since you > claim any object can be stored and that the retrieved value must be > EQL, then any object can be retrieved. This is totally contradictory > to the quoted paragraph above. It very explicitly states in which > cases it is an error to invoke the object as a function, and the case > you are establishing is not covered. ---------- I don't see any reason to read into the quoted text that those are the ONLY cases that may not be invokable. I read that last sentence as a cautionary example indicating that not everything residing in that slot will be executable. I agree with Guy that the nature of things put into that slot is implementation specific -- portable code should not assume anything about it. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Apr 86 12:10:06 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Apr 86 07:45:43 PST Received: by hplabs.ARPA ; Sat, 5 Apr 86 07:44:35 pst Date: Sat, 5 Apr 86 07:44:35 pst From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: Re: EVAL-WHEN (really symbol-function) Cc: diamant@hplabs.ARPA From: Guy Steele Date: 4 Apr 1986 09:35-EST From: NGALL@G.BBN.COM Date: Thu 3 Apr 86 22:52:12-EST From: "Rodney A. Brooks" There is no requirement in CLtL that it be legal for a symbol function cell to contain a lambda expression. In some implementations this will cause an error when such a symbol is used in the function position of an eval-ed expression. These implementations place a closure in symbol function cells for interpreted functions, which all point to the same compiled code sequence which takes a literal from the closure (the literal is the lambda expression) and does the right call into the middle of the interpreter. I agree. This should definitely be pointed out on page 90. Also, exactly what objects may be the value in a setf of (symbol-function <>) should be clarified. Apparently, this too is true (considering that all of us do not seem to agree on this). I would contend that any Lisp object may be the value in a setf of (symbol-function ), and that a subsequent invocation of (symbol-function ) should retrieve exactly that object (or one EQL to it). However, this does not prevent implementations from wrapping that object in a closure internally on storing and unwrapping it again on fetching. --Guy I have to disagree with you, Guy, for the following reason. The following piece of code is perfectly legal Common Lisp: (defun evaluate-fun (func &rest args) (if (or (null (symbol-function func)) (macro-function func) (special-form-p func)) (error "Not a function.") (apply (symbol-function func) args))) ; I know that the symbol-function ; is redundant here -- that isn't ; the point (evaluate-fun 'cons 'a 'b) ; should return (A . B) Here is what CLtL says (p. 90): "symbol-function returns the current global function definition named by symbol. An error is signalled if the symbol has no function definition; see fboundp. Note that the definition may be an object representing a special form or macro. In the latter case, it is an error to attempt to invoke the object as a function." Note that the only valid object which may be returned is something of type function (if the symbol has a global function definition). This is obvious from the last sentence in the paragraph above. Since you claim any object can be stored and that the retrieved value must be EQL, then any object can be retrieved. This is totally contradictory to the quoted paragraph above. It very explicitly states in which cases it is an error to invoke the object as a function, and the case you are establishing is not covered. As far as allowing a lambda as the function cell, CLtL states that an implementation is at liberty to always compile its code. If the lambda must be left in its original state, then the implementation has to compile every time a function is called, rather than when one is defined! John Diamant Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs Fort Collins, CO  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 22:25:46 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Apr 86 07:41:17 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11242; Fri 4-Apr-86 10:38:03-EST Date: Fri, 4 Apr 86 10:37 EST From: David C. Plummer Subject: Excuse me? To: "BACH::GREEK" , common-lisp In-Reply-To: The message of 3 Apr 86 15:08-EST from "BACH::GREEK" Supersedes: <860404103736.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860404103752.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 3 Apr 86 15:08:00 EST From: "BACH::GREEK" You don't really mean that all of the lexical variables in a program should be interned when the fastload file is loaded. Do you? Excuse me, lexical variables aren't interned, print names are. Maybe you are asking if there is any direct correlation between the lexical variable and the symbol it was named in the program. No, there is no direct correlation in the Symbolics implementation. There is an indirect association for debugging purposes, but execution of compiled code never looks there.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 22:24:24 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Apr 86 07:40:54 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11241; Fri 4-Apr-86 10:37:48-EST Date: Fri, 4 Apr 86 10:37 EST From: David C. Plummer Subject: Excuse me? To: "BACH::GREEK" , common-lisp In-Reply-To: The message of 3 Apr 86 15:08-EST from "BACH::GREEK" Message-ID: <860404103736.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 3 Apr 86 15:08:00 EST From: "BACH::GREEK" You don't really mean that all of the lexical variables in a program should be interned when the fastload file is loaded. Do you? Excuse me, lexical variables aren't interned, symbols are. Maybe you are asking if there is any direct correlation between the lexical variable and the symbol it was named in the program. No, there is no direct correlation in the Symbolics implementation. There is an indirect association for debugging purposes, but execution of compiled code never looks there.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 22:21:10 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 4 Apr 86 06:35:44 PST Date: 4 Apr 1986 09:35-EST Sender: NGALL@G.BBN.COM Subject: Re: EVAL-WHEN From: NGALL@G.BBN.COM To: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: Bobrow.pa@XEROX.COM, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM] 4-Apr-86 09:35:03.NGALL> In-Reply-To: <12196029728.56.BROOKS@OZ.AI.MIT.EDU> Date: Thu 3 Apr 86 22:52:12-EST From: "Rodney A. Brooks" To: Bobrow.pa@XEROX.COM Subject: Re: EVAL-WHEN In-Reply-To: <860403-181205-2031@Xerox> Message-ID: <12196029728.56.BROOKS@OZ.AI.MIT.EDU> Doesn't (setf (symbol-function 'foo) (COPY '(LAMBDA ...))) guarantee to produce a function definition not compiled by compiling the file. If (setf (symbol-function 'foo) ...) compiles, then all bets are off. There is no requirement in CLtL that it be legal for a symbol function cell to contain a lambda expression. In some implementations this will cause an error when such a symbol is used in the function position of an eval-ed expression. These implementations place a closure in symbol function cells for interpreted functions, which all point to the same compiled code sequence which takes a literal from the closure (the literal is the lambda expression) and does the right call into the middle of the interpreter. ------- -------------------- This should definitely be pointed out on page 90. Also, exactly what objects may be the value in a setf of (symbol-function <>) should be clarified. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 21:15:42 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Apr 86 11:02:02 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 APR 86 11:02:58 PST Date: 4 Apr 86 10:37 PST From: Bobrow.pa@Xerox.COM Subject: Re: Dave Moon's summary of EVAL-WHEN issues. In-reply-to: "BACH::GREEK" 's message of 4 Apr 86 08:48:00 EST To: common-lisp@su-ai.ARPA cc: Bobrow.pa@Xerox.COM Message-ID: <860404-110258-2543@Xerox> If EVAL-WHEN and DO-WHEN have the wrong connotation, how about USE-WHEN as less specific.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 20:53:41 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 4 Apr 86 07:55:13 PST Received: from katherine by GODOT.THINK.COM via CHAOS; Fri, 4 Apr 86 10:55:52 est Date: Fri, 4 Apr 86 10:57 EST From: Guy Steele Subject: Re: EVAL-WHEN To: NGALL@G.BBN.COM, BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: Bobrow.pa@XEROX.COM, common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <[G.BBN.COM] 4-Apr-86 09:35:03.NGALL> Message-Id: <860404105729.2.GLS@THINK-KATHERINE.ARPA> Date: 4 Apr 1986 09:35-EST From: NGALL@G.BBN.COM Date: Thu 3 Apr 86 22:52:12-EST From: "Rodney A. Brooks" Doesn't (setf (symbol-function 'foo) (COPY '(LAMBDA ...))) guarantee to produce a function definition not compiled by compiling the file. If (setf (symbol-function 'foo) ...) compiles, then all bets are off. There is no requirement in CLtL that it be legal for a symbol function cell to contain a lambda expression. In some implementations this will cause an error when such a symbol is used in the function position of an eval-ed expression. These implementations place a closure in symbol function cells for interpreted functions, which all point to the same compiled code sequence which takes a literal from the closure (the literal is the lambda expression) and does the right call into the middle of the interpreter. This should definitely be pointed out on page 90. Also, exactly what objects may be the value in a setf of (symbol-function <>) should be clarified. I would contend that any Lisp object may be the value in a setf of (symbol-function ), and that a subsequent invocation of (symbol-function ) should retrieve exactly that object (or one EQL to it). However, this does not prevent implementations from wrapping that object in a closure internally on storing and unwrapping it again on fetching. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 20:51:23 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 4 Apr 86 07:46:53 PST Received: from katherine by GODOT.THINK.COM via CHAOS; Fri, 4 Apr 86 10:47:30 est Date: Fri, 4 Apr 86 10:49 EST From: Guy Steele Subject: EVAL-WHEN To: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860403182353.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <860404104902.1.GLS@THINK-KATHERINE.ARPA> Date: Thu, 3 Apr 86 18:23 -EST From: David A. Moon Date: 1 Apr 86 09:14:00 EST From: "BACH::GREEK" Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1, no less).... I agree with you. EVAL-WHEN is intended to control when the normal processing of its body is done and is not intended to imply that that processing is done by the function EVAL. The choice of name is perhaps poor. But DO-WHEN, the obvious alternative, is even worse. We really don't have very good terminology for discussing these issues. A related issue, that has been brought up before, is that sometimes it is useful for a macro to be able to determine the expansion context (top-level, interior form, compiled, interpreted, etc.). --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 19:19:30 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Apr 86 14:52:39 PST Received: ID ; Fri 4 Apr 86 17:53:15-EST Date: Fri, 4 Apr 1986 17:53 EST Message-ID: Sender: WHOLEY@C.CS.CMU.EDU From: Skef Wholey To: Pavel.pa@XEROX.COM Cc: Common-Lisp@SU-AI.ARPA Subject: EVAL-WHEN In-reply-to: Msg of 4 Apr 1986 17:37-EST from Pavel.pa at Xerox.COM Gosh, how about reviving a Lisp-tradition of using nomenclature specific to computers and architectures -- the same that gave us CAR and CDR. Looking at the PDP-10 instruction set, upon which the venerable MacLisp and Interlisp spent most of their lives, we might arrive at XCT-WHEN. Spelling it as normal people might, how about EXECUTE-WHEN? --Skef  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 17:49:19 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 4 Apr 86 14:38:37 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 APR 86 14:37:08 PST Date: Fri, 4 Apr 86 14:37:03 PST From: Pavel.pa@Xerox.COM Subject: Re: EVAL-WHEN In-reply-to: <860404154845.4.JPG@AUK.SCRC.Symbolics.COM> To: Common-Lisp@SU-AI.ARPA Message-ID: <860404-143708-2836@Xerox> > Moon's English suggests PROCESS-WHEN . Please don't use any names with the word ``process''; eventually there will be a multiprocessing proposal and it would be a pity to have certain associations made. Pavel  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 17:45:21 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 4 Apr 86 06:00:16 PST Date: 4 Apr 86 08:48:00 EST From: "BACH::GREEK" Subject: Dave Moon's summary of EVAL-WHEN issues. To: "common-lisp" Reply-To: "BACH::GREEK" Thank you. This summarizes the issues quite well. My suggestion that there is another EVAL-WHEN situation was prompted by one simple desire. There is no way to tell the compiler to digest a DEFMACRO for purposes of future expansion, but not to evaluate it or dump it in the fastload file. What I want is: (EVAL-WHEN (COMPILER-DIGEST) (DEFMACRO ... I don't want to say (EVAL-WHEN (COMPILE) ...) because I don't want to change my global environment. I don't want to say (EVAL-WHEN (LOAD) ...) because I don't want it dumped. I certainly agree that "EVAL-WHEN" is a real misnomer for this sort of capability. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Apr 86 16:22:58 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Apr 86 12:48:44 PST Received: from AUK.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11302; Fri 4-Apr-86 15:49:20-EST Date: Fri, 4 Apr 86 15:48 EST From: Jeffrey P. Golden Subject: EVAL-WHEN To: gls@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <860404104902.1.GLS@THINK-KATHERINE.ARPA> Message-ID: <860404154845.4.JPG@AUK.SCRC.Symbolics.COM> Date: Fri, 4 Apr 86 10:49 EST From: Guy Steele Date: Thu, 3 Apr 86 18:23 -EST From: David A. Moon Date: 1 Apr 86 09:14:00 EST From: "BACH::GREEK" Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1, no less).... I agree with you. EVAL-WHEN is intended to control when the normal processing of its body is done and is not intended to imply that that processing is done by the function EVAL. The choice of name is perhaps poor. But DO-WHEN, the obvious alternative, is even worse. Moon's English suggests PROCESS-WHEN .  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 23:01:49 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Apr 86 19:50:28 PST Date: Thu 3 Apr 86 22:52:12-EST From: "Rodney A. Brooks" Subject: Re: EVAL-WHEN To: Bobrow.pa@XEROX.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <860403-181205-2031@Xerox> Message-ID: <12196029728.56.BROOKS@OZ.AI.MIT.EDU> Doesn't (setf (symbol-function 'foo) (COPY '(LAMBDA ...))) guarantee to produce a function definition not compiled by compiling the file. If (setf (symbol-function 'foo) ...) compiles, then all bets are off. There is no requirement in CLtL that it be legal for a symbol function cell to contain a lambda expression. In some implementations this will cause an error when such a symbol is used in the function position of an eval-ed expression. These implementations place a closure in symbol function cells for interpreted functions, which all point to the same compiled code sequence which takes a literal from the closure (the literal is the lambda expression) and does the right call into the middle of the interpreter. -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 21:23:18 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Apr 86 18:14:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 APR 86 18:12:05 PST Date: 3 Apr 86 18:12 PST From: Bobrow.pa@Xerox.COM Subject: Re: EVAL-WHEN In-reply-to: David A. Moon 's message of Thu, 3 Apr 86 18:23 -EST To: Moon@SCRC-STONY-BROOK.ARPA cc: Common-Lisp@SU-AI.ARPA Message-ID: <860403-181205-2031@Xerox> In fact I know of no way that is guaranteed to produce an interpreted definition. Perhaps this is good, since I believe there are some implementations that don't have an interpreter, but simply compile everything. Doesn't (setf (symbol-function 'foo) (COPY '(LAMBDA ...))) guarantee to produce a function definition not compiled by compiling the file. If (setf (symbol-function 'foo) ...) compiles, then all bets are off.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 19:25:55 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Apr 86 16:06:58 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 454886; Thu 3-Apr-86 18:26:12-EST Date: Thu, 3 Apr 86 18:23 -EST From: David A. Moon Subject: EVAL-WHEN To: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 1 Apr 86 09:14-EST from "BACH::GREEK" Message-ID: <860403182353.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 1 Apr 86 09:14:00 EST From: "BACH::GREEK" Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1, no less). I think, however, that the case of (EVAL-WHEN (LOAD) (DEFUN...)) is straightforward. When the book says that "the compiler should arrange to evaluate the forms in the body when the compiled file ... is loaded", it means that the DEFUN should be evaluated to produce its effect of stashing a function in the symbol's definition. I don't think anyone meant to imply that the body of the DEFUN had to be processed in any particular fashion (e.g., macroexpanding it at load time). But I'll acknowledge that it's not precisely clear. I agree with you. EVAL-WHEN is intended to control when the normal processing of its body is done and is not intended to imply that that processing is done by the function EVAL. The choice of name is perhaps poor. If you do want the DEFUN to be processed as if it was entered at top-level, you might do the following, which will produce an interpreted definition: (EVAL-WHEN (LOAD) (EVAL '(DEFUN ...)) ) EVAL of a quoted expression is the way I tell people to do it, however I don't think the Common Lisp language guarantees that the compiler is not smart enough to figure out what it thought you meant and compile the defun anyway. In fact I know of no way that is guaranteed to produce an interpreted definition. Perhaps this is good, since I believe there are some implementations that don't have an interpreter, but simply compile everything. A related question is what to do with other sorts of top-level forms, not DEFUNs or DEFMACROS. Some LISPs have a (perhaps secret) switch which determines whether the compiler dumps anonymous compiled functions or dumps the lists and interprets them at load time. There may be demantic differences resulting from the choice. See below. A couple of other questions have been asked before and never really answered. Are EVAL-WHENs allowed down in the guts of a function or macro and what do they mean there? The discussion on page 66 that everybody hates was intended to rule out EVAL-WHEN inside the guts of a function or a macro. I cannot think of a meaningful interpretation of EVAL-WHEN in this position. Also, would it clarify things if we acknowledged the fourth EVAL-WHEN situation, that of the compiler digesting a definition without actually evaluating it? This occurs, for example, when the compiler sees a DEFMACRO. It doesn't evaluate it per se, but it does digest it enough to be able to expand future macro calls. It's not sufficient to say that DEFMACRO is a special case and the compiler always looks at it, because the compiler doesn't look if it's wrapped in an (EVAL-WHEN (EVAL) ...). This implies that there is some secret situation that has been left out of the list. I don't think this is EVAL-WHEN. EVAL-WHEN controls when the normal processing would happen. What you are asking for, and I think this is reasonable, is a way to control what processing happens, rather than when it happens. A new feature to do this could be wedged into EVAL-WHEN, since obviously EVAL-WHEN was designed to be extensible, but I'm not sure that's the place to put it that makes the most sense. In summary, I see three issues here: (1) The name of EVAL-WHEN leads to confusion since this special form is not actually related to the EVAL function. Should this problem be attacked by changing the name or by documenting it better? (2) The specification needs to clarify in which positions EVAL-WHEN is allowed, in which positions it is forbidden, and in which positions it is up to the implementation. This relates to the issue about the positions in which DEFUN is allowed. (3) It would be useful to have a way to turn off the compiler's normal processing of a form. Some discussion of exactly what this means may be in order.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 15:40:51 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 3 Apr 86 12:30:01 PST Date: 3 Apr 86 15:08:00 EST From: "BACH::GREEK" Subject: Excuse me? To: "common-lisp" Reply-To: "BACH::GREEK" You don't really mean that all of the lexical variables in a program should be interned when the fastload file is loaded. Do you? - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 15:29:21 EST Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 3 Apr 86 12:14:01 PST Date: Thu, 3 Apr 1986 15:02 EST Message-ID: Sender: DICK%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: Dick@MC.LCS.MIT.EDU To: common-lisp@SU-AI.ARPA A few days ago I sent out a message about LetS. Apparently because it was too long, it did not get through to all of the recipients. I am including a shortened form of the message below. I apologize to all the people who are getting this twice. Dick Waters SHORTENED LETS MESSAGE This message advertises a Common Lisp macro package called LetS (rhymes with lettuce) which it is hoped will become a standard iteration facility in Common Lisp. LetS makes it possible to write a wide class of algorithms which are typically written as loops in a functional style which is similar to expressions written with the Common Lisp sequence functions. LetS supports a number of features which make LetS expressions more expressive than sequence expressions. However, the key feature of LetS is that every LetS expression is automatically transformed into an efficient iterative loop. As a result, unlike sequence expressions, LetS expressions are just as efficient as the traditional loop expressions they replace. Extensive documentation of LetS is in the file "DICK;LETSD >" on the MIT-AI machine. You are invited to read this documentation and make comments on it. I am interested in getting as wide a feedback as possible. If you cannot access the documentation file directly, send me your US mail address and I will mail you a copy. After an initial testing and feedback period, a final version of LetS which runs under all Common Lisps will be created along with formal documentation. This should happen within a couple of months. The following is a couple of examples of using LetS This sums up the positive elements in a vector. (defun sum-pos-vect-lets (v) (Rsum (Tplusp (Evector v)))) Automatic mapping is used for ordinary fns applied to series of values. (defun sum-cube-abs-vect (v) (Rsum (expt (abs (Evector v)) 3))) (sum-cube-abs-vect #(1 -2 3)) => (+ 1 8 27) => 36 New series functions can be defined by using the form defunS. (defunS Rsum (numbers) (declare (series numbers)) (reduceS #'+ 0 numbers)) LetS provides two forms (LetS and LetS*) which are analogous to let and let*. (defun mean-and-deviation (observations) (letS* ((ob (Elist observations)) (num-obs (Rlength ob)) (mean (/ (Rsum ob) num-obs)) (deviation (- (/ (Rsum (expt ob 2)) num-obs) (expt mean 2)))) (list mean deviation)))  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 13:59:00 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 3 Apr 86 10:41:24 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11125; Thu 3-Apr-86 13:41:35-EST Date: Thu, 3 Apr 86 13:41 EST From: David C. Plummer Subject: [JAR@MC.LCS.MIT.EDU: changes] To: Guy Steele , common-lisp@SU-AI.ARPA, JAR@MIT-MC.ARPA In-Reply-To: <860403105630.5.GLS@THINK-KATHERINE.ARPA> Message-ID: <860403134125.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 3 Apr 86 10:56 EST From: Guy Steele From the SCHEME mailing list: Date: Tue, 1 Apr 86 21:42:41 EST From: Jonathan A Rees To: RRRS-AUTHORS@MC.LCS.MIT.EDU Message-Id: <[MC.LCS.MIT.EDU].869021.860401.JAR> I intend to add all the hyperbolic trig functions to Scheme. Also, the gamma function, Bessel functions, and Legendre polynomials. I use these all the time and don't know how anyone gets by without them. I never use them, but Chebychev are used all the time for generating FM modulated audio waves. I think Scheme numbers are really ad hoc. The ring should be a required argument to +, *, etc. so that they know where the answer should come from. (E.g. (+ 4 7 (MOD Z 5)) ==> 1.) That's not the way to do it at all. The right way to do it is extend numbers, not functions. That leaves + unchanged. Coersion rules apply, and error checking is in force. For example, the way you do the above is not (+ 4 7 (mod z 5)) but rather (+ (coerce 4 '(mod 5)) (coerce 7 '(mod 5))) => #<1 mod 5> Coersion lets you do (+ (coerce 4 '(mod 5)) 7) to get the same answer, but (+ (coerce 4 '(mod 5)) (coerce 7 '(mod 6))) is an error because of incompatible moduli. Scheme should support arithmetic mod N, polynomial arithmetic, and arithmetic in arbitrary algebraic number fields. Complex number fall out as a special case: (SQRT -1 (MOD (POLY R) (LAMBDA (X) (+ (* X X) 1 R)))) ==> 1i Again, don't extend arithmetic, extend numbers: (sqrt (coerce -1 )) This should be easy to implement. I don't see why we need all these random special forms. For example, there's no need to have QUOTE or LAMBDA. We can write (SET! (X Y Z) (+ X (* Y Z N) N)) instead of (LAMBDA (X Y Z) (+ X (* Y Z N) N)). No ambiguity will result because if the first thing is a list then obviously the expression can't be an assignment. Similarly, we should be writing (SET! (D #(A (B C) 4))) instead of (QUOTE (D #(A (B C) 4))) because what would one-argument SET! mean? I like this! I don't understand why there's no existential quantifer in Scheme. For example, I often find myself wanting to write (EXISTS (X) (AND (MEMQ X L1) (MEMQ X L2))) to find out whether the lists L1 and L2 intersect. Doesn't scheme support prolog YET? If we have first-class continuations I don't see any reason why we shouldn't have first-class stores also. E.g. (LET ((Z (CONS 1 2))) (CALL-WITH-CURRENT-STORE (LAMBDA (S) (SET-CAR! Z 3) (LIST (CAR Z) (S (LAMBDA () (CAR Z))))))) ==> (3 1) And while we're on the subject of modules, why don't we just adopt Common Lisp's package system wholesale? It's really useful and elegant. Also Zetalisp's LOOP construct is really good. I'll put all these features in the report (Penguin Books has already expressed interest, by the way) unless people send me enough money. Modestly, Jonathan Rees Editor  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 13:46:12 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 Apr 86 10:33:29 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 APR 86 10:31:45 PST Date: 3 Apr 86 10:32 PST From: Gregor.pa@Xerox.COM Subject: Re: packages, lexical variables, and compiling In-reply-to: David C. Plummer 's message of Thu, 3 Apr 86 11:58 EST To: DCP@SCRC-QUABBIN.ARPA cc: smh@MIT-EMS.ARPA, greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA Message-ID: <860403-103145-1391@Xerox> I think there are two answers to "Haflich's little program". Answer 1: Any program that depends on the order that various symbols are interned to work correctly should do so explicitly. At the beginning of the program there should be all the make-packages, shadows and lists of symbols to be interned in the correct order. To depend on the order that various symbols are loaded implicitly (i.e. by depending on the order in which functions which use those symbols are loaded) is just asking for trouble. Answer 2: Programmers should be allowed to assume that "as much as is possible" loading a compiled file and loading the source file have the same effect. I guess I believe both of these answers, and so I think CLtL should require that the symbols be interned. But I can't think of a reasonable coding style that would *really* depend on this feature. P.S. Option 2, "CLtL requires that the symbols not be created", clearly doesn't make any sense at all for all the reasons mentioned by DCP and other reasons as well.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 13:23:17 EST Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Apr 86 09:53:06 PST Date: Thu, 3 Apr 86 12:48 EST From: David.Dill@A.CS.CMU.EDU (C410DD60) To: common-lisp@SU-AI.ARPA Subject: internal symbol preservation Message-Id: <03Apr86.124832.DD60@A.CS.CMU.EDU> "::" should be regarded as a convenience feature of the programming environment, and should not be used in programs. Internal symbols are internal because they are not supposed to be accessed from outside of the package. The obvious right thing is that a common lisp implementation should not feel obliged to keep internal symbols around just so they can be accessed from outside of the package. Early drafts of the package chapter said this, but apparently this was changed as one of many unimprovements.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 12:17:55 EST Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 3 Apr 86 08:59:02 PST Received: from FIREBIRD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 82729; Thu 3-Apr-86 11:59:29-EST Date: Thu, 3 Apr 86 11:58 EST From: David C. Plummer Subject: packages, lexical variables, and compiling To: Steven Haflich , "BACH::GREEK" , common-lisp@SU-AI.ARPA In-Reply-To: <8604030501.AA06396@mit-ems.ARPA>, The message of 3 Apr 86 09:03-EST from "BACH::GREEK" Message-ID: <860403115830.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 3 Apr 86 00:01:56 est From: Steven Haflich [Bottom line: I don't think this has anything to do with the language. Instead, I think we are slopping over into program environment issues (again).] Consider the file foo.lisp: (IN-PACKAGE "MYPACKAGE") (DEFUN FOO (X) (LET ((X-PLUS-1 (1+ X))) (LIST X X-PLUS-1))) Loading foo.lisp into any common lisp has the side effect of creating package MYPACKAGE if it does not yet exist, and also creating symbols MYPACKAGE::FOO, MYPACKAGE::X, and MYPACKAGE::X-PLUS-1 if any of these do not exist. So much is clear. If foo.lisp is compiled to produce foo.bin, and foo.bin is later loaded into a different lisp world, clearly package MYPACKAGE and symbol MYPACKAGE:FOO must be created if they do not yet exist. But what about symbols MYPACKAGE::X and MYPACKAGE::X-PLUS-1 ? The symbolics implementation will create the symbols MYPACKAGE::X and MYPACKAGE::X-PLUS-1. They are stored in something called the debugging-info info. The function ARGLIST (not part of CL, one of our extensions) will pluck the arglist stored in the debugging-info. In addition, it is possible to declare what the values are; any symbols there will be in the resulting environment and ARGLIST will also return them as the second value. Furthermore, X-PLUS-1 will be stored in a part of the debugging-info that the debugger can find. Thus if there was an error, the debugger would know that X-PLUS-1 not only IS a variable, but where it is (on the stack, in a lexical environment, whatever) and actually >>build an environment that has the current lexical state of the function in it<< and use that environment for the read-eval-print loop. What does this have to do with CLtL?? Absolutely NOTHING! The existence of symbols naming these lexical variables is not required for execution of the function. (A clever compiler could even optimize X-PLUS-1 away.) Still, it is easy for a program to tell whether these symbols exist, and it is possible to construct package interlocutions which will fail depending on whether or not the symbols are created. There are three possibilities: 1 - CLtL requires that the symbols are created (although some implementations fail to do so), preserving interpreter-compiler consistency. This is not needed for simple systems that do not have a lexical debugger or something like the ARGLIST function. It may be a bit tricky for those systems that do renames of local variables and functions (as discussed in the scoping problems of inlinifying FLET and LABELS). 2 - CLtL requires that the symbols not be created, which saves storage but loses interpreter-compiler consistency. All implementations that include a somewhat powerful programming environment will therefore be incompatible with CLtL. 3 - CLtL explicitly leaves it up to the implementation. This gets my vote. Unless I have missed something, CLtL is silent on the matter. This is *not* quite the same as leaving it up to the implementation. Should the language definition be more specific? Maybe yes, maybe no. I vote no for the reasons stated above. I think the real question is this: What programs will work incorrectly if they depend on package non-polution? Isn't that what you are really worried about? X and X-PLUS-1 will not have a global value nor a global definition, nor a property list. It is as if I typed 'X and 'X-PLUS-1 at the interpreter. Typing at READ (probably of the read-eval-print loop) will either use existing symbols, create new ones if you are writing new code, or >>create new ones if you happen to make a typo<<. Are you careful to UNINTERN your typos? Date: 3 Apr 86 09:03:00 EST From: "BACH::GREEK" A couple of comments on Mr. Haflich's little program. First of all, I don't think it's absolutely clear that the compiler is obliged to create MYPACKAGE if it can somehow avoid it. After all, it's really nice if the compiler leaves the global environment alone. Implementation of this nicety is another matter, however. I don't think this is what Steven Haflich meant, or at least said. He said the compiler had to cause MYPACKAGE to be created >>in the lisp environment the compiled file is later loaded into<<. Secondly, I don't think it's so easy for the interpreter to detect the presence of the lexical symbols. At least not in a correct program. We've carefully constrained all the symbol-hacking functions to work only on the dynamic (global) aspects of symbols. Therefore the compiler need not create real symbols for lexical variables. I agree with this except for when you "enter the debugger," whatever that means in various systems. In the Symbolics implementation, it means quite a bit as I stated above. The program is correct, and the read-eval-print loop (what I think you mean by the interpreter) DOES get the lexical symbols into its environment. Again, the debugger is not part of CLtL, and therefore CLtL says nothing and can say nothing about its 'correctness'.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 11:05:12 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Apr 86 07:54:26 PST Received: from katherine by GODOT.THINK.COM via CHAOS; Thu, 3 Apr 86 10:55:00 est Date: Thu, 3 Apr 86 10:56 EST From: Guy Steele Subject: [JAR@MC.LCS.MIT.EDU: changes] To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <860403105630.5.GLS@THINK-KATHERINE.ARPA> From the SCHEME mailing list: Date: Tue, 1 Apr 86 21:42:41 EST From: Jonathan A Rees To: RRRS-AUTHORS@MC.LCS.MIT.EDU Message-Id: <[MC.LCS.MIT.EDU].869021.860401.JAR> I intend to add all the hyperbolic trig functions to Scheme. Also, the gamma function, Bessel functions, and Legendre polynomials. I use these all the time and don't know how anyone gets by without them. I think Scheme numbers are really ad hoc. The ring should be a required argument to +, *, etc. so that they know where the answer should come from. (E.g. (+ 4 7 (MOD Z 5)) ==> 1.) Scheme should support arithmetic mod N, polynomial arithmetic, and arithmetic in arbitrary algebraic number fields. Complex number fall out as a special case: (SQRT -1 (MOD (POLY R) (LAMBDA (X) (+ (* X X) 1 R)))) ==> 1i This should be easy to implement. I don't see why we need all these random special forms. For example, there's no need to have QUOTE or LAMBDA. We can write (SET! (X Y Z) (+ X (* Y Z N) N)) instead of (LAMBDA (X Y Z) (+ X (* Y Z N) N)). No ambiguity will result because if the first thing is a list then obviously the expression can't be an assignment. Similarly, we should be writing (SET! (D #(A (B C) 4))) instead of (QUOTE (D #(A (B C) 4))) because what would one-argument SET! mean? I don't understand why there's no existential quantifer in Scheme. For example, I often find myself wanting to write (EXISTS (X) (AND (MEMQ X L1) (MEMQ X L2))) to find out whether the lists L1 and L2 intersect. If we have first-class continuations I don't see any reason why we shouldn't have first-class stores also. E.g. (LET ((Z (CONS 1 2))) (CALL-WITH-CURRENT-STORE (LAMBDA (S) (SET-CAR! Z 3) (LIST (CAR Z) (S (LAMBDA () (CAR Z))))))) ==> (3 1) And while we're on the subject of modules, why don't we just adopt Common Lisp's package system wholesale? It's really useful and elegant. Also Zetalisp's LOOP construct is really good. I'll put all these features in the report (Penguin Books has already expressed interest, by the way) unless people send me enough money. Modestly, Jonathan Rees Editor  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 11:02:59 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Apr 86 07:50:12 PST Received: from katherine by GODOT.THINK.COM via CHAOS; Thu, 3 Apr 86 10:50:45 est Date: Thu, 3 Apr 86 10:52 EST From: Guy Steele Subject: Common Lisp Problems - Can't write a code walker To: Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860401-142807-1904@Xerox> Message-Id: <860403105214.4.GLS@THINK-KATHERINE.ARPA> Date: 1 Apr 86 13:27 PST From: Gregor.pa@Xerox.COM This is the first of a few messages describing the problems I have had with Common Lisp while writing Portable Common Loops.... ... 3- Implementations have special forms in their extended lisps that are not Common Lisp special forms. I don't know if there is anything we can do about this, but I thought I would mention it. (I suppose we could agree on a common syntax for defining code walker templates and a common mechanism for retrieving them but that doesn't seem too likely). Such implementations are in violation of the Common Lisp specification. Page 57 of CLtL is very clear about this. An implementation of Common Lisp is NOT free simply to randomly add a new special form as an "extension"; it must also provide an equivalent macro definition so that MACROEXPAND may be used to get rid of it for purposes of program analysis.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 09:28:59 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 3 Apr 86 06:19:13 PST Date: 3 Apr 86 09:03:00 EST From: "BACH::GREEK" Subject: Lexical variables and compilation. To: "common-lisp" Reply-To: "BACH::GREEK" A couple of comments on Mr. Haflich's little program. First of all, I don't think it's absolutely clear that the compiler is obliged to create MYPACKAGE if it can somehow avoid it. After all, it's really nice if the compiler leaves the global environment alone. Implementation of this nicety is another matter, however. Secondly, I don't think it's so easy for the interpreter to detect the presence of the lexical symbols. At least not in a correct program. We've carefully constrained all the symbol-hacking functions to work only on the dynamic (global) aspects of symbols. Therefore the compiler need not create real symbols for lexical variables. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Apr 86 00:11:44 EST Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 2 Apr 86 21:02:40 PST Received: by mit-ems.ARPA (4.12/4.8) id AA06396; Thu, 3 Apr 86 00:01:56 est Date: Thu, 3 Apr 86 00:01:56 est From: Steven Haflich Message-Id: <8604030501.AA06396@mit-ems.ARPA> To: common-lisp@suai Subject: packages, lexical variables, and compiling Consider the file foo.lisp: (IN-PACKAGE "MYPACKAGE") (DEFUN FOO (X) (LET ((X-PLUS-1 (1+ X))) (LIST X X-PLUS-1))) Loading foo.lisp into any common lisp has the side effect of creating package MYPACKAGE if it does not yet exist, and also creating symbols MYPACKAGE::FOO, MYPACKAGE::X, and MYPACKAGE::X-PLUS-1 if any of these do not exist. So much is clear. If foo.lisp is compiled to produce foo.bin, and foo.bin is later loaded into a different lisp world, clearly package MYPACKAGE and symbol MYPACKAGE:FOO must be created if they do not yet exist. But what about symbols MYPACKAGE::X and MYPACKAGE::X-PLUS-1 ? The existence of symbols naming these lexical variables is not required for execution of the function. (A clever compiler could even optimize X-PLUS-1 away.) Still, it is easy for a program to tell whether these symbols exist, and it is possible to construct package interlocutions which will fail depending on whether or not the symbols are created. There are three possibilities: 1 - CLtL requires that the symbols are created (although some implementations fail to do so), preserving interpreter-compiler consistency. 2 - CLtL requires that the symbols not be created, which saves storage but loses interpreter-compiler consistency. 3 - CLtL explicitly leaves it up to the implementation. Unless I have missed something, CLtL is silent on the matter. This is *not* quite the same as leaving it up to the implementation. Should the language definition be more specific?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Apr 86 14:05:33 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 2 Apr 86 10:41:29 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10927; Wed 2-Apr-86 13:41:44-EST Date: Wed, 2 Apr 86 13:41 EST From: David C. Plummer Subject: The Environment To: "BACH::GREEK" , common-lisp In-Reply-To: The message of 2 Apr 86 12:27-EST from "BACH::GREEK" Message-ID: <860402134140.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 2 Apr 86 12:27:00 EST From: "BACH::GREEK" Whew, I have to be careful what I imply in my messages. I certainly wasn't suggesting that we define the internal format of the environment, only how the user sees it in terms of interface. Mr. Plummer and I agree on this point. Still, do you think we can all agree on the interface, and thus the semantics? I think we should give it a try. I think what you will find are three things: -1- Things everybody agrees on, e.g., .defun variable-defined-p symbol &optional env returns a keyword which is the usage of the variable, one of NIL (unknown) :SPECIAL :LEXICAL :CONSTANT (e.g., :INSTANCE) -2- Things not everybody agrees on -3- Things which are down-and-out hard, e.g., "Which PROG is belongs with this GO-TAG?" I just realized this gets more complicated because there are two classes of programs that are using something called an 'environment' for potentially different reasons. One class is the interpreter, which does know something about GO tags, but the source code of the PROG isn't necessarily in the environment. The other class is a code walker or compiler, which uses a much higher degree of bookkeeping and annotation.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Apr 86 12:57:34 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 2 Apr 86 09:40:16 PST Date: 2 Apr 86 12:27:00 EST From: "BACH::GREEK" Subject: The Environment To: "common-lisp" Reply-To: "BACH::GREEK" Whew, I have to be careful what I imply in my messages. I certainly wasn't suggesting that we define the internal format of the environment, only how the user sees it in terms of interface. Mr. Plummer and I agree on this point. Still, do you think we can all agree on the interface, and thus the semantics? - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Apr 86 12:11:07 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 2 Apr 86 08:48:37 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10890; Wed 2-Apr-86 11:49:13-EST Date: Wed, 2 Apr 86 11:49 EST From: David C. Plummer Subject: The Environment To: "BACH::GREEK" , common-lisp In-Reply-To: The message of 2 Apr 86 11:07-EST from "BACH::GREEK" Message-ID: <860402114909.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 2 Apr 86 11:07:00 EST From: "BACH::GREEK" Gregor has pointed out some of the many problems with writing programs that need to understand the current global environment. There are additional problems caused by the separation of global environment from compilation environment. Not that we all agree on how that separation should work. Do y'all think we could get enough concensus on how the environment should look to the user so that we could add the appropriate support functions to Common LISP? This would lock in at least basic concepts, making it hard to experiment with radically different environments. But that loss might be well worth the gains. If a concensus is possible, I'd be willing to make a rough proposal concerning the representation of symbols attributes and separation of global and compiler environments. This is the wrong direction, since it imposes restrictions on the format of the environment. What would be OK is to define an interface which imposes requirements of the environment. Define the functionality you need, invent some function names, but don't go near the format of the environment.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Apr 86 11:32:30 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 2 Apr 86 08:19:16 PST Date: 2 Apr 86 11:07:00 EST From: "BACH::GREEK" Subject: The Environment To: "common-lisp" Reply-To: "BACH::GREEK" Gregor has pointed out some of the many problems with writing programs that need to understand the current global environment. There are additional problems caused by the separation of global environment from compilation environment. Not that we all agree on how that separation should work. Do y'all think we could get enough concensus on how the environment should look to the user so that we could add the appropriate support functions to Common LISP? This would lock in at least basic concepts, making it hard to experiment with radically different environments. But that loss might be well worth the gains. If a concensus is possible, I'd be willing to make a rough proposal concerning the representation of symbols attributes and separation of global and compiler environments. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Apr 86 11:06:05 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 2 Apr 86 07:54:28 PST Received: from hplabsc by hplabs.ARPA ; Wed, 2 Apr 86 07:53:26 pst Received: by hplabsc ; Wed, 2 Apr 86 07:55:08 pst Date: Wed, 2 Apr 86 07:55:08 pst From: Jim Kempf Message-Id: <8604021555.AA05471@hplabsc> To: common-lisp@su-ai.ARPA Subject: Re:Common Lisp Problems-Can't write a code walker Cc: snyder@hplabsc I'll be interested in seeing further problems that arose with writing a code walker for Portable Common Loops. Some of the problems mentioned in the original posting were addressed in a proposal for modifications to Common Lisp which we felt were needed to portably implement CommonObjects. Alan Snyder presented the document at the December Common Lisp meeting. In particular, querying the environment object passed to macros for information on declarations was mentioned. CommonObjects doesn't do code-walking, since we have an extension to our Common Lisp which allows us to establish macro-like substitutions for symbols (a kind of symbol macro), that was needed in order to implement instance variables with proper scoping. I think that being able to easily implement a portable code-walker in Common Lisp is generally desirable, however. Jim Kempf kempf@hplabs  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Apr 86 19:36:08 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 Apr 86 14:27:21 PST Received: from Cabernet.ms by ArpaGateway.ms ; 01 APR 86 14:28:07 PST Date: 1 Apr 86 13:27 PST From: Gregor.pa@Xerox.COM Subject: Common Lisp Problems - Can't write a code walker To: Common-Lisp@SU-AI.ARPA cc: Gregor.pa@Xerox.COM Message-ID: <860401-142807-1904@Xerox> This is the first of a few messages describing the problems I have had with Common Lisp while writing Portable Common Loops. This message lists some reasons why it is *hard* to write a portable code walker in Common Lisp. This message doesn't propose detailed solutions to these problems, it mostly just states the problems. - You can't query to find the current state of global proclamations. Specifically, you can't ask if a variable has been declared globally special. This doesn't make is impossible to write a code walker since you can write a little piece of code to test if a variable is special, but it is a nuisance. This piece of code from PCL shows the problem: #-(or Symbolics Xerox TI VaxLisp KCL LMI) (defvar *globally-special-variables* ()) (defun variable-globally-special-p (symbol) #+(or Symbolics Lucid TI LMI) (get symbol 'special) #+Xerox (member symbol globalvars) #+VaxLisp (get symbol 'system::globally-special) #+KCL (proclamation `(special ,symbol)) #-(or Symbolics Lucid TI LMI Xerox VaxLisp KCL) (or (not (null (member symbol *globally-special-variables* :test #'eq))) (when (eval `(flet ((ref () ,symbol)) (let ((,symbol '#,(list nil))) (and (boundp ',symbol) (eq ,symbol (ref)))))) (push symbol *globally-special-variables*) t))) KCL has a function called PROCLAMATION which takes the same arguments as proclaim and returns t if that PROCLAIM is in effect. Perhaps Common Lisp should have a function called PROCLAIMP which works the same way as the KCL proclamation function. 2- Lack of clarity and lack of functionality with regard to environments. Common Lisp doesn't *clearly* provide a mechanism to make an environment that has certaion function macro or lexical variable bindings. Or to make an environment that is based on some existing environment but has extra bindings. Or to query an environment about its bindings. In I tried to get around this problem with a weird evalhook macroexpand hack. But it isn't completely portable. CommonLisp needs defined mechanisms for manipulating these environment structures. 3- Implementations have special forms in their extended lisps that are not Common Lisp special forms. I don't know if there is anything we can do about this, but I thought I would mention it. (I suppose we could agree on a common syntax for defining code walker templates and a common mechanism for retrieving them but that doesn't seem too likely).  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Apr 86 11:56:17 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 1 Apr 86 08:45:56 PST Received: from ZACHARY.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 18203; Tue 1-Apr-86 11:49:51-EST Date: Tue, 1 Apr 86 11:47 EST From: Guy Steele Subject: [rose@GODOT.THINK.COM: option for recovering proclamations] To: common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA Message-ID: <860401114720.7.GLS@ZACHARY.THINK.COM> Date: 01 Apr 86 09:15:43 EST (Tue) From: rose@think.THINK.COM You could shadow LISP:PROCLAIM with STARLISP:PROCLAIM, making the latter a macro which squirrels away its info, and also expands to a LISP:PROCLAIM. Package hackery to make this happen: (SHADOW 'LISP:PROCLAIM 'STARLISP-INTERNALS) (EXPORT 'STARLISP-INTERNALS::PROCLAIM 'STARLISP-INTERNALS) (DEFMACRO STARLISP-INTERNALS:PROCLAIM (DECLARATION) `(PROGN (GOBBLE ',DECLARATION) (LISP:PROCLAIM ,DECLARATION))) (DEFMACRO USE-STARLISP () `(PROGN (USE-PACKAGE 'STARLISP) (IMPORT 'STARLISP-INTERNALS:PROCLAIM))) ;; And so: (IN-PACKAGE 'MY-APPLICATION) (USE-STARLISP) (PROCLAIM ...) Small reward. You still have to code-walk for the (DECLARE...) forms.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Apr 86 11:48:47 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 1 Apr 86 08:36:44 PST Received: from ZACHARY.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 18195; Tue 1-Apr-86 11:41:20-EST Date: Tue, 1 Apr 86 11:38 EST From: Guy Steele Subject: [CAL@THINK-AQUINAS.ARPA: declarations] To: common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA Message-ID: <860401113847.5.GLS@ZACHARY.THINK.COM> Return-path: <@GODOT.THINK.COM:CAL@THINK-AQUINAS.ARPA> Received: from GODOT.THINK.COM by THINK-AQUINAS.ARPA via INTERNET with SMTP id 18147; 1 Apr 86 01:47:53-EST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Tue, 1 Apr 86 01:43:38 est Date: Tue, 1 Apr 86 01:45 EST From: Cliff Lasser Subject: declarations To: GLS@THINK-AQUINAS.ARPA Cc: Lispm-users@GODOT.THINK.COM Message-Id: <860401014524.3.CAL@THINK-JEHOSEPHAT.ARPA> If I were to do: (PROCLAIM '(DECLARATION TARGET-LANGUAGE)) (PROCLAIM '(TARGET-LANGUAGE ADA)) would I be able to write code that would uncover that declaration. I couldn't find anything helpful in the CL manual. (ps: This would be very useful)  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Apr 86 09:29:32 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 1 Apr 86 06:19:17 PST Date: 1 Apr 86 09:14:00 EST From: "BACH::GREEK" Subject: EVAL-WHEN To: "common-lisp" Reply-To: "BACH::GREEK" Mr. Fry has begun our bimonthly discussion of EVAL-WHEN (on April 1, no less). I think, however, that the case of (EVAL-WHEN (LOAD) (DEFUN...)) is straightforward. When the book says that "the compiler should arrange to evaluate the forms in the body when the compiled file ... is loaded", it means that the DEFUN should be evaluated to produce its effect of stashing a function in the symbol's definition. I don't think anyone meant to imply that the body of the DEFUN had to be processed in any particular fashion (e.g., macroexpanding it at load time). But I'll acknowledge that it's not precisely clear. If you do want the DEFUN to be processed as if it was entered at top-level, you might do the following, which will produce an interpreted definition: (EVAL-WHEN (LOAD) (EVAL '(DEFUN ...)) ) A related question is what to do with other sorts of top-level forms, not DEFUNs or DEFMACROS. Some LISPs have a (perhaps secret) switch which determines whether the compiler dumps anonymous compiled functions or dumps the lists and interprets them at load time. There may be demantic differences resulting from the choice. A couple of other questions have been asked before and never really answered. Are EVAL-WHENs allowed down in the guts of a function or macro and what do they mean there? Also, would it clarify things if we acknowledged the fourth EVAL-WHEN situation, that of the compiler digesting a definition without actually evaluating it? This occurs, for example, when the compiler sees a DEFMACRO. It doesn't evaluate it per se, but it does digest it enough to be able to expand future macro calls. It's not sufficient to say that DEFMACRO is a special case and the compiler always looks at it, because the compiler doesn't look if it's wrapped in an (EVAL-WHEN (EVAL) ...). This implies that there is some secret situation that has been left out of the list. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Apr 86 05:07:18 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Apr 86 01:54:14 PST Received: from BUDDY.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 Apr 86 04:56-EST Date: Tue, 1 Apr 86 04:54 EST From: Christopher Fry Subject: eval-when ambiguity To: common-lisp@SU-AI.ARPA Message-ID: <860401045418.4.CFRY@BUDDY.AI.MIT.EDU> When compiling a file with a top level call: (eval-when (load) (defun foo () (a-macro)) ) There seem to be 2 possibilites: 1. The definition gets compiled at compile-file time and saved to the file in compiled format 2. The list structure of the call is saved to the file and it's EVALED when the file is loaded. Semantically, the major difference seems to be the time of macroexpansion. I can imagine wanting both functionalities. Which one is CL defined to do? How do you get the other functionality? [keep in mind that the first arg to the eval-when might have compile or eval in it.] In CLtL, p 69, the first 2 paragraphs of the eval-when description are clear and concise. They indicate CL should perform as in 2 above. The succeeding paragraphs, in an attempt to clarify, do exactly the opposite.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 19:28:00 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 16:16:12 PST Date: 31 Mar 1986 19:14-EST Sender: NGALL@G.BBN.COM Subject: Re: predicates for all type specifier symbols From: NGALL@G.BBN.COM To: KMP@SCRC-STONY-BROOK.ARPA Cc: Daniels.PA@XEROX.COM, Common-Lisp@SU-AI.ARPA Cc: clerha@SU-AI.ARPA Message-ID: <[G.BBN.COM]31-Mar-86 19:14:22.NGALL> In-Reply-To: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 31 Mar 86 16:10 EST From: Kent M Pitman To: Daniels.PA@Xerox, NGALL@G.BBN.COM Subject: predicates for all type specifier symbols In-Reply-To: <860331-121028-4949@Xerox> Message-ID: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Actually, the TRUE and FALSE functions I asked for return the constant values true and false. The TP and NILP functions being proposed happen to constantly return true and false, respectively, but do not do so because they are directly defined to do so; they do so because it is a logical consequence of the fact that all things are of type T and no things are of type NIL. In addition to the number of args issues that Daniels pointed out, let me make it clear that I would not be satisfied with these because code written to use them would not be perspicuous. You're right, :TEST #'true is more perspicuous than :TEST #'tp but I think :CONDITION #'condition is the most perspicuous. So we don't need the function TRUE to reduce visual clutter. It would bother me as much as it bothered me to see code in Maclisp that did: (AND FOO (NOT (TERPRI)) (PRINT MESSAGE) ...) Sure, it was defined in Maclisp that TERPRI returned NIL and PRINT returned T but there are times when in spite of definition, it just isn't stylistically appropriate to take advantage of that fact in code that you would want to show your mother. I don't agree with your analogy to TERPRI. The phrase :TEST #'tp means "whatever condition is handed to me is within the set of conditions that I will deal with". Granted its not as perspicuous as :TEST #'conditionp but its not as random as just using any always-true function. While I'm on the subject, let me point out that I consider completeness arguments for having all possible "-P" type predicates to be weak because it only reinforces the arbitrary line between system and user code. User-defined types are not required to have such predicates, and even if they have them, the naming conventions we defaultly assign do not match. If we required the fixing of the way predicates were constructed and removed the user's ability to either inhibit the definition of such predicates or choose an alternate name for such predicates, then we'd be making progress toward linguistic consistency. As it is, I think we're just gonna have to settle for the fact that the names that are there are there for convenience and not for any purist reason. Having accepted that, I don't see a lot of reason for introducing a lot of new predicates. If there were particulars that people had found immensely useful in a variety of circumstances, maybe we could consider adding them on a case-by-case basis. But let's not treat this as a class-action suit. "Class-Action Suit" makes it sound like I'm asking for hundreds of new predicates. I'm asking for 13. I doubt that all (even most of?) the existing predicates are "immensely useful", so why should the few additional ones have to pass such a test. I would find some of them "useful", e.g., fixnump (I didn't understand Moon's objection to this one), sequence, and simple-array. Also, I like the idea embodied in defstruct: If someone defines a type, chances are they would find a predicate useful. I think the same should apply to system defined types. I guess you prefer the idea embodied in deftype, which does not define an associated predicate. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 16:42:36 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 13:29:59 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 451202; Mon 31-Mar-86 16:07:52-EST Date: Mon, 31 Mar 86 16:10 EST From: Kent M Pitman Subject: predicates for all type specifier symbols To: Daniels.PA@Xerox, NGALL@G.BBN.COM cc: Common-Lisp@SU-AI In-Reply-To: <860331-121028-4949@Xerox> Message-ID: <860331161012.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Actually, the TRUE and FALSE functions I asked for return the constant values true and false. The TP and NILP functions being proposed happen to constantly return true and false, respectively, but do not do so because they are directly defined to do so; they do so because it is a logical consequence of the fact that all things are of type T and no things are of type NIL. In addition to the number of args issues that Daniels pointed out, let me make it clear that I would not be satisfied with these because code written to use them would not be perspicuous. It would bother me as much as it bothered me to see code in Maclisp that did: (AND FOO (NOT (TERPRI)) (PRINT MESSAGE) ...) Sure, it was defined in Maclisp that TERPRI returned NIL and PRINT returned T but there are times when in spite of definition, it just isn't stylistically appropriate to take advantage of that fact in code that you would want to show your mother. While I'm on the subject, let me point out that I consider completeness arguments for having all possible "-P" type predicates to be weak because it only reinforces the arbitrary line between system and user code. User-defined types are not required to have such predicates, and even if they have them, the naming conventions we defaultly assign do not match. If we required the fixing of the way predicates were constructed and removed the user's ability to either inhibit the definition of such predicates or choose an alternate name for such predicates, then we'd be making progress toward linguistic consistency. As it is, I think we're just gonna have to settle for the fact that the names that are there are there for convenience and not for any purist reason. Having accepted that, I don't see a lot of reason for introducing a lot of new predicates. If there were particulars that people had found immensely useful in a variety of circumstances, maybe we could consider adding them on a case-by-case basis. But let's not treat this as a class-action suit.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 16:05:52 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 12:48:32 PST Date: 31 Mar 1986 15:47-EST Sender: NGALL@G.BBN.COM Subject: Re: Predicates for all type specifier symbols From: NGALL@G.BBN.COM To: Daniels.PA@XEROX.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]31-Mar-86 15:47:31.NGALL> In-Reply-To: <860331-121028-4949@Xerox> Date: 31 Mar 86 12:10:03 PST (Monday) From: Daniels.PA@Xerox.COM To: NGALL@G.BBN.COM Subject: Re: Predicates for all type specifier symbols In-Reply-To: <[G.BBN.COM]28-Mar-86 11:20:13.NGALL> Message-ID: <860331-121028-4949@Xerox> "Also, If we had TP and NILP we would have the TRUE and FALSE functions that KMP was asking for!" Not quite: TRUE and FALSE take an arbitrary number of arguments and ignore them all. Oops! You're right. I should have said "we would have the TRUE and FALSE functions that are sufficient for reducing the 'visual clutter' mentioned in KMP's error proposal!" -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 15:26:56 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 31 Mar 86 12:15:01 PST Received: from Cabernet.ms by ArpaGateway.ms ; 31 MAR 86 12:10:28 PST Date: 31 Mar 86 12:10:03 PST (Monday) From: Daniels.PA@Xerox.COM Subject: Re: Predicates for all type specifier symbols In-reply-to: <[G.BBN.COM]28-Mar-86 11:20:13.NGALL> To: NGALL@G.BBN.COM cc: common-lisp@SU-AI.ARPA Message-ID: <860331-121028-4949@Xerox> "Also, If we had TP and NILP we would have the TRUE and FALSE functions that KMP was asking for!" Not quite: TRUE and FALSE take an arbitrary number of arguments and ignore them all. -- Andy. --  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 14:47:26 EST Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 31 Mar 86 11:34:03 PST Received: by isi-vaxa.ARPA (4.12/4.7) id AA04101; Mon, 31 Mar 86 11:34:57 pst Message-Id: <8603311934.AA04101@isi-vaxa.ARPA> Date: 31 Mar 1986 1134-PST (Monday) To: common-lisp@su-ai.ARPA From: Neches@ISI-VAXA.ARPA Subject: common-lisp on vaxes under vms? A friend of mine is looking for a version of common-lisp that he could run on a vax under vms. Can anyone tell me who I could suggest that he contact? He is in a university setting, and on a low budget, so it would be best if he could find a version that is either in the public domain or licensed cheaply to universities. Please reply to Neches@isi-vaxa.arpa. Thanks.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 11:36:50 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 31 Mar 86 07:06:26 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 10297; Mon 31-Mar-86 10:05:01-EST Date: Mon, 31 Mar 86 10:05 EST From: David C. Plummer Subject: Predicates for types. To: "BACH::GREEK" , NGALL@G.BBN.COM, Fischer.pa@Xerox.COM, Scott E. Fahlman , Skef Wholey , David A. Moon , common-lisp In-Reply-To: The message of 28 Mar 86 12:32-EST from "BACH::GREEK" , <[G.BBN.COM]28-Mar-86 11:20:13.NGALL>, <860328-143519-3626@Xerox>, , <[G.BBN.COM]29-Mar-86 15:54:53.NGALL>, , , <860329215031.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860331100506.8.DCP@FIREBIRD.SCRC.Symbolics.COM> One reason to have specific predicates is efficiency. This is not just an implementation detail hidden by the compiler, such as (typecase foo (fixnum ...) (integer ...) (number ...) ...) or (typep foo 'number) I admit the user should probably use those constructs instead of the -P predicates and instead let the compiler do the fun. Other constructs, however, do not lend themselves to this abstraction. Would you rather type (count-if #'integerp sequence) or (count-if #'(lambda (object) (typep object 'integer)) sequence) ?? In addition to which would you rather type, which would you rather read in somebody else's code?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 11:00:04 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 31 Mar 86 07:48:27 PST Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 31 Mar 86 10:49:04 est Date: Mon, 31 Mar 86 10:50 EST From: Guy Steele Subject: Re: Predicates for all type specifier symbols To: Fischer.pa@Xerox.COM, NGALL@G.BBN.COM Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <860328-143519-3626@Xerox> Message-Id: <860331105045.2.GLS@GUIDO.THINK.COM> Date: 28 Mar 86 14:35 PST From: Fischer.pa@Xerox.COM Why do we need any predicate aside from TYPEP? (ron) [Sign on a paper towel dispenser] Why take two when one will do? [Graffito immediately beneath] For gracious living. We don't need anything beyond TYPEP, but in some cases INTEGERP or ATOM is easier to recognize. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 31 Mar 86 09:28:30 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 31 Mar 86 06:20:17 PST Date: 31 Mar 86 09:16:00 EST From: "BACH::GREEK" Subject: Type predicates. To: "common-lisp" Reply-To: "BACH::GREEK" We need all of the type predicates currently in Common LISP because removing them would break every program in existence. However, adding more seems rather silly. We might even say that TYPEP is the preferred way to check the type of an object, and that the other type predicates are only retained for compatability. Some people might object on the grounds that (INTEGERP X) is more immediately obvious than (TYPEP X 'INTEGER). - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 29 Mar 86 21:59:45 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Mar 86 18:52:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 450265; Sat 29-Mar-86 21:49:21-EST Date: Sat, 29 Mar 86 21:50 EST From: David A. Moon Subject: Predicates for all type specifier symbols To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860329215031.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 29 Mar 1986 20:31 EST From: "Scott E. Fahlman" I agree that if we aren't going to flush all of these things (and for compatibility we probably can't), then we ought to complete the set of predicates for single-symbol type specifiers. Perhaps we ought to re-read the voting documents and discussion from the era when we got rid of FIXNUMP and so forth before adding any type-specific predicates.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 29 Mar 86 20:38:51 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Mar 86 17:31:03 PST Received: ID ; Sat 29 Mar 86 20:31:55-EST Date: Sat, 29 Mar 1986 20:31 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Skef Wholey Cc: common-lisp@SU-AI.ARPA Subject: Predicates for all type specifier symbols In-reply-to: Msg of 29 Mar 1986 16:54-EST from Skef Wholey I agree that if we aren't going to flush all of these things (and for compatibility we probably can't), then we ought to complete the set of predicates for single-symbol type specifiers. I'd leave out T and NIL, however. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 29 Mar 86 17:02:12 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Mar 86 13:54:00 PST Received: ID ; Sat 29 Mar 86 16:54:53-EST Date: Sat, 29 Mar 1986 16:54 EST Message-ID: Sender: WHOLEY@C.CS.CMU.EDU From: Skef Wholey To: "Scott E. Fahlman" Cc: common-lisp@SU-AI.ARPA Subject: Predicates for all type specifier symbols In-reply-to: Msg of 28 Mar 1986 20:16-EST from Scott E. Fahlman The old-fashioned type predicates are useful for sequence function tests and the like. By using the same logic that gets us to the proposed functions TRUE and FALSE, we can get to the old-fashioned type predicates. At any rate, they save typing, as does CADDDR (which no one seems interested in flushing). That the set of such predicates is incomplete calls for the addition of functions to complete the set, rather than the elimination of all type predicate functions. Back in the early Common Lisp days, one principal guiding the design was "brain compataiblity" -- There are some things that will cause more trouble in the short run due to programmers being unfamiliar with new names or argument ordering or missing features or different functionality than can be justified by streamlining the language. I guarantee that if these functions are not provided, many major pieces of portable software will define them for themselves, and some superset implementations will provide them anyway, and porting such software will be more of a hassle than it should be. I have seen this happen with ASSQ while porting two systems (OPS-5 and PCL) in two Common Lisps (Symbolics and Spice). The result is that the portable code now has hacks to define such functions only if they don't already exist. HOWEVER, if we were to nuke our old friends LISTP, ATOM, NUMBERP, and so on, we could introduce something in the spirit of the proposed CONSTANT function to make :TEST functions a wee bit easier to create. (defun typefun (type) #'(lambda (x) (typep x type))) As with CONSTANT, this needn't cons a new function for each invocation -- it could return constant functions for the common cases. --Skef  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 29 Mar 86 16:04:10 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 29 Mar 86 12:55:18 PST Date: 29 Mar 1986 15:54-EST Sender: NGALL@G.BBN.COM Subject: Re: Predicates for all type specifier symbols From: NGALL@G.BBN.COM To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]29-Mar-86 15:54:53.NGALL> In-Reply-To: Date: Fri, 28 Mar 1986 20:16 EST From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Predicates for all type specifier symbols In-Reply-To: Msg of 28 Mar 1986 17:35-EST from Fischer.pa at Xerox.COM Message-ID: It was proposed long ago that we just flush all the specific type specifiers and just go with Typep. A few pre-existing ones were then added back in for compatibility with existing Lisps and existing Lispers. Another ugly compromise, I guess. A similar situation prevails in SETF, where a couple of old favorites were retained, even though they are now redundant. -- Scott -------------------- What implementations did commonp pre-exist in :-? Also, If we want to steer away from type-specific predicates and towards TYPEP, why does DEFSTRUCT create a predicate by default? Also, one disadvantage with TYPEP is that you have to wrap it up in a lambda-pression in order to pass it around, i.e., I much prefer #'listp to #'(lambda (x) (typep x 'list)). In any case, if we decide to have predicates that always return T and NIL respectively, (e.g., for KMP condition system proposal) I suggest that we add the type-specifiers T and NIL to the set of type-specifiers that have associated predicates, TP and NILP, repectively. -- Nick P.S. any comments on the desirability of the new type-specifiers that I proposed?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 23:41:07 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Mar 86 20:28:34 PST Received: ID ; Fri 28 Mar 86 22:59:11-EST Date: Fri, 28 Mar 1986 20:16 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Predicates for all type specifier symbols In-reply-to: Msg of 28 Mar 1986 17:35-EST from Fischer.pa at Xerox.COM It was proposed long ago that we just flush all the specific type specifiers and just go with Typep. A few pre-existing ones were then added back in for compatibility with existing Lisps and existing Lispers. Another ugly compromise, I guess. A similar situation prevails in SETF, where a couple of old favorites were retained, even though they are now redundant. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 17:46:57 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 28 Mar 86 14:35:12 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 MAR 86 14:35:19 PST Date: 28 Mar 86 14:35 PST From: Fischer.pa@Xerox.COM Subject: Re: Predicates for all type specifier symbols In-reply-to: NGALL@G.BBN.COM's message of 28 Mar 86 11:20 EST To: NGALL@G.BBN.COM cc: common-lisp@SU-AI.ARPA Message-ID: <860328-143519-3626@Xerox> Why do we need any predicate aside from TYPEP? (ron)  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 16:46:37 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Mar 86 13:06:29 PST Date: Fri, 28 Mar 1986 15:55 EST Message-ID: Sender: DICK%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU From: Dick@MC.LCS.MIT.EDU To: cl-iteration@SU-AI.ARPA, common-lisp@SU-AI.ARPA Subject: LetS -- a new loop notation In-reply-to: Msg of 1 Mar 1986 00:01-EST from Masinter.pa at Xerox.COM This message advertises a Common Lisp macro package called LetS (rhymes with process) which it is hoped will become a standard iteration facility in Common Lisp. LetS makes it possible to write a wide class of algorithms which are typically written as loops in a functional style which is similar to expressions written with the Common Lisp sequence functions. LetS supports a number of features which make LetS expressions more expressive than sequence expressions. However, the key feature of LetS is that every LetS expression is automatically transformed into an efficient iterative loop. As a result, unlike sequence expressions, LetS expressions are just as efficient as the traditional loop expressions they replace. An experimental version of LetS currently exists on the MIT-AI machine in the file "DICK;LETS BIN". Although LetS is written in Common Lisp, it has not yet been tested on anything other than a Symbolics Lisp Machine. For various detailed reasons it is unlikely to run on any other machine. Everyone who wants to is invited to borrow this file and try LetS out. I am very interested to hear any and all comments on LetS. Extensive documentation of LetS is in the file "DICK;LETSD >" also on the MIT-AI machine. Even people who do not have a Lisp Machine or are not able to access the code are invited to read this documentation and make comments on it. I am interested in getting as wide a feedback as possible. If you cannot access the documentation file directly, send me your US mail address and I will mail you a copy. The documentation is much too long to reliably send via computer mail. After an initial testing and feedback period, a final version of LetS which runs under all Common Lisps will be created along with formal documentation. This should happen within a couple of months. A very brief summary of lets is included at the end of this message. Dick Waters ! The advantages (with respect to conciseness, readability, verifiability and maintainability) of programs written in a functional style are well known. A simple example of the clarity of the functional style is provided by the Common Lisp program below. This function computes the sum of the positive elements of a vector. (defun sum-pos-vect (v) (reduce #'+ (remove-if-not #'plusp v))) A key feature of sum-pos-vect is that it makes use of an intermediate aggregate data structure (a sequence) to represent the selected set of vector elements. The use of sequences as intermediate quantities in computations makes it possible to use functional composition to express a wide variety of computations which are usually represented as loops. Unfortunately, as typically implemented, sequence expressions are extremely inefficient. The problem is that straightforward evaluation of a sequence expression requires the actual creation of the intermediate sequence objects. Since alternate algorithms using loops can often compute the same result without creating any intermediate sequences, the overhead engendered by using sequence expressions is quite reasonably regarded as unacceptable in many situations. A solution to the problem of the inefficiency of sequence expressions is to transform them into iterative loops which do not actually create any intermediate sequences before executing them. For example, sum-pos-vect might be transformed as shown below. (defun sum-pos-vect-transformed (v) (prog (index last sum element) (setq index 0) (setq last (length v)) (setq sum 0) L (if (not (< index last)) (return sum)) (setq element (aref v index)) (if (plusp element) (setq sum (+ element sum))) (setq index (1+ index)) (go L))) Several researchers have investigated the automatic transformation of sequence expressions into loops. For example, APL compilers transform many kinds of sequence expressions into loops. Unfortunately, there is a fundamental problem with the transformation of sequence expressions into loops. Although many sequence expressions can be transformed, many cannot. For example, Common Lisp provides a sequence function (reverse) which reverses the elements in a sequence. Suppose that a sequence expression enumerates a sequence, reverses it, and then reduces it to some value. This sequence expression cannot be computed without using intermediate storage for the enumerated sequence because the first element of the reversed sequence is taken from the last element of the enumerated sequence. There is no way to transform the sequence expression into an efficient loop without eliminating the reverse operation. A solution to the problems caused by the presence of non-transformable sequence operations is to restrict the kinds of sequence operations which are allowed so that every sequence expression is guaranteed to be transformable. For example, one could start by outlawing the operation reverse. ! LETS LetS supports a wide class of sequence expressions that are all guaranteed to be transformable into efficient loops. In order to avoid confusion with the standard Common Lisp data type sequence, the data type supported by LetS is called a series. Using LetS the program sum-pos-vect would be rendered as shown below. The function Evector converts the vector v into a series which contains the same elements in the same order. The function Tplusp is analogous to (remove-if-not #'plusp ...) except that it operates on a series. The function Rsum corresponds to (reduce #'+ ... :initial-value 0) except that it takes in a series as its argument. (defun sum-pos-vect-lets (v) (Rsum (Tplusp (Evector v)))) LetS automatically transforms the body of this program as shown below. The readability of the transformed code is reduced by the fact that it contains a large number of gensymed variables. However, the code is quite efficient. The only significant problem is that too many variables are used. (For example, the variable #:vector5 is unnecessary.) However, this problem need not lead to inefficiency during execution as long as a compiler which is capable of simple optimizations is available. (defun sum-pos-vect-lets-transformed (v) (let (#:index12 #:last4 #:sum21 #:element11 #:vector5) (tagbody (setq #:vector5 v) (setq #:index12 0) (setq #:last4 (length #:vector5)) (setq #:sum21 0) #:p0 (if (not (< #:index12 #:last4)) (go #:e9)) (setq #:index12 (1+ #:index12)) (setq #:element11 (aref #:vector5 #:index12)) (if (not (plusp #:element11)) (go #:p0)) (setq #:sum21 (+ #:element11 #:sum21)) (go #:p0) #:e9) #:sum21)) RESTRICTIONS ENFORCED BY LETS The key aspect of LetS is that it enforces a palatable (and not overly strict) set of easily understandable restrictions which guarantee that every series expression can be transformed into a highly efficient loop. This allows programmers to write series expressions which are much easier to work with than the loops they might otherwise write, without suffering a decrease in efficiency. There are two central restrictions which are enforced by LetS. First, every series must be statically identifiable so that transformation can occur at compile time rather than at run time. Second every series function is required to be "in-order". A series function is said to be in-order if it reads each input series in order, one element at a time, starting from the first one, and if it creates the output series (if any) in order, one element at a time, starting from the first one. In addition, the function must do this without using internal storage for more than one element at a time for each of the input and output series. For example, the series functions Evector, Tplusp, and Rsum are all in-order. In contrast, the function reverse is not in-order. (Reverse either has to read the input in reverse order, or save up the elements until the last one is read in.) ! OTHER FEATURES OF LETS Although efficiency is the main goal of LetS, LetS supports a number of features which are not directly related to efficiency per se. Most notable of these is implicit mapping of functions over series. Whenever an ordinary Lisp function is syntactically applied to a series, it is automatically mapped over the elements of the series. The following example illustrates implicit mapping. In the function below, the computation "(lambda (x) (expt (abs x) 3))" is implicitly mapped over the series of numbers generated by Evector. Implicit mapping of this sort is a commonly used feature of APL and is extremely convenient. (defun sum-cube-abs-vect (v) (Rsum (expt (abs (Evector v)) 3))) (sum-cube-abs-vect #(1 -2 3)) => (+ 1 8 27) => 36 New series functions can be defined by using the form defunS. The following example shows how the function Rsum could be defined. More complex forms can be defined by using the ordinary Common Lisp macro definition facilities to define macros which create appropriate series expressions. (defunS Rsum (numbers) (declare (series numbers)) (reduceS #'+ 0 numbers)) LetS provides two forms (LetS and LetS*) which are analogous to let and let*. As shown in the example below, These forms can be used to bind both ordinary variables (e.g., num-obs, mean, and deviation) and series variables (e.g., ob). Whether or not a variable is a series is determined by looking at the type of value produced by the expression which computes the value bound to it. (defun mean-and-deviation (observations) (letS* ((ob (Elist observations)) (num-obs (Rlength ob)) (mean (/ (Rsum ob) num-obs)) (deviation (- (/ (Rsum (expt ob 2)) num-obs) (expt mean 2)))) (list mean deviation))) The complete documentation of LetS compares LetS with the Common Lisp sequence functions and with the Zeta Lisp Loop macro. LetS supports essentially all of the functionality of the Loop macro in a style which looks like sequence functions and which is exactly as efficient as the loop macro. THE ANCESTRY OF LETS The LetS package described here is descended from an earlier package of the same name (See MIT/AIM-680a and "Expressional Loops", Proc. Eleventh ACM SIGACT-SIGPLAN Symposium on the Principles of Programming Languages, January 1984). The current system differs from the earlier system in a number of ways. In particular, the new system supports a much wider set of features.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 15:13:38 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 28 Mar 86 12:02:28 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 MAR 86 11:57:27 PST Date: 28 Mar 86 11:57 PST From: Gregor.pa@Xerox.COM Subject: Re: Standardization In-reply-to: Jeff Dalton 's message of Tue, 25 Mar 86 17:19:29 GMT To: jeff%aiva.edinburgh.ac.uk@cs.ucl.ac.uk cc: common-lisp@su-ai.arpa, liz@brillig.umd.edu, eulisp%inria.uucp@cs.ucl.ac.uk Message-ID: <860328-115727-3499@Xerox> I do intend to send out a message summarizing the problems I have had making Portable CommonLoops. I Have been going through the sources looking for places where I have comments saying things like "this would be easier if Common Lisp had...". I will try to finish this in the next couple of days and send it out.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 12:52:06 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Mar 86 09:43:42 PST Date: 28 Mar 86 12:32:00 EST From: "BACH::GREEK" Subject: Predicates for types. To: "common-lisp" Reply-To: "BACH::GREEK" Interesting you should mention those. I would suggest that we get rid of the ones we have and just use TYPEP. Of course, we can't get rid of them for sake of compatability. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 12:15:10 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 28 Mar 86 09:00:14 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9801; Fri 28-Mar-86 11:51:25-EST Date: Fri, 28 Mar 86 11:58 EST From: David C. Plummer Subject: Re: inline declaration for FLET and LABELS To: Rodney A. Brooks , DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <12194094203.57.BROOKS@OZ.AI.MIT.EDU> Message-ID: <860328115855.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu 27 Mar 86 13:40:03-EST From: "Rodney A. Brooks" The problem is that when you expand an FLET'ed or LABELS'ed function, you have to 'fool' somebody by backing up the lexical environment correctly. Consider this contoration: (compiler-let ((*foo* 'foo)) (macrolet ((foo () `'(outer ,*foo*))) (flet ((foo1 () (foo))) (flet ((foo2 () (foo1))) (declare (inline foo2)) (compiler-let ((*foo* 'bar)) (macrolet ((foo () `'(inner ,*foo*))) (flet ((foo1 () (foo))) (foo2)))))))) This is supposed to return (OUTER FOO). If the call to FOO2 were expanded into FOO1 but the environment were not unrolled, it would instead return (INNER BAR). I'm not saying it is impossible; I'm saying it is probably damn hard to implement. Correct. It is hard but not impossible. For Lucid's compiler this was one of three places (the other two were to do with shared environments for closures) I had to introduce variations on source level special forms during alphatization that are not available at user level. Basically I alphatize the body of the flet defined function in the environment where it is defined, and then for inline susbstitution protect it from re-alphatization with an extension to locally. Alphatization uniquifies everything so eventually all the references are right. (I'm not sure this is yet in any released version but will be soon.) Indeed, I can see how that can work. [Putting on my programming environment hat...] Implemenations should be careful that what they put in source locators and debugging information should correspond to what the user input, not what the compiler uniquified things to. For example, in the Symbolics implementation, the function spec of FLET and LABELS functions is (:INTERNAL ) For example, the FOO1, FOO2 and (the second) FOO1 in the above form, if they were in a function called BAR, would be (:INTERNAL BAR 0 FOO1) (:INTERNAL BAR 1 FOO2) (:INTERNAL BAR 2 FOO1)  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Mar 86 11:34:37 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 28 Mar 86 08:20:27 PST Date: 28 Mar 1986 11:20-EST Sender: NGALL@G.BBN.COM Subject: Predicates for all type specifier symbols From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]28-Mar-86 11:20:13.NGALL> Why aren't there predicate functions for ALL the type specifier symbols in Table 4-1 (pg 43)? The following type sepecs. lack an associated predicate (I think): bignum bit double-float fixnum long-float nil ratio sequence short-float simple-array single-float t (and the proposed) signed-byte unsigned-byte Its a pain having to keep track of which ones have predicates and which ones don't. Also, If we had TP and NILP we would have the TRUE and FALSE functions that KMP was asking for! While I'm on this Table, let me suggest a few more type specs: closure form lambda-expression place printed readable-object {covers only those objects that can posssibly have a readable representation.} type-specifier boolean {equiv. to (member t nil)} function-name {covers only those objects that may be an arg of the FUNCTION special form; equiv. to (or symbol lambda-expression)} function-definition {covers only those things that symbol-function returns} -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Mar 86 14:44:35 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 27 Mar 86 11:24:17 PST Date: Thu, 27 Mar 86 14:26:20 EST From: Jonathan A Rees Subject: inline declaration for FLET and LABELS To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Thu 27 Mar 86 13:20 EST from David C. Plummer Message-ID: <[MC.LCS.MIT.EDU].863705.860327.JAR> I've implemented it a couple times and never had any trouble, but then I've never tried to write a compiler which tried to implement optimizations via macro expansion. It's best in lexical languages either to uniquely rename user variables like RABBIT does, or to make "virtual closures" to make sure that lambda-expressions know what lexical environment they came from (I've never tried that although I think it would work). The LETREC case seems harder to me since you have to deal with mutual recursion.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Mar 86 14:17:26 EST Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 27 Mar 86 10:59:22 PST Date: Thu 27 Mar 86 13:40:03-EST From: "Rodney A. Brooks" Subject: Re: inline declaration for FLET and LABELS To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <860327132013.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <12194094203.57.BROOKS@OZ.AI.MIT.EDU> The problem is that when you expand an FLET'ed or LABELS'ed function, you have to 'fool' somebody by backing up the lexical environment correctly. Consider this contoration: (compiler-let ((*foo* 'foo)) (macrolet ((foo () `'(outer ,*foo*))) (flet ((foo1 () (foo))) (flet ((foo2 () (foo1))) (declare (inline foo2)) (compiler-let ((*foo* 'bar)) (macrolet ((foo () `'(inner ,*foo*))) (flet ((foo1 () (foo))) (foo2)))))))) This is supposed to return (OUTER FOO). If the call to FOO2 were expanded into FOO1 but the environment were not unrolled, it would instead return (INNER BAR). I'm not saying it is impossible; I'm saying it is probably damn hard to implement. Correct. It is hard but not impossible. For Lucid's compiler this was one of three places (the other two were to do with shared environments for closures) I had to introduce variations on source level special forms during alphatization that are not available at user level. Basically I alphatize the body of the flet defined function in the environment where it is defined, and then for inline susbstitution protect it from re-alphatization with an extension to locally. Alphatization uniquifies everything so eventually all the references are right. (I'm not sure this is yet in any released version but will be soon.) -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Mar 86 13:31:07 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 27 Mar 86 10:21:38 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9517; Thu 27-Mar-86 13:12:36-EST Date: Thu, 27 Mar 86 13:20 EST From: David C. Plummer Subject: inline declaration for FLET and LABELS To: Patrick G. Sobalvarro , DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <[AI.AI.MIT.EDU].21839.860327.PGS> Message-ID: <860327132013.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 27 Mar 86 11:56:25 EST From: "Patrick G. Sobalvarro" Date: Tue, 25 Mar 86 11:04 EST From: David C. Plummer A few of us just realized that (defun foo () (labels ((bar ...) (baz ...)) (declare (inline bar baz)) ...)) is realitively easy to implement compare to (defun foo () (flet ((bar ...) (baz ...)) (declare (inline bar baz)) ...)) The problem is the scoping rules. Consider (defun foo () (flet ((car (x) (cdr x)) (cdr (x) (car x))) (declare (inline car cdr)) ...)) While this is quite legal, it may be VERY hard to implement. Therefore, when we consider allowing inline declarations for local functions, we should keep this in mind in the documentation. I'm not sure I understand this -- do you have your flet and your labels backwards here? In that case, I think that most compilers that couldn't do block compilation would just ignore inline declarations when they caused circularities. Consider that the situation you're describing isn't too different from compiling globally defined mutually recursive functions that are declared inline. The problem is that when you expand an FLET'ed or LABELS'ed function, you have to 'fool' somebody by backing up the lexical environment correctly. Consider this contoration: (compiler-let ((*foo* 'foo)) (macrolet ((foo () `'(outer ,*foo*))) (flet ((foo1 () (foo))) (flet ((foo2 () (foo1))) (declare (inline foo2)) (compiler-let ((*foo* 'bar)) (macrolet ((foo () `'(inner ,*foo*))) (flet ((foo1 () (foo))) (foo2)))))))) This is supposed to return (OUTER FOO). If the call to FOO2 were expanded into FOO1 but the environment were not unrolled, it would instead return (INNER BAR). I'm not saying it is impossible; I'm saying it is probably damn hard to implement.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Mar 86 12:04:49 EST Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 27 Mar 86 08:55:20 PST Date: Thu, 27 Mar 86 11:56:25 EST From: "Patrick G. Sobalvarro" Subject: inline declaration for FLET and LABELS To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Tue 25 Mar 86 11:04 EST from David C. Plummer Message-ID: <[AI.AI.MIT.EDU].21839.860327.PGS> Date: Tue, 25 Mar 86 11:04 EST From: David C. Plummer A few of us just realized that (defun foo () (labels ((bar ...) (baz ...)) (declare (inline bar baz)) ...)) is realitively easy to implement compare to (defun foo () (flet ((bar ...) (baz ...)) (declare (inline bar baz)) ...)) The problem is the scoping rules. Consider (defun foo () (flet ((car (x) (cdr x)) (cdr (x) (car x))) (declare (inline car cdr)) ...)) While this is quite legal, it may be VERY hard to implement. Therefore, when we consider allowing inline declarations for local functions, we should keep this in mind in the documentation. I'm not sure I understand this -- do you have your flet and your labels backwards here? In that case, I think that most compilers that couldn't do block compilation would just ignore inline declarations when they caused circularities. Consider that the situation you're describing isn't too different from compiling globally defined mutually recursive functions that are declared inline.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 26 Mar 86 18:16:14 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 26 Mar 86 15:01:28 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8824; Tue 25-Mar-86 11:02:32-EST Date: Tue, 25 Mar 86 11:04 EST From: David C. Plummer Subject: inline declaration for FLET and LABELS To: common-lisp@SU-AI.ARPA Message-ID: <860325110403.9.DCP@FIREBIRD.SCRC.Symbolics.COM> A few of us just realized that (defun foo () (labels ((bar ...) (baz ...)) (declare (inline bar baz)) ...)) is realitively easy to implement compare to (defun foo () (flet ((bar ...) (baz ...)) (declare (inline bar baz)) ...)) The problem is the scoping rules. Consider (defun foo () (flet ((car (x) (cdr x)) (cdr (x) (car x))) (declare (inline car cdr)) ...)) While this is quite legal, it may be VERY hard to implement. Therefore, when we consider allowing inline declarations for local functions, we should keep this in mind in the documentation.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 22:59:22 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 Mar 86 19:48:20 PST Date: Tue, 25 Mar 86 22:50:24 EST From: "George J. Carrette" Subject: the Duck port you gave up on. To: liz@BRILLIG.UMD.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].861813.860325.GJC> I can see why you gave up. The program referenced such jewels as the internal macros used by the backquote-macros, COMPILER:QC-FILE-IN-PROGRESS, not to mention various undocumented features of the DEC, Symbolics, and LMI implementation. In fact this is a classic case of pre-common-lisp lossage. Porting the previous "zetalisp" version from Symbolics rel 6 took me only 3 hours. So the "commonlispification" of DUCK in this case was somewhat misguided. What you had was a program that was painfully hacked to work in DEC's VAX implementation. {Insert a short history of NISP, and the port to T...} Better luck next time.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 20:27:46 EST Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 25 Mar 86 17:11:02 PST Received: by sri-unix.ARPA (4.12/4.16) id AA26536; Tue, 25 Mar 86 15:09:19 pst Received: from pyrps5 (pyrps5.ARPA) by pyramid (4.12/3.14) id AA11288; Tue, 25 Mar 86 01:55:57 pst Received: by pyrps5 (4.12/3.14) id AA00513; Tue, 25 Mar 86 01:55:31 pst Date: 25 Mar 1986 01:36-PST From: David Bein Subject: comments... To: common-lisp@SU-AI.ARPA Message-Id: <512127419/bein@pyrps5> Just to get my 2-cents worth in ... Why not have the keyword :ignore be part of the STANDARD features list? Then someone would not have the problem of knowing whether it is or is not in the features list. So when you want to eat an s-expression just do: #-:ignore (mumble-frats ...) On the other hand, I tend to agree with the purists that this kind of mucking with the standard is to be avoided. So maybe it would be appropriate if our mailers were taught to ignore letters about things like this. Another idea is that we start attaching a GC: field to the letters we send out which can be used by mail-reading programs to decide whether to "ignore" this or that piece of mail. --David  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 16:30:32 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 25 Mar 86 11:59:32 PST Received: by GODOT.THINK.COM; Tue, 25 Mar 86 15:00:08 est Date: Tue, 25 Mar 86 15:00:08 est From: gls@GODOT.THINK.COM (Guy Steele) Message-Id: <8603252000.AA08699@GODOT.THINK.COM> To: common-lisp@sail Subject: Suggestions for language changes The following suggestions were made to me orally at the December meeting. I just ran across my notes again, and am sending these out now in case I didn't before. I apologize for the fact that I failed to note who made which suggestions, and memory fails me. [1] Clarify what division by zero does. [2] DENOMINATOR should be allowed to return 0 for non-standard objects. [3] TAGBODY should allow constants (specifically strings) in the body, not as tags but simply to be effectively ignored. [4] Clarify whether DEFSTRUCT or DEFTYPE can redefine a built-in type. [5] There should be a way to force a constituent to be purely alphabetic in the lexer. Right now there is no way to make colon be alphabetic and not a package marker, for example. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 14:55:23 EST Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 25 Mar 86 11:37:05 PST Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a002819; 25 Mar 86 19:04 BST From: Jeff Dalton Date: Tue, 25 Mar 86 17:19:29 GMT Message-Id: <14603.8603251719@aiva.ed.ac.uk> To: common-lisp@su-ai.arpa, liz@brillig.umd.edu Subject: Re: Standardization Cc: eulisp%inria.uucp@cs.ucl.ac.uk From: Liz Allen I once tried to port some code that ran fine under DEC Common Lisp to LMI's Common Lisp and had *lots* of trouble -- in fact, I finally had to give up. ... Has anyone else tried porting common lisp code from one implementation to another? (I imagine that the implementors of things like CommonLoops could also comment on this subject.) I have ported several programs of varying sizes (up to 150 pages or so) from Spice Lisp to Kyoto Common Lisp (KCL) and then to Sun (Lucid) Common Lisp. Some of this code was originally written in Spice Lisp, but other parts came from Franz Lisp or even T. I have also written some new code that was to run in both KCL and Sun Lisp; most of this has not been tried in Spice. Finally, I have ported some of things to Poplog Common Lisp. (The KCL and Poplog cases are particularly enlightening in that they were developed by people outside the central Common Lisp community and hence had to depend more on the published description of the language.) None of my code depended on things outside the Silver Book, and except where blocked by bugs I was always able to get something that worked everywhere in the end. Nonetheless, it was a rare program that could be ported as-is. In general, incompatibilities could be attributed to any of several reasons, here listed roughly in order of decreasing frequency: 1. Incorrect interpretations of the language specification. These are cases that *I* think are wrong but where (a) the implementa- tion seems to be meant to work this way and (b) it is possible to see how someone might have understood the CLtL in this way. Many of these involve packages. 2. Bugs in the implementations. The cases I think are wrong that don't meet criteria (a) and (b). This includes faulty handling of incorrect programs. (Incidentally, this category is becoming more common and may be number one any day now. Perhaps I initially used parts of the language that were more thoroughly debugged.) 3. Allowed differences. Implementations of Common Lisp are allowed to differ in certain ways apart from internal implementation details. Examples would be potential numbers (p. 341) and symbols like "::" (p. 176). Some implementations enforce a stricter interpretation of the language than others in the sense that programs that work in the stricter system will work in less strict ones but not the other way around. In this case, it helps to start in the stricter system because then you will be warned about things like potential numbers that you might otherwise have overlooked in CLtL. Extensions to Common Lisp can also be a problem. For example, if a system defines a new external symbol in the Lisp package, and I have a program that also defines that symbol, I will have to do something to resolve the conflict. (Would it be reasonable to require that extensions be defined in a different package?) 4. Implementation or environment differences. Some programs will have difficulties in some systems because of the machine or the operating system involved or because things like storage management are done differently. Sometimes it is helpful (or necessary) to rewrite parts of the program. This differs from category (3) in that there isn't much that the language definition can do. We could say what must be done with potential numbers, but we could hardly require that all systems must have the same performance. Cases like the treatment of tail-recursion may fall somewhere in between. 5. Ambiguities, inconsistencies, or mistakes in the specification. This is similar to case (1) except that the specification is (more) clearly at fault. Note that many of the inconsistencies are due to uneven revision, things missed when parts of the language were changed; others have origins that are less obvious. 6. Uneven development. Some implementations are more up-to-date than others in that they may have responded to changes or clarifications that were discussed on this mailing list. Of these categories, (1), (3), and (5) have implications for standardization, (1) and (5) because a standard needs a clear, precise, and consistent specification, and (3) because it shows that some incompatibilities are inherent in Common Lisp; after all, Common Lisp is meant to be a common subset. It is also important to note that all of this can be improved. There do not seem to be any "fatal inconsistencies" that would bring down a large part of the language. To me, this means that a standard can be based on Common Lisp, but also that improvements in the specification are needed. (A final note: Clearly the number of cases in each category, and hence their order, reflects the selection of dialects involved (how could it be otherwise?), but many of the obvious conclusions about these dialects do not hold. I say this, without saying what those conclusions would be, to avoid giving a false, negative impression of any of these systems. I don't feel this is the right place to make such comparisons.) -- Jeff  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 14:14:11 EST Received: from MIT-ZERMATT.ARPA by SU-AI.ARPA with TCP; 25 Mar 86 10:58:11 PST Received: from MIT-CHERRY.ARPA by MIT-ZERMATT.ARPA via CHAOS with CHAOS-MAIL id 29025; Tue 25-Mar-86 13:59:14-EST Date: Tue, 25 Mar 86 13:58 EST From: Soley@MIT-MC.ARPA Subject: Re: Standardization To: liz%brillig.umd.edu@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8603242224.AA03479@brillig.umd.edu> Message-ID: <860325135846.3.SOLEY@MIT-CHERRY.ARPA> Message-Id: <8603242224.AA03479@brillig.umd.edu> To: common-lisp@su-ai.ARPA Subject: Re: Standardization In-Reply-To: Your message of Fri, 21 Mar 1986 13:24 EST. Date: Mon, 24 Mar 86 17:24:32 -0500 From: Liz Allen I once tried to port some code that ran fine under DEC Common Lisp to LMI's Common Lisp and had *lots* of trouble -- in fact, I finally had to give up. Now the system I was porting (Drew McDermott's deductive retrieval system, DUCK) did some interesting things and was probably pushing some things beyond their normal limits. I have ported DUCK several times (actually, several times too many . . .), and it could hardly be considered a candidate for most portable program of the year. Has anyone else tried porting common lisp code from one implementation to another? If so, how did it go? I have also ported several other medium-sized CL programs, between Symbolics, TI, Gold Hill, NIL, and others, and have been fairly happy with how it went.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 14:14:05 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 25 Mar 86 10:59:10 PST Date: Tue, 25 Mar 86 14:01:09 EST From: Jonathan A Rees Subject: Standardization To: liz@BRILLIG.UMD.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].861386.860325.JAR> Date: Mon, 24 Mar 86 17:24:32 -0500 From: Liz Allen Has anyone else tried porting common lisp code from one implementation to another? If so, how did it go? My scheme implementation has been run in at least four common lisp implementations now. Nearly every problem I had was due to a bug in the implementation. A small number of other problems (like LISP package pollution) were due to language deficiencies which I believe can and will be fixed fairly painlessly by the standardization process.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Mar 86 06:13:41 EST Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 25 Mar 86 03:02:01 PST Received: by brillig.umd.edu (5.9/4.7) id AA03479; Mon, 24 Mar 86 17:24:33 EST Message-Id: <8603242224.AA03479@brillig.umd.edu> To: common-lisp@su-ai.ARPA Subject: Re: Standardization In-Reply-To: Your message of Fri, 21 Mar 1986 13:24 EST. Date: Mon, 24 Mar 86 17:24:32 -0500 From: Liz Allen Just a note from experience and a question for thought... I once tried to port some code that ran fine under DEC Common Lisp to LMI's Common Lisp and had *lots* of trouble -- in fact, I finally had to give up. Now the system I was porting (Drew McDermott's deductive retrieval system, DUCK) did some interesting things and was probably pushing some things beyond their normal limits. Still, there were some surprises that seemed to me like real incompatibilities. (I could probably dig them up if someone wants to see them.) Maybe things have improved since then, but I can't help wondering how standard everything really is. Has anyone else tried porting common lisp code from one implementation to another? If so, how did it go? If not, maybe it ought to be tried... -Liz  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Mar 86 13:34:35 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Mar 86 10:23:23 PST Received: ID ; Fri 21 Mar 86 13:24:43-EST Date: Fri, 21 Mar 1986 13:24 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Standardization In-reply-to: Msg of 21 Mar 1986 12:54-EST from Guy Steele I agree with most of what Guy Steele and Bob Mathis have said on the subject of how much we want to change the language in the course of producing this first standard. I would add only two things: First, I think that it would not be out of order to consider incompatible changes, even where the current language is unambiguous and implementable, if we really feel that the change is worth it. But in all such considerations, we must bear in mind the costs as well as any possible benefits. There are now a lot of Common Lisp implementations around, a growing body of Common Lisp software, tutorial material on the language, and some users who have invested time in learning this language. By the time the standard is ready, there will be a lot more. The more of this investment that a proposed change would effect, the more benfit we would have to see in order for the change to be adopted. We certainly are not looking at a situation where we have license to start from scratch or to make a lot of gratuitous changes based on minor aesthetic considerations. The other thing to say is that before beginning this in earnest, we may want to plan on the existence of future versions that could make more radical changes (given a lot more lead time and a stable Common Lisp where people can get work done while waiting for the changes). I think that for many good, pragmatic reasons we need to standardize something like the current Common Lisp, but this is certainly not the last word in programming languages, and if we think carefully about when the next wave might break, we might have a better idea of what we can afford to change, or not to change, in this one. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Mar 86 13:01:48 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Mar 86 09:51:57 PST Received: from yon by GODOT.THINK.COM via CHAOS; Fri, 21 Mar 86 12:52:37 est Date: Fri, 21 Mar 86 12:54 EST From: Guy Steele Subject: Standardization To: David.Dill@A.CS.CMU.EDU, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <20Mar86.170218.DD60@A.CS.CMU.EDU> Message-Id: <860321125427.3.GLS@THINK-YON.ARPA> Date: Thu, 20 Mar 86 17:02 EST From: David.Dill@A.CS.CMU.EDU (C410DD60) To what extent can Common Lisp be changed in the process of becoming a standard? To what extent CAN it be changed? Arbitrarily (unfortunately), but if you change it too much then everyone will abandon it. Fortunately there are balancing pressures. To what extent SHOULD it be changed? My opinion is that what is there is mostly sound (I happen to be proud of what the committee produced in the initial design), but that ambiguities must be clarified, which will inevitably require some changes in some implementations, and certain extensions are needed (such as error handling).  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Mar 86 11:48:34 EST Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 21 Mar 86 08:39:54 PST Date: 21 Mar 1986 07:24-PST Sender: MATHIS@USC-ISIF.ARPA Subject: Re: Standardization From: MATHIS@USC-ISIF.ARPA To: David.Dill@A.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Message-ID: <[USC-ISIF.ARPA]21-Mar-86 07:24:03.MATHIS> In-Reply-To: <20Mar86.170218.DD60@A.CS.CMU.EDU> One of the difficult issues in any standrads effort is what to change and what to keep the same (or at least compatible). What's one person's bug is another's feature. I think most people want the standard to be very nearly what people think of today when they say "Common Lisp," but the formal agreement on that mutual understanding can be very difficult and may result in some unexpected changes. -- Bob Mathis  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Mar 86 02:26:52 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 20 Mar 86 23:15:18 PST Received: from MORRISON.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 21 Mar 86 01:54-EST Date: Fri, 21 Mar 86 01:52 EST From: Christopher Fry Subject: Re: Ignoring a list. To: preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA In-Reply-To: <8603191917.AA07213@gswd-vms.ARPA> Message-ID: <860321015236.4.CFRY@MIT-MORRISON.ARPA> From: Gregor.pa@Xerox.COM Subject: Re: Ignoring a list. This seems like an environment issue to me, and not one that the language needs to take a stand on. After all: - A particular environment might have some really nice way of implementing and supporting this feature. It could gray the form out, or turn it blue or something. In that environment the "standard" way of implementing it might not be useful or it might be difficult to provide really nice environment support for it. ---------- A particular environment might have a really nice way of supporting comments, say by displaying them in italics or boxes. Therefore the standard shouldn't provide a standard way of indicating comments... ---------- Such a fancy environment could manage to hide a char sequence like #; - There is no significant need for a "standard" way to do this because the only time a user really needs to comment out random forms (in a hurry) is when they are debugging. I spend most of my time debugging. If you are debugging then you already have to learn enough about the environment that knowing how to comment out a form does not seem like such a burden. Yeah, but lets make it as easy as we can. This isn't really a major issue, but the ability to comment out a form by marking the beginning of it seems like a very useful ability to have. Marking both ends is (a) a pain in the ass, even if it does take only two keystrokes to get to the end of the form and (b) much more prone to the "oops, i took out the front one but not the back one" variety of error. I agree. Here's the proposals for commenting out a form via prefix syntax that I've seen so far: #! currently reserved for users #-T where T would be a feature of every implementation #+IGNORE Where IGNORE could not be a feature in any lisp implementation #; possible conflict with the syntax for comment to end of line #+(or) clever but not immediately obvious #-(and) clever but not immediately obvious Most # letter combinations are presently undefined and not reserved for the user. Unfortunately, #c is used for complex numbers. Maybe the next best is #d {"Don't use" or "semantically Delete from program"} There are about 10 other oddball chars that are not defined or reserved for # reader macros. They are: " $ % & > @ ^ _ ` ~ Out of these, I guess I'd favor #% but I have no strong preference. #; is easy to remember for those of us already use to the semicolon comment. How much editor or whatever code is out there that would have to be modified?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Mar 86 18:45:42 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 Mar 86 15:37:41 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7203; Thu 20-Mar-86 18:37:42-EST Date: Thu, 20 Mar 86 18:37 EST From: David C. Plummer Subject: Standardization To: C410DD60 , common-lisp@SU-AI.ARPA In-Reply-To: <20Mar86.170218.DD60@A.CS.CMU.EDU> Message-ID: <860320183705.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 20 Mar 86 17:02 EST From: David.Dill@A.CS.CMU.EDU (C410DD60) To what extent can Common Lisp be changed in the process of becoming a standard? Let's call the thing published by Digital Press CLtL'84. Let's also assume that the typos and clarifications are also part of the language. There have been some proposed extensions and some proposed changes to CLtL'84. Some of these are acknowledged bugs in the language, e.g., GET-SETF-METHOD needs to take an environment. Others are not, e.g., should the TRUE and FALSE functions be put into the language? I hope that the ANSI/ISO standardization is not a rubber stamping of CLtL'84 but instead incorporates or addresses the ideas and proposals in the years since then. The result may drop some things that are in CLtL'84 and add other things. Yes, this means incompatible, and it means that vendors have to say "We implement CLtL'84" or "We implement ISO Lisp ye6.4.t9", but on the other hand, most vendors, and perhaps this list, may agree that the ANSI/ISO version overrides CLtL'84.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Mar 86 17:21:25 EST Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Mar 86 14:15:38 PST Date: Thu, 20 Mar 86 17:02 EST From: David.Dill@A.CS.CMU.EDU (C410DD60) To: common-lisp@su-ai.arpa Subject: Standardization Message-Id: <20Mar86.170218.DD60@A.CS.CMU.EDU> To what extent can Common Lisp be changed in the process of becoming a standard?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Mar 86 16:37:20 EST Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 20 Mar 86 13:27:23 PST Date: 20 Mar 1986 13:26-PST Sender: MATHIS@USC-ISIF.ARPA Subject: SPARC Endorses X3J13 From: MATHIS@USC-ISIF.ARPA To: Common-Lisp@SU-AI.ARPA Cc: Mathis@USC-ISIF.ARPA Message-ID: <[USC-ISIF.ARPA]20-Mar-86 13:26:04.MATHIS> NEWS: Today SPARC endorsed the proposal for the formation of a new X3 technical committee (X3J13) for work on a standard for Common Lisp. It now goes forward to a full X3 vote. SPARC also endorsed the associated new work item (NWI) proposal for an ISO standard for Common Lisp. This also goes to X3 for a vote and then into the ISO structure. For more information contact: Bob Mathis, 9712 Ceralene Drive, Fairfax, VA 22032-1704, (703)-425-5923  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Mar 86 00:03:52 EST Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 19 Mar 86 20:56:10 PST Received: by uw-beaver.arpa (4.42/4.2) id AA16448; Wed, 19 Mar 86 21:03:33 PST Date: Wed, 19 Mar 86 21:03:33 PST From: @uw-beaver.arpa Return-Path: <@uw-beaver.arpa> Message-Id: <8603200503.AA16448@uw-beaver.arpa> Apparently-To: COMMON-LISP@SU-AI.ARPA  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Mar 86 17:57:09 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Mar 86 14:33:46 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAR 86 14:33:52 PST Date: 19 Mar 86 14:32 PST From: Masinter.pa@Xerox.COM Subject: Re: Ignoring a list. To: COMMON-LISP@su-ai.ARPA Message-ID: <860319-143352-3298@Xerox> While we're having this silly discussion: my standard way of commenting out code is (if nil ..code..) and then putting it back in is (if t ..code..) You have to mark both ends to comment it out, but then putting it back in is trivial. You can comment the nil and t if you want.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Mar 86 15:12:26 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 19 Mar 86 11:57:16 PST Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA07213; Wed, 19 Mar 86 13:17:15 CST Message-Id: <8603191917.AA07213@gswd-vms.ARPA> Date: Wed, 19 Mar 86 13:12:54 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: Ignoring a list. From: Gregor.pa@Xerox.COM Subject: Re: Ignoring a list. This seems like an environment issue to me, and not one that the language needs to take a stand on. After all: - A particular environment might have some really nice way of implementing and supporting this feature. It could gray the form out, or turn it blue or something. In that environment the "standard" way of implementing it might not be useful or it might be difficult to provide really nice environment support for it. ---------- A particular environment might have a really nice way of supporting comments, say by displaying them in italics or boxes. Therefore the standard shouldn't provide a standard way of indicating comments... ---------- - There is no significant need for a "standard" way to do this because the only time a user really needs to comment out random forms (in a hurry) is when they are debugging. If you are debugging then you already have to learn enough about the environment that knowing how to comment out a form does not seem like such a burden. ---------- I suppoose it's slightly tacky to ship code with debugging support in it, but I'd really like to know that my commented-out forms will still be commented out on the standard system I deliver them to. Also, there is a limited set of #s reserved to the user -- I would prefer this form came from the general "undefined" pot rather than the "undefined and guaranteed never to be defined" pot. ---------- - To the extent that we do need a "standard" way of doing this (which I have argued above is a small extent).there is already a standard way of doing it. Take the name of the lisp you are using and use #-, as in #-FooLisp. ---------- So somebody taking my code and trying (silly person) to port it to another CL will suddenly have my commented-out code reappearing? This isn't really a major issue, but the ability to comment out a form by marking the beginning of it seems like a very useful ability to have. Marking both ends is (a) a pain in the ass, even if it does take only two keystrokes to get to the end of the form and (b) much more prone to the "oops, i took out the front one but not the back one" variety of error. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Mar 86 13:16:14 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Mar 86 10:02:12 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAR 86 09:49:26 PST Date: 19 Mar 86 09:50 PST From: Gregor.pa@Xerox.COM Subject: Re: Ignoring a list. In-reply-to: David C. Plummer 's message of Wed, 19 Mar 86 10:13 EST To: DCP@SCRC-QUABBIN.ARPA cc: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA Message-ID: <860319-094926-2920@Xerox> This seems like an environment issue to me, and not one that the language needs to take a stand on. After all: - A particular environment might have some really nice way of implementing and supporting this feature. It could gray the form out, or turn it blue or something. In that environment the "standard" way of implementing it might not be useful or it might be difficult to provide really nice environment support for it. - There is no significant need for a "standard" way to do this because the only time a user really needs to comment out random forms (in a hurry) is when they are debugging. If you are debugging then you already have to learn enough about the environment that knowing how to comment out a form does not seem like such a burden. - To the extent that we do need a "standard" way of doing this (which I have argued above is a small extent). there is already a standard way of doing it. Take the name of the lisp you are using and use #-, as in #-FooLisp.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Mar 86 11:44:53 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 19 Mar 86 06:22:38 PST Date: 19 Mar 86 09:14:00 EST From: "BACH::GREEK" Subject: Ignoring a list. To: "common-lisp" Reply-To: "BACH::GREEK" I agree with Scott that this is a fairly absurd discussion (I don't, however, agree with his editorial comment about FORMAT, which is moaned about all over but never with an alternative suggestion. [This is not an editorial comment, of course]). In the time we've all spent writing about some method of ignoring one list, we could all have typed many #| ... |# constructs. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Mar 86 11:37:39 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 19 Mar 86 07:13:33 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6489; Wed 19-Mar-86 10:13:32-EST Date: Wed, 19 Mar 86 10:13 EST From: David C. Plummer Subject: Ignoring a list. To: "BACH::GREEK" , common-lisp In-Reply-To: The message of 19 Mar 86 09:14-EST from "BACH::GREEK" Message-ID: <860319101300.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 19 Mar 86 09:14:00 EST From: "BACH::GREEK" I agree with Scott that this is a fairly absurd discussion (I don't, however, agree with his editorial comment about FORMAT, which is moaned about all over but never with an alternative suggestion. [This is not an editorial comment, of course]). In the time we've all spent writing about some method of ignoring one list, we could all have typed many #| ... |# constructs. That's true. The thing we are dicussing is that you can type 3 or 4 times as many #;, #+IGNORE's, #+++IGNORE's, etc, than you can type #|...|#. This is because #|...|# requires hacking two places in the text (before and after the expression). Removing a #+IGNORE to reinstate code is similarly easier than removing the #| |# pair.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 21:21:27 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Mar 86 18:10:18 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 441580; Tue 18-Mar-86 21:09:02-EST Date: Tue, 18 Mar 86 21:09 EST From: Kent M Pitman Subject: [ART@THINK-AQUINAS.ARPA: Another To: Fahlman@C.CS.CMU.EDU cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: Message-ID: <860318210941.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue, 18 Mar 1986 17:56 EST From: "Scott E. Fahlman" I am a bit leery of #+ignore or #+++ignore, because some turkey could make IGNORE or ++IGNORE be a feature after all and ruin everything; but #+(or) strikes me as an acceptable idiom (but perhaps #-(and) is better to emphasize its negative nature). Feh! This is by far the ugliest and most confusing construct ever proposed for Common Lisp (not counting Format, of course). I don't think that this problem needs to be solved, but if it does I find #; infinitely preferable, even though it wastes a perfectly good macro character. As a pragmatic issue, some text editors (particularly Emacs) will have trouble with "#;" because they will think the ";" means comment to end of line and may not recognize the "#;" as a cluster. While such programs would obviously be in error, they might not get fixed very quickly and users might suffer as a consequence. For this reason, I suggest that "#;" be held in reserve and not used for anything that does not read just a single line of text. Similar motivation was likely used when we made #|...|# be matchfix -- to avoid confusion with the fact that |...| by itself is matchfix. -kmp  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 20:31:22 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 17:21:13 PST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6407; Tue 18-Mar-86 20:11:33-EST Date: Tue, 18 Mar 86 20:09 EST From: David A. Moon Subject: Re: [ART@THINK-AQUINAS.ARPA: Another To: Common-Lisp@SU-AI.ARPA In-Reply-To: <860318173619.4.GLS@THINK-UBALDO.ARPA> Message-ID: <860318200937.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 18 Mar 86 17:36 EST From: Guy Steele > Date: Tue, 18 Mar 1986 10:42 EST > From: "Scott E. Fahlman" > I'd like to see the combination #! be reserved for something more > important and interesting than comment out a single expression. ....The problem with either of these methods, however, is that both ; and #| are forced to treat their contents as unstructured text, and therefore many editors cannot deal with editing the code in its commented-out state (it won't indent properly, etc.). Our editor uses #|| ... ||# as a way to comment out structured text. This is just a convention and doesn't involve an actual extension to Common Lisp. I'm not sure whether editor conventions are properly in the domain of the Common Lisp language specification, though.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 18:03:19 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Mar 86 14:53:57 PST Received: ID ; Tue 18 Mar 86 17:56:06-EST Date: Tue, 18 Mar 1986 17:56 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: COMMON-LISP@SU-AI.ARPA Subject: [ART@THINK-AQUINAS.ARPA: Another In-reply-to: Msg of 18 Mar 1986 17:36-EST from Guy Steele I am a bit leery of #+ignore or #+++ignore, because some turkey could make IGNORE or ++IGNORE be a feature after all and ruin everything; but #+(or) strikes me as an acceptable idiom (but perhaps #-(and) is better to emphasize its negative nature). Feh! This is by far the ugliest and most confusing construct ever proposed for Common Lisp (not counting Format, of course). I don't think that this problem needs to be solved, but if it does I find #; infinitely preferable, even though it wastes a perfectly good macro character. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 17:52:49 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Mar 86 14:34:06 PST Received: from ubaldo by GODOT.THINK.COM via CHAOS; Tue, 18 Mar 86 17:34:25 est Date: Tue, 18 Mar 86 17:36 EST From: Guy Steele Subject: Re: [ART@THINK-AQUINAS.ARPA: Another To: DCP@SCRC-QUABBIN.ARPA, preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860318163930.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-Id: <860318173619.4.GLS@THINK-UBALDO.ARPA> Date: Tue, 18 Mar 86 16:39 EST From: David C. Plummer Date: Tue, 18 Mar 86 14:33:57 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) > From: David A. Moon > Date: Tue, 18 Mar 1986 10:42 EST > From: "Scott E. Fahlman" > I'd like to see the combination #! be reserved for something more > important and interesting than comment out a single expression. > We typically use #+IGNORE for this, although personally I'm a big fan > of semicolon for comments. ---------- So, why not use "#;", which the book says is undefined? Seems reasonably mnemonic to make it "ignore s-expression" given that I don't think this is in the domain of the language, since there is already a perfectly good way (two actually: ; and #|...|#) to comment something out. The responses so far have shown that several people have different ways to accomplish the goal.... It seems to me that if several people have independently found it necessary to invent another way, however crocky, to comment out an s-expression, then the existing methods are not perfectly good. I too have found ; and #| inconvenient for this purpose. One reason is that one is forced not only to insert the comment mark itself but often also one or more newlines. (cond ((am-i-losing) (try-to-win)) ((am-i-winning) #|(try-to-lose)|#) (t (try-to-try))) really looks awful, and to use ";" one must do something like (cond ((am-i-losing) (try-to-win)) ((am-i-winning) ;;(try-to-lose) ) (t (try-to-try))) [the double semicolon being necessary to make the indentation conventions of many editors do the right thing]. The problem with either of these methods, however, is that both ; and #| are forced to treat their contents as unstructured text, and therefore many editors cannot deal with editing the code in its commented-out state (it won't indent properly, etc.). This is the main attraction for me of a standard way to comment out an s-expression. I am a bit leery of #+ignore or #+++ignore, because some turkey could make IGNORE or ++IGNORE be a feature after all and ruin everything; but #+(or) strikes me as an acceptable idiom (but perhaps #-(and) is better to emphasize its negative nature). --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 16:51:51 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 13:40:29 PST Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6287; Tue 18-Mar-86 16:40:21-EST Date: Tue, 18 Mar 86 16:39 EST From: David C. Plummer Subject: Re: [ART@THINK-AQUINAS.ARPA: Another To: Scott E. Preece , COMMON-LISP@SU-AI.ARPA In-Reply-To: <8603182038.AA06268@gswd-vms.ARPA> Message-ID: <860318163930.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 18 Mar 86 14:33:57 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) > From: David A. Moon > > Date: Tue, 18 Mar 1986 10:42 EST > From: "Scott E. Fahlman" > > > I'd like to see the combination #! be reserved for something more > important and interesting than comment out a single expression. > > We typically use #+IGNORE for this, although personally I'm a big fan > of semicolon for comments. ---------- So, why not use "#;", which the book says is undefined? Seems reasonably mnemonic to make it "ignore s-expression" given that ";" is "ignore-rest-of-line". -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece I don't think this is in the domain of the language, since there is already a perfectly good way (two actually: ; and #|...|#) to comment something out. The responses so far have shown that several people have different ways to accomplish the goal. Mine is #+++ignore (and to put temporary code in that really shouldn't be there, I use #---ignore
) on the grounds that I can later search for --- and +++ as markers for things needing attention.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 15:49:26 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Mar 86 12:39:15 PST Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA06268; Tue, 18 Mar 86 14:38:14 CST Message-Id: <8603182038.AA06268@gswd-vms.ARPA> Date: Tue, 18 Mar 86 14:33:57 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: [ART@THINK-AQUINAS.ARPA: Another > From: David A. Moon > > Date: Tue, 18 Mar 1986 10:42 EST > From: "Scott E. Fahlman" > > > I'd like to see the combination #! be reserved for something more > important and interesting than comment out a single expression. > > We typically use #+IGNORE for this, although personally I'm a big fan > of semicolon for comments. ---------- So, why not use "#;", which the book says is undefined? Seems reasonably mnemonic to make it "ignore s-expression" given that ";" is "ignore-rest-of-line". -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 14:46:20 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 11:37:41 PST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6264; Tue 18-Mar-86 14:37:37-EST Date: Tue, 18 Mar 86 14:35 EST From: David A. Moon Subject: [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)] To: common-lisp@SU-AI.ARPA, cal@THINK-AQUINAS.ARPA In-Reply-To: <860318101323.2.GLS@THINK-UBALDO.ARPA> Message-ID: <860318143541.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 17 Mar 86 04:52 EST From: Cliff Lasser It appears that CL:MAKE-PACKAGE makes it necessary to refer to unexported symbols of that package as FOO::BAR as opposed to FOO:BAR. Is there anyway to tell CL that ALL symbols of a package should be exported so that the behavior is the same as ZL:MAKE-PACKAGE? For the record, Symbolics' implementation includes as extensions the :EXTERNAL-ONLY (value T or NIL) and :COLON-MODE (value :INTERNAL or :EXTERNAL) options to MAKE-PACKAGE for this purpose. The former option exports all symbols, the latter simply causes : to have the same effect as :: . I don't know whether any other implementations have picked up these ideas.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 14:34:48 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 18 Mar 86 11:25:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6257; Tue 18-Mar-86 14:24:55-EST Date: Tue, 18 Mar 86 14:23 EST From: David A. Moon Subject: [ART@THINK-AQUINAS.ARPA: Another reader macro] To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860318142305.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 18 Mar 1986 10:42 EST From: "Scott E. Fahlman" I'd like to see the combination #! be reserved for something more important and interesting than comment out a single expression. The #| ... |# does this job perfectly well, except that you need to find the end of the thing you are commenting out: only one or two extra keystrokes in a decent editor. I suppose that if doing this as a pure prefix were deemed useful, we could adopt the convention that the feature T is always present in all Common Lisps, so that #-T would do the right thing. We typically use #+IGNORE for this, although personally I'm a big fan of semicolon for comments.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 11:08:55 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Mar 86 07:57:46 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 440718; Tue 18-Mar-86 10:40:26-EST Date: Tue, 18 Mar 86 10:41 EST From: Kent M Pitman Subject: Error handling proposal To: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 18 Mar 86 00:26-EST from Dick Gabriel Message-ID: <860318104101.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 17 Mar 86 2126 PST From: Dick Gabriel The file is: CLERR.PRP[COM,LSP] and can be FTPed without login. -rpg- A word of explanation for those who don't understand what this message is about. The proposal is going to be discussed on CL-ERROR-HANDLING for now. When it has reached concensus on that list, it will be moved to the COMMON-LISP list. If you're not on CL-ERROR-HANDLING and would like to be, send mail to RPG@SU-AI. Please do not send mail about this to COMMON-LISP for now, since it's a broader list and some of its recipients may not want to see every detail of the design process. Thanks, -kmp  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 10:49:19 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Mar 86 07:40:38 PST Received: ID ; Tue 18 Mar 86 10:42:49-EST Date: Tue, 18 Mar 1986 10:42 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: [ART@THINK-AQUINAS.ARPA: Another reader macro] In-reply-to: Msg of 18 Mar 1986 10:31-EST from Guy Steele I'd like to see the combination #! be reserved for something more important and interesting than comment out a single expression. The #| ... |# does this job perfectly well, except that you need to find the end of the thing you are commenting out: only one or two extra keystrokes in a decent editor. Is suppose that if doing this as a pure prefix were deemed useful, we could adopt the convention that the feature T is always present in all Common Lisps, so that #-T would do the right thing. [It's really too bad that some people decided that T and NIL were cute names for Lisp dialects. Would #-T run afoul of someone's T-language emulation package?] -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 10:37:22 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Mar 86 07:29:29 PST Received: from ubaldo by GODOT.THINK.COM via CHAOS; Tue, 18 Mar 86 10:29:47 est Date: Tue, 18 Mar 86 10:31 EST From: Guy Steele Subject: [ART@THINK-AQUINAS.ARPA: Another reader macro] To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <860318103140.4.GLS@THINK-UBALDO.ARPA> Another true-life story from a real User: Date: Tue, 18 Mar 86 01:19 EST From: Art Medlar I've often had a need to comment out a single s-expression temporarily. Using a semicolon is reasonable only when the expression is on one line, and it's really annoying when the line containing the expression has other things that you don't want to comment out, like closing parentheses of super-expressions. #-LISPM would probably work, but it's not intended to be used this way, and it's too long. So I wrote the #! reader macro. When placed immediately in front of a list, it causes the reader to completely ignore the list. It's a lot like #| |# except it operates over a single s-expression and so needs no termination symbol. It is more useful than (comment ...) and (ignore ...) since comment returns the symbol COMMENT and ignore returns NIL. For example, the following form returns T (and (minusp -1) #!(zerop (+ 4 3)) (plusp 1) #!(zerop 0)) To get it, load a:>utility>reader-macros. If it doesn't cause any problems, I'll add it to the system. --art  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 10:19:52 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Mar 86 07:10:49 PST Received: from ubaldo by GODOT.THINK.COM via CHAOS; Tue, 18 Mar 86 10:11:29 est Date: Tue, 18 Mar 86 10:13 EST From: Guy Steele Subject: [CAL@THINK-AQUINAS.ARPA: packages and common lisp (yuk)] To: common-lisp@SU-AI.ARPA Cc: cal@THINK-AQUINAS.ARPA Message-Id: <860318101323.2.GLS@THINK-UBALDO.ARPA> This may be relevant to Common Lispers: Date: Mon, 17 Mar 86 20:29 EST From: Cliff Lasser Date: Mon, 17 Mar 86 12:55 EST From: Guy Steele Date: Mon, 17 Mar 86 04:52 EST From: Cliff Lasser It appears that CL:MAKE-PACKAGE makes it necessary to refer to unexported symbols of that package as FOO::BAR as opposed to FOO:BAR. Is there anyway to tell CL that ALL symbols of a package should be exported so that the behavior is the same as ZL:MAKE-PACKAGE? Thanx -Cliff Apparently not. About the best you can do is, at some appropriately late point, (do-symbols (x pkg) (export x pkg)). --Guy UGH  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Mar 86 00:55:28 EST Date: 17 Mar 86 2126 PST From: Dick Gabriel Subject: Error handling proposal To: common-lisp@SU-AI.ARPA The file is: CLERR.PRP[COM,LSP] and can be FTPed without login. -rpg-  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Mar 86 22:45:31 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Mar 86 19:34:59 PST Received: ID ; Mon 17 Mar 86 22:37:05-EST Date: Mon, 17 Mar 1986 22:37 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Committee Membership for ANSI/ISO At the December Common Lisp meeting Scott Fahlman, Dick Gabriel, Bob Mathis, Dave Moon, Stephen Squires, Guy Steele, and Dan Weinreb were charged with the duty of selecting a technical committee and a steering committee to develop ANSI and ISO standards for Common Lisp. This message is to report on the membership of those committees, to describe the actions we have taken towards making those committees official, and to outline the next steps we need to take. We have decided not to create the committee under DARPA sponsorship, but rather to operate within the ANSI framework, setting up a committee for Common Lisp under X3 tentatively known as X3J13. The membership in X3J13 will be self-selecting: X3 committees are open to anyone who pays the dues ($150/year) and who participates actively in the committee's work. These organizations move very slowly: X3J13 cannot begin operating until next fall at the earliest. Once the X3J13 committee is functioning, the technical and steering committees will report to X3J13. In the meantime, we expect to make considerable progress toward producing an acceptable standard. X3 committees are permitted to have members from other countries. We have not asked anyone outside the U. S. to join either committee as yet, but we intend to invite some members from outside the U. S. as a way of getting the benefit of international experience and cooperation. There are two committees that we propose to establish now: the steering committee and the technical committee. The steering committee is charged with guiding the results of the technical committee through the standardization process, particularly at the ISO level. The technical committee is to refine the language definition and produce a document specifying the proposed Common Lisp standard. The American members of the steering committee are: Richard P. Gabriel, Lucid, Inc. Robert F. Mathis, Private Consultant John McCarthy, Stanford University Ronald Ohlander, USC Information Sciences Institute Stephen L. Squires, Defense Advanced Research Projects Agency Guy L. Steele Jr., Thinking Machines, Inc. The American members of the technical committee were chosen according to several criteria: (1) The member must have a deep knowledge of Lisp, with experience both in the implementation and design of at least one serious Lisp implementation. (2) The member must be a well-recognized, prominent individual. He or she must be someone whose reputation is recognized internationally. (3) The group, considered as a whole, must reflect the wide variety of viewpoints and backgrounds that are present in the Common Lisp community. (4) The committee must not be so large that it is unable to reach decisions with reasonable speed. (5) The members are chosen as individuals with a commitment to the success of Common Lisp as a widely used standard, and not as representatives of their respective companies or organizations. Obviously, if the committee is to be of reasonable size, it is not possible for every company and implementation group to be represented on the technical committee. Our intention is to discuss each issue as it arises on the Common Lisp mailing list and to invite any interested individuals to observe and participate in this discussion. The technical committee will be responsible for making final decisions on what will go into the proposed Common Lisp document, but no final decisions will be made without ample opportunity for input from the whole community. Some disagreement is probably inevitable, but there will be no surprises. While the opinion of each individual will be considered, companies may wish to appoint an official spokesperson who is authorized to speak for the company in technical matters. We will attempt to arrange for netmail access for one person from any serious implementation group that does not currently enjoy such access. The American members of the technical committee are: Alan Bawden, Massachusetts Institute of Technology Daniel G. Bobrow, Xerox Corporation Scott E. Fahlman, Carnegie-Mellon University Richard P. Gabriel, Lucid, Inc. Martin L. Griss, Hewlett-Packard, Inc. David A. Moon, Symbolics, Inc. Jonathan A. Rees, Massachusetts Institute of Technology Guy L. Steele Jr., Thinking Machines, Inc. At this point a document has been submitted to the Standards Planning and Requirements Committee of X3, known as SPARC, proposing the formation of the X3J13 committee. SPARC is the committee which must approve the formation of any new technical committees. The document outlines the need for such a committee, the scope of the standard, the potential members of the committee, and the plan and schedule for accomplishing the standard. We hope that the standardization work informally started in the Lisp community will continue to fruition at the national and international levels. Scott E. Fahlman Richard P. Gabriel Robert F. Mathis David A. Moon Guy L. Steele Jr. Stephen L. Squires Daniel L. Weinreb  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Mar 86 11:49:19 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 17 Mar 86 08:41:34 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA16499; Mon, 17 Mar 86 09:43:59 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA06716; Mon, 17 Mar 86 09:43:56 MST Date: Mon, 17 Mar 86 09:43:56 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8603171643.AA06716@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Namespaces While the idea of defining namespaces is intriguing, I don't think we're in a position to try to standardize on it. The notion of "namespace" is pretty informal - we talk about namespaces for variables, for functions, for packages, etc. But recall that separate namespaces for variables and functions implies that symbol-function and symbol-value are different, plus we have an flet in addition to let, as well as a great many other consequences. Being able to define new namespaces and attach interesting semantics to them is tantamount to being able to make an implementation switch from Common Lisp to Scheme and back at the tweak of a flag. I haven't seen anybody do this! (although it would make an interesting paper). So since namespace definition is a fairly heavy-duty research issue, we shouldn't try to standardize on it, unless someone has an absolutely brilliant proposal... stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Mar 86 04:30:36 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Mar 86 01:23:19 PST Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 17 Mar 86 04:15-EST Date: Mon, 17 Mar 86 04:14 EST From: Christopher Fry Reply-To: cfry%oz@MIT-MC.ARPA Subject: How many name spaces in CL? To: Fahlman@C.CS.CMU.EDU, GJC@MIT-MC.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860317041432.3.CFRY@DUANE.AI.MIT.EDU> Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 14 Mar 86 11:15-EST Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 11:14:01 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86 07:48:11 PST Received: ID ; Fri 14 Mar 86 10:48:08-EST Date: Fri, 14 Mar 1986 10:48 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: Common-Lisp@SU-AI.ARPA Subject: How many name spaces in CL? In-reply-to: Msg of 14 Mar 1986 07:46-EST from George J. Carrette WHy would anyone want to enumerate this set? There are a bunch of obvious members, and then they get kind of arguable and trail off into infinity. I've thought about such a list myself. A list of namespaces is a concise, useful viewpoint of CL. Thank you GJC for making it for us. I hope it will appear in the next CLtL. With so many name spaces already it is unfortnate there is no construct for defining new name spaces. There are several such mechanisms: hashtables, property lists, macros... it all depends on how you choose to look at the result. A mechanism for defining namespaces has some interesting possibilities. First, the list that GJC constructed by hand could have been created automatically by the def-namespace form. If for no other reason than documentation, its useful. Next, I can imagine an apropos which takes a list of namespaces to search through. I'll be suprised if there aren't other uses, though I wouldn't want to jump into making such a mechanism part of CL. Scott raises the issue that every plist or random alist is, in effect, a separate namespace. This is true for one definition of namespace. But at least some of the namespaces that GJC was using have the characteristic that each namespace contained only and all objects of a type. Such is not true for random data structures. Maybe this property can be exploited for a general gain in power similarly to deftype?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 10:58:21 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86 07:48:11 PST Received: ID ; Fri 14 Mar 86 10:48:08-EST Date: Fri, 14 Mar 1986 10:48 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: Common-Lisp@SU-AI.ARPA Subject: How many name spaces in CL? In-reply-to: Msg of 14 Mar 1986 07:46-EST from George J. Carrette WHy would anyone want to enumerate this set? There are a bunch of obvious members, and then they get kind of arguable and trail off into infinity. With so many name spaces already it is unfortnate there is no construct for defining new name spaces. There are several such mechanisms: hashtables, property lists, macros... it all depends on how you choose to look at the result. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 09:06:00 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Mar 86 05:58:39 PST Received: ID ; Fri 14 Mar 86 08:58:33-EST Date: Fri, 14 Mar 1986 08:58 EST Message-ID: From: Rob MacLachlan To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA Cc: Common-Lisp@SU-AI.ARPA Subject: Packages Date: Thursday, 13 March 1986 16:42-EST From: MURRAY%umass-cs.csnet at CSNET-RELAY.ARPA To: Common-Lisp at su-ai.ARPA Re: Packages A Truly Portable Common-Lisp program can use ONLY the LISP package, or one that it has created itself. If not, then it uses something that is NOT in Common-Lisp, and therefore would have to be modified to run on a different machine/system. Thus, I don't see what all the fuss it about. If you use the DEBUGGER package, then your code is NOT Common-Lisp. This has been stated before by other people (Gregor, Wienreb), and I hope it won't need to be stated again. Untrue, or at least not proven. Using a package doesn't imply that any symbols from that package are used in code. Why would you use a package when you don't use any of the symbols? My answer is that some symbols may be part of the programming environment rather than part of code. My program doesn't call debug:backtrace, but I do. I am therefore not portable, but this has no direct effect on my program. JAR suggests that this problem can be avoided by not using Lisp symbols in the user interface. This may be a good idea, but it is not obvious to me that Common Lisp should make impossible reasonable user interfaces which do use symbols. Interestingly, DCP says: Personally, I always specify a default for MAKE-PACKAGE :USE. That's probably because our default is to :USE only LISP, which I think is the right thing. :USE'ing any other packages would lead to name conflicts KMP is trying to avoid. This leads me to conclude that he never writes a portable program, since he always explicitly mentions non-Common Lisp packages in his :USE lists. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 07:52:43 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Mar 86 04:45:24 PST Date: Fri, 14 Mar 86 07:46:13 EST From: "George J. Carrette" Subject: How many name spaces in CL? To: gls@AQUINAS.THINK.COM cc: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of Wed 12 Mar 86 10:27 EST from Guy Steele Message-ID: <[MC.LCS.MIT.EDU].850498.860314.GJC> I've been trying to come up with a complete list of name spaces in CL. So far I have: 0. SPECIAL FORM 1. lexical bound function, e.g. FLET 2. global function, SYMBOL-FUNCTION, presumably DEFUN? 3. lexical value. LET, SETQ. 4. fluid value. LET, SETQ, semantics overloaded via special declaration. 5. GO TAGBODY 6. BLOCK NAME 7. CATCH TAG 8. TYPE SPECIFIER 9. PACKAGE NAME Did I leave any out? It might be nice to have a table of these in the CL manual. Columns with entries for the binding and setting constructs, or an "X" if no construct. With so many name spaces already it is unfortnate there is no construct for defining new name spaces.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 07:38:50 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 14 Mar 86 04:32:43 PST Date: Fri, 14 Mar 86 07:33:35 EST From: "George J. Carrette" Subject: Package Naming Conventions To: greek%bach.decnet@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 13 Mar 86 08:51:00 EST from BACH::GREEK Message-ID: <[MC.LCS.MIT.EDU].850474.860314.GJC> From time to time I have had to deal with 3 programs that were in the COMPILER package. Obviously all three were compilers. One was lispmachine native, and the other two cross compilers. In the LMI software, and most likely in the TI and Symbolics too by pedigree, the package NAME space is potentially nested, so you can set up packages that shadow other package names. Then package names can be used a bit more like one uses directory names in an operating system, it makes sense to nest them, FOO:BAR:BAZ:SYMBOL. (Search rules and ACLS anyone?) You probably want to introduce such a feature into your system, so then at least users will be able to port code without package name conflicts. Look at the bright side, at least on a VAX you can run more than one lisp environment at the same time on the same machine. -gjc  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 14 Mar 86 02:06:44 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Mar 86 22:58:47 PST Date: Fri, 14 Mar 86 01:59:39 EST From: "Glenn S. Burke" Subject: -*- lines To: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].850353.860314.GSB> I found these especially useful in Maclisp where the parsiing had to be done in Teco. I'm not going to bother to explain all the references, but for those who know already, i did a file attribute list frob for LSB which (redundantly) specified the module and system, and the use of an LSB file attribumte list option was useful for both incremnetal compilation on the lispm and for getting things read into Maclisp via LEDIT in the correct readtable. I just looked at the creation date of the latest such hacked ledit file i use, and it was in 1980. I was a bit surprised by the age... It's still being used.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 20:25:06 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 13 Mar 86 17:12:28 PST Received: from LONG-TAILED-JAEGER.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5012; Thu 13-Mar-86 20:12:02-EST Date: Thu, 13 Mar 86 20:14 EST From: David A. Moon Subject: Re: (DELETE ... :COUNT NIL) To: NGALL@G.BBN.COM cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]13-Mar-86 19:51:02.NGALL> Message-ID: <860313201417.4.MOON@LONG-TAILED-JAEGER.SCRC.Symbolics.COM> Date: 13 Mar 1986 19:51-EST From: NGALL@G.BBN.COM Date: Thu, 13 Mar 86 15:52 EST From: Kent M Pitman I cannot find any place in CLtL where it specifies what will happen if you try to do: (DELETE thing list :COUNT NIL) Cf. pg 247, first para. So the only actual problem is that the definition of the arguments to DELETE is not in the section of the manual that purports to describe DELETE. Good, I wish all language issues were disposed of this easily!  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 20:10:56 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Mar 86 16:53:45 PST Date: 13 Mar 1986 19:51-EST Sender: NGALL@G.BBN.COM Subject: Re: (DELETE ... :COUNT NIL) From: NGALL@G.BBN.COM To: KMP@SCRC-STONY-BROOK.ARPA Cc: Common-Lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]13-Mar-86 19:51:02.NGALL> In-Reply-To: <860313155229.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu, 13 Mar 86 15:52 EST From: Kent M Pitman To: Common-Lisp@SU-AI.ARPA Subject: (DELETE ... :COUNT NIL) Message-ID: <860313155229.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I cannot find any place in CLtL where it specifies what will happen if you try to do: (DELETE thing list :COUNT NIL) Cf. pg 247, first para. The discussion of keywords on p62 suggests that keywords get initialized to NIL if not supplied. I assume you mean "if [an initform is] not supplied." On p254, the notation used to describe DELETE is ambiguous. Because the syntax is described as DELETE @i(item) @i(sequence) &key :from-end :test ... and not DELETE @i(item) @i(sequence) &key from-end test ... it's hard to tell whether the author meant to imply that these keywords would default to NIL if unsupplied or whether there might be initial values that he wasn't telling us about. I don't understand why the colon-prefix makes a difference. The default value for :from-end is nil (cf. pg 246). The default value for :test is EQL (or maybe #'EQL, cf. pg 245). From experience, I have learned to distrust the initializations of &optional and &key variables because they frequently lead to confusion. That is, if you tell someone "the stream is optional and defaults to standard output", they still can't tell without constructing an experiment whether you mean: (DEFUN FOO (&OPTIONAL STREAM ...) (IF (NOT STREAM) (SETQ STREAM *STANDARD-OUTPUT*)) ...) or (DEFUN FOO (&OPTIONAL (STREAM *STANDARD-OUTPUT*) ...) ...) The latter may seem to be implied, but in my experience, the former implementation is much more robust since it allows one to simply write NIL when they only want to specify a later variable. eg, if I only want to supply a second argument of 3, I can write: (FOO NIL 3) to match the first implementation, but must write: (FOO *STANDARD-OUTPUT* 3) if the implementation is the second. In cases where the default is computed in some hairy and/or private way, the situation complicates considerably. The right thing to do is to say "if the STREAM is unsupplied or NIL it defaults to the value of the special variable *standard-input*" (cf. pg 374). This can be implemented with (defun foo (&optional (stream nil)) (setf stream (or stream *standard-output*))...) Sometimes, the actual implementation may even have been driven by irrelevant issues like whether the arglist was `getting too cluttered' and the writer may have just taken the initialization down in the body to `pretty things up' without really thinking out what the semantic effect of that change would be. The argument for &KEY is similar. It may turn out that you want to define a function DELQ as per Maclisp. Two possible implementations present themselves: (DEFUN DELQ (THING LIST &OPTIONAL COUNT) (DELETE THING LIST :TEST #'EQ :COUNT COUNT)) and (DEFUN DELQ (THING LIST &OPTIONAL (COUNT NIL COUNT-P)) (APPLY #'DELETE THING LIST :TEST #'EQ (IF COUNT-P (LIST :COUNT COUNT) '()))) Is this perspicuous enough? (defun delq (thing list &optional (count nil)) (delete thing list :test #'eq :count (or count (length list)))) Personally, I think the former is more perspicuous, but it can only be written if we define that it is acceptable for DELETE to take a :COUNT argument of NIL. If the definition of DELETE is left as vague as it is now, only the second implementation of DELQ above will be portable. See above. This issue is obviously more general than just DELETE. My conclusions from all this are as follows: * The manual is simply ambiguous on this point currently and unless someone can cite a definitive passage, I guess we'll have to resign ourselves to this not being defined. See above passage. * Wherever it is possible to get some concensus, I think we should strive to make passing a keyword of NIL be the same as not passing a keyword. There will be cases where this will not be possible, so I am not suggesting that this be an across the board thing -- but I think it can usefully be handled on a case-by-case basis. :COUNT, :TEST, and :TEST-NOT keywords are good places to start, however, since there could be no confusion about whether the NIL was intended as a valid argument. Things like :VERBOSE would not be candidates since NIL is already valid as an explicit argument. I think this is the current consensus. I think that all keywords for which NIL is an invalid argument are documented as "if supplied and not NIL" (i.e., supplying NIL is equiv. to not supplying the keyword arg). Two exceptions are :test and :test-not. This should be clarified on page 246. * Where there is no concensus, or where we agree that passing a keyworded value of NIL is different than passing no argument, the manual should clearly indicate such. The manual should always clearly state what the default for a keyword is. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 18:47:48 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Mar 86 15:36:51 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 437344; Thu 13-Mar-86 15:52:39-EST Date: Thu, 13 Mar 86 15:52 EST From: Kent M Pitman Subject: (DELETE ... :COUNT NIL) To: Common-Lisp@SU-AI.ARPA Message-ID: <860313155229.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I cannot find any place in CLtL where it specifies what will happen if you try to do: (DELETE thing list :COUNT NIL) The discussion of keywords on p62 suggests that keywords get initialized to NIL if not supplied. On p254, the notation used to describe DELETE is ambiguous. Because the syntax is described as DELETE @i(item) @i(sequence) &key :from-end :test ... and not DELETE @i(item) @i(sequence) &key from-end test ... it's hard to tell whether the author meant to imply that these keywords would default to NIL if unsupplied or whether there might be initial values that he wasn't telling us about. From experience, I have learned to distrust the initializations of &optional and &key variables because they frequently lead to confusion. That is, if you tell someone "the stream is optional and defaults to standard output", they still can't tell without constructing an experiment whether you mean: (DEFUN FOO (&OPTIONAL STREAM ...) (IF (NOT STREAM) (SETQ STREAM *STANDARD-OUTPUT*)) ...) or (DEFUN FOO (&OPTIONAL (STREAM *STANDARD-OUTPUT*) ...) ...) The latter may seem to be implied, but in my experience, the former implementation is much more robust since it allows one to simply write NIL when they only want to specify a later variable. eg, if I only want to supply a second argument of 3, I can write: (FOO NIL 3) to match the first implementation, but must write: (FOO *STANDARD-OUTPUT* 3) if the implementation is the second. In cases where the default is computed in some hairy and/or private way, the situation complicates considerably. Sometimes, the actual implementation may even have been driven by irrelevant issues like whether the arglist was `getting too cluttered' and the writer may have just taken the initialization down in the body to `pretty things up' without really thinking out what the semantic effect of that change would be. The argument for &KEY is similar. It may turn out that you want to define a function DELQ as per Maclisp. Two possible implementations present themselves: (DEFUN DELQ (THING LIST &OPTIONAL COUNT) (DELETE THING LIST :TEST #'EQ :COUNT COUNT)) and (DEFUN DELQ (THING LIST &OPTIONAL (COUNT NIL COUNT-P)) (APPLY #'DELETE THING LIST :TEST #'EQ (IF COUNT-P (LIST :COUNT COUNT) '()))) Personally, I think the former is more perspicuous, but it can only be written if we define that it is acceptable for DELETE to take a :COUNT argument of NIL. If the definition of DELETE is left as vague as it is now, only the second implementation of DELQ above will be portable. This issue is obviously more general than just DELETE. My conclusions from all this are as follows: * The manual is simply ambiguous on this point currently and unless someone can cite a definitive passage, I guess we'll have to resign ourselves to this not being defined. * Wherever it is possible to get some concensus, I think we should strive to make passing a keyword of NIL be the same as not passing a keyword. There will be cases where this will not be possible, so I am not suggesting that this be an across the board thing -- but I think it can usefully be handled on a case-by-case basis. :COUNT, :TEST, and :TEST-NOT keywords are good places to start, however, since there could be no confusion about whether the NIL was intended as a valid argument. Things like :VERBOSE would not be candidates since NIL is already valid as an explicit argument. * Where there is no concensus, or where we agree that passing a keyworded value of NIL is different than passing no argument, the manual should clearly indicate such.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 17:57:07 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Mar 86 14:46:04 PST Received: from umass-cs by csnet-relay.csnet id bf26067; 13 Mar 86 17:08 EST Date: Thu, 13 Mar 86 16:42 EST From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA To: Common-Lisp@su-ai.ARPA Subject: Packages A Truly Portable Common-Lisp program can use ONLY the LISP package, or one that it has created itself. If not, then it uses something that is NOT in Common-Lisp, and therefore would have to be modified to run on a different machine/system. Thus, I don't see what all the fuss it about. If you use the DEBUGGER package, then your code is NOT Common-Lisp. This has been stated before by other people (Gregor, Wienreb), and I hope it won't need to be stated again. The problem is your program's package names may conflict with an already existing one. Common-Lisp seems to have already provided the solution: Have source files use a DEFVARiable for all the packages referred to. The variable can be bound to a package that has a non-conflicting name for any given implementation. However, now you can only refer to symbols in another package that have been Imported, since you can't use a package prefix on a symbol, but once code is ready for Porting, conflicts within the program would be known, and there would be no need for prefixing. During development, you would know the name of the package. Kelly Murray  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 15:01:28 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 13 Mar 86 11:48:15 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4852; Thu 13-Mar-86 14:47:57-EST Date: Thu, 13 Mar 86 14:47 EST From: Daniel L. Weinreb Subject: (LOAD ... :VERBOSE T) To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860313144722.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 13 Mar 1986 13:30 EST From: "Scott E. Fahlman" I can imagine legitimate reasons for wanting to include a Load operation, with appropriate switches, into portable code, so we ought to at least provide guidelines for what the various switches do in terms of verbosity. I don't think it gets to far over into environment-land if we just indicate something like the following: I agree completely. This is what we should be talking about, and we should not venture further into environment-land.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 13:43:01 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Mar 86 10:31:27 PST Received: ID ; Thu 13 Mar 86 13:30:59-EST Date: Thu, 13 Mar 1986 13:30 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: (LOAD ... :VERBOSE T) In-reply-to: Msg of 13 Mar 1986 10:43-EST from Daniel L. Weinreb I can imagine legitimate reasons for wanting to include a Load operation, with appropriate switches, into portable code, so we ought to at least provide guidelines for what the various switches do in terms of verbosity. I don't think it gets to far over into environment-land if we just indicate something like the following: 1. Load with no switches should not print anything on standard-output. 2. The :verbose switch is intended to print some per-file information and an indication when the loading is done, but not something for every form that is loaded. 3. The :print switch is intended to cause the read/eval/print loop's output to be printed, or if the file is compiled, something for each form that is loaded. 4. These are only guidelines covering the intent of how these switches are to be used. Implementations are free to indicate this kind of information in other ways if that makes sense in their environment. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 10:51:32 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 13 Mar 86 07:44:37 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4716; Thu 13-Mar-86 10:44:22-EST Date: Thu, 13 Mar 86 10:43 EST From: Daniel L. Weinreb Subject: (LOAD ... :VERBOSE T) To: common-lisp@SU-AI.ARPA In-Reply-To: <860313030645.5.CFRY@MOSCOW-CENTRE.AI.MIT.EDU> Message-ID: <860313104349.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 13 Mar 86 03:06 EST From: Christopher Fry It's too bad we chose those names, because they are confusing. :verbose isn't very verbose and is not the most verbose of the available options. I think we followed Maclisp in this. If the world were young, I would suggest that :verbose print a comment for each item loaded, that the default be to print just the "Loading FOO ...done." message, and that there be a :silent keyword when you want to suppress all printout. But this is probably not important enough to be worht an incompatible change. -- Scott Another possibility is to eliminate the :print arg, and have :verbose take the values of :silent :file :forms . I agree with Scott that the default should be to print something like: "Loading FOO ...done." [my ":file" option] I can't stand getting the *silent-treatment* for long computations, as is conventional in UNIX. In our programming environment, we have other ways to tell the user how far along a computation has gotten than to type out on standard output. These ways involve graphics and text in other windows. (Some of what I am referring to is software that will be in the next release, also.) The point is that this is a programming environment issue, not a language issue. We cannot standardize on things like this, and so Common Lisp should not attempt to address these issues. The line between language and programming environment is not razor-sharp, and certainly "load" falls in the gray zone. But let's be quick to realize when it is that we are debating programming environment issues, and let's admit that there is no way that Common Lisp can do a satisfactory job in this area, rather than letting Common Lisp be drawn hopelessly further and further into the programming environment world.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 09:06:44 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 13 Mar 86 05:59:10 PST Date: 13 Mar 86 08:51:00 EST From: "BACH::GREEK" Subject: Package Naming Conventions To: "common-lisp" Reply-To: "BACH::GREEK" I believe that the simplest method of naming packages so that conflicts do not arise is to require every organization that produces Common LISP software to prefix their packages with an official (registered) organization name. This seems unlikely. Without such an agreement, we have to start coming up with special cases. In addition to USER and LISP, we invent a SYSTEM package. Then we start wondering about additional packages shipped with the base system, such as an editor or debugger or whatever. So maybe we say that these packages must begin with SYSTEM-, or we say that they can have any name. Now independent organizations can't be sure they won't step all over someone else's packages. And so on. I think we should either all agree that we will support a package naming convention that someone devises, or we might as well stop talking about naming conventions. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 03:21:24 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 13 Mar 86 00:06:42 PST Received: from MOSCOW-CENTRE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 13 Mar 86 03:07-EST Date: Thu, 13 Mar 86 03:06 EST From: Christopher Fry Reply-To: cfry%oz@MIT-MC.ARPA Subject: (LOAD ... :VERBOSE T) To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860313030645.5.CFRY@MOSCOW-CENTRE.AI.MIT.EDU> It's too bad we chose those names, because they are confusing. :verbose isn't very verbose and is not the most verbose of the available options. I think we followed Maclisp in this. If the world were young, I would suggest that :verbose print a comment for each item loaded, that the default be to print just the "Loading FOO ...done." message, and that there be a :silent keyword when you want to suppress all printout. But this is probably not important enough to be worht an incompatible change. -- Scott Another possibility is to eliminate the :print arg, and have :verbose take the values of :silent :file :forms . I agree with Scott that the default should be to print something like: "Loading FOO ...done." [my ":file" option] I can't stand getting the *silent-treatment* for long computations, as is conventional in UNIX.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 02:27:57 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 12 Mar 86 23:16:54 PST Date: Thu, 13 Mar 86 02:17:42 EST From: "Glenn S. Burke" Subject: Re: initforms and implicit blocks To: NGALL@BBNG.ARPA cc: COMMON-LISP@SU-AI.ARPA, apollo!dfm@UW-BEAVER.ARPA Message-ID: <[MC.LCS.MIT.EDU].849069.860313.GSB> A little semantic experiment i did in NIL (i don't know if it is in the released version) is that (defun foo (params...) ...) defines foo to havve a function definition of (named-lambda foo (params...) ...). THis is similar but not identical to the named-lambda which had been on the lispm at some point. Additionally, when applied, that function is that provides the named block. All the forms for &optional and &key arguments in the lambda list are evaluated inside of the block. With the right modularity, this was not at all difficult to put into both the compiler and the interpreter.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 13 Mar 86 01:20:35 EST Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 12 Mar 86 22:12:31 PST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Thu, 13 Mar 86 00:50:37 EST From: mcvax!suna.psg.npl.co.uk!jrp@seismo.CSS.GOV Received: by mcvax.uucp; Thu, 13 Mar 86 05:19:31 +0100 (MET) Received: from nplpsg.uucp by eagle.Ukc.AC.UK with UUCP id a028098; 12 Mar 86 23:14 GMT Received: from suna (localhost) by suna.psg.npl.co.uk; Thu, 13 Mar 86 22:36:16 GMT To: common-lisp@su-ai.arpa Subject: Deletion from Mailing list Date: 13 Mar 86 22:36:13 GMT (Thu) Message-Id: <1000.511137373@suna> Please remove me from the mailing list common-lisp. Apologies in advance for cluttering the mailing list, but I can't for the life of me find the owner's name. Thanks, John Pavel  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Mar 86 17:16:23 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 12 Mar 86 14:07:21 PST Date: Wed, 12 Mar 86 17:08:03 EST From: Jonathan A Rees Subject: Which package... To: RAM@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Tue 11 Mar 1986 18:42 EST from Rob MacLachlan Message-ID: <[MC.LCS.MIT.EDU].848564.860312.JAR> Date: Tue, 11 Mar 1986 18:42 EST From: Rob MacLachlan The Spice Lisp debugger has various commands and functions associated with it which are packaged symbols. When I implement a portable system, I am going to set up the package environment so that I can use the debugger. If I can't say this in a portable way, then I will have to edit the sources before every release or maintain a site dependent file which does the package setup. When another site uses the system, it is likely that they will edit it again so that they can use their debugger. This is a totally gratuitous system dependency. A design technique I particularly like for getting around context-sensitivity of this sort is to make the user interface commands (debug, trace, edit, logout, etc.) accessible through a mechanism other than the traditional READ + EVAL interface. In liberating a user interface from READ, it can be made useful even when the current package doesn't use LISP or USER (a situation I often work with). By the same token (so to speak), a separate command namespace makes short command names possible without risk of conflict with user variables - e.g. E for edit, Q for quit, etc. An example of this kind of interface (which I admit has myriad problems, but none which couldn't be fixed) is Symbolics' "command processor," which I usually use in the mode where user input is normally parsed as s-expression, but user input which begins with a colon is parsed as a carriage-return-terminated "command" of some sort. (Note that colon is NOT a read macro.) I don't want to argue the benefits of this paricular interface - zillions of other syles are possible - I just want to argue against the importance of the READ-EVAL status quo. It seems inappropriate to argue against an important language feature for promoting robustness and portability, like a predictable LISP (or defaultly-used) package, on the grounds that it makes a certain kludgy kind of user interface, which doesn't work all that well anyhow, not work. Jonathan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Mar 86 14:42:09 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 12 Mar 86 11:29:31 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4400; Wed 12-Mar-86 13:19:01-EST Date: Wed, 12 Mar 86 13:18 EST From: Daniel L. Weinreb Subject: Having lots of packages with extensions. To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Mar 86 12:34-EST from "BACH::GREEK" Message-ID: <860312131836.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 11 Mar 86 12:34:00 EST From: "BACH::GREEK" I sure feel uncomfortable, however, if we don't at least say that all those extra packages follow some naming convention, like SYSTEM-xxx. Otherwise a layered product simply does not know what names it can use for its packages. I have traversed this road before. This doesn't work, because there is no such thing as a "system/user" distinction in a Lisp environment. There are many levels, and levels built on levels; there's no line between what is the "system" and what isn't. I've seen what happens when you introduce such a convention: every user who produces a package that's part of a substrate names it SYSTEM-XXX, so that "user" packages can be built on it. This is definitely the problem of conflict of package names, but after seeing the same thing on many systems in many contexts, I am convinced that there's no straightforward and satisfactory solution. Furthermore, if we say that there can be arbitrary packages with extensions, then what the hell are we bothering to define the SYSTEM package for? Good question. I think it's a special-case solution to a tiny bit of the problem of conflicting package names, akin to attacking an elephant with a BB gun, by making one reserved package name for each CL implementation. Maybe there's a better reason and I can't reconstruct it.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Mar 86 14:09:17 EST Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 12 Mar 86 11:02:03 PST Received: by isi-vaxa.ARPA (4.12/4.7) id AA05540; Wed, 12 Mar 86 11:02:47 pst From: berman@isi-vaxa.ARPA (Richard Berman) Message-Id: <8603121902.AA05540@isi-vaxa.ARPA> Date: 12 Mar 1986 1102-PST (Wednesday) To: Common-Lisp@Su-Ai.Arpa Cc: Subject: Validation Contributors ISI is gonna be ramping up the long-awaited supported. The first part of this is to begin gathering the validation programs promised in the meeting late last year, and to figure out what areas are not covered and assign them to the willing. I'll be contacting the people who had an interest directly. In the meantime, any general data regarding validations, willingness to help, etc. should be sent to me. Thanks a whole heck of a lot. RB  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Mar 86 10:38:47 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 12 Mar 86 07:31:59 PST Received: from guido by GODOT.THINK.COM via CHAOS; Wed, 12 Mar 86 10:32:27 est Date: Wed, 12 Mar 86 10:34 EST From: Guy Steele Subject: TRUE, FALSE To: MMcM@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <860311200354.4.MMCM@OWL.SCRC.Symbolics.COM> Message-Id: <860312103442.2.GLS@GUIDO.THINK.COM> Date: Tue, 11 Mar 86 20:03 EST From: Mike McMahon Guy's proposed function cannot be used with special forms (macros) that take something to be "evaluated in the function context", such as for example the :print-function option to defstruct. My experience shows TRUE and FALSE ideally suited for such applications. [I am now putting on my SCHEME hat.] This is merely another example of how awkward it is to have distinguished "function contexts" and "value contexts" when using functionals. I agree now that TRUE and FALSE may be better suited to the Common lisp style than CONSTFN (but that style is sometimes awkward). --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 12 Mar 86 10:31:38 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 12 Mar 86 07:24:53 PST Received: from guido by GODOT.THINK.COM via CHAOS; Wed, 12 Mar 86 10:25:13 est Date: Wed, 12 Mar 86 10:27 EST From: Guy Steele Subject: Some notes about declarations To: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860311174837.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-Id: <860312102727.1.GLS@GUIDO.THINK.COM> Date: Tue, 11 Mar 86 17:48 EST From: Kent M Pitman Do we provide a way to type-declare functions (ie, FTYPE) that have &optional or &rest specifications? It seems like (FTYPE (FUNCTION (INTEGER &OPTIONAL INTEGER) FLOAT)) would have been reasonable, but I can't find anything that suggests I can do this. &REST would be more complicated, but not prohibitively so. Am I missing something or do we not have a way to do this at all. CLtL, page 47, 4 lines from bottom, make the offhand remark that the &optional, &rest, and &key markers may appear in the list of argument types, but unfortunately that bagbiter Steele failed to give any examples. Furthermore, &allow-other-keys ought to be allowed, because that has an effect on the external user interface. I believe this issue has been discussed before on this mailing list. One problem is that for an &optional argument one can give just the type, but for a &key argument one must write the keyword as well as the type, as (:start (integer 0 ())), for example. Do we provide a way to declare that a function is n-ary (or not) at all? That is, the equivalent of the *EXPR and *LEXPR declarations in Maclisp? I guess I would be surprised if there was no CL implementation that could generate better code in cases where I declared this kind of thing ahead of time. Sure: to make it n-ary, say (DECLARE (FTYPE (FUNCTION (&REST T) T) APPEND)) to declare APPEND, for example. And while we're on the subject, is there some reason that PROCLAIM was not made to be n-ary? It has bothered me on numerous occassions that I have to do: (PROCLAIM '(SPECIAL X)) (PROCLAIM '(FIXNUM X)) when we could just as well have allowed: (PROCLAIM '(SPECIAL X) '(FIXNUM X)) Allowing multiple arguments would be more consistent with DECLARE. No reason I know of. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 20:58:33 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 11 Mar 86 17:52:11 PST Date: Tue, 11 Mar 86 20:52:52 EST From: "George J. Carrette" Subject: common lisp motto To: RPG@SU-AI.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 11 Mar 86 0918 PST from Dick Gabriel Message-ID: <[MC.LCS.MIT.EDU].847577.860311.GJC> Isnt that rather "Why use head when mold will do?"  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 20:15:57 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 17:06:49 PST Received: from OWL.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4186; Tue 11-Mar-86 20:06:25-EST Date: Tue, 11 Mar 86 20:03 EST From: Mike McMahon Subject: TRUE, FALSE To: Guy Steele cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <860311105957.5.GLS@GUIDO.THINK.COM> Message-ID: <860311200354.4.MMCM@OWL.SCRC.Symbolics.COM> Guy's proposed function cannot be used with special forms (macros) that take something to be "evaluated in the function context", such as for example the :print-function option to defstruct. My experience shows TRUE and FALSE ideally suited for such applications.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 18:49:59 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Mar 86 15:42:04 PST Received: ID ; Tue 11 Mar 86 18:42:49-EST Date: Tue, 11 Mar 1986 18:42 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Which package... There is a point which I think is being missed in this package discussion. The default package environment, isn't just a programming issue; it is also an environment issue. I believe that there should be some portable way for a program to get the default programming environment. If there isn't, then many otherwise portable programs will be modified to use the local version of the default environment. The Spice Lisp debugger has various commands and functions associated with it which are packaged symbols. When I implement a portable system, I am going to set up the package environment so that I can use the debugger. If I can't say this in a portable way, then I will have to edit the sources before every release or maintain a site dependent file which does the package setup. When another site uses the system, it is likely that they will edit it again so that they can use their debugger. This is a totally gratuitous system dependency. Rob