Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 22:50:48 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 19:30:05 PDT Date: 23 Jul 1986 22:27-EDT Sender: NGALL@G.BBN.COM Subject: Re: Some easy ones (?) From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Cc: Fahlman@C.CS.CMU.EDU Message-ID: <[G.BBN.COM]23-Jul-86 22:27:40.NGALL> In-Reply-To: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 23 Jul 86 13:08 EDT From: David C. Plummer To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU Subject: Re: Some easy ones (?) In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> Message-ID: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 23 Jul 1986 02:30-EDT From: NGALL@G.BBN.COM Taking into account the other comments on this function (the ones that I agree with at least), how about this proposal (PARSE-BODY body &optional environment declarations-allowed-p doc-string-allowed-p) Parses a BODY argument of the form ({declaration|doc-string}* {form}*) ... Until somebody says something profound to change my mind, I hold that if a "body" may not contain either declarations or doc-strings, it is not a true body, and therefore you have no right to call PARSE-BODY. I have no idea what the reference to CASE and PROGN was. If the claim that each clause of a CASE contained a "body" you are wrong; it contains an "implicit PROGN". Implicit PROGNs are not suitable arguments to PARSE-BODY. This may not be profound, but its true. A robust macro definition of CASE, i.e., one that performs an expansion time check to ensure that the initial forms after the KEYFORM are not declarations, can be written much more easily with DECLARATIONS-ALLOWED-P, e.g., (defmacro case (keyform &rest clauses &environment env) (multiple-value-bind (decls doc clauses) (parse-body clauses env nil) (declare (ignore decls doc)) ;; At this point I can rest assured that parse-body has detected ;; any illegal declarations. ...) Things are easier still if we adopt my proposal for &body: (defmacro case (keyform &body (&forms clauses)) ;; At this point I can rest assured that parse-body has detected ;; any illegal declarations. ...) Profound enough? -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 22:23:53 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 19:04:21 PDT Date: 23 Jul 1986 22:01-EDT Sender: NGALL@G.BBN.COM Subject: Re: Declaration before variable From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 22:01:53.NGALL> In-Reply-To: The message of 23 Jul 1986 1252-PDT from Rem@IMSSS Date: 23 Jul 1986 1252-PDT From: Rem@IMSSS To: NGALL%G.BBN.COM@SCORE Subject: Declaration before variable ... Perhaps LISP should do this: (DEFUN (STRING FOO) ((INTEGER X1 X2) (STRING S) (REAL Z)) ...) I.e. anywhere a simple name can appear to introduce a new binding of a variable or name of function, a list of two elements can appear to both introduce the name and tell its type, including SPECIAL etc. Anywhere a sequence of names can appear, a list of more than two elements can appear, where the first element is the type and the remaining elements are names, thus ... (INTEGER X1 X2) ... has the same effect as ... (INTEGER X1) (INTEGER X2) ... This would make it absolutely clear which value is being declared, instead of this crock: (DE FOO (X1 X2 X Z) (DECLARE (INTEGER X1 X2) (STRING X [SIC]) (REAL Z)) ...) where we have to know that the declare affects the X1 etc. which have already appeared earlier as well as usages of X1 etc. that appear later, and may or may not affect deeper bindings X1 etc. but you have to read the manual to find out which ones it affects. Should my idea be submitted to CL discussion?? (does it have any merit?) I would love such a declaration scheme. I did not propose such a radical change since I felt that, while some implementors had expressed interest in 'cleaning up' the semantics of declarations, no one wanted a really radical change. In my proposal, I kept as close to the syntax and semantics of current declarations as I could. The only real 'change', is that first proposed by Pavel: a declaration should not have a scope greater than the object to which it refers. If everyone is willing to consider a radical change to decls, I second REMs proposal. -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 22:16:38 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 18:43:07 PDT Date: 23 Jul 1986 21:39-EDT Sender: NGALL@G.BBN.COM Subject: Re: Some easy ones (?) From: NGALL@G.BBN.COM To: FREEMAN@SUMEX-AIM.ARPA Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 21:39:54.NGALL> In-Reply-To: <12225052592.76.FREEMAN@SUMEX-AIM.ARPA> Date: Wed 23 Jul 86 13:59:34-PDT From: Andy Freeman Nick (NGALL@G.BBN.COM) replied to Fahlman: Proposal #9: Variable Name Conflicts Clarification: Specify that it is an error for two parameters (including supplied-p and &aux parameters) in the same lambda-list to have the same (EQL) name. [As previous discussion brought out, we could instead allow this case with the last-bound (rightmost) argument shadowing previous bindings in the same arglist, but this is certainly bad style and interacts in nasty ways with the proposed change to the scope of declarations.] Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. I don't know about DO*, but LET* should be able to shadow previous names. The restriction seems reasonable for the others mentioned. -andy Why should LET* be able to shadow previous names when LAMBDA expressions cannot? -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 22:01:13 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 18:43:07 PDT Date: 23 Jul 1986 21:39-EDT Sender: NGALL@G.BBN.COM Subject: Re: Some easy ones (?) From: NGALL@G.BBN.COM To: FREEMAN@SUMEX-AIM.ARPA Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 21:39:54.NGALL> In-Reply-To: <12225052592.76.FREEMAN@SUMEX-AIM.ARPA> Date: Wed 23 Jul 86 13:59:34-PDT From: Andy Freeman Nick (NGALL@G.BBN.COM) replied to Fahlman: Proposal #9: Variable Name Conflicts Clarification: Specify that it is an error for two parameters (including supplied-p and &aux parameters) in the same lambda-list to have the same (EQL) name. [As previous discussion brought out, we could instead allow this case with the last-bound (rightmost) argument shadowing previous bindings in the same arglist, but this is certainly bad style and interacts in nasty ways with the proposed change to the scope of declarations.] Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. I don't know about DO*, but LET* should be able to shadow previous names. The restriction seems reasonable for the others mentioned. -andy Why should LET* be able to shadow previous names when LAMBDA expressions cannot? -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 21:36:25 EDT Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 18:19:16 PDT Date: Wed, 23 Jul 86 21:28:48 EDT From: Jonathan A Rees Subject: Recursive Compilation? To: kempf%hplabsc@HPLABS.HP.COM cc: common-lisp@SU-AI.ARPA, snyder%hplabsc@HPLABS.HP.COM In-reply-to: Msg of Wed 23 Jul 86 16:29:10 pdt from Jim Kempf Message-ID: <[AI.AI.MIT.EDU].74639.860723.JAR> Date: Wed, 23 Jul 86 16:29:10 pdt From: Jim Kempf ... I can't find anything in CLtL to indicate that compilation SHOULDN'T be recursive, but the environmental problems with making it so would seem to be pretty hairy (another set of bindings for variables in compiler-let?, etc.). Does anybody have any comments? Yes, me, I have a comment. Compilers ought to be re-entrant. There's no excuse for them not to be. COMPILER-LET should be flushed, since MACROLET does what COMPILER-LET was intended to do, and does it correctly. - Jonathan  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 19:48:38 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 16:29:54 PDT Received: from hplabsc by hplabs.HP.COM ; Wed, 23 Jul 86 16:29:39 pdt Received: by hplabsc ; Wed, 23 Jul 86 16:29:10 pdt Date: Wed, 23 Jul 86 16:29:10 pdt From: Jim Kempf Message-Id: <8607232329.AA08900@hplabsc> To: common-lisp@su-ai.ARPA Subject: Recursive Compilation? Cc: snyder%hplabsc@hplabs.HP.COM In the process of bringing up CommonLoops, we ran into an interesting issue regarding the compiler. We would like to require CommonLoops at compile time, so that we don't have to build it into the compiler but just have it around when we're compiling something. However, it compiles something at load time (immediate reason not apparent, possibly for speed, also maybe something doesn't work interpreted). This causes the compiler to be invoked recursively, which signals an error. I can't find anything in CLtL to indicate that compilation SHOULDN'T be recursive, but the environmental problems with making it so would seem to be pretty hairy (another set of bindings for variables in compiler-let?, etc.). Does anybody have any comments? Jim Kempf hplabs!kempf  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 19:06:46 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 15:48:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 86 15:46:56 PDT Date: 23 Jul 86 15:45 PDT From: masinter.pa@Xerox.COM Subject: Re: (declare (type fixnum ---)) considered etc. In-Reply-To: To: common-lisp@SU-AI.ARPA Message-ID: <860723-154656-1964@Xerox> FLOAT is more portable than FIXNUM. Portable implementations which generate single-float in one implementation will continue to generate single-float in another implementation, even if the meaning of single-float differs in the two implementations. There are few functions that will propagate any change in the floating point precision of a value from one declaration-type to another; if you have something that deals exclusively in SINGLE-FLOAT, then * and + aren't suddenly going to return an unexpected DOUBLE-FLOAT. With FIXNUM, the most innocuous * might take something that is FIXNUM and produce a non-FIXNUM; the boundary between FIXNUM and BIGNUM invisible to most of the language. Larry [two clarifications: in Xerox Common Lisp, the FIXNUM range is (signed-byte 17), and FIXNUM declarations are ignored, because all of the opcodes do generic arithmetic, so I didn't actually have to *do* anything about the bogus FIXNUM declarations.]  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 17:32:17 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 14:08:36 PDT Date: Wed 23 Jul 86 13:59:34-PDT From: Andy Freeman Subject: Re: Some easy ones (?) To: NGALL@BBNG.ARPA cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> Message-ID: <12225052592.76.FREEMAN@SUMEX-AIM.ARPA> Nick (NGALL@G.BBN.COM) replied to Fahlman: Proposal #9: Variable Name Conflicts Clarification: Specify that it is an error for two parameters (including supplied-p and &aux parameters) in the same lambda-list to have the same (EQL) name. [As previous discussion brought out, we could instead allow this case with the last-bound (rightmost) argument shadowing previous bindings in the same arglist, but this is certainly bad style and interacts in nasty ways with the proposed change to the scope of declarations.] Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. I don't know about DO*, but LET* should be able to shadow previous names. The restriction seems reasonable for the others mentioned. -andy -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 16:24:52 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 86 12:57:49 PDT Received: ID ; Wed 23 Jul 86 15:53:25-EDT Date: Wed, 23 Jul 1986 15:53 EDT Message-ID: From: Rob MacLachlan To: "Robert A. Cassels" Cc: common-lisp@SU-AI.ARPA Subject: (declare (type fixnum ---)) considered etc. In-reply-to: Msg of 23 Jul 1986 15:26-EDT from Robert A. Cassels Almost every other language in the entire world has a "INTEGER" type which has an ill-defined, fixed precision. If Common Lisp is going to have comparable performance to these languages when running on the same hardware, then it is going to have to be comparably inelegant. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 16:12:30 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 11:57:48 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23159; Wed 23-Jul-86 14:57:04 EDT Date: Wed, 23 Jul 86 14:58 EDT From: Daniel L. Weinreb Subject: (declare (type fixnum ---)) considered etc. To: gls@Think.COM, common-lisp@SU-AI.ARPA In-Reply-To: <860723123211.2.GLS@BOETHIUS.THINK.COM> Message-ID: <860723145835.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 23 Jul 86 12:32 EDT From: Guy Steele One thing one can say is (OR FIXNUM (SIGNED-BYTE 20)), say, which a sufficiently clever compiler (heh, heh, heh) would understand to mean "use a fixnum, unless fixnums are less than 20 bits, in which case use at least 20 bits (whatever that takes)". What is the advantage of using this instead of (SIGNED-BYTE 20)?  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 16:11:33 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 11:53:50 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23157; Wed 23-Jul-86 14:53:13 EDT Date: Wed, 23 Jul 86 14:54 EDT From: Daniel L. Weinreb Subject: (declare (type fixnum ---)) considered etc. To: DCP@QUABBIN.SCRC.Symbolics.COM, RAM@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA, masinter.PA@XEROX.ARPA In-Reply-To: <860723124252.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860723145444.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 23 Jul 86 12:42 EDT From: David C. Plummer Date: Wed, 23 Jul 1986 10:39 EDT From: Rob MacLachlan It seems that FIXNUM is no less portable than FLOAT, since nothing is guaranteed about float exponent range and precision. A Common Lisp program which uses floats cannot be totally portable. One could take this as an argument against the currently system of float types, but I don't have a better solution. Good point. The difference with fixnums is that they are (a) exact and (b) have overflow provision (into bignums). All this means to me is that FLOAT is wrong as well. Table 2-1, page 17, specifies "recommended" minimum sizes for the floating types. I originally argued that these should be required minimum sizes, for exactly the reasons we're discussing here, and I still think they should be. A "recommendation" is meaningless if you are trying to write code and feel secure that it will run in other implementations of CL.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 16:10:25 EDT Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 11:35:17 PDT Date: 23 Jul 86 14:30:00 EST From: "BACH::VANROGGEN" Subject: proposals 5-14 To: "common-lisp" cc: vanroggen Reply-To: "BACH::VANROGGEN" #5: I also think the environment argument should go last, much like other functions currently do, and both the environment argument and the doc-allowed-p argument should be optional, defaulting to NIL. Returning the declarations without DECLARE's in them is a good idea too. #6: I'd prefer KMP's syntax, because it's compatible and doesn't look like it's giving a default value to the body. #9: I assume this really means the same symbol, not the same string as a name (and certainly not by EQL). #11: Any reason why we still allow integers? If we want to keep them, then why not allow characters and other numbers? #13: The restriction on not modifying code (provided by &REST and &BODY) sounds reasonable, but what about that given by &WHOLE? This would seem to follow, yet it would make displacing macros harder to implement. But I basically disagree with the proposal. &REST should always cons up a true list which the function can manipulate and return. CAR and CDR should work on real conses only, not temporary ones too. If we really want to add a language feature to avoid definite consing, add another lambda-list keyword and ARG/LISTIFY. Otherwise we should let clever software and hardware try to avoid unnecessary consing. ---Walter ------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 16:06:23 EDT Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 12:45:04 PDT Date: 23 Jul 86 15:27:00 EST From: "BACH::GREEK" Subject: Oops, sorry. To: "common-lisp" Reply-To: "BACH::GREEK" Yes, my comment about pervasive declarations did mean to refer to Alan Bawden's proposal, not Nick's. Again, we should be very careful to avoid situations where one declaration can refer to multiple entities with the same name. - Paul ------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 15:58:59 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 12:28:22 PDT Received: from KRYPTON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48343; Wed 23-Jul-86 15:26:37 EDT Date: Wed, 23 Jul 86 15:26 EDT From: Robert A. Cassels Subject: Re: (declare (type fixnum ---)) considered etc. To: masinter.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <860721-190646-2493@Xerox> Message-ID: <860723152656.1.CASSELS@KRYPTON.SCRC.Symbolics.COM> Date: 21 Jul 86 19:02 PDT From: masinter.pa@Xerox.COM The fixnum declaration is one of the easiest things to remove. a) Implementations that support (or need) fixnum declarations can add them to their extension. This is clearly allowed by the spec, but it becomes something that is an implementation's private extension rather than part of the public, portable standard. The cost to implementors is zero. Why not leave it, but put it in the SYSTEM: package? That way, users are reminded that they are doing something which is implementation-dependent. Isn't this what that package is for? System programmers, who need to refer to it, will probably be :USEing SYSTEM anyway. [Systems programming in Lisp? Surely you jest! :-] Are there any other symbols which ought to go in SYSTEM:? b) Users who have code that has fixnum declarations could add, trivially, a (deftype fixnum () ...) Or import the symbol. c) The intent of fixnum declarations is reasonably supported by a much more portable expression where the range of a variable is declared explicitly rather than depending on implementation-dependent fixnum ranges. I agree. If you're going to use declarations at all, they might as well have some real semantic meaning. I understand that the major current use is to encourage smart compilers on stupid hardware to generate more efficient code, rather than to supply program-specific semantics. But we should encourage users to use more meaningful declarations. I don't know the source of the "certainly" in your message.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 13:35:58 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 10:21:51 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48241; Wed 23-Jul-86 13:21:25 EDT Date: Wed, 23 Jul 86 13:21 EDT From: David C. Plummer Subject: Structure sharing in arguments To: hpfclp!diamant@hplabs.HP.COM, common-lisp@SU-AI.ARPA In-Reply-To: The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM Message-ID: <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 22 Jul 86 21:39:37 pdt From: hpfclp!diamant@hplabs.HP.COM From: Scott Fahlman Subject: Some easy ones (?) Proposal #13: Structure Sharing in Arguments Clarification: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy, and therefore the user should not perform destructive operations on it. Similarly, a function that takes a &REST argument should not destructively modify it because in some implementations its top-level list structure might share with a list that the user gave as the last argument to APPLY. I don't really care whether you add a restriction not to do destructive operations on a &REST or &BODY argument, but it better be clear that the list returned may not be something which will go away on exiting the function (which could happen if the parameter list were stored on the stack and a pointer to that list was returned -- apparently what Symbolics does). Nothing currently in CLtL limits me from doing the following (nor should it): (defun foo (&rest x) x) (defun list (&rest list) list) (defun copy-list (list) (apply #'list list)) [Yes, Symbolics uses stack-consed &rest lists, and they will screw you every now and then. >>> My view of our current position <<< is that the efficiency issues (e.g., not calling copy-list on every &rest arg) are outweighed by the programmer resources needed to implement the copying only when necessary.] I'm fairly convinced that disallowing destructive operations on &rest lists is funtionally equivalent to not being allowed to store them in stable storage or to return them. I think my first proof caused CLtL to dictate some aspects of function calls. I'm looking for a proof that is within the bounds of CLtL that does have such dictations. Maybe there aren't any. Maybe I'm wrong and they aren't equivalent, but I suspect they are.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 13:26:52 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 10:08:57 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48225; Wed 23-Jul-86 13:08:34 EDT Date: Wed, 23 Jul 86 13:08 EDT From: David C. Plummer Subject: Re: Some easy ones (?) To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> Message-ID: <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 23 Jul 1986 02:30-EDT From: NGALL@G.BBN.COM Taking into account the other comments on this function (the ones that I agree with at least), how about this proposal (PARSE-BODY body &optional environment declarations-allowed-p doc-string-allowed-p) Parses a BODY argument of the form ({declaration|doc-string}* {form}*) ... Until somebody says something profound to change my mind, I hold that if a "body" may not contain either declarations or doc-strings, it is not a true body, and therefore you have no right to call PARSE-BODY. I have no idea what the reference to CASE and PROGN was. If the claim that each clause of a CASE contained a "body" you are wrong; it contains an "implicit PROGN". Implicit PROGNs are not suitable arguments to PARSE-BODY. Proposal #7: TYPE-SPECIFIER-P Proposed extension: Add a new function TYPE-SPECIFIER-P that is true of valid type specifiers and false of all other Lisp objects. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time. I like the idea of a corresponding type-specifier named TYPE-SPECIFIER (not TYPE). You're right. Friendly ammendment accepted. I don't think a second value to indicate 'don't-know' is necessary. For example, if expanding a type-specifier signals an error, then it is simply not a vaild type-specifier. Proposal #13: Structure Sharing in Arguments Clarification: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy, and therefore the user should not perform destructive operations on it. Similarly, a function that takes a &REST argument should not destructively modify it because in some implementations its top-level list structure might share with a list that the user gave as the last argument to APPLY. I agree with the suggestions that returning or storing such a list must be forbidden also. Also, any kind of function/macro call (regardless of how it was invoked) should be included in this restriction. That may have been my suggestion, but there was a lot of other stuff I said that this whole thing is a cop-out. I think not being able to destructively modify it is equivalent to not being allowed to store it or return it. (More on this in the next piece of mail.) This leads to very unintuitive behavior and hard/very-hard/very-very-hard to find bugs. How do you KNOW if the argument is somebody's apply arg. See next piece of mail. Proposal #14: THE and VALUES Clarification: Specify that in (THE (VALUES ...) form), the form may return more values, but not fewer, than the number of types specified in the (VALUES ...) form, and that any extra values are of unrestricted type. Also specify that (THE type form) where type is not (VALUES ...) is equivalent to (THE (VALUES type) form). Since the VALUES type-spec is already allowed to contain &optional, &rest, and &key, I agree with DCP(?) that in (THE (VALUES...) form), the form must return the 'required' values, may return the &optional values, and any leftover values are discarded by THE, unless &rest or &key is specified. I prefer using &rest T to . T. I'll have to think about this. I just responded to RAM going along with his contention that THE is a declaration and should not change the runtime semantics. I the last 10 minutes of thinking about this issue I still agree with him: THE is for declaratative purposes, not procedural purposes. On the procedural side, I suggested a TAKE-VALUES form.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 13:05:37 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:54:45 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48207; Wed 23-Jul-86 12:54:20 EDT Date: Wed, 23 Jul 86 12:54 EDT From: David C. Plummer Subject: THE VALUES To: Rob MacLachlan , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 23 Jul 1986 09:50 EDT From: Rob MacLachlan Well, I think everyone is wrong about this one. (THE (VALUES ...) ...) specifies the functional type of the continuation. This is in effect what CLTL already says: "...indicates the parameter list of a function that, when given to multiple-value-call along with the values, would be suitable for receiving those values." I strongly disagree with any proposal which gives THE mandatory run-time semantics. THE is a declaration --- its presence should not change the meaning of a correct program. If the form returns too many values, then the program is in error and the result is undefined. I agree that it is highly desirable to be able to specify the type of the first value without worrying about the actual number of values. To this end, I propose that (THE FOO ...) should be synonomous with the (THE (VALUES FOO &REST T) ...). This allows one to say things like (THE FIXNUM (TRUNCATE ...)). OK, I can buy that. I still want a form for run-time semantics for the purposes of multiple-value-call and multiple-value-list. Something like (take-values
) where is not evaluated and can be either a non-negative integer which is the number of values, or a list of type specifiers. (An integer is shorthand for (t t ...).) The take-values form returns exactly the number of specified values, by truncating or padding the values returned by as necessary. This can be naively implemented as a macro given what is currently in CLtL, but I think it is useful enough for some compilers to take advantage of it that it should be considered part of the language. It should also be clarified that the VALUES type specifier may have &ALLOW-OTHER-KEYS.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 13:04:22 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:43:48 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48198; Wed 23-Jul-86 12:43:00 EDT Date: Wed, 23 Jul 86 12:42 EDT From: David C. Plummer Subject: (declare (type fixnum ---)) considered etc. To: Rob MacLachlan , David C. Plummer cc: common-lisp@SU-AI.ARPA, Scott E. Fahlman , masinter.PA@XEROX.COM In-Reply-To: Message-ID: <860723124252.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Wed, 23 Jul 1986 10:39 EDT From: Rob MacLachlan Well, I had previously believed that the FIXNUM declaration was reasonable, but this was based on the erroneous belief that an array index must be a fixnum. If it is fact the case that some implementations have small (2^16) fixnums, then this is a serious source of non-portability. A possible solution would be to have an INDEX type which is (INTEGER 0 (ARRAY-DIMENSION-LIMIT)). In any case, I think there are valid arguments for retaining the FIXNUM declaration: 1] Much existing code would have to be changed. This code will probably work on any implementation for some range of inputs. In my opinion, that is one of THE poorest reasons to keep it. Why have any semantics at all? 2] There is precendent for sacrificing portability to gain efficiency. The problem with saying something like (SIGNED-BYTE 32) is that it is probably just as arbitrary as FIXNUM, yet is unlikely to be a good match for a given implementation. In fact in this particular case, nearly all implementations on conventional hardware would be forced to consider bignums. Back to semantics again. How can a program that specifies it is using fixnums possibly return the right answer reliably if the size of the fixnum is variable by the implementation? If a program is going to deal with (signed-byte 12) it should say that, instead of FIXNUM. Does the following make anybody feel any better: (eval-when (compile) (unless (subtypep '(signed-byte 20) 'fixnum) (warn "This program is using (unsigned-byte 20), ~@ but these a subtype of fixnum in this ~@ implementation. Efficiency will be lost!"))) Using (signed-byte 20) >>properly<< reflects the intent of the programmer, and the above warns that they will not be efficient. It seems that FIXNUM is no less portable than FLOAT, since nothing is guaranteed about float exponent range and precision. A Common Lisp program which uses floats cannot be totally portable. One could take this as an argument against the currently system of float types, but I don't have a better solution. Good point. The difference with fixnums is that they are (a) exact and (b) have overflow provision (into bignums). I suggest that there should be some short integer type which is defined to have a reasonably large magnitude (> 2^20). This is analogous to the float types which have suggested minimum precisions. Note that CLTL currently suggest (p 14) that FIXNUM be at least (SIGNED-BYTE 16), so uses of FIXNUM consistent with this can be considered portable. I agree with shebs: we don't need another data type. BTW, When I say (signed-byte 32) I really mean (signed-byte 31) and when you say (signed-byte 16) you really mean (signed-byte 15).  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 13:03:01 EDT Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:49:21 PDT Received: from utokyo-relay by csnet-relay.csnet id ar02912; 23 Jul 86 12:43 EDT Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA03821; Wed, 23 Jul 86 18:30:43+0900 Received: by ccut.u-tokyo.junet (4.12/6.1Junet) id AA27066; Wed, 23 Jul 86 18:15:23+0900 Date: Wed, 23 Jul 86 18:15:23+0900 From: Masayuki Ida Message-Id: <8607230915.AA27066@ccut.u-tokyo.junet> To: common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU, ida%u-tokyo.junet@CSNET-RELAY.ARPA, mathis@ADA20.ISI.EDU Subject: JIS WG start in japan We had the first meeting of JIS Lisp WG on July 22. This means japan start to try to find a standard of Lisp officially. It will take a long time to make a final decision. Members are: Chair: M.Ida (Aoyama Gakuin University) H. Murao (Univ. of Tokyo) H. Motoyoshi (ETL, MITI) T. Yuasa (Kyoto university) N. Inada (Riken) S. Kobayashi (Toshiba) I. Takeuchi (NTT) M. Yasumura (Hitachi) M. Kuroda (Mitsubishi) H. Nakamura (Fujitsu) A. Nagasaka (Oki) T. Kurokawa (IBM japan) Y. Hashimoto (NEC) S. Itoh (MITI) This WG is the official working group to prepare a draft for JIS LISP. I have been chairing another committee named Jeida Common Lisp committee, which is a group of CommonLisp enthusiastic persons from more than 26 organizations including the companies which send members to the JIS WG. (Under the Jeida committee, there are four WGs; subset WG, Object oriented WG, Kanji WG and bboard WG) I think Jeida Common Lisp committee roughly corresponds to common-lisp@su-ai. JIS Lisp WG will roughly correspond to the comming ANSI/ISO committee. The base for JIS will be also Common Lisp, I believe. But, we will start from the scratch for the WG. I want to keep a good relation to the USA committee. Thank you. M.ida ida@utokyo-relay.csnet ----  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 12:42:14 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:31:22 PDT Received: from boethius by Godot.Think.COM via CHAOS; Wed, 23 Jul 86 12:31:29 edt Date: Wed, 23 Jul 86 12:32 EDT From: Guy Steele Subject: (declare (type fixnum ---)) considered etc. To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: Message-Id: <860723123211.2.GLS@BOETHIUS.THINK.COM> Date: Wed, 23 Jul 1986 10:39 EDT From: Rob MacLachlan ... It seems that FIXNUM is no less portable than FLOAT, since nothing is guaranteed about float exponent range and precision. A Common Lisp program which uses floats cannot be totally portable. One could take this as an argument against the currently system of float types, but I don't have a better solution. One thing one can say is (OR FIXNUM (SIGNED-BYTE 20)), say, which a sufficiently clever compiler (heh, heh, heh) would understand to mean "use a fixnum, unless fixnums are less than 20 bits, in which case use at least 20 bits (whatever that takes)". --Guy  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Jul 86 12:18:15 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 23 Jul 86 09:01:24 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48132; Wed 23-Jul-86 11:58:18 EDT Date: Wed, 23 Jul 86 11:58 EDT From: David C. Plummer Subject: Computer Implementations Sociologists To: Common-Lisp@SU-AI.ARPA, tcp-ip@SRI-NIC.ARPA Message-ID: <860723115811.6.DCP@FIREBIRD.SCRC.Symbolics.COM> I'm wondering if there are any social scientists that study why various aspects of computers exist the way they do. My current questions relate to languages and network protocols. Other topics include computer architectures, operating systems and I'm sure several others. Languages is an older field. I'm not really interested in a simple history of FORTRAN or BASIC or COBOL or ADA or CommonLisp. I'm more interested in the overall motivations, goals and constraints placed upon the designers, how well the result met the goals, what problems the language didn't solve, how the goals were found to be faulty, how the goals change over time (e.g., as memory and disk gets cheaper), etc. This goes all the way from conception, implementation, revision, widespread usage, evolution, etc. Networks are a newer field, but certainly has had its share of good and bad ideas. Again, I'm not interested in a simply history of the ARPAnet, LANs, etc. I'm interested in such things as the constraints under which designers use numeric encoding instead of symbolic values. Is it host language support? Is it to reduce byte count for 1970 packet charges that haven't evaporated in this the information age? Is it just historical inertia? Has anybody studied the "Not made here" syndrome? What is the cause of it? Is it simple arrogance, or do original designers plan things too specifically that can be generalized? If so, do they realize what they are doing, or does one learn to be more general as one gets older and wiser? How do protocols become imposed on people? What is the effect of the imposition? Has anybody studied possible hypocrisy among designers? For example, if a standard is to be imposed, what if it is known to be unsuitable for some organization? How many things are done because of underying, and possibly not realized, job security desires? Those are the types of questions/debates I'm interested in seeing outsider study results. I'm sure we all have opinions on some of the above. I do. Doing some soul searching to learn why one has opinions can sometimes be very enlightening. Any leads on professionals or publications that address these? Replies to me only, please. I'll redistribute replies to interested individuals. I'd be interested in actively discussing this, but I don't have time in the short term.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 11:25:01 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 08:14:44 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA12816; Wed, 23 Jul 86 09:14:48 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA12733; Wed, 23 Jul 86 09:14:45 MDT Date: Wed, 23 Jul 86 09:14:45 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8607231514.AA12733@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: (declare (type fixnum ---)) considered etc. Summary: Expires: References: Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article RAM@C.CS.CMU.EDU (Rob MacLachlan) writes: >I suggest that there should be some short integer type which is >defined to have a reasonably large magnitude (> 2^20). [...] Help me, Mr. Wizard, they're trying to add more datatypes to CL!! :-) stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 10:53:21 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jul 86 07:40:07 PDT Received: ID ; Wed 23 Jul 86 10:39:55-EDT Date: Wed, 23 Jul 1986 10:39 EDT Message-ID: From: Rob MacLachlan To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA, "Scott E. Fahlman" , masinter.PA@XEROX.COM Subject: (declare (type fixnum ---)) considered etc. In-reply-to: Msg of 22 Jul 1986 16:53-EDT from David C. Plummer Well, I had previously believed that the FIXNUM declaration was reasonable, but this was based on the erroneous belief that an array index must be a fixnum. If it is fact the case that some implementations have small (2^16) fixnums, then this is a serious source of non-portability. A possible solution would be to have an INDEX type which is (INTEGER 0 (ARRAY-DIMENSION-LIMIT)). In any case, I think there are valid arguments for retaining the FIXNUM declaration: 1] Much existing code would have to be changed. This code will probably work on any implementation for some range of inputs. 2] There is precendent for sacrificing portability to gain efficiency. The problem with saying something like (SIGNED-BYTE 32) is that it is probably just as arbitrary as FIXNUM, yet is unlikely to be a good match for a given implementation. In fact in this particular case, nearly all implementations on conventional hardware would be forced to consider bignums. It seems that FIXNUM is no less portable than FLOAT, since nothing is guaranteed about float exponent range and precision. A Common Lisp program which uses floats cannot be totally portable. One could take this as an argument against the currently system of float types, but I don't have a better solution. I suggest that there should be some short integer type which is defined to have a reasonably large magnitude (> 2^20). This is analogous to the float types which have suggested minimum precisions. Note that CLTL currently suggest (p 14) that FIXNUM be at least (SIGNED-BYTE 16), so uses of FIXNUM consistent with this can be considered portable. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 10:28:55 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 07:20:37 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA11852; Wed, 23 Jul 86 08:20:50 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA12480; Wed, 23 Jul 86 08:20:47 MDT Date: Wed, 23 Jul 86 08:20:47 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8607231420.AA12480@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Some easy ones (?) Summary: Expires: References: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> NGALL@G.BBN.COM writes: > --------------------------------------------------------------------------- > Proposal #6: Parsing in &BODY > > Extend the syntax of an &BODY parameter to DEFMACRO to allow writing > &body (body-var [declarations-var [doc-string-var]]). If only body-var > appears in parentheses, it means the same as a body-var with no > parentheses. Otherwise, it means to give the original body to > PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is > specified) and then bind the variables to the corresponding values > returned by PARSE-BODY. This is purely a syntactic convenience for the > user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then > call PARSE-BODY himself. > >How about a compromise? >&body may be follwed by a list of the form >(&forms {var|(var[initform[svar]])} > [&declarations <> > [&doc-string <>]]) Ugh. This seems like extra hair in the language to save macro writers 1 line of code every once in a while. Remember, if it goes in the language, then every implementation *must* incur the space overhead, not to mention that it has to be written about in the standard, in manufacturer's manuals, in textbooks, ad nauseam. It's just not worth it. stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 09:59:52 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jul 86 06:50:30 PDT Received: ID ; Wed 23 Jul 86 09:50:41-EDT Date: Wed, 23 Jul 1986 09:50 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: THE VALUES In-reply-to: Msg of 21 Jul 1986 21:46-EDT from Scott E. Fahlman Well, I think everyone is wrong about this one. (THE (VALUES ...) ...) specifies the functional type of the continuation. This is in effect what CLTL already says: "...indicates the parameter list of a function that, when given to multiple-value-call along with the values, would be suitable for receiving those values." I strongly disagree with any proposal which gives THE mandatory run-time semantics. THE is a declaration --- its presence should not change the meaning of a correct program. If the form returns too many values, then the program is in error and the result is undefined. I agree that it is highly desirable to be able to specify the type of the first value without worrying about the actual number of values. To this end, I propose that (THE FOO ...) should be synonomous with the (THE (VALUES FOO &REST T) ...). This allows one to say things like (THE FIXNUM (TRUNCATE ...)). It should also be clarified that the VALUES type specifier may have &ALLOW-OTHER-KEYS. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 07:30:24 EDT Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 04:18:31 PDT Received: by navajo.stanford.edu; Wed, 23 Jul 86 04:17:11 PDT Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA16037; Wed, 23 Jul 86 03:50:10 pdt Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA04163; Wed, 23 Jul 86 03:53:30 PDT Date: Wed, 23 Jul 86 03:53:30 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8607231053.AA04163@bhopal.edsel.uucp> To: navajo!NGALL%G.BBN.COM@navajo.stanford.edu Cc: navajo!ALAN%AI.AI.MIT.EDU@navajo.stanford.edu, navajo!Common-Lisp%SU-AI.ARPA@navajo.stanford.edu In-Reply-To: NGALL@G.BBN.COM's message of 23 Jul 1986 03:00-EDT Subject: DECLARE SPECIAL Considered Confusing ? Re: your question "How do I shadow the SPECIAL declaration if "every occurance of FOO is taken to be a ... special binding"? E.g., How can I bind X lexically in the body of the following: (defun foo (x) (declare (special x))...)" I thought Alan's proposal didn't just simply say "every occurance ...", but rather "every occurance ..., unless shadowed by another declaration". Thus, assuming there is to be an UNSPECIAL, or LOCAL, declaration, which is a no-op when the variable isn't declared or proclaimed special, then you can insulate some small piece of context from the larger lexical context in which it is embedded by just such a means. Consider for example: (defmacro square (form) `(let ((temp ,form)) (declare (local temp) (notype temp)) (* temp temp))) Actually, many of us would probably have written "square" as: (defmacro square (form) (let ((temp (gensym))) ;or maybe even "(gentemp)" `(let ((,temp ,form)) (* ,temp ,temp)))) but that is no big issue (you'll probably prefer the former if you are stuck with an implementation that can't GC symbols). It seems to me that Alan's proposal infuses declarations with the same kind of scoping semantics that exists for variable bindings. In the form (let ((a )) . . . (let ((a )) . . . )) the meaning of this is "a is bound to something, unless it is bound to something else"; which is parallel to Alan's notion for declarations that has (unfortunately) been called "shadowing". I find the unification of these two scoping rules to be very attractive. -- JonL --  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 03:53:53 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jul 86 00:44:58 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 86 00:45:18 PDT Date: 23 Jul 86 00:44 PDT From: masinter.pa@Xerox.COM Subject: Re: Bawden's Alternate Proposal In-reply-to: Alan Bawden 's message of Wed, 23 Jul 86 01:20:16 EDT To: common-lisp@SU-AI.ARPA Message-ID: <860723-004518-1243@Xerox> Before we get carried away, there are a few advantages to lexical scoping.... [A simple example: (defmacro call-double (fn value) `(let((a ,value)) (,fn a a))) You don't want pervasive declarations in the context of the macro invocation to muck with what "a" means. ] One source of problems with "special" declarations is that they talk about two different things: references & bindings. Since we're considering radical changes, lets consider separating out the two uses: Masinter's alternative: (DECLARE (SPECIAL var1 var2 ...)) only affect the *binding* of var1 and var2. Which binding? Only the one that they are lexically apparent in. SPECIAL declarations can only occur in declarations in LAMBDA and LET and are only meaningful for the variables that are actually bound there. How do you tell if a *reference* is special or lexical? A reference is lexical if the variable is lexically apparent, and special if it isn't. If you want, we can add another declaration (SPECIAL-REFERENCE var1 var2 ...) which is like (IGNORE var1 ...) in that its only use is to turn off compiler warnings. In this case, if you declare something as USED-FREELY, the compiler won't warn about special references to variables that aren't PROCLAIMed special. (Interlisp has this separation: special declarations are done with SPECVARS, while reference declarations, just there to turn off warnings, are done with USEDFREE.)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 03:13:59 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Jul 86 00:01:49 PDT Date: 23 Jul 1986 03:00-EDT Sender: NGALL@G.BBN.COM Subject: Re: DECLARE SPECIAL Considered Confusing From: NGALL@G.BBN.COM To: ALAN@AI.AI.MIT.EDU Cc: Common-Lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 03:00:58.NGALL> In-Reply-To: <[AI.AI.MIT.EDU].73400.860721.ALAN> Date: Mon, 21 Jul 86 16:02:37 EDT From: Alan Bawden To: Common-Lisp@SU-AI.ARPA Subject: DECLARE SPECIAL Considered Confusing In-Reply-To: Msg of 20 Jul 1986 18:52-EDT from NGALL at G.BBN.COM Message-ID: <[AI.AI.MIT.EDU].73400.860721.ALAN> Actually, the more I think about this as a simplification, the more I like it. So here is a counter-proposal for rationalizing the semantics of declarations: 1. All declarations are completely pervasive. That is, if you write (locally (declare (special foo)) ...) then every occurance of FOO within the body is taken to be a special reference or a special binding. The only way to escape from the effects of a declaration within the body, is to explicitly shadow the declaration with another. This applies to -all- declarations: FTYPE, INLINE, etc. How do I shadow the SPECIAL declaration if "every occurance of FOO is taken to be a ... special binding"? E.g., How can I bind X lexically in the body of the following: (defun foo (x) (declare (special x))...) 2. Declarations that occur in the bodies of special forms (DEFUN, LET, DO, etc.), and in LAMBDA expressions, are taken to mean the same thing as if the entire form was enclosed in a LOCALLY containing the same declarations. So (let ,pairs ,@dcls ,@body) and (locally ,@dcls (let ,pairs ,@body)) are completely equivalent. (Since LAMBDA expressions aren't forms, the equivalent using LOCALLY isn't always completely straightforward to construct. For example, this case: ((lambda ,vars ,@dcls ,@body) ,@vals) is equivalent to using LOCALLY as follows: (funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals) .) Question: Why isn't LOCALLY just called PROGN? Answer: Because PROGN doesn't allow declarations :-). Your proposal completely contradicts the spirit of lexical scoping by allowing a declaration OUTSIDE THE LEXICAL SCOPE of an entity to AFFECT that entity. Thus the programmer must look outside the lexical scope of the entity to determine its type, whether it is special, whether it is inline, etc. This is BAD language semantics. Sure PROCLAIM is BAD too, but lets not compound the error. Also, it makes no sense for one binding to shadow another if the declarations aren't shadowed also. This is what DCW was alluding to. It will just confuse the user to have a flat namespace for declarations and a shadowing namespace for bindings. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 02:51:19 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 23:31:52 PDT Date: 23 Jul 1986 02:30-EDT Sender: NGALL@G.BBN.COM Subject: Re: Some easy ones (?) From: NGALL@G.BBN.COM To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL> In-Reply-To: Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Some easy ones (?) Message-ID: What follows are ten proposals adapted from Steele's list of last December. These have been discussed before, and I believe that they should not stir up much new controversy. There are a lot of issues like this, so I'm hoping that we can deal with these in batches, while continuing to discuss more difficult issues like declaration scoping. We shall see. Please read these over and indicate any problems you discover, or whether they all look OK to you. The plan is to discuss these things for a week (or more if complexities arise), then to put the proposals forth in their final form for a last round of comments, and finally to send the proposals to the technical committee, who will make the final decisions. This is something of an experiment. If we can't handle this many simple things at once, we'll have to deal with issues in smaller batches, but then it will take twice as long to settle these things. -- Scott --------------------------------------------------------------------------- Proposal #5: PARSE-BODY Extension: Add a new function (PARSE-BODY body environment documentation-allowed-p). It pulls apart the body into three parts: a list of DECLARE forms, a documentation string (or NIL if none), and the body proper. These are returned in the order body, declarations, and doc-string as three values. PARSE-BODY may perform macro-expansion (using the given environment) in order to determine whether an initial macro-call expands into a DECLARE form or documentation string. Taking into account the other comments on this function (the ones that I agree with at least), how about this proposal (PARSE-BODY body &optional environment declarations-allowed-p doc-string-allowed-p) Parses a BODY argument of the form ({declaration|doc-string}* {form}*) according to the rules on page ????[Currently, incompletely specified on pages 67, 153-154] and returns three values: a list of the DECLARATIONs, the DOC-STRING (or NIL if none), and a list of the FORMS (which may share structure with the BODY). All the DECLARATIONs and none of the FORMS will have been MACROEXPANDed and none of the FORMS will have been. The optional parameter ENVIRONMENT (which defaults to NIL, which represents the null lexical environment) is used for such macro expansion. If the optional parameter DECLARATIONS-ALLOWED-P is true (the default), then BODY may contain declarations and a doc-string. Otherwise, if it is NIL, (in which case the argument to DOC-STRING-ALLOWED-P must also be NIL) an error is signalled if there are any declarations before the first FORM in BODY (or before the end of BODY if there are no FORMs). If the optional parameter DOC-STRING-ALLOWED-P is true (the default), then the first string encountered before, during, or immediately after the DECLARATIONs in BODY is returned as the second value. Any subsequent string is considered a FORM. Otherwise, if it is NIL, then all strings in BODY are considered FORMs. [Rationale: declarations-allowed-p is useful for ensuring that certain bodies do NOT contain decls, e.g., the 'body' of CASE, PROGN, etc. declarations-allowed-p=nil -> doc-string-allowed-p=nil since currently, CLtL does not have ANY bodies that allow a doc-string without allowing decls. doc-string-allowed-p is shorter, and uses the correct terminology. The order of the return values reflects their (typical) order in CLtL. Decls are left expanded since it is unlikely that anything would care about their unexpanded form; but the same is not true for forms, so all of the forms are returned unexpanded.] --------------------------------------------------------------------------- Proposal #6: Parsing in &BODY Change (could conceivably break existing code which destructures &body arguments, but this should be rare as such destructuring is generally too complex to do via the built in mmechanism): Extend the syntax of an &BODY parameter to DEFMACRO to allow writing &body (body-var [declarations-var [doc-string-var]]). If only body-var appears in parentheses, it means the same as a body-var with no parentheses. Otherwise, it means to give the original body to PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is specified) and then bind the variables to the corresponding values returned by PARSE-BODY. This is purely a syntactic convenience for the user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then call PARSE-BODY himself. Note: This extension is proposed only for &BODY, not for &REST, so &BODY will no longer be exactly equivalent to &REST in a DEFMACRO arglist. [Note: KMP has suggested the syntax (...&body body-var decl-var doc-var). This does not break any existing code and would allow default and supplied-p values for the three variables. I (sef) don't think these are important advantages, and I prefer the syntax proposed above, which is less confusing to the eye -- my eye, ayway. The proposed format is the one we discussed on the mailing list earlier and seemed to be favored by most people.] How about a compromise? &body may be follwed by a list of the form (&forms {var|(var[initform[svar]])} [&declarations <> [&doc-string <>]]) Which means to give the list which would be bound by &rest to and the environment that would be bound by &environment to PARSE-BODY (with declarations-allowed-p true iff &declarations is specified, ditto for doc-string-allowed-p) and then bind the variables to the corresponding values returned by PARSE-BODY. This is an upward compatible change (if a list whose first element is NOT &forms appears after &body, it is destructured in the normal way. Note that the &forms, etc., parameters may not be destructured [CLtL should also put such a restriction on other defamcro parameters, e.g., &environment, but that is another proposal.] --------------------------------------------------------------------------- Proposal #7: TYPE-SPECIFIER-P Proposed extension: Add a new function TYPE-SPECIFIER-P that is true of valid type specifiers and false of all other Lisp objects. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time. I like the idea of a corresponding type-specifier named TYPE-SPECIFIER (not TYPE). I don't think a second value to indicate 'don't-know' is necessary. For example, if expanding a type-specifier signals an error, then it is simply not a vaild type-specifier. --------------------------------------------------------------------------- Proposal #8: Clarifications to DEFCONSTANT Clarifications: Clarify that using DEFCONSTANT to redefine any constant described in the Common Lisp specification is an error. Clarify that if the user defines a constant, compiles code that refers to that constant, and then redefines the constant, then behavior of the compiled code may be unpredictable. It is an error to execute such code. I would change "redefines the constant" to "redefines the constant to a new, non-eql, value". Clarify that it is not an error to issue a second DEFCONSTANT command for an existing constant iff the new value is EQL to the old one. [That last clarification has not been discussed previously, as far as I know, but seems to be needed for reloading certain compiled code files, etc.] Flush the last clarification. My change makes it unnecessary when talking about affected compiled code, and it contradicts pg. 56. Finally, it makes it impossible to change your mind about the value of a constant (before compiling any code). --------------------------------------------------------------------------- Proposal #9: Variable Name Conflicts Clarification: Specify that it is an error for two parameters (including supplied-p and &aux parameters) in the same lambda-list to have the same (EQL) name. [As previous discussion brought out, we could instead allow this case with the last-bound (rightmost) argument shadowing previous bindings in the same arglist, but this is certainly bad style and interacts in nasty ways with the proposed change to the scope of declarations.] Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. --------------------------------------------------------------------------- Proposal #10: Forms That Allow Declarations Extension: Permit declarations before the body of a LABELS, FLET, or MACROLET. Fine. That WAS simple :-). --------------------------------------------------------------------------- Proposal #11: Contents of Tagbody Clarification: Specify that constant forms such as strings may appear at top-level in a tagbody, but that only symbols and integers are considered to be tags. It is an error to use anything else as the destination tag for a GO. [Several forms of this have been kicked around. This seems as good as any. The original issue was whether you could put something like a string at top-level and, if so, whether you could go to it.] Fine. --------------------------------------------------------------------------- Proposal #12: Unique Names For Tags Clarification: Specify that it is an error for the same (EQL) tag to appear more than once in the body of a TAGBODY. (However, a TAGBODY may have the same tag as another TAGBODY in which it nests, in which case the tag in the outer TAGBODY is shadowed, as already specified.) Fine. --------------------------------------------------------------------------- Proposal #13: Structure Sharing in Arguments Clarification: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy, and therefore the user should not perform destructive operations on it. Similarly, a function that takes a &REST argument should not destructively modify it because in some implementations its top-level list structure might share with a list that the user gave as the last argument to APPLY. I agree with the suggestions that returning or storing such a list must be forbidden also. Also, any kind of function/macro call (regardless of how it was invoked) should be included in this restriction. --------------------------------------------------------------------------- Proposal #14: THE and VALUES Clarification: Specify that in (THE (VALUES ...) form), the form may return more values, but not fewer, than the number of types specified in the (VALUES ...) form, and that any extra values are of unrestricted type. Also specify that (THE type form) where type is not (VALUES ...) is equivalent to (THE (VALUES type) form). Since the VALUES type-spec is already allowed to contain &optional, &rest, and &key, I agree with DCP(?) that in (THE (VALUES...) form), the form must return the 'required' values, may return the &optional values, and any leftover values are discarded by THE, unless &rest or &key is specified. I prefer using &rest T to . T. --------------------------------------------------------------------------- -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 01:27:54 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 22:18:36 PDT Date: Wed, 23 Jul 86 01:20:16 EDT From: Alan Bawden Subject: Bawden's Alternate Proposal To: DLW@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Tue 22 Jul 86 15:36 EDT from Daniel L. Weinreb Message-ID: <[AI.AI.MIT.EDU].74164.860723.ALAN> Date: Tue, 22 Jul 86 15:36 EDT From: Daniel L. Weinreb ... However, I am not completely happy with this as a philosophy for the language. After all, we have a whole set of scoping rules designed to deal with things like: (let ((a ---)) ... (let ((a ---)) ...)) SPECIAL declarations already have this problem. If at toplevel you do (PROCLAIM '(SPECIAL A)), then you are restricted in the way you can choose the names of your lexical variables. Which is exactly the reason we generally spell special variables with *'s. Sure, this isn't a perfect solution. But I am coming to prefer it to the existing situation. While you're at it, you could simplify the scoping rules as well, by simply not allowing such constructs; the user can always change the name of the inner "a". I don't understand what this has to do with it. I don't see why anyone would generalize my suggestion to such a restriction.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 01:06:48 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 22 Jul 86 21:39:51 PDT Received: by hplabs.HP.COM ; Tue, 22 Jul 86 21:39:37 pdt Date: Tue, 22 Jul 86 21:39:37 pdt From: hpfclp!diamant@hplabs.HP.COM To: common-lisp@su-ai.ARPA Subject: Structure sharing in arguments From: Scott Fahlman Subject: Some easy ones (?) Proposal #13: Structure Sharing in Arguments Clarification: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy, and therefore the user should not perform destructive operations on it. Similarly, a function that takes a &REST argument should not destructively modify it because in some implementations its top-level list structure might share with a list that the user gave as the last argument to APPLY. I don't really care whether you add a restriction not to do destructive operations on a &REST or &BODY argument, but it better be clear that the list returned may not be something which will go away on exiting the function (which could happen if the parameter list were stored on the stack and a pointer to that list was returned -- apparently what Symbolics does). Nothing currently in CLtL limits me from doing the following (nor should it): (defun foo (&rest x) x) About an earlier issue which I didn't have time to respond to when it came up regarding the error level proposal: regardless of how the details are worked out, I don't want the set of "must" reportable errors to be very large. At least not at all levels of safety/speed. There should be an out of at least one combination which allows very minimal error checking. If I remember correctly from your proposal, you suggested that anything which "signals an error" should be an always required reportable error. I wouldn't mind having only one combination of safety/speed which would not require this, but I would strongly object to having all these errors required to be reportable no matter what optimizations are requested. Conventional architecture implementations pay a substantial performance penalty for every error check emitted in the final code. John  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 00:51:40 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 22 Jul 86 21:39:51 PDT Received: by hplabs.HP.COM ; Tue, 22 Jul 86 21:39:37 pdt Date: Tue, 22 Jul 86 21:39:37 pdt From: hpfclp!diamant@hplabs.HP.COM To: common-lisp@su-ai.ARPA Subject: Structure sharing in arguments From: Scott Fahlman Subject: Some easy ones (?) Proposal #13: Structure Sharing in Arguments Clarification: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy, and therefore the user should not perform destructive operations on it. Similarly, a function that takes a &REST argument should not destructively modify it because in some implementations its top-level list structure might share with a list that the user gave as the last argument to APPLY. I don't really care whether you add a restriction not to do destructive operations on a &REST or &BODY argument, but it better be clear that the list returned may not be something which will go away on exiting the function (which could happen if the parameter list were stored on the stack and a pointer to that list was returned -- apparently what Symbolics does). Nothing currently in CLtL limits me from doing the following (nor should it): (defun foo (&rest x) x) About an earlier issue which I didn't have time to respond to when it came up regarding the error level proposal: regardless of how the details are worked out, I don't want the set of "must" reportable errors to be very large. At least not at all levels of safety/speed. There should be an out of at least one combination which allows very minimal error checking. If I remember correctly from your proposal, you suggested that anything which "signals an error" should be an always required reportable error. I wouldn't mind having only one combination of safety/speed which would not require this, but I would strongly object to having all these errors required to be reportable no matter what optimizations are requested. Conventional architecture implementations pay a substantial performance penalty for every error check emitted in the final code. John  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 00:47:38 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 21:35:24 PDT Date: 23 Jul 1986 00:34-EDT Sender: NGALL@G.BBN.COM Subject: Re: Declare Special From: NGALL@G.BBN.COM To: ELIOT%cs.umass.edu@RELAY.CS.NET Cc: Common-Lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 00:34:19.NGALL> In-Reply-To: The message of Mon, 21 Jul 86 10:33 EST from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Date: Mon, 21 Jul 86 10:33 EST From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Declare Special I think the basic idea of putting the declaration inside the form it is trying to affect is inherently un-lispish and will always be confusing. I think that we should define a set of special forms that syntactically enclose the body they apply to and supply the needed functionality. Maybe in CL-2000 these can be made the standard. The best place to put a decl is adjacent to the entity it refers to (a la Ada). I don't know of any language that puts declarations for function parameters BEFORE the parameters (do you); those that don't put them adjacent to the parameters (e.g., C) put them 'inside the body'. I think that is a pretty good reason for CL to do the same. Locally is a good start. I have a question about its semantics, though. Consider: (locally (declare (special foo)) (let ((foo )) (print foo))) I cannot figure out what this does from CLtL. Probably the binding is not affected by locally, (even though the declaration is pervasive) so in fact the binding *cannot* be referenced. The reference to foo is (presumably) affected by a pervasive declaration, so this code fragment does something unpredictable. You figured it out. A good compiler will warn you that the lexical variable foo is never referenced. The fragment's behavior is quite predicatable: it will print the value of the special variable foo. I think two additional special forms would be helpful. One would be exactly like locally, except that it would pervasively affect bindings as well as references to variables. In other words, this would be a lexically scoped version of proclaim. (Perhaps call it proclaim-locally). Could you give some examples of how proclaim-locally would be helpful? It sounds relatively useless to me. The last special form needed would supply the standard lexically scoped declarations. Hopefully this is not too confusing. The syntax would again be identical to locally, but the scope would be everything through the scope of the next enclosing binding. (For variable declarations of course.) For example: (lexical-locally (declare (special x)) ;; x special here. (let ((x 3)) ;binds x specially. ;; x special here (and = 3) (let ((x 4)) ;Binds x lexically. ....))) All I can say is that I prefer my decls as close to their entities as possible, and you are suggesting a syntax that would allow them to be moved arbitrarily far away, and to affect unrelated references, i.e., what has the x outside the outer LET got to do with the x bound in the outer LET? Why should they share a decl? People probably wouldn't want to use these at top-level, so there is still a need for something like Pavel's suggestion. Elsewhere these forms would usually be clearer. Having two different declaration styles is bound to be more confusing than one. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jul 86 00:23:05 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 21:12:30 PDT Date: 23 Jul 1986 00:10-EDT Sender: NGALL@G.BBN.COM Subject: Re: Declarations From: NGALL@G.BBN.COM To: greek%bach.decnet@HUDSON.DEC.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jul-86 00:10:56.NGALL> In-Reply-To: The message of 22 Jul 86 10:21:00 EST from "BACH::GREEK" Date: 22 Jul 86 10:21:00 EST From: "BACH::GREEK" To: "common-lisp" Subject: Declarations I think we should be very careful about declarations which can pertain to more than one entity with the same name. Nick's proposal that all declaration are pervasive brings out this problem in spades. I think it is dangerous, since a declaration could easily tell a lie about one or the other of the two entities. - Paul I think you mean Alan Bawden's proposal. I did not propose that all declarations should be pervasive (only one's not associated with bindings in the current contour). And I agree that such a simple rule for decls is dangerous. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 19:01:41 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 22 Jul 86 15:48:25 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUL 86 15:47:04 PDT Date: 22 Jul 86 15:46 PDT From: bane.pa@Xerox.COM Subject: setf of nthcdr? To: common-lisp@SU-AI.ARPA Message-ID: <860722-154704-3382@Xerox> On a mundane note, currently NTHCDR isn't required by CLtL to have a SETF method. Unlike (setf (sqrt...)) and (setf (not...)), this one seems to make sense and should be easy to agree on.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 18:57:31 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 15:38:30 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47682; Tue 22-Jul-86 18:30:39 EDT Date: Tue, 22 Jul 86 18:30 EDT From: David C. Plummer Subject: (setf (not x) y) => (setf x (not y)) To: Guy Steele , DCP@QUABBIN.SCRC.Symbolics.COM, Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <860722125418.3.GLS@BOETHIUS.THINK.COM> Supersedes: <860722182636.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860722183008.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 22 Jul 86 12:54 EDT From: Guy Steele Fine. I don't see any reason why a user shouldn't be allowed to do a DEFSETF of NOT. I am not crazy about installing it as a requirement in the language. Years ago I sent out examples involving * and SQRT, looking something like this: (setf (sqrt x) y) -> (setq x (* y y)) (setf (* x y) z) -> (setq x (/ z y)) (setf (* x x) z) -> (setq x (sqrt z)) We could do it, but it would be wrong. Some things are more wrong than others. Anyway, an argument against telling the user to DEFSETF of NOT is that some systems may complain if more than one use tries to do that, on the grounds that different users are stepping on each other's toes. Symbolics is such an implementation. I think SETF of NOT has a fairly concise semantic meaning and is generally useful, and at least 90% correct, if not higher. Maybe we should standardize .defun sys:allow-redefinition function-spec &optional (type 'defun) so that I can preface my implementation of DEFSETF of NOT with (sys:allow-redefinition 'NOT 'DEFSETF) ? I'm quite serious about this (in addition to DEFSETF of NOT).  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 18:46:53 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 15:30:48 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 62527; Tue 22-Jul-86 18:28:25 EDT Date: Tue, 22 Jul 86 18:26 EDT From: David C. Plummer Subject: (setf (not x) y) => (setf x (not y)) To: Guy Steele , DCP@QUABBIN.SCRC.Symbolics.COM, Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <860722125418.3.GLS@BOETHIUS.THINK.COM> Message-ID: <860722182636.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 22 Jul 86 12:54 EDT From: Guy Steele Fine. I don't see any reason why a user shouldn't be allowed to do a DEFSETF of NOT. I am not crazy about installing it as a requirement in the language. Years ago I sent out examples involving * and SQRT, looking something like this: (setf (sqrt x) y) -> (setq x (* y y)) (setf (* x y) z) -> (setq x (/ z y)) (setf (* x x) z) -> (setq x (sqrt z)) We could do it, but it would be wrong. Some things are more wrong than others. Anyway, an argument against telling the user to DEFSETF of NOT is that some systems may complain if more than one use tries to do that, on the grounds that different users are stepping on each other's toes. Symbolics is such an implementation. I think SETF of NOT has a fairly concise semantic meaning and is generally useful, and at least 90% correct, if not higher.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 18:19:55 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 15:05:11 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47635; Tue 22-Jul-86 17:59:31 EDT Date: Tue, 22 Jul 86 17:59 EDT From: David C. Plummer Subject: GC function To: Jim Hassett , common-lisp@SU-AI.ARPA In-Reply-To: The message of 21 Jul 86 09:26 EDT from Jim Hassett Message-ID: <860722175932.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 21 Jul 86 09:26 ??? From: Jim Hassett Your date field ended in ???, which our mail header parser decided not to parse. The discussion concerning (GC) suggests that a major use would be to trigger garbage collection so that delays could be avoided during some subsequent processing, such as benchmarks or real-time operations. It seems a bit devious to invoke garbage collection for the purpose of preventing it, so perhaps a more direct approach to this application could be used: without-gc-delay form [Macro] Evaluates form and returns what form returns, but prevents (as far as is reasonable for the implementation) delays due to garbage collection. It could be left up to the implementation to decide whether garbage collection should be done before evaluating the form. Obviously, it is possible that some forms which could otherwise be handled might exhaust available memory when processed in this manner, unless the implementation can provide for doing garbage collection if it can be seen to be necessary. Does this make sense over a reasonably broad range of implementations? I think so. Is it sufficiently useful to be included in the language? Quite possibly. This is the best thing I've seen from this discussion so far. You also raise some of the right issues. As an example to some of the things this would do in the Symbolics implementation, it would prevent the GC from starting during execution, and cause "scavenging during cons" to be turned off. As you say, the implementation may do (or finish) a GC before entering the form. In copying garbage collectors, you could have a "delay" by referencing an object in oldspace and needing to transport it. It may also be a reasonable restriction/warning that implementations must be careful to avoid spending too much time within the form, since it may inhibit all GC activity, and you could therefore run out of room.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 18:08:03 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 14:48:57 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47620; Tue 22-Jul-86 17:48:19 EDT Date: Tue, 22 Jul 86 17:48 EDT From: David C. Plummer Subject: Some easy ones (?) -- 107 lines of answer (!) To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM> #5, parse-body, looks reasonable. Two comments: I don't think you need a declarations-allowed-p argument on the grounds that the semantics of PARSE-BODY implies declarations. What's the whole point? Along the same lines you don't need documenation-allow-p. Don't you have to return a list of doc strings? I don't know if the BODY returned should contain the macroexpanded first form in case it wasn't a declare. Part says yes, to avoid multiple expansion, part says no, on the grounds that the compiler might have some knowledge of certain macros before they get expanded. (E.g., it might arrange for the fail case of CHECK-TYPE to branch to the end of the function to allow the normal case to do sequential execution, but the expansion of CHECK-TYPE might destroy the semantic meaning. #6: This just seems to random to me. If you are really parsing a body, you should be required to accept all three of new body, declarations and documentation. I'm under the impression there are relatively few macros that actually have to use PARSE-BODY (but those that do really need it!), and therefore this syntax doesn't have high visibility. (P.s., (...&body body-var decl-var doc-var) will break a compile that isn't prepared for it.) #7: Why isn't (TYPE-SPECIFIER-P foo) == (typep foo 'type). In other words, why not define a type named TYPE that fills this gap instead of a new function. #8, DEFCONSTANT: Yes. The last clarification is fine. #9: Fine. There is a 35% reasonable counter example, but I've been getting too random recently. Do you really want to say "is an error" or "signals an error" when the compiler/interpreter tries to interpret such code. #10 declarations for LABELS, FLET: Yes. You may want to explicitly state the a common such declaration is INLINE. I can't remember the reason for MACROLET. Refresher? #11 TAGBODY contents: Yes. The real issue is that tagbody tags must be EQL, right? The restriction to symbols and integers as tags and strings being part of the program is much less confusing. #12 TAGBODY tag uniqueness: Yes. Consider changing "is an error" to "signals an error". This is a compile-time issue, not a runtime issue, so "signals an error" or "is an error and issues a warning" is more appropriate. #13 stack &REST lists: I don't think this is a clarification, it is a changle. [It would be nice if there were page numbers to go with these clarifications. This one is page 60 or so.] The clarification is not strong enough. What is special with being called with APPLY? Doesn't the same clarification allow stack-"consed" &REST args? That would break some of the examples on page 64. If you really want to "clarify" this, you must specify that it is an error to destructively modify the &REST argument, and it is also an error to return it or store it in stable storage. These restrictions have been complained about by Symbolics customers for years. I think they are also confusing (which is why we get complaints), in that the programmer has to be very keen on when and how each list is being used. Consider this program (defun foo (&rest b) (bar b)) All of a sudden, FOO has to know that BAR's first argument will not be destructively modified or stored in stable storage. This is highly non-local to FOO. This is not an easy thing to solve /efficiently/. Sure, the compiler can insert a (setq rest-arg (copy-list rest-arg)) all the time, but it shouldn't have to. In other words, I vote no. #14 THE VALUES: Page 161? I can't remember the discussion, but this seems pretty random. What I would prefer to see is a substantive change here, which is along the lines of the following (the type form) arranges to return exactly one value and it is of type type. This is similar to (the (values type) form) If you want all the values, and the first is of type type, you say (the (values type . t) form) If you want EXACTLY two values, you say (the (values type1 type2) form) The implementation is responsible for adding or removing values that FORM returns to return exactly two. To do this today, one has to say (multiple-value-bind (a b) form (values (the type1 a) (the type2 b))) or (multiple-value-bind (a b) form (the (values type1 type2) (values a b))) Is this at all related to returning extra multiple values and using multiple-value-call? I can imaging a smart compiler that would turn (multiple-value-call #'list (the (values t t) (get-two-things)) (the (values t t t) (get-three-things))) into efficient code that calls LIST of 5 arguments. As the language is currently defined, the above could return a list of any number of elements, from 0 to . What is useful and what is really trying to be accomplished by this proposal? ======= I think you better split things up. Maybe its just me being to talkative and/or flaming. I'm quite fond of Common Lisp. Really! I would like to see it do useful and reasonable things. If a change doesn't look like it does both, then I question its motivation. #14 is reasonable, but I don't see that it is useful, and I do see changes to it that I think are also reasonable and are potentially useful for programmers and implementations.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 17:55:21 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 14:36:13 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47447; Tue 22-Jul-86 15:35:36 EDT Date: Tue, 22 Jul 86 15:36 EDT From: Daniel L. Weinreb Subject: Bawden's Alternate Proposal To: ALAN@MIT-AI.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[AI.AI.MIT.EDU].73460.860721.ALAN> Message-ID: <860722153640.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 21 Jul 86 17:55:05 EDT From: Alan Bawden This is correct. Since function names are lexically scoped, you can call the inner function something other than FOO with only a minor change to your program. Is this situation actually common in anyone's code? It sounds like the basic idea of your proposal could be described as follows: to keep everything simple and clear, get rid of the whole idea of non-pervasive declarations. Everything is pervasive. Also, everything applies (pervades) exactly around a specific lexical enclosure, which is either the LOCALLY form, or the body of the special form with a DECLARE in it. Why are non-pervasive declarations flushable? Because the only reason for them was to affect one variable named, say, "foo", without affecting another named "foo", and since everything is lexically scoped, you can always just rename the other "foo" to prevent the declaration from affecting it. That way, you don't need the "fine control" provided by non-pervasive declarations. I do like the idea of simplifying the rules as much as possible. However, I am not completely happy with this as a philosophy for the language. After all, we have a whole set of scoping rules designed to deal with things like: (let ((a ---)) ... (let ((a ---)) ...)) While you're at it, you could simplify the scoping rules as well, by simply not allowing such constructs; the user can always change the name of the inner "a".  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 17:55:00 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jul 86 14:37:00 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47557; Tue 22-Jul-86 16:53:01 EDT Date: Tue, 22 Jul 86 16:53 EDT From: David C. Plummer Subject: (declare (type fixnum ---)) considered etc. To: Scott E. Fahlman , masinter.PA@XEROX.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: References: <860721-164728-2170@Xerox>, Message-ID: <860722165303.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 21 Jul 1986 20:45 EDT From: "Scott E. Fahlman" We certainly can't remove the fixnum declaration, Sorry, I don't see this as given. We can have a type of FIXNUM for those that wanted to look, but we can make it illegal as a type declaration because it produces non-portable code. I think a type declaration of (signed-byte 32) is CORRECT for what the programmer meant and therefore much more appropriate. but we can warn against this problem in the new spec. Whether anyone heeds the warning is another matter. Languages should be useful and helpful for programmers (whether those programmers are human or otherwise). Warnings should be heeded. One could try arguing that if a function compiles with a warning, then the compiler is at liberty to redefine the function as if it were written (defun foo (&rest ignore) (declare (ignore ignore)) (break)) and force the user to write code that at least passes the compiler's tests.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 13:50:47 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 22 Jul 86 10:33:50 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUL 86 10:25:42 PDT Date: 22 Jul 86 10:24 PDT From: Daniels.pa@Xerox.COM Subject: Re: Some easy ones (?) In-reply-to: Masinter.pa's message of 21 Jul 86 22:15 PDT To: Masinter.pa@Xerox.COM cc: common-lisp@SU-AI.ARPA Message-ID: <860722-102542-2911@Xerox> "Proposal #7: TYPE-SPECIFIER-P How about restricting it to symbols? Otherwise, there are imponderables..." Seems like we would end up with the same situation as with SUBTYPEP - there are three possible answers: yes, I'm sure; no, I'm sure; and no, I can't tell. -- Andy. --  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 13:39:02 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 22 Jul 86 10:24:39 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 60227; Tue 22-Jul-86 03:35:58 EDT Date: Tue, 22 Jul 86 03:35 EDT From: Robert W. Kerns Subject: (setf (not x) y) => (setf x (not y)) To: Scott E. Fahlman cc: David C. Plummer , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860722033557.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Sun, 20 Jul 1986 15:16 EDT From: "Scott E. Fahlman" OK, I considered those suggestions as seriously as I could, and to me they look utterly worthless and needlessly confusing. Unless you can demonstrate some good use for these constructs that could not be done much perspicuously and clearly using existing mechanisms, I suggest we drop this. -- Scott I have had "structure accessors" which worked by doing 1- on a stored field that had to be stored 1-origin for some reason. After about the third occurance of this, it was tempting to write a DEFSETF for 1- instead of for my accessors.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 13:03:45 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 22 Jul 86 09:53:39 PDT Received: from boethius by Godot.Think.COM via CHAOS; Tue, 22 Jul 86 12:53:36 edt Date: Tue, 22 Jul 86 12:54 EDT From: Guy Steele Subject: (setf (not x) y) => (setf x (not y)) To: DCP@QUABBIN.SCRC.Symbolics.COM, Fahlman@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <860720154642.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-Id: <860722125418.3.GLS@BOETHIUS.THINK.COM> Fine. I don't see any reason why a user shouldn't be allowed to do a DEFSETF of NOT. I am not crazy about installing it as a requirement in the language. Years ago I sent out examples involving * and SQRT, looking something like this: (setf (sqrt x) y) -> (setq x (* y y)) (setf (* x y) z) -> (setq x (/ z y)) (setf (* x x) z) -> (setq x (sqrt z)) We could do it, but it would be wrong. --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 12:37:25 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Jul 86 09:26:55 PDT Date: 22 Jul 86 12:25:00 EST From: "BACH::GREEK" Subject: The Noncontroversial Ten Proposals To: "common-lisp" Reply-To: "BACH::GREEK" #5: PARSE-BODY I think it should take another optional that says whether declarations are allowed. This just makes it more general. If it has to expand a macro to check for declarations and finds that the expansion does NOT contain a declaration, does it return the body with or without the first form expanded? How about returning two lists of declarations: those for specials and all others? This could be used by the interpreter. Is it worth the extra time? I think the values should be returned in logical order: declarations, doc-string, body. What happened to our discussion of programs which modify constants? I believe we agreed that was an error. Or was it too controversial? How about a LET, FLET, or LABELS which defines the same name more than once? - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 12:01:17 EDT Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 22 Jul 86 08:50:09 PDT Received: from RICKY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 40336; Tue 22-Jul-86 11:52:25-EDT Date: Tue, 22 Jul 86 11:51 EDT From: Richard Mlynarik Subject: Proposal #5 To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860722115114.5.MLY@RICKY.AI.MIT.EDU> Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" Proposal #5: PARSE-BODY Extension: Add a new function (PARSE-BODY body environment documentation-allowed-p). It pulls apart the body into three parts: a list of DECLARE forms, a documentation string (or NIL if none), and the body proper. These are returned in the order body, declarations, and doc-string as three values. PARSE-BODY may perform macro-expansion (using the given environment) in order to determine whether an initial macro-call expands into a DECLARE form or documentation string. There could be an &optional before then environment and doc-p args (environment args are optional everywhere else: ie macroexpand and (proposed) eval.) I have found it more convenient to return a list of declarations (ie the "insides" of declare forms) rather than declare forms themselves. That is, I would have (parse-body '((declare (type atom x) (weird y)) (declare (special z y)))) return a decls value of ((atom x) (weird y) (special z y)). This makes it easier for the caller to do assoc tests for certain kinds of relevant declarations. A sample call to this style of parse-body looks like: (multiple-value-bind (body decls) (parse-body body environment) `#'(lambda ,arglist (declare ,@decls) (return-from ,block-name (progn . ,body)))) What ever happened to the (declare (documentation "foo")) proposal? (The documentation declaration being equivalent to supplying a doc-string) KMP (I believe) suggested this a long time ago and a lot of people seemed to think that it was a good and necessary thing (some going as far as to implement it) If there were such a documentation declaration, a doc-string could just be returned from PARSE-BODY as part of the declarations rather than as a separate value. (The doc-string-valid-p arg is still needed, though)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 10:35:01 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 22 Jul 86 07:25:13 PDT Date: 22 Jul 86 10:21:00 EST From: "BACH::GREEK" Subject: Declarations To: "common-lisp" Reply-To: "BACH::GREEK" I think we should be very careful about declarations which can pertain to more than one entity with the same name. Nick's proposal that all declaration are pervasive brings out this problem in spades. I think it is dangerous, since a declaration could easily tell a lie about one or the other of the two entities. - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 03:04:28 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 23:55:23 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 23:55:45 PDT Date: 21 Jul 86 23:55 PDT From: Masinter.pa@Xerox.COM Subject: Re: exit-to-system In-reply-to: Guy Steele 's message of Mon, 21 Jul 86 15:01 EDT To: Common-lisp@su-ai.ARPA Message-ID: <860721-235545-2606@Xerox> A number of arguments seem to be of the form "Well, when I see the word BYE I think it might mean turn off the power on my system..." So lets go for a more specific name than QUIT (or EXIT) , which could mean QUIT of any number of things (QUIT the process, QUIT the debugger loop, QUIT this top-level loop, etc.) For example, EXIT-LISP &optional forever [Function] The exact behavior EXIT-LISP is, of course, implementation dependent. Its purpose is to leave the running Lisp system. In Lisp systems that run under an operating system with a command shell, this command returns you to the operating system shell. The optional parameter "forever" indicates whether there's any intention to return to this Lisp. - - - - - - - - - - - - - Interlisp in all of its implementations has had (LOGOUT) forever. (LOGOUT) under Unix, VMS and Tops-20 meant "go to operating system". In Interlisp-D, (LOGOUT) means "leave but save enough to let me come back" and (LOGOUT T) means "leave without saving state". A call to (LOGOUT) *can* return -- when you restart! It doesn't mean that it "failed". LOGOUT seems like a good model for what is wanted here. Users moving from Interlisp-10 to Interlisp-D found it a natural analog, even though what it did was very different.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 01:29:35 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 22:17:55 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 22:15:20 PDT Date: 21 Jul 86 22:15 PDT From: Masinter.pa@Xerox.COM Subject: Re: Some easy ones (?) In-reply-to: "Scott E. Fahlman" 's message of Mon, 21 Jul 86 21:46 EDT To: common-lisp@SU-AI.ARPA Message-ID: <860721-221520-2564@Xerox> --------------------------------------------------------------------------- Proposal #6: Parsing in &BODY I like (KMP's) &body body-var [declarations-var [doc-string-var]] over Proposal #6. 1) KMP's is better style: a) every other part of the argument list a list means (a a-default-value) but Proposal#6 would mean (body declarations-var) b) a list in &rest means to destructure; Proposal#6 would make a list after &rest and &body mean very different things. 2) KMP's is simpler to describe in the manual. (No, "if you say (foo) it means the same as foo") 3) upward compatible -- For the many of the same reasons, I don't like allowing default or supplied-p values for these; in addition, it is meaningless (what's the difference between body not supplied and body = NIL?), and more difficult to implement. --------------------------------------------------------------------------- Proposal #7: TYPE-SPECIFIER-P How about restricting it to symbols? Otherwise, there are imponderables, e.g., if I say (deftype frobnitz (&key a b) ...) is (type-specifier-p '(frobnitz :a 3)) true and (type-specifier-p '(frobnitz :c 3)) false? Is (type-specifier-p '(array (3 3 #(a vector in the wrong place)))) true or false? At least with symbols there's some hope of a simple definition.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jul 86 01:22:38 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Jul 86 22:11:18 PDT Received: from umass-cs by csnet-relay.csnet id ak02823; 22 Jul 86 1:10 EDT Date: Mon, 21 Jul 86 10:33 EST From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Declare Special I support cleaning up the semantics of declarations. I find myself using *very* deffensive coding techniques instead of looking at the manual every time I write a declaration. I think the basic idea of putting the declaration inside the form it is trying to affect is inherently un-lispish and will always be confusing. I think that we should define a set of special forms that syntactically enclose the body they apply to and supply the needed functionality. Maybe in CL-2000 these can be made the standard. Locally is a good start. I have a question about its semantics, though. Consider: (locally (declare (special foo)) (let ((foo )) (print foo))) I cannot figure out what this does from CLtL. Probably the binding is not affected by locally, (even though the declaration is pervasive) so in fact the binding *cannot* be referenced. The reference to foo is (presumably) affected by a pervasive declaration, so this code fragment does something unpredictable. I think two additional special forms would be helpful. One would be exactly like locally, except that it would pervasively affect bindings as well as references to variables. In other words, this would be a lexically scoped version of proclaim. (Perhaps call it proclaim-locally). The last special form needed would supply the standard lexically scoped declarations. Hopefully this is not too confusing. The syntax would again be identical to locally, but the scope would be everything through the scope of the next enclosing binding. (For variable declarations of course.) For example: (lexical-locally (declare (special x)) ;; x special here. (let ((x 3)) ;binds x specially. ;; x special here (and = 3) (let ((x 4)) ;Binds x lexically. ....))) People probably wouldn't want to use these at top-level, so there is still a need for something like Pavel's suggestion. Elsewhere these forms would usually be clearer.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 22:15:46 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 19:06:25 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 86 19:06:46 PDT Date: 21 Jul 86 19:02 PDT From: masinter.pa@Xerox.COM Subject: Re: (declare (type fixnum ---)) considered etc. In-reply-to: "Scott E. Fahlman" 's message of Mon, 21 Jul 86 20:45 EDT To: Fahlman@C.CS.CMU.EDU cc: common-lisp@su-ai.ARPA Message-ID: <860721-190646-2493@Xerox> The fixnum declaration is one of the easiest things to remove. a) Implementations that support (or need) fixnum declarations can add them to their extension. This is clearly allowed by the spec, but it becomes something that is an implementation's private extension rather than part of the public, portable standard. The cost to implementors is zero. b) Users who have code that has fixnum declarations could add, trivially, a (deftype fixnum () ...) c) The intent of fixnum declarations is reasonably supported by a much more portable expression where the range of a variable is declared explicitly rather than depending on implementation-dependent fixnum ranges. I don't know the source of the "certainly" in your message.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 22:01:42 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jul 86 18:46:31 PDT Received: ID ; Mon 21 Jul 86 21:46:51-EDT Date: Mon, 21 Jul 1986 21:46 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Some easy ones (?) What follows are ten proposals adapted from Steele's list of last December. These have been discussed before, and I believe that they should not stir up much new controversy. There are a lot of issues like this, so I'm hoping that we can deal with these in batches, while continuing to discuss more difficult issues like declaration scoping. We shall see. Please read these over and indicate any problems you discover, or whether they all look OK to you. The plan is to discuss these things for a week (or more if complexities arise), then to put the proposals forth in their final form for a last round of comments, and finally to send the proposals to the technical committee, who will make the final decisions. This is something of an experiment. If we can't handle this many simple things at once, we'll have to deal with issues in smaller batches, but then it will take twice as long to settle these things. -- Scott --------------------------------------------------------------------------- Proposal #5: PARSE-BODY Extension: Add a new function (PARSE-BODY body environment documentation-allowed-p). It pulls apart the body into three parts: a list of DECLARE forms, a documentation string (or NIL if none), and the body proper. These are returned in the order body, declarations, and doc-string as three values. PARSE-BODY may perform macro-expansion (using the given environment) in order to determine whether an initial macro-call expands into a DECLARE form or documentation string. --------------------------------------------------------------------------- Proposal #6: Parsing in &BODY Change (could conceivably break existing code which destructures &body arguments, but this should be rare as such destructuring is generally too complex to do via the built in mmechanism): Extend the syntax of an &BODY parameter to DEFMACRO to allow writing &body (body-var [declarations-var [doc-string-var]]). If only body-var appears in parentheses, it means the same as a body-var with no parentheses. Otherwise, it means to give the original body to PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is specified) and then bind the variables to the corresponding values returned by PARSE-BODY. This is purely a syntactic convenience for the user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then call PARSE-BODY himself. Note: This extension is proposed only for &BODY, not for &REST, so &BODY will no longer be exactly equivalent to &REST in a DEFMACRO arglist. [Note: KMP has suggested the syntax (...&body body-var decl-var doc-var). This does not break any existing code and would allow default and supplied-p values for the three variables. I (sef) don't think these are important advantages, and I prefer the syntax proposed above, which is less confusing to the eye -- my eye, ayway. The proposed format is the one we discussed on the mailing list earlier and seemed to be favored by most people.] --------------------------------------------------------------------------- Proposal #7: TYPE-SPECIFIER-P Proposed extension: Add a new function TYPE-SPECIFIER-P that is true of valid type specifiers and false of all other Lisp objects. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time. --------------------------------------------------------------------------- Proposal #8: Clarifications to DEFCONSTANT Clarifications: Clarify that using DEFCONSTANT to redefine any constant described in the Common Lisp specification is an error. Clarify that if the user defines a constant, compiles code that refers to that constant, and then redefines the constant, then behavior of the compiled code may be unpredictable. It is an error to execute such code. Clarify that it is not an error to issue a second DEFCONSTANT command for an existing constant iff the new value is EQL to the old one. [That last clarification has not been discussed previously, as far as I know, but seems to be needed for reloading certain compiled code files, etc.] --------------------------------------------------------------------------- Proposal #9: Variable Name Conflicts Clarification: Specify that it is an error for two parameters (including supplied-p and &aux parameters) in the same lambda-list to have the same (EQL) name. [As previous discussion brought out, we could instead allow this case with the last-bound (rightmost) argument shadowing previous bindings in the same arglist, but this is certainly bad style and interacts in nasty ways with the proposed change to the scope of declarations.] --------------------------------------------------------------------------- Proposal #10: Forms That Allow Declarations Extension: Permit declarations before the body of a LABELS, FLET, or MACROLET. --------------------------------------------------------------------------- Proposal #11: Contents of Tagbody Clarification: Specify that constant forms such as strings may appear at top-level in a tagbody, but that only symbols and integers are considered to be tags. It is an error to use anything else as the destination tag for a GO. [Several forms of this have been kicked around. This seems as good as any. The original issue was whether you could put something like a string at top-level and, if so, whether you could go to it.] --------------------------------------------------------------------------- Proposal #12: Unique Names For Tags Clarification: Specify that it is an error for the same (EQL) tag to appear more than once in the body of a TAGBODY. (However, a TAGBODY may have the same tag as another TAGBODY in which it nests, in which case the tag in the outer TAGBODY is shadowed, as already specified.) --------------------------------------------------------------------------- Proposal #13: Structure Sharing in Arguments Clarification: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy, and therefore the user should not perform destructive operations on it. Similarly, a function that takes a &REST argument should not destructively modify it because in some implementations its top-level list structure might share with a list that the user gave as the last argument to APPLY. --------------------------------------------------------------------------- Proposal #14: THE and VALUES Clarification: Specify that in (THE (VALUES ...) form), the form may return more values, but not fewer, than the number of types specified in the (VALUES ...) form, and that any extra values are of unrestricted type. Also specify that (THE type form) where type is not (VALUES ...) is equivalent to (THE (VALUES type) form). ---------------------------------------------------------------------------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 20:55:04 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jul 86 17:45:28 PDT Received: ID ; Mon 21 Jul 86 20:45:44-EDT Date: Mon, 21 Jul 1986 20:45 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: masinter.PA@XEROX.COM Cc: common-lisp@SU-AI.ARPA Subject: (declare (type fixnum ---)) considered etc. In-reply-to: Msg of 21 Jul 1986 19:46-EDT from masinter.PA at Xerox.COM We certainly can't remove the fixnum declaration, but we can warn against this problem in the new spec. Whether anyone heeds the warning is another matter. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 19:56:45 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 Jul 86 16:47:08 PDT Received: from Salvador.ms by ArpaGateway.ms ; 21 JUL 86 16:47:28 PDT From: masinter.PA@Xerox.COM Date: 21 Jul 86 16:46:41 PDT Subject: (declare (type fixnum ---)) considered etc. To: common-lisp@su-ai.ARPA Message-ID: <860721-164728-2170@Xerox> I recently had the opportunity to port an application which had (declare (type fixnum x y)) for some of the variables. Unfortunately, the variables could legally exceed most-positive-fixnum in our implementation (where most-positive-fixnum is 2^16). Currently the book does nothing to discourage such unportable declarations. What would have been more reasonable would be to (declare (type (signed-byte 32) x y)) if that was what had been meant.... I'd like to see the book (if not the spec) revised to explicitly discourage using "fixnum" in declarations, if it isn't eliminated. Most of the other type specifiers--including those with implementation-dependent ranges such as short-float or string-char--don't have the same problem because they correspond to something real in the language.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 18:36:18 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Jul 86 15:26:03 PDT Date: 21 Jul 1986 18:24-EDT Sender: NGALL@G.BBN.COM Subject: Re: Declarations From: NGALL@G.BBN.COM To: greek%bach.decnet@HUDSON.DEC.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]21-Jul-86 18:24:30.NGALL> In-Reply-To: The message of 21 Jul 86 14:34:00 EST from "BACH::GREEK" Date: 21 Jul 86 14:34:00 EST From: "BACH::GREEK" To: "common-lisp" Subject: Declarations I hadn't read Nick's clarification to Pavel's proposal before I sent out my last message. Nick's clarification looks quite good. A question: Why did you choose to say that declarations pertaining to names that are not bound in the current contour affects references in the entire form? Why not just in the body of the form? I felt that decls pertaining to names not bound in the current contour were analogous to the optimize decl which never pertains to names. If I have a tight loop that I want to go fast, I write (do ((rest list (rest rest))) ((endp rest...) (declare (optimize (speed 3) (safety 0))) ...) And I expect the optimize to affect the step forms and the end test in addition to the actual body. If OPTIMIZE affected only the 'simple body', I'd have to write (do ((rest list (locally (declare (optimize...)) (rest rest)))) ((locally (declare (optimize...)) (endp rest))...) (declare (optimize (speed 3) (safety 0))) ...) Yech! I think the same argument holds, for example, for INLINE. If I want to open-code all calls to some accessor function in a do loop, where some of the calls to the accessor function are in the step forms, I don't want to use LOCALLY all over the place. One can think up similar arguments for FLET, etc. I'm not sure I know which is better, I'm just wondering how you decided. - Paul ------ --------------------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 18:04:02 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 14:53:38 PDT Date: Mon, 21 Jul 86 17:55:05 EDT From: Alan Bawden Subject: Bawden's Alternate Proposal To: common-lisp@SU-AI.ARPA In-reply-to: Msg of 21 Jul 86 16:34:00 EST from "BACH::GREEK" Message-ID: <[AI.AI.MIT.EDU].73460.860721.ALAN> From: "BACH::GREEK" Bawden's proposal would result in the following. (FLET ((FOO (X) (FOO X X))) (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO 5) ...) The declaration for FOO would pertain to both the locally-defined FOO and the outer FOO used in its body. This is correct. Since function names are lexically scoped, you can call the inner function something other than FOO with only a minor change to your program. Is this situation actually common in anyone's code?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 17:41:55 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 14:31:35 PDT Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 17:31:41 edt Date: Mon, 21 Jul 86 17:32 EDT From: Guy Steele Subject: Tail Recursion in Common Lisp ??? To: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: Message-Id: <860721173224.8.GLS@BOETHIUS.THINK.COM> Date: Fri, 18 Jul 1986 12:44 EDT From: "Scott E. Fahlman" It is my belief, based on what I know of the constraints various groups feel they are working under, that there is no chance in hell that required tail-recusrion removal will be added to Common Lisp in the near future. There's just no point in discussing this further. If you want a guarantee that tail-recursion will be handled well, use Scheme or that subset of Common Lisps that are able to support this; if you want a guarantee that your code will be efficient in Common Lisp, use DO. I believe that tail-recursion removal will be ALLOWED in the final spec, though some groups read the current manual as requiring a full call, even from a function to itself, in case someone has installed a new definition for FOO in the middle of running FOO. We will discuss this and, I hope, find a set of rules under which tail-recursion removal is legal (but not required) unless the user has explicitly requested the full call. We will of course try to clearly document exactly what is allowed and what is required in this area, once this has been decided. -- Scott I agree with Scott's sentiment: we just can't require it now. One minor correction: the removal of tail recursion is not necessarily synonymous with failing to examine the function cell at call time; that is, one might have removal of tail recursion (stack doesn't grow when you do a tail-recursive call) that is not implemented by a simple JUMP instruction back to the top of the current procedure. Tail-recursion removal is more general than self-recursion removal. For more flames, see my paper in Proc. ACM '77 National Conference. --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 17:41:17 EDT Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 21 Jul 86 14:32:23 PDT Date: Mon, 21 Jul 86 17:19:58 EDT From: "Curtis A. Scott" To: common-lisp@su-ai.arpa cc: gls@aquinas.think.com, cscott%bfly-vax@bbn.com Subject: exit-to-system Now I know you don't think multiple threads of control are a good thing, but QUIT has a fairly natural interpretation in the Multilisp-style world. It might mean "This computation has done the side-effects it needed to do, so abandon it". This implies a return to the operating system (if there is one) if there are no other threads of control (since the work done by the REP loop has been declared finished), or to reclamation of the task resources if the system as a whole still has a goal. This is also a natural interpretation on a multitasking lisp machine. Thus the concept is clear and not particularly machine-dependent. --Curtis  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 16:58:31 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 13:47:02 PDT Date: 21 Jul 86 16:34:00 EST From: "BACH::GREEK" Subject: Bawden's Alternate Proposal To: "common-lisp" Reply-To: "BACH::GREEK" Bawden's proposal would result in the following. (FLET ((FOO (X) (FOO X X))) (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO 5) ...) The declaration for FOO would pertain to both the locally-defined FOO and the outer FOO used in its body. That's two different FOOs, and the declaration is going to be a lie for one or the other! A single declaration should never be able to refer to two different entities with the same name. - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 16:10:48 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 Jul 86 13:01:18 PDT Date: Mon, 21 Jul 86 16:02:37 EDT From: Alan Bawden Subject: DECLARE SPECIAL Considered Confusing To: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of 20 Jul 1986 18:52-EDT from NGALL at G.BBN.COM Message-ID: <[AI.AI.MIT.EDU].73400.860721.ALAN> Date: 20 Jul 1986 18:52-EDT From: NGALL at G.BBN.COM Date: Sun, 20 Jul 86 17:11:53 EDT From: Alan Bawden The old rule ... did have the advantage that you can always extract the declarations from the body of a macro form and just wrap the entire expansion in a LOCALLY. (let* ((x 1) (y (1+ x))) (declare (special x)) ...) is not equivalent to (locally (declare (special x)) (let ((x 1)) (let ((y (1+ x))) ...) You're quite right. I had always assumed that the ability to extract declarations like this was the reason we adopted the rule in the first place (making both macros and documentation easier to write), but I was certainly mistaken. Actually, the more I think about this as a simplification, the more I like it. So here is a counter-proposal for rationalizing the semantics of declarations: 1. All declarations are completely pervasive. That is, if you write (locally (declare (special foo)) ...) then every occurance of FOO within the body is taken to be a special reference or a special binding. The only way to escape from the effects of a declaration within the body, is to explicitly shadow the declaration with another. This applies to -all- declarations: FTYPE, INLINE, etc. 2. Declarations that occur in the bodies of special forms (DEFUN, LET, DO, etc.), and in LAMBDA expressions, are taken to mean the same thing as if the entire form was enclosed in a LOCALLY containing the same declarations. So (let ,pairs ,@dcls ,@body) and (locally ,@dcls (let ,pairs ,@body)) are completely equivalent. (Since LAMBDA expressions aren't forms, the equivalent using LOCALLY isn't always completely straightforward to construct. For example, this case: ((lambda ,vars ,@dcls ,@body) ,@vals) is equivalent to using LOCALLY as follows: (funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals) .) Question: Why isn't LOCALLY just called PROGN?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 15:10:58 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 12:01:00 PDT Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 15:00:56 edt Date: Mon, 21 Jul 86 15:01 EDT From: Guy Steele Subject: Re: exit-to-system To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <860715120338.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <860721150138.9.GLS@BOETHIUS.THINK.COM> Date: Tue, 15 Jul 86 12:03 EDT From: Daniel L. Weinreb ... I feel the same way about the BYE function. Common Lisp would need a concept of "returning to the operating system" or something like that. Some implementations do not have any such thing. It is out of the scope of Common Lisp. The only way I can imagine that such functions would be acceptable would be if their definition said something like "In some implementations, this function is allowed to do absolutely nothing". They would therefore have to be considered part of a "user interface" rather than part of the language, since no portable program could sensibly call them. I think we should try to confine ourselves to the language business. We have more than enough work ahead of us in that department! Well, we do have ED, which is clearly a user-interface thing. Here is a stab at defining QUIT: QUIT [Function] This function is intended to terminate the running Lisp system in some appropriate manner. In some implementations or under some circumstances the Lisp system and all data contained within it may be destroyed, more or less irretrievably, in which case the user might be left in communication with the ``operating system'' or ``command shell,'' or might be ``logged out.'' In other implementations or under other circumstances this function might do nothing, in which case the call to QUIT returns NIL (to indicate that the call ``failed''). ___ / \ This was a serious attempt. I happened to think that QUIT | / | is a reasonable thing to standardize, but I find it very | :/) | difficult to come up with a definition that is portable | / | without seeming tongue-in-cheek. \___/ --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 14:58:40 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:44:51 PDT Received: from boethius by Godot.Think.COM via CHAOS; Mon, 21 Jul 86 14:45:00 edt Date: Mon, 21 Jul 86 14:45 EDT From: Guy Steele Subject: DESCRIBE-ARGUMENTS; or, special variables considered disgusting To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <8607151422.AA01086@Zarathustra.Think.COM> Message-Id: <860721144545.8.GLS@BOETHIUS.THINK.COM> Date: Tue, 15 Jul 86 10:20 EST From: mike%gold-hill-acorn@mit-live-oak.ARPA ... Info is also lost if it is a string. Package qualifiers are needed to tell which variables are being bound if any of the symbols in the arglist are specvars. Arrgghhh. Letting any binding construct bind special variables was a BIG mistake. Should have had a SPECLET construct and nothing else. Anyway, now that we are stuck with it, how about FUNCTION-PARAMETER-NAMES has a symbol in the result if it is special and a string if it is not? (IN-PACKAGE 'YUK) (DEFUN FOO (A B &REST C) (DECLARE (SPECIAL A C)) ...) (IN-PACKAGE 'USER) (FUNCTION-PARAMETER-NAMES 'YUK:FOO) => (YUK:A "B" &REST YUK:C) That will show them! (Seriously, is specbinding any business of the caller of FUNCTION-PARAMETER-NAMES?) --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 14:58:40 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:45:28 PDT Date: 21 Jul 86 14:34:00 EST From: "BACH::GREEK" Subject: Declarations To: "common-lisp" Reply-To: "BACH::GREEK" I hadn't read Nick's clarification to Pavel's proposal before I sent out my last message. Nick's clarification looks quite good. A question: Why did you choose to say that declarations pertaining to names that are not bound in the current contour affects references in the entire form? Why not just in the body of the form? I'm not sure I know which is better, I'm just wondering how you decided. - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 14:37:01 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:24:57 PDT Date: 21 Jul 86 14:14:00 EST From: "BACH::GREEK" Subject: Scope of Declarations. To: "common-lisp" Reply-To: "BACH::GREEK" We've been off the network for a while, so I just got a chance to read Pavel's proposal and the responses. I'd like to give a cheer for this proposal, which simplifies declarations and removes some of the bogusities of the current description. I have not thought carefully about any new problems it might create. Now, at the risk of hairing it up again, let me ask what people think about declarations which do not pertain to a name being bound in the current contour. In particular: (LET ((X 1)) (DECLARE (FIXNUM Y)) ... (LOCALLY (DECLARE (FIXNUM Y)) ...) These are certainly powerful in many different situations. Is the extra complexity worth it? - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 14:13:57 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 21 Jul 86 11:03:59 PDT Date: 21 Jul 86 14:04:00 EST From: "BACH::GREEK" Subject: A Bit More on Lambda-List Parsing To: "common-lisp" Reply-To: "BACH::GREEK" We've been off the network for a while, so I couldn't get in my two cents on the issue of lambda lists and their parsing/representation. If it's officially too late to comment, I apologize. Why not define a function called PARSE-LAMBDA-LIST which takes a lambda list and some information about what is allowed in it? This function would parse the lambda list and return a structure (!). This structure would contain all of the detailed information about the lambda list, what was in it, whether &ALLOW-OTHER-KEYS was there, blah, blah, blah. There would also be a function that returned the structure describing the lambda list for a given function (or macro, why not?). We could design the structure so that each slot could either contain the appropriate information or a value meaning "I don't know". In this way, implementations which don't remember certain information could indicate this. - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 11:41:55 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Jul 86 08:31:53 PDT Received: from sperry-csd by csnet-relay.csnet id aa26692; 21 Jul 86 11:30 EDT Date: Mon, 21 Jul 86 09:26 ??? From: Jim Hassett To: common-lisp@SU-AI.ARPA Subject: GC function The discussion concerning (GC) suggests that a major use would be to trigger garbage collection so that delays could be avoided during some subsequent processing, such as benchmarks or real-time operations. It seems a bit devious to invoke garbage collection for the purpose of preventing it, so perhaps a more direct approach to this application could be used: without-gc-delay form [Macro] Evaluates form and returns what form returns, but prevents (as far as is reasonable for the implementation) delays due to garbage collection. It could be left up to the implementation to decide whether garbage collection should be done before evaluating the form. Obviously, it is possible that some forms which could otherwise be handled might exhaust available memory when processed in this manner, unless the implementation can provide for doing garbage collection if it can be seen to be necessary. Does this make sense over a reasonably broad range of implementations? Is it sufficiently useful to be included in the language? - Jim Hassett  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jul 86 00:42:58 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jul 86 21:34:46 PDT Received: ID ; Mon 21 Jul 86 00:35:02-EDT Date: Mon, 21 Jul 1986 00:35 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposals Proposals 1 - 4 are now in the hands of the technical committee. We are trying to work out a schedule for making decisions on these things. All I can say right now is that we'll move on these as quickly as we can. Next, I think we want to continue the discussion of Pavel's proposed changes to declaration scope. I'll send out a message soon clarifying what I think the proposal currently is. Most people who have expressed opinions so far so far seem to favor the proposal on its merits, and several have said that they hate the existing rules. The key question now is whether anyone opposes this change, either on its merits or because it would be too hard for them to implement. (I don't think it will break much existing user code, but I could be wrong.) Speak now if you want to oppose this change. I said it would take near-unanimity to make a change of this size, and that's what we've seen so far. While we're considering this hard issue, I will send out a bunch of easy (I hope) proposals culled from the list of issues Guy Steele passed out at the Boston meeting last December. Most of these were discussed on the mailing list before December, and we seemed to agree on them at the time, so my expectation is that few of these issues will result in fresh controversy. We'll see. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 19:01:46 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 20 Jul 86 15:53:12 PDT Date: 20 Jul 1986 18:52-EDT Sender: NGALL@G.BBN.COM Subject: Re: DECLARE SPECIAL Considered Confusing From: NGALL@G.BBN.COM To: ALAN@AI.AI.MIT.EDU Cc: Common-Lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]20-Jul-86 18:52:13.NGALL> In-Reply-To: <[AI.AI.MIT.EDU].73028.860720.ALAN> Date: Sun, 20 Jul 86 17:11:53 EDT From: Alan Bawden To: Common-Lisp@SU-AI.ARPA Subject: DECLARE SPECIAL Considered Confusing In-Reply-To: Msg of 19 Jul 1986 17:17-EDT from NGALL at G.BBN.COM Message-ID: <[AI.AI.MIT.EDU].73028.860720.ALAN> Nobody has yet pointed out that changing the rules for (DECLARE (SPECIAL ...)) to follow the scoping of the variables involved does make it harder for people to write certain macros that bind variables. For example, consider trying to write LET*; you have to grovel through the declarations in the body in order to distribute the SPECIAL declarations properly. The old rule (which I have always found appalling -- I'm not trying to defend it) did have the advantage that you can always extract the declarations from the body of a macro form and just wrap the entire expansion in a LOCALLY. I don't think the old rule did make (LET* (...) (declare ...) ...) equivalent to (locally (declare ...) {some expansion for LET*}) For example, (let* ((x 1) (y (1+ x))) (declare (special x)) ...) is not equivalent to (locally (declare (special x)) (let ((x 1)) (let ((y (1+ x))) ...) Since the declaration only affects the reference to x in (1+ x); the outer LET incorrectly binds the lexical variable x. The use of LOCALLY as you suggest, only works for pervasive declarations, and the only purely pervasive declaration in CLtL is OPTIMIZE. As I said in my previous letter, I don't think FTYPE or INLINE are purely pervasive. E.g., (flet ((foo (...) ...(foo...)...)) (declare (ftype (function...) foo)) (foo...) ...) is not equivalent to (locally (declare (ftype (function...) foo)) (flet ((foo (...) ...(foo...)...)) (foo...) ...)) since the declaration in the first form would affect only the second call to foo and the decl. in the second form would affect only the first call to foo. If we really intend to open this whole can of worms, it might also be a good idea for someone to remind us all of the arguments for the concept of "pervasive declarations". -------------------- I think the can is already open in the case of FTYPE and INLINE, since CLtL is certainly muddled about whether they are simply pervasive declarations or declarations that concern bindings and only the references within the scope of the those bindings. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 17:19:35 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 Jul 86 14:10:44 PDT Date: Sun, 20 Jul 86 17:11:53 EDT From: Alan Bawden Subject: DECLARE SPECIAL Considered Confusing To: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of 19 Jul 1986 17:17-EDT from NGALL at G.BBN.COM Message-ID: <[AI.AI.MIT.EDU].73028.860720.ALAN> Nobody has yet pointed out that changing the rules for (DECLARE (SPECIAL ...)) to follow the scoping of the variables involved does make it harder for people to write certain macros that bind variables. For example, consider trying to write LET*; you have to grovel through the declarations in the body in order to distribute the SPECIAL declarations properly. The old rule (which I have always found appalling -- I'm not trying to defend it) did have the advantage that you can always extract the declarations from the body of a macro form and just wrap the entire expansion in a LOCALLY. If we really intend to open this whole can of worms, it might also be a good idea for someone to remind us all of the arguments for the concept of "pervasive declarations".  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 16:23:24 EDT Received: from UR-ACORN.ARPA by SU-AI.ARPA with TCP; 20 Jul 86 13:09:43 PDT Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 30776; 20 Jul 86 16:06:03-EDT Date: Sun, 20 Jul 86 16:06 EDT From: Brad Miller Subject: Re: (setf (not x) y) => (setf x (not y)) To: dcp@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA Fcc: ACORN:>miller>mail>mailout.file Message-ID: <860720160619.7.MILLER@UR-CASHEW.ARPA> Sorry, I must be dense. What does this buy us? Brad Miller  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 15:59:57 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 20 Jul 86 12:48:01 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45875; Sun 20-Jul-86 15:46:47 EDT Date: Sun, 20 Jul 86 15:46 EDT From: David C. Plummer Subject: (setf (not x) y) => (setf x (not y)) To: Scott E. Fahlman , David C. Plummer cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860720154642.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 20 Jul 1986 15:16 EDT From: "Scott E. Fahlman" OK, I considered those suggestions as seriously as I could, and to me they look utterly worthless and needlessly confusing. Unless you can demonstrate some good use for these constructs that could not be done much perspicuously and clearly using existing mechanisms, I suggest we drop this. Some of this may be tainted by the Symbolics environment, which has DEFSUBST, which can easily be done in CLtL using PROCLAIM using INLINE (that's what it actually does), and that SETF "happens to know" that it should expand inline forms. This makes life a LOT easier, and probably isn't considered portable CL. Doing it with inline functions is prefereable to macros, as we shall see. With that as background, consider this (defstruct direction up-p left-p front-p) There are at least two ways to express the inverses. One is to build them into the defstruct, and the other is to write abstractions that use the existing slots. If macros were used, we would get (defmacro direction-down-p (dir) `(not (direction-up-p ,dir))) If SETF of NOT were to be adopted, it would automatically be possible to SETF DIRECTION-DOWN-P. As it is, I have to (defsetf direction-down-p (dir) (down-p) `(setf (direction-up-p ,dir) (not ,down-p))) and I have to do that for all of the others. The reason inline functions are preferable for the standard reason: you can't funcall macros. Since our substs are effectively macros to the compiler (with hair to preserve order of evaluation if necessary), SETF sees them as valid things to macroexpand. The language should let me easily capture a concept (DIRECTION-DOWN-P) and shouldn't burden me with a lot of tedious "junk" (DEFSETF of same) in order to make effective use of it.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 15:29:24 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jul 86 12:17:05 PDT Received: ID ; Sun 20 Jul 86 15:16:57-EDT Date: Sun, 20 Jul 1986 15:16 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: (setf (not x) y) => (setf x (not y)) OK, I considered those suggestions as seriously as I could, and to me they look utterly worthless and needlessly confusing. Unless you can demonstrate some good use for these constructs that could not be done much perspicuously and clearly using existing mechanisms, I suggest we drop this. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 14:11:26 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 20 Jul 86 11:03:05 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45856; Sun 20-Jul-86 13:59:30 EDT Date: Sun, 20 Jul 86 13:59 EDT From: David C. Plummer Subject: (setf (not x) y) => (setf x (not y)) To: common-lisp@SU-AI.ARPA Message-ID: <860720135927.2.DCP@FIREBIRD.SCRC.Symbolics.COM> NOT is not one of the special things recognized by SETF (CLtL pg 95++). One theory says that if Y is not NIL, then X must be NIL and the right semantics hold, but if Y is NIL, X could be anything that is not NIL, whereas (not Y) will be T. I claim this is OK, since NOT is for boolean purposes. Anybody could do this via the escape clause on page 97: "Any form for which a defsetf or define-setf-method declaration has been made." However, I believe the spirit of the escape clause is for user forms, not CLtL supplied forms, such as NOT. [Randomness notch goes up. I hope this doesn't detract from the above, which I think is quite reasonable.] In theory the same could be applied to ZEROP. That is, (setf (zerop x) y) => (setf x (if y 0 -1)) This is on the grounds that zerop is trying to test for all bits off and therefore the inverse is all bits one. This, of course, assumes two's complement arithmetic. Section 12.7, page 220, assumes this for the logical operations. Maybe the correct expression for "all bits off" is (not (logtest x -1)), and many people are potentially misusing ZEROP? (BTW, ZEROP isn't in the index.) I'll stop the randomness at this point and not mention 1+. Please consider the first two paragraphs seriously. We can consider the rest seriously only if we adopt the convention for SETF of NOT.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 13:57:32 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 20 Jul 86 10:48:44 PDT Date: Sun, 20 Jul 86 13:49:55 EDT From: Jonathan A Rees Subject: No need to optimize tail recursion, use infinite virtual stack! To: common-lisp@SU-AI.ARPA Message-ID: <[AI.AI.MIT.EDU].72977.860720.JAR> [I wanted to send this only to REM, but I don't know his network address -- MIT-AI's mailer doesn't know about host IMSSS.] Date: 18 Jul 1986 1410-PDT From: Rem at IMSSS To: COMMON-LISP at SU-AI Re: No need to optimize tail recursion, use infinite virtual stack! If a finite segment of stack is in real memory, but upon overflowing the stack the old part of it is swapped out to disk and the upper part in memory bubbled down to make new room, an effectively infinite stack can be emulated. With tail recursion emulating iteration, there is one big sweep of gobbling up more and more virtual stack, followed by one quick unwind of all that stack, thus very little thrashing, thus not too inefficient. When bubbling the stack, stack frames have to be updated, or else must reference virtual stack locations at the outset, but there seem to be no major problems. Has any implementation of any LISP whatsoever tried virtual infinite stacks? You'd be limited by the amount of available backing store, which is certainly not "effectively infinite," and could very easily be inadequate. E.g. assuming, say, 16 bytes per iteration of a loop, and a 200-megabyte backing store for the stack, a loop could only iterate less than 13 million times. More typically, a loop might take 64 bytes, and the backing store would be 30 meg, and you'd be limited to 500,000 iterations. NIL took this approach, but with the heap instead of with the stack (i.e. it had no GC), and it worked much better than I would have expected. But in general, far fewer things are allocated on the heap than on the stack, so I don't think that virtual memory, without either GC or early deletion, would work as well for a stack. Jonathan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 00:40:32 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jul 86 21:32:52 PDT Received: ID ; Sun 20 Jul 86 00:32:35-EDT Date: Sun, 20 Jul 1986 00:32 EDT Message-ID: From: Rob MacLachlan To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: get-setf-method takes optional environment argument In-reply-to: Msg of 19 Jul 1986 23:57-EDT from David C. Plummer Did we also decide DEFINE-SETF-METHOD needs to allow an &ENVIRONMENT argument to be able to effect this? DEFINE-SETF-METHOD has an &environment arg in Spice Lisp. I don't see any other way for hairy setf methods to get the environment. I believe that this particular issue was overlooked while the discussion was going on. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jul 86 00:08:03 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 19 Jul 86 20:58:18 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 21732; Sat 19-Jul-86 23:55:51 EDT Date: Sat, 19 Jul 86 23:57 EDT From: David C. Plummer Subject: get-setf-method takes optional environment argument To: common-lisp@SU-AI.ARPA Message-ID: <860719235739.4.DCP@FIREBIRD.SCRC.Symbolics.COM> I think we all agree (at least we seemed to last September or so) that get-setf-method needs to tkae an optional environment argument in order to correctly expand things. For example (defmacro foo (a b) `(aref ,a ,b)) (setf (ldb (byte 2 2) (foo (x) (y))) (z)) == (setf (ldb (byte 2 2) (aref (x) (y))) (z)) but, given the above defmacro is still the global definition (macrolet ((foo (a b) `(aref ,a 2 ,b))) ; added a 2 in the middle (setf (ldb (byte 2 2) (foo (x) (y))) (z))) should be == (setf (ldb (byte 2 2) (aref (x) 2 (y))) (z)) but given the descipiption in CLtL it has no way to see the macrolet'd definition of FOO, and will therefore expand incorrectly. Did we also decide DEFINE-SETF-METHOD needs to allow an &ENVIRONMENT argument to be able to effect this? xo  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jul 86 17:43:18 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Jul 86 14:18:23 PDT Date: 19 Jul 1986 17:17-EDT Sender: NGALL@G.BBN.COM Subject: Re: DECLARE SPECIAL Considered Confusing From: NGALL@G.BBN.COM To: Pavel.pa@XEROX.COM Cc: Moon@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]19-Jul-86 17:17:01.NGALL> In-Reply-To: <860711-184339-1110@Xerox> Date: 11 Jul 86 18:43 PDT From: Pavel.pa@Xerox.COM In this message I will give a complete description of my proposal for declaration scoping. I won't attempt to argue for it on the basis of ``obviousness'' or clarity, though, because I think that there are people who find each of the two ways of scoping special declarations confusing. Rather, I like this way of doing things because it satisfies an important (to me) consistency criterion: the scope of \any/ declaration coincides with a particular lexical identifier scope. I don't think you mean 'any' here; I think you mean 'any declaration that concerns the bindings of variables' (cf. pg. 154). You cannot mean 'any' since in the example below (let ((x 1)) (declare (inline foo)) (foo x)) the declaration does not 'coincide with a particular lexical identifier scope.' A more extreme example is (let (...) (declare (optimize ...)) ...) in which the declaration does not refer to ANY named entity. If we consider declarations that only concern the bindings of variables, we see that CLtL already agrees with your consistency criterion: "[Declarations] that concern variable bindings apply only to the bindings made by the form at the head of whose body they appear." (pg. 154) Thus by definition, the scope of the decl. is the scope of the binding. Thus in the following example of valid CL code (let ((x (oddp x))) (declare (type (member t nil) x)) ...) The declaration has no effect on the reference of x in the init form. Unfortunately, TYPE and IGNORE are the only decl specs that only concern bindings. SPECIAL concerns bindings also, but it also pervasively affects references (this is what you want changed). And FTYPE and INLINE simply confuse me. First of all, FTYPE is not explicitly stated to be a pervasive decl spec, I believe this is an omission. Secondly, there is this confusing sentence at the end of their descriptions: "Note that the rules of lexical scoping are observed; if one of the functions mentioned has a lexically apparent local definition (as made by FLET or LABELS), then the declaration applies to that local definition and not to the global definition." This makes it sound like FTYPE and INLINE are like SPECIAL: they concern bindings AND affect references (but not pervasively?). For example, (FLET ((zap (...)...(zap...)...)) (declare (inline zap)) ...) Is the call to zap in the local definition of zap affected by the declaration? My reading of CLtL and commonsense make me answer no. The call to zap is not a call to the local def. of zap, and according to my reading of the sentence quoted above, the decl. only affects references within the scope of the innermost binding of the name zap. But this interpretation depends upon not interpreting 'pervasively' as stated in CLtL. Is my interpretation correct? If so, it seems to me that FLET and INLINE already work in an intuitive manner. Consider the following example: (FLET ((zap () (zoop))) (declare (inline zoop)) ...) According to my reading of CLtL, the call to zoop IS affected by the declaration. And this makes sense to me. I could not tell from Pavel's proposal whether or not this would be true in his proposal. I propose the following change to CLtL (which pretty much agrees with both CLtL and Pavel): For all decl specs that concern named entities (and this includes all CLtL decl specs except OPTIMIZE (the DECLARATION decl spec doesn't really matter)), If the name mentioned in the decl spec of a declaration that appears at the beginning of a form in whose 'head' the name is bound, then the declaration affects that binding and all references within the binding's scope. Otherwise, if the name mentioned in the decl spec of a declaration that appears at the beginning of a form is not the name of a binding established by that form (this is just another way of stating what was stated in the antecedent of the above sentence), then the declaration does not affect any binding, but it affects all references in the entire form (from the open parenthesis to the close). In addition, the distinction between 'pervasive' and non-pervasive declarations should be flushed. It is a bogus distinction. Some examples should help clarify this: (let ((y x)) (declare (type list x)) ...x...) Both references to x are affected. This would be a new (upward compatible) feature (and a useful one I think). Note: Currently, TYPE is said to 'affect' only bindings. This is bogus. It also affects all references to the binding. This can be seen in many compilers when one references the binding incorrectly, e.g., (let ((x 1)) (declare (type integer x)) (car x)) (let ((x x)) (declare (type list x)) ...x...) Only the second reference to x is affected (since the first reference is not within the scope of the binding named by x. The binding of x is also affected (i.e., type checking may be done at binding/assignment time). This example is also valid for the SPECIAL dec spec. (let ((x 1)) (declare (type t x)) ... (let () (declare (type cons x)) (setf x (cons 1 2)) ...x...)) The 'reference' to x in the SETF form is affected by the second declaration only (as is the other reference). (let () (declare (ignore x)) ...x...) The reference to x is affected (The compiler should issue a warning that an ignored variable was referenced.). This kind of declaration might be useful in code generated by a macro to cause a check that user written code in the body does not reference certain 'reserved' specials. (FLET ((zap (...)...(zap...)...(zoop...)...)) (declare (function zap (...)...) (function zoop (...)...)) ...) The call to zap is not affected, but the call to zoop is. (LAMBDA (&optional (x x) (y (zap x))) (declare (type list x) (function zap...)) ...) Only the second ref. of x is affected. The call to zap if affected by the FUNCTION decl spec. Here comes the only new, incompatible (with some implementations:-) behaviour: (let ((x 'local)) (let ((x 'special) (y x)) (declare (special x)) ...)) The ref. to x is not affected by the declaration (x still refers to the lexical binding.). This is different from current CLtL semantics. (let ((x 1)) (let ((y x)) (declare (special x)) ...x...)) BOTH refs. to x ARE affected by the declaration. This is actually consistent with current CLtL semantics. Finally, decl specs that do not concern named entities (the only one in CL is OPTIMIZE), always affect all subforms within the form in which the decl spec is declared. I believe this proposal is complete, consistent, and simple to apply. Comments? -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jul 86 12:18:08 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jul 86 09:09:20 PDT Received: ID ; Sat 19 Jul 86 12:09:18-EDT Date: Sat, 19 Jul 1986 12:09 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Stride 440 User Cc: Common-Lisp@SU-AI.ARPA Subject: Question about the function DOCUMENTATION In-reply-to: Msg of 18 Jul 1986 11:46-EDT from Stride 440 User By my reading of the manual, an implementation is only required to support the five types of documentation specified. Allowing an arbitrary symbol to be used as the type argument to (SETF (DOCUMENTATION symbol doc-type)) is a nice extension, and most implementations get this for free, but it is neither required nor forbidden by anything currently in the manual. So both Lucid and DEC are in compliance on this. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jul 86 01:25:48 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 18 Jul 86 22:16:03 PDT Received: from umass-cs by csnet-relay.csnet id aq09670; 19 Jul 86 1:14 EDT Date: Fri, 18 Jul 86 10:46 EST From: Stride 440 User To: Common-Lisp@SU-AI.ARPA Subject: Question about the function DOCUMENTATION I have some questions about what the DOCUMENTATION function should do about "exotic" doc-types. Under VAXLISP (DEC's Common LISP for VMS) and on the TI Explorers' LISP, documentation strings are stored on a property list under a documentation property of the symbol (VAXLISP also has a text library for system supplied symbols and uses a special keyword symbol to flag the fact that the documentation is in the library). Neither system cares what doc-type is. Thus doc-type can be any symbol. Under Lucid's Common LISP for the SUN Workstation, only the five doc-types mentioned in the Common LISP manual are allowed. Lucid's Common LISP uses a structure with five hash tables to store the documentation strings. The manual lists five documentation types (variable, function, structure, type and setf), but does not say whether these are the only allowed types. My question is: Is it intended that only the five doc-types be allowed (in which case Lucid's Common LISP is correct) or merely the these five types are used by the standard DEFxxx special-forms/macros supplied by Common LISP and that user packages can add new documentation types as desired (in which case Lucid's Common LISP is wrong)? Robert Heller Heller@UMass-CS.CSNET  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jul 86 00:37:38 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jul 86 21:29:36 PDT Received: ID ; Sat 19 Jul 86 00:29:25-EDT Date: Sat, 19 Jul 1986 00:29 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Tail Recursion in Common Lisp ??? In-reply-to: Msg of 18 Jul 1986 18:46-EDT from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA I don't recall any suggestion that the current definition of Common Lisp does not allow tail-recursion optimization. How could a language definition possibly disallow it? OK, it was suggested that it was illegal to optimize a function that calls itself tail-recursively into a simple iteration that just jumps back to the start of the current function without checking for redefinition of the function in the meantime. The discussion was not about the legality of doing the jump instead of a full recursive call, but about whether the check was required. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 23:46:49 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 18 Jul 86 20:39:37 PDT Received: from tektronix by csnet-relay.csnet id am08979; 18 Jul 86 23:34 EDT Received: by tektronix.TEK (5.31/6.16) id AA11810; Fri, 18 Jul 86 15:43:47 PDT Received: by tekchips.TEK (5.31/6.16) id AA01359; Fri, 18 Jul 86 15:46:15 PDT Message-Id: <8607182246.AA01359@tekchips.TEK> To: common-lisp@SU-AI.ARPA Subject: Re: Tail Recursion in Common Lisp ??? Date: 18 Jul 86 15:46:13 PDT (Fri) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA ...does...Common Lisp require...tail recursion optimization ? No. It has even been suggested that the current definition does not allow tail-recursion optimization -- that's an issue we have to settle soon, and I hope that we'll be able to work out a solution in which this is allowed. -- Scott I recall a number of messages claiming that the current definition of Common Lisp makes tail recursion optimization difficult, and I recall that Kent Pitman pointed out that in (DEFUN FOO () (FOO)) the current value of FOO must be fetched before the tail-recursive call is performed (though this should have nothing to do with tail recursion optimization). I don't recall any suggestion that the current definition of Common Lisp does not allow tail-recursion optimization. How could a language definition possibly disallow it? -- Will Clinger  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 19:59:09 EDT Received: from IMSSS by SU-AI with PUP; 18-Jul-86 16:45 PDT Date: 18 Jul 1986 1410-PDT From: Rem@IMSSS Subject: No need to optimize tail recursion, use infinite virtual stack! To: COMMON-LISP@SU-AI If a finite segment of stack is in real memory, but upon overflowing the stack the old part of it is swapped out to disk and the upper part in memory bubbled down to make new room, an effectively infinite stack can be emulated. With tail recursion emulating iteration, there is one big sweep of gobbling up more and more virtual stack, followed by one quick unwind of all that stack, thus very little thrashing, thus not too inefficient. When bubbling the stack, stack frames have to be updated, or else must reference virtual stack locations at the outset, but there seem to be no major problems. Has any implementation of any LISP whatsoever tried virtual infinite stacks? -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 19:02:58 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 18 Jul 86 11:01:53 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 18 JUL 86 11:02:04 PDT Date: 18 Jul 86 11:01 PDT From: Masinter.pa@Xerox.COM Subject: Re: Tail Recursion in Common Lisp ??? In-reply-to: ...various messages ... To: Common-Lisp@su-ai.ARPA Message-ID: <860718-110204-6950@Xerox> Can we keep the discussion of tail recursion down to contributions that don't say some variation of the following: tail recursers: "its elegant & I learned about it in my scheme class & people who expect it will be unhappy" tail pushers: "when you're debugging its nice to see how you got there, and besides its hard to implement" message recursers: "Can we keep the discussion of tail recursion down to contributions that don't say some variation ...." (Sorry:-) Larry  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 19:02:38 EDT Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 18 Jul 86 10:58:08 PDT To: "Scott E. Fahlman" cc: Common-Lisp@su-ai.ARPA, cscott@bfly-vax.bbn.com Subject: Re: Tail Recursion in Common Lisp ??? In-reply-to: Your message of Fri, 18 Jul 1986 12:44 EDT. Date: 18 Jul 86 13:47:56 EDT (Fri) From: cscott@bfly-vax.bbn.com Naturally tail-recursion removal should not be allowed where it would change the semantics! On a multiprocessor, for example, if the semantics allow redefinition of a fun to affect a currently-running instance, then naturally there would have to be a check for such redefinition at the required point (presumably the application). Ditto if there is a redefinition of the fun in the body of the fun.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 19:02:26 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Jul 86 10:29:11 PDT Received: by Godot.Think.COM; Fri, 18 Jul 86 13:28:33 edt Message-Id: <8607181728.AA14934@Godot.Think.COM> To: "Scott E. Fahlman" Cc: Common-Lisp@su-ai.ARPA Subject: Re: Tail Recursion in Common Lisp ??? In-Reply-To: Your message of Fri, 18 Jul 1986 12:44 EDT. Date: 18 Jul 86 13:28:27 EDT (Fri) From: Bradley C. Kuszmaul Perhaps this has been mentioned before, but one way to think about tail recursion which allows the right thing to happen if the user modifies the definition of the function in the middle of running it is to do as follows: Do the tail recursion by "goto"'ing indirectly through the symbol's function cell (rather than by "goto"'ing directly to the location where the code happens to be). (Of course, the "goto" would reclaim the stack space of the current function call before allocating the stack space for the recursive call.) This allows the efficiency (mod one indirect pointer chase) of the classical tail recursion (i.e. it does not eat up stack), with the program illness of common-lisp (i.e. the semantics are preserved for dynamic redefinition of functions) Such a mechanism does screw up some debuggers, but we could argue that * Implementors who want good debuggers should not do tail recursion, or * Implementors should only do tail recursion if some appropriate declaration is made. Thus, there may be programming environment reasons (the debugger) for not doing tail recursion, but it is possible to efficiently support tail recursion even in the face of dynamic redefinition of function names. In fact, this approach allows all of the "tail calls" to be optimized by using the same "goto" mechanism, so mutually recursive functions which are defined and compiled separately could win. (One could even get rid of the extra pointer chase in the truly recursive case by stating that if an INLINE declaration is made for the function, then dynamic redefinition of the function is not allowed and a direct goto could be used.) -Brad  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 19:02:10 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jul 86 09:44:19 PDT Received: ID ; Fri 18 Jul 86 12:44:32-EDT Date: Fri, 18 Jul 1986 12:44 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: Tail Recursion in Common Lisp ??? In-reply-to: Msg of 18 Jul 1986 11:55-EDT from cscott at bfly-vax.bbn.com It is my belief, based on what I know of the constraints various groups feel they are working under, that there is no chance in hell that required tail-recusrion removal will be added to Common Lisp in the near future. There's just no point in discussing this further. If you want a guarantee that tail-recursion will be handled well, use Scheme or that subset of Common Lisps that are able to support this; if you want a guarantee that your code will be efficient in Common Lisp, use DO. I believe that tail-recursion removal will be ALLOWED in the final spec, though some groups read the current manual as requiring a full call, even from a function to itself, in case someone has installed a new definition for FOO in the middle of running FOO. We will discuss this and, I hope, find a set of rules under which tail-recursion removal is legal (but not required) unless the user has explicitly requested the full call. We will of course try to clearly document exactly what is allowed and what is required in this area, once this has been decided. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 19:01:54 EDT Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 18 Jul 86 09:03:08 PDT To: "David C. Plummer" cc: Common-Lisp@su-ai.ARPA Subject: Re: Tail Recursion in Common Lisp ??? In-reply-to: Your message of Thu, 17 Jul 86 22:38 EDT. <860717223819.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 18 Jul 86 11:55:17 EDT (Fri) From: cscott@bfly-vax.bbn.com I hope this issue has not been rehashed too many times -- I have not been reading this list for long. Scheme at MIT left out iterative constructs as a pedagogical exercise, both to show that it was practical and to force students (who are usually familiar with iterative constructs) to think recursively. Syntactic sugar for iteration (e.g. DO) appears in the new Scheme standard, and is acknowledged by most Scheme people to be a useful way of thinking about many problems. An implementation of Common Lisp that does not do tail recursion is just a bad implementation. Specifications of resource optimizations do not belong in the language spec; it is up to the buyers/users to be aware of the limitations of an implementation. Buying a Common Lisp which lacks tail recursion is like buying a car with a 2-pint gas tank -- it'll get you moving, but not too far. There is a legitimate worry here. If programmers believe (as ZetaLISP programmers do) that recursion is a bad thing because of resource constraints, they won't use one of the two most useful styles of programming in Lisp. Instead of putting a requirement in the language, the common wisdom should be that a Common Lisp without tail recursion (or a compiler, which should go much further in static analysis of resource usage) is not to be taken seriously. Then we can all assume it, much as C programmers assume at least 2K words of stack. Otherwise portable code will avoid it, and all Common Lisp programmers will be the poorer.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 17:54:12 EDT Received: from [128.89.0.157] by SU-AI.ARPA with TCP; 18 Jul 86 09:03:08 PDT To: "David C. Plummer" cc: Common-Lisp@su-ai.ARPA Subject: Re: Tail Recursion in Common Lisp ??? In-reply-to: Your message of Thu, 17 Jul 86 22:38 EDT. <860717223819.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 18 Jul 86 11:55:17 EDT (Fri) From: cscott@bfly-vax.bbn.com I hope this issue has not been rehashed too many times -- I have not been reading this list for long. Scheme at MIT left out iterative constructs as a pedagogical exercise, both to show that it was practical and to force students (who are usually familiar with iterative constructs) to think recursively. Syntactic sugar for iteration (e.g. DO) appears in the new Scheme standard, and is acknowledged by most Scheme people to be a useful way of thinking about many problems. An implementation of Common Lisp that does not do tail recursion is just a bad implementation. Specifications of resource optimizations do not belong in the language spec; it is up to the buyers/users to be aware of the limitations of an implementation. Buying a Common Lisp which lacks tail recursion is like buying a car with a 2-pint gas tank -- it'll get you moving, but not too far. There is a legitimate worry here. If programmers believe (as ZetaLISP programmers do) that recursion is a bad thing because of resource constraints, they won't use one of the two most useful styles of programming in Lisp. Instead of putting a requirement in the language, the common wisdom should be that a Common Lisp without tail recursion (or a compiler, which should go much further in static analysis of resource usage) is not to be taken seriously. Then we can all assume it, much as C programmers assume at least 2K words of stack. Otherwise portable code will avoid it, and all Common Lisp programmers will be the poorer.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 Jul 86 16:59:42 EDT Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 18 Jul 86 13:42:27 PDT Date: Fri 18 Jul 86 13:25:11-PDT From: James Rice Subject: Tail Recursion. To: Common-Lisp@SU-AI.ARPA Message-ID: <12223735614.56.RICE@SUMEX-AIM.ARPA> Given that it seems most unlikely that CL implementations will be required to support tail recursion optimisation, it also seems likely that we will be stuck with having to decorate function definitions, which we want to be compiled tail recursively if possible. Can I make a plea that this decoration, presumably some form of declaration, should a) be part of the standard, requiring and b) NOT be linked to such things as the Saftey switch, as it is in at least one implementation. Tail recursion optimisation is something quite orthogonal to generated code Safety. Perhaps (Declare (Optimize (Tail-Recursion))) would be ok. I feel strongly that using such things as InLine NotInLine to control such things, as was suggested a while back would be most unclear. Rice -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 22:51:14 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jul 86 19:38:54 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44661; Thu 17-Jul-86 22:38:24 EDT Date: Thu, 17 Jul 86 22:38 EDT From: David C. Plummer Subject: Tail Recursion in Common Lisp ??? To: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, Bernard S. Greenberg cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860717223819.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 17 Jul 1986 22:00 EDT From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Date: Thursday, 17 July 1986 10:53-EDT From: Bernard S. Greenberg If the spec -allows- tail-recursion optimization, and "my" implementation "supports" tail-recursion, then "I" can ... write a "tail-recursive" program, which ... will blow the stack of most certified implementations that do not "support" tail-recursion, and is thus, subtly, not portable. Which is why, even though tail recursion is an attribute of the implementation, it might be nice for the standard to say something on the issue (either a "yes, you can assume it" or "no, you can't.") A lot of people, at least at MIT, are learning Lisp via SCHEME, so they come out into the real world believing that tail recursion is a safe way to do things. There are some implementations that will drop out if they are forced to implement tail recursion. The standard argument revolves around programming environments and debugger information. Since I'm relatively new to the list, I'm not familiar with discussion of iteration constructs at all. I sat down to write a quickie Common Lisp program which used tail recursion, and was rather surprised when it blew up. The last form in the body was an IF, in which both branches called the toplevel function (I had hoped) tail-recursively. Can this kind of iteration be \nicely/ expressed other ways? Zetalisp's LOOP was able to give me what I wanted, expressed in a very different way. But since it's not part of the standard (and I dislike its non-LISPish syntax), I'd rather not use it. A rough example of the kind of thing I was doing: (defun remove (atom list) (labels ((remove-1 (remaining result) (cond ((endp remaining) result) ((eq (first remaining) atom) (remove-1 (cdr remaining) result)) (t (remove-1 (cdr remaining) (cons (first remaining) result)))))) (nreverse (remove-1 list '())))) Try (defun remove (atom list) (do ((rev-answer nil (if (eql (first remaining) atom) rev-answer (cons (first remaining) rev-answer))) (remaining list (cdr remaining))) ((endp remaining) (nreverse rev-answer)))) Somebody made the claim the other day, I think on this list, that if you had tail recursion you can do away with the "syntactic sugar" of iteration constructs. I'll claim that is somewhat bogus. The iteration constructs express an idea. They express iteration. Syntactic sugar embodies ideas and provides abstractions. Also, the iteration constructs can easily macroexpand into tail recursive calls if that's the way you want to implement them.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 22:11:29 EDT Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 17 Jul 86 19:00:28 PDT Date: Thu, 17 Jul 1986 22:00 EDT Message-ID: From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "Bernard S. Greenberg" Cc: Common-Lisp@SU-AI.ARPA Subject: Tail Recursion in Common Lisp ??? In-reply-to: Msg of 17 Jul 1986 10:53-EDT from Bernard S. Greenberg Date: Thursday, 17 July 1986 10:53-EDT From: Bernard S. Greenberg If the spec -allows- tail-recursion optimization, and "my" implementation "supports" tail-recursion, then "I" can ... write a "tail-recursive" program, which ... will blow the stack of most certified implementations that do not "support" tail-recursion, and is thus, subtly, not portable. Which is why, even though tail recursion is an attribute of the implementation, it might be nice for the standard to say something on the issue (either a "yes, you can assume it" or "no, you can't.") A lot of people, at least at MIT, are learning Lisp via SCHEME, so they come out into the real world believing that tail recursion is a safe way to do things. Since I'm relatively new to the list, I'm not familiar with discussion of iteration constructs at all. I sat down to write a quickie Common Lisp program which used tail recursion, and was rather surprised when it blew up. The last form in the body was an IF, in which both branches called the toplevel function (I had hoped) tail-recursively. Can this kind of iteration be \nicely/ expressed other ways? Zetalisp's LOOP was able to give me what I wanted, expressed in a very different way. But since it's not part of the standard (and I dislike its non-LISPish syntax), I'd rather not use it. A rough example of the kind of thing I was doing: (defun remove (atom list) (labels ((remove-1 (remaining result) (cond ((endp remaining) result) ((eq (first remaining) atom) (remove-1 (cdr remaining) result)) (t (remove-1 (cdr remaining) (cons (first remaining) result)))))) (nreverse (remove-1 list '())))) Thanks! Stever  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 17:08:21 EDT Received: from IMSSS by SU-AI with PUP; 17-Jul-86 13:57 PDT Date: 17 Jul 1986 1356-PDT From: Rem@IMSSS Subject: Expanding macros more than once? To: COMMON-LISP@SU-AI Perhaps the best course is to say "it is an error" to code a macro in such a way that it has different semantics different times it is expanded. Then implementors will be free to expand multiple times in interpretor and just once in compiler, or whatever other strategy they prefer, but writers of macros will have to carefully avoid writing number-of-expand dependent macros. This seems a better tradeoff than requiring all interpretors to expand macros just once. Further debate welcome... -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 15:50:10 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 17 Jul 86 12:39:16 PDT Date: 17 Jul 1986 15:37-EDT Sender: NGALL@G.BBN.COM Subject: APPEND and NCONC From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]17-Jul-86 15:37:50.NGALL> The doc for APPEND should be clarified to warn the user that APPEND can return a non-list, e.g., (append '() t) => t Also, the doc for NCONC should be clarified so that NCONC behaves analogously to APPEND when its last argument is an atom. -- Nick {Sorry if this is a repeat.}  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 12:17:00 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jul 86 09:01:48 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43923; Thu 17-Jul-86 11:57:30 EDT Date: Thu, 17 Jul 86 11:58 EDT From: Daniel L. Weinreb Subject: Tail Recursion in Common Lisp ??? To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860717115808.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Since the question of tail recursion comes up again and again, though, I think the spec ought to make some explicit mention of the policy of the language definition. The statement should indicate that if you write a program that recurses heavily, thinking that this is not consuming stack space due to tail recursion, you should be aware that not all implementations have this property and your program might not work. Yes, I agree that there are a million issues like this and we can't mention them all explicitly. In this case, though, it's worth a specific mention just because experience shows that many people wonder about it and ask (presumably because the presence of lexical scoping suggests other similarities with Scheme).  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 11:29:03 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Jul 86 08:14:24 PDT Received: ID ; Thu 17 Jul 86 11:11:58-EDT Date: Thu, 17 Jul 1986 11:11 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Bernard S. Greenberg" Cc: Common-Lisp@SU-AI.ARPA Subject: Tail Recursion in Common Lisp ??? In-reply-to: Msg of 17 Jul 1986 10:53-EDT from Bernard S. Greenberg "8/9 of this can of worms is below the surface". If the spec -allows- tail-recursion optimization, and "my" implementation "supports" tail-recursion, then "I" can, and most likely -will-, write a "tail-recursive" program, which is theoretically portable, but in fact, will blow the stack of most certified implementations that do not "support" tail-recursion, and is thus, subtly, not portable. There are a million issues like this. For example, Common Lisp will also allow theoretically portable programs that are 10 megabytes in size, and that will blow the memory on small, non-virtual-memory machines. We don't want to outlaw large programs or efficient compilers or any compilation technique that leads to more effective use of resources just because not everyone will have it and someone might be screwed by that. Portability is an important goal of Common Lisp, but not the only goal. The best we can do in this case is to spell out clearly what is allowed and what is required, and let programmers decide whether they want to depend on non-required efficiency mechanisms, knowing that not all machines will have them. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 Jul 86 11:08:28 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 17 Jul 86 07:54:27 PDT Received: from SORA.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43826; Thu 17-Jul-86 10:54:04 EDT Date: Thu, 17 Jul 86 10:53 EDT From: Bernard S. Greenberg Subject: Tail Recursion in Common Lisp ??? To: Fahlman@C.CS.CMU.EDU, Parker.es@XEROX.COM cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860717105303.8.BSG@SORA.SCRC.Symbolics.COM> Date: Wed, 16 Jul 1986 15:47 EDT From: "Scott E. Fahlman" ok, ok, my question was sloppily worded. does the definition of Common Lisp require that all implementations have tail recursion optimization ? No. It has even been suggested that the current definition does not allow tail-recursion optimization -- that's an issue we have to settle soon, and I hope that we'll be able to work out a solution in which this is allowed. -- Scott "8/9 of this can of worms is below the surface". If the spec -allows- tail-recursion optimization, and "my" implementation "supports" tail-recursion, then "I" can, and most likely -will-, write a "tail-recursive" program, which is theoretically portable, but in fact, will blow the stack of most certified implementations that do not "support" tail-recursion, and is thus, subtly, not portable.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 23:53:43 EDT Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 16 Jul 86 20:43:01 PDT Date: Wed 16 Jul 86 20:43:25-PDT From: Hiroshi "Gitchang" Okuno Subject: RE: easier addressing for EuLISP discussions To: common-lisp@SU-AI.ARPA Message-ID: <12223291104.51.OKUNO@SUMEX-AIM.ARPA> > If demand is sufficient, it may also be worth inaugurating a North > American EuLISP discussion distribution in the same way, in order to > cut down on transatlantic traffic. I agree to this proposal. I think that the mailing list inside each country should be maintained by each country, because it will reduce the international communication costs drastically. In Japan, the Common-Lisp bboard is distributed by NTT. - Gitchang - P.S. utah-cs.edu is wrong, because its official name is utah-cs.arpa or utah-cs (without edu) at sumex-aim.stanford.edu - maybe at NIC. -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 18:11:10 EDT Date: 16 Jul 86 1421 PDT From: Dick Gabriel Subject: Object-oriented-Programming Meeting at L&FP To: Common-Lisp@SU-AI.ARPA There will be an Object-Oriented Programming Meeting at 2:00 PM, Wednesday August 6 in the Kresge Little Theater, which is right downstairs from Kresge Auditorium, site of the Lisp Conference technical sessions. -rpg-  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 17:44:11 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 16 Jul 86 14:20:54 PDT Received: from ux63.bath.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a002004; 15 Jul 86 22:04 BST Date: 15 Jul 1986 22:03:30-GMT From: bond!m42!jap%ux63.bath.ac.uk@Cs.Ucl.AC.UK To: common-lisp <@Cs.Ucl.AC.UK:common-lisp@su-ai.arpa> >From m42!jap Tue Jul 15 21:22:27 1986 remote from bond Received: by bond.UUCP (4.12/4.7) id AA15560; Tue, 15 Jul 86 21:22:27 bst Received: by m42.UUCP (4.12/4.7) id AA07132; Tue, 15 Jul 86 21:15:09 bst Date: Tue, 15 Jul 86 21:15:09 bst From: bond!m42!jap (Julian Padget) Message-Id: <8607152015.AA07132@m42.UUCP> To: bond!bath63!common-lisp%su-ai.arpa@uk.ac.ucl.cs Subject: easier addressing Thanks to the assistance of the folks in Utah, it might now perhaps be easier for people in the US to get mail to eulisp (and to tender requests for addition to the distribution). There is now an alias eulisp@utah-cs.edu (at least I presume it is edu these days) which will pass mail on to the bboard at INRIA, in addition there is the alias eulisp-request@utah-cs.edu (same caveat) which will forward requests to Je'ro^me Chailloux who is the bboard maintaniner. If demand is sufficient, it may also be worth inaugurating a North American EuLISP discussion distribution in the same way, in order to cut down on transatlantic traffic. --Julian.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 16:53:28 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 Jul 86 13:31:12 PDT Received: from tektronix by csnet-relay.csnet id aj04469; 16 Jul 86 15:55 EDT Received: by tektronix.TEK (5.31/6.16) id AA20872; Wed, 16 Jul 86 11:19:15 PDT Received: by tekchips.TEK (5.31/6.16) id AA28807; Wed, 16 Jul 86 11:21:39 PDT Message-Id: <8607161821.AA28807@tekchips.TEK> To: common-lisp@SU-AI.ARPA Subject: Re: Definition time macros Organization: Tektronix, Inc., Beaverton, OR. Date: 16 Jul 86 11:21:37 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA From: David A. Moon From: Kent M Pitman From: "Scott E. Fahlman" From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU I'd like to see this tightened up to indicate that macros expand once, as in a compiler, and are not expanded over and over each time an expression is interpreted. I feel very strongly that requiring this is a bad idea. I feel very strongly that requiring this would be a very good idea. I think Scheme has a big lesson to teach us here. They have made lexical analysis occur at a well-defined time and it has made program-understanding a much more straightforward issue. But they can't even agree among themselves what the semantics of macros should be! It's useful to distinguish between agreement on what the semantics should be, what the semantics will be, and what the semantics is. The designers of Common Lisp clearly don't agree on what the semantics of macros should be, are trying to agree on what the semantics will be, and are fairly well agreed on what the semantics is. Thanks to Common Lisp, the designers of Scheme felt free to worry about what the semantics should be instead of worrying about a stopgap. When Kent mentioned Scheme, he may have been thinking of the design principle that the semantics of the language must make sense independently of any strategies that might be used to implement it. To paraphrase Guy Steele: If, in the course of discussing a proposed language feature, such terms as "interpreter", "compiler", or "macro expansion time" come up, they serve as a warning! For example, if a language feature doesn't make sense in an implementation that doesn't have an interpreter, then the feature should be considered only for inclusion in the programming environment section. This is analogous to saying that a language feature that doesn't make sense in an implementation that doesn't have a garbage collector should be included, if at all, only in the programming environment section. If the semantics were defined so that macros were expanded only once, then implementors of programming environments could: 1. Let users see the macro-expanded code. 2. Do the work necessary to keep users from seeing code they didn't write. (There's a continuum between 1 and 2, fortunately.) 3. Expand macros multiple times and advertise the bug as a feature. The main difference between this and the status quo is that the status quo has such a poorly defined semantics that implementors can expand macros multiple times and advertise the bug as a feature without having to admit that it's a bug. Neat trick. William Clinger Tektronix Computer Research Laboratory  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 16:05:39 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jul 86 12:49:28 PDT Received: ID ; Wed 16 Jul 86 15:48:02-EDT Date: Wed, 16 Jul 1986 15:47 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: James Parker Cc: Common-Lisp@SU-AI.ARPA Subject: Tail Recursion in Common Lisp ??? In-reply-to: Msg of 16 Jul 1986 15:41-EDT from James Parker ok, ok, my question was sloppily worded. does the definition of Common Lisp require that all implementations have tail recursion optimization ? No. It has even been suggested that the current definition does not allow tail-recursion optimization -- that's an issue we have to settle soon, and I hope that we'll be able to work out a solution in which this is allowed. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 15:57:12 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 16 Jul 86 12:41:59 PDT Received: from Gamay.ms by ArpaGateway.ms ; 16 JUL 86 12:41:58 PDT Date: 16 Jul 86 12:41:52 PDT (Wednesday) Subject: Re: Tail Recursion in Common Lisp ??? In-reply-to: <8607161918.AA20027@utah-orion.ARPA> To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) From: James Parker cc: Common-Lisp@SU-AI.ARPA, James Parker Message-ID: <860716-124158-4659@Xerox> stan, > Tail recursion optimization . . . is a property of an implementation. ok, ok, my question was sloppily worded. does the definition of Common Lisp require that all implementations have tail recursion optimization ? James  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 14:31:45 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 16 Jul 86 11:19:28 PDT Received: from Gamay.ms by ArpaGateway.ms ; 16 JUL 86 10:50:53 PDT Date: 16 Jul 86 10:50:48 PDT (Wednesday) Subject: Tail Recursion in Common Lisp ??? To: Common-Lisp@SU-AI.ARPA From: James Parker cc: James Parker Message-ID: <860716-105053-4517@Xerox> please excuse my ignorance. i'm learning Lisp from Abelson & Sussman, and my Common Lisp book by Steele hasn't arrived yet. does Common Lisp have tail recursion like Scheme, so that the syntatic sugar for iterative loops is unnecessary ? if not, then is it being considered ? James  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 11:33:31 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Jul 86 08:22:42 PDT Received: ID ; Wed 16 Jul 86 11:21:25-EDT Date: Wed, 16 Jul 1986 11:21 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Rob MacLachlan Cc: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of 16 Jul 1986 02:12-EDT from Rob MacLachlan I thought about allowing the inhibition if SAFETY < SPEED, but one might also want to suppress the error checking to get more compact code or even faster compilation, so the set of all the relative conditions gets pretty hairy. That's why I picked absolute safety values for enabling these checks. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 02:22:07 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 23:13:32 PDT Received: ID ; Wed 16 Jul 86 02:12:26-EDT Date: Wed, 16 Jul 1986 02:12 EDT Message-ID: From: Rob MacLachlan To: Proposal #1 (OPTIMIZE SAFETY)@C.CS.CMU.EDU Cc: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of 13 Jul 1986 21:03-EDT from Scott E. Fahlman I have some comments regarding the interpretation of the optimize declaration. I believe that the best way to use the optimize information is to compare the values for different qualities. This is because the decisions made by the compiler almost always are trade-offs. You can trade speed for space and compilation speed for speed, but absolute levels of optimization seem fairly meaningless. It makes more sense to me to say that optional error checks would be inhibited whenever SAFETY < SPEED. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 01:35:56 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 15 Jul 86 22:23:13 PDT Received: from umass-cs by csnet-relay.csnet id bf16484; 16 Jul 86 1:15 EDT Date: Tue, 15 Jul 86 14:48 EST From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Function-Parameter-names I can imagine someone trying to write an editor in portable CL who would want to use function-parameter-names to provide the user with some documentation. The list of symbols would be more valuable than a describe-function-parameters function, because it allows the editor to choose a format that fitwhere it has to. This can be important, because many editors (i.e. Emacs &friends) devote most of the sceen to displaying text leaving only a small area in which messages have to appear. ANother use for the symbols themselves is to check for declarations. A code walker might not have access to the source code for a function, but it could determine if any of the arguments are special variables or something. Chris Eliot  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 Jul 86 01:29:16 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 15 Jul 86 22:16:42 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42046; Tue 15-Jul-86 17:49:52 EDT Date: Tue, 15 Jul 86 17:48 EDT From: David A. Moon Subject: Definition time macros To: Kent M Pitman cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <860715154038.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <860715174829.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 15 Jul 86 15:40 EDT From: Kent M Pitman Date: Tue, 15 Jul 1986 14:55 EDT From: "Scott E. Fahlman" Date: 15 Jul 86 12:07-EDT From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU I'd like to see this tightened up to indicate that macros expand once, as in a compiler, and are not expanded over and over each time an expression is interpreted. I feel very strongly that requiring this is a bad idea. I feel very strongly that requiring this would be a very good idea. I think Scheme has a big lesson to teach us here. They have made lexical analysis occur at a well-defined time and it has made program-understanding a much more straightforward issue. But they can't even agree among themselves what the semantics of macros should be!  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 23:50:07 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 20:40:06 PDT Received: ID ; Tue 15 Jul 86 23:39:00-EDT Date: Tue, 15 Jul 1986 23:38 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Feh! Proposal 4 is still on the list of things that will come before the technical committee, but I personally no longer support it. It was a very marginal idea anyway, with practically no uses in portable code. I thought that if we could all agree on a reasonable format for returning the names of the functions, whenever they are available, it might be of some use to have a standard interface to this feature. As it stands, we've got several different proposals on how to do this, each of which seems to be best on some system or other, plus people who don't think it's a good idea to peek inside the black box surronding a function's implementation. I now believe we should forget this proposal and move on to other issues of more importance. Users who want to get at a function's argument list will just have to learn how their local system encodes this information, if it does so at all. I still support proposals 1, 2, and some form of 3. (I don't care much whether it's 3A or 3B.) -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 21:59:33 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 18:48:47 PDT Received: ID ; Tue 15 Jul 86 21:47:43-EDT Date: Tue, 15 Jul 1986 21:47 EDT Message-ID: From: Rob MacLachlan To: Masinter.pa@XEROX.COM Cc: common-lisp@SU-AI.ARPA Subject: Proposals 2, 3, & 4 In-reply-to: Msg of 15 Jul 1986 21:04-EDT from Masinter.pa at Xerox.COM Date: Tuesday, 15 July 1986 21:04-EDT From: Masinter.pa at Xerox.COM To: common-lisp at SU-AI.ARPA Re: Proposals 2, 3, & 4 ...Furthermore, this example seems to contradict the assertion that the "semantics of the language require the storage of the information returned by FUNCTION-PARAMETERS, so every implementation must have some way to access this information." unless access of the information were to parse the disassembly of the definition somehow. In this case, the information is in fact stored in the code. I think that it is reasonable to peek at stylized entry code to determine this information. Although the fixed and optional arg counts are directly represented in Spice Lisp, we would have to do some work to find out the valid keywords. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 21:37:20 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 18:25:27 PDT Received: ID ; Tue 15 Jul 86 21:23:41-EDT Date: Tue, 15 Jul 1986 21:23 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Alan Snyder Cc: common-lisp@SU-AI.ARPA Subject: Definition time macros In-reply-to: Msg of 15 Jul 1986 19:47-EDT from Alan Snyder I think the idea of definition-time macro expansion should be explored; the result might be worthwhile. Well, I'm not against exploration. The H-P system does Defun-time macro-expansion in the interpreter, so you're in an ideal position to explore this, and H-P probably ought to be working on the problems you mention: redefinition of macros and true source-level debugging. Whenever this stuff is ready, let us know; due to H-P's generosity, a lot of us will be in a position to try the resulting system and see if we do indeed like it better than the current chaotic way of handling macros. We can also see just how much work was required to solve the problems, and whether it makes sense to require every implementation install similar facilities. We probably should not hold up the rest of the language design until we've seen how this exploration comes out. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 21:20:26 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 15 Jul 86 18:05:21 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 86 18:04:53 PDT Date: 15 Jul 86 18:04 PDT From: Masinter.pa@Xerox.COM Subject: Proposals 2, 3, & 4 to: common-lisp@SU-AI.ARPA Message-ID: <860715-180453-3747@Xerox> Argument lists in Interlisp are used for two purposed. One is for applications that want a descriptive form, for printing out arguments on the stack and in the editor; the other is for applications that need an accurate list for advise, break and the like. For most functions, the values returned are the same, but in some situations, the descriptive arguments differ by being more elaborate, having elipsis, arguments that aren't described (e.g., "secret" optionals). The language design principle that we have to be careful about with this is that we want to retain some amount of modularity around exactly how a function is implemented. Currently (defun foo (a) ...) is equivalent to (defun foo (&rest args) (if (> (length args) 1) (error 'too-many-arguments ...)) (if (< (length args) 1) (error 'too-few-arguments ...)) (let ((a (car args))) ...) Nothing so far in the language description prohibits that equivalence: you can't "look inside" functions once they've been defined. We're now adding something to the language that makes that equivalence no longer valid, because you can tell what the parameter list is. Furthermore, this example seems to contradict the assertion that the "semantics of the language require the storage of the information returned by FUNCTION-PARAMETERS, so every implementation must have some way to access this information." unless access of the information were to parse the disassembly of the definition somehow. Interlisp has had an ARGLIST function which gives you back the argument list of a function, but ARGLIST is really part of the *environment* rather than part of the *language*. I would feel much more comfortable with all of these proposals if they were somehow classified as that part of the environment that Common Lisp standardized on. This isn't bad. Despite its title, CLtL directly contains a number of functions and features that are logically part of an environment rather than part of the language, in part so that people can write portable environment tools. Things like the stepper, evalhook, room, trace, the description of the top level loop, the +, ++, +++ variables, etc. are all part of Common Lisp the Environment. While there are many parts of the environment that we will find difficulty agreeing upon, those features for which "most implementations have something like this" are good candidates. We've identified a number of potentially portable environment tools which could make good use of a well-defined function-argument-list access method. Some specific comments on Proposal 2,3,4, given that they are part of "environment" rather than "language": There are two uses for argument lists in Interlisp: "accurate" argument information for program-modifying programs like ADVISE and BREAK, and "descriptive" argument information for program-creation-and-debugging-aid programs like the debugger and what-are-the-arguments-to-the-function-I'm-typing. For many objects of examination these are the same, but not always. Macros and special forms might have "descriptive" arguments, for example; its as valid to ask about format of macro calls as it is function calls. In some cases, the descriptive arguments contain sequences (X1 ... XN) while the "real" argument list is (the Interlisp equivalent of) &REST. The differing requirements of these two applications have caused most of the polarization of the discussion. I will attempt a specific proposal that I think addresses the needs independently.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 20:01:52 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 15 Jul 86 16:49:53 PDT Received: from hplsny by hplabs.HP.COM ; Tue, 15 Jul 86 16:47:43 pdt Received: by hplsny ; Tue, 15 Jul 86 16:48:01 pdt From: Alan Snyder Message-Id: <8607152348.AA01682@hplsny> Date: Tue, 15 Jul 86 16:47:49 PDT Subject: Re: Definition time macros To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 15-Jul-86 18:18:00 X-Mailer: NMail [$Revision: 2.5 $] No doubt about it, one can develop a cleaner semantics for a language without an interpreter. Cleaner still is to require all of the code to be presented at one time so that it can be compiled into a block and so that everything can be checked statically -- none of this incremental stuff. There are already lots of languages like that, and I'd hate to see Common Lisp become one of them. OK, this exaggerates your position, but I think that expanding macros just once, at "enclose time" is a step in that direction. The package system is another step in that same direction (I can't write a call to a function in another package unless the package has already been defined); is it too late to take back the package system? Common Lisp straddles the fence regarding easy incremental change versus static checking and efficiency; the result is that interpreter/compiler consistency is still a mess. I think the idea of definition-time macro expansion should be explored; the result might be worthwhile. Two problems have been mentioned: propagating the effects of redefining a macro, and source-code debugging. I believe (without proof) that these problems can be effectively solved in a development environment (a delivery vehicle might choose not to solve these problems). Dependency chains can be used to propagate changes. The expanded code can be annotated to indicate its relationship with the source code. Alan -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 19:31:33 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 16:17:37 PDT Received: ID ; Tue 15 Jul 86 19:16:02-EDT Date: Tue, 15 Jul 1986 19:15 EDT Message-ID: From: Rob MacLachlan To: franz!fizzy!jkf@KIM.BERKELEY.EDU Cc: common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU Subject: Proposals 2, 3, & 4 In-reply-to: Msg of 15 Jul 1986 10:56-EDT from franz!fizzy!jkf at kim.berkeley.edu Date: Tuesday, 15 July 1986 10:56-EDT From: franz!fizzy!jkf at kim.berkeley.edu To: Scott E. Fahlman cc: common-lisp at su-ai.arpa Re: Proposals 2, 3, & 4 Actually storing the & keywords in the list saves space overall since it then doesn't require you to have fixed, normally empty, slots to hold rest, optional and key symbols. The point is that nearly all implementations will already have the arg count information stored in some other way so that their call mechanisms can work. It is desirable to separate the mandatory semantics of the call interface from the informational content of parameter names. For debugging interpreted code you would like the symbol for each of the formal parameters since that would permit the debugger to poke through the lexical environment an locate the current value of that argument. [You can imagine cases where using a string for the name would be ambiguous.] If symbols are to be used for interpreted code, then using strings for compiled code would be a pain. Debuggers are blatently non-portable anyway. I question that there is any use for paramater names in portable code other than simple display. A debugger is certainly not an example of such a use. >> The debugging-type >> things I had in mind would get along just fine with strings, and symbols >> cost considerably more in storage. Most people tend to use the name parameter names over and over again. Recall that for the 627 functions in our lisp package, the total length of the parameter description lists is 1510. There are only 248 unique symbols in that list of 1510. I think that in this case saving the parameters as symbols saves a significant amount of space over saving the parameters as strings (unless you simulate a package by creating a hash table of parameter name strings, in which case it is hard to say which is more space efficient, it depends on how many of those 248 symbols would have existed anyway). This argument is plausible, but incorrect. Changing to a string representation in Spice Lisp significantly reduced storage. This is partly due to the use of a single string for the entire argument list. Some sharing of strings also exists, since our fasl dumper makes equal strings EQ, thus making identical strings in the same file EQ. It is also significant that boxed symbol, package and list storage was replaced with unboxed string storage. This change eliminated >1000 (10%) of the symbols in our core image. I think that using the arglist to indicate argument info is silly unless the paramater names are required to be right, and that it is unreasonable to require the names to be stored. The semantics of the language require the storage of the information returned by FUNCTION-PARAMETERS, so every implementation must have some way to access this information. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 18:42:19 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 15:20:23 PDT Received: ID ; Tue 15 Jul 86 18:18:46-EDT Date: Tue, 15 Jul 1986 18:18 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Kent M Pitman Cc: Common-Lisp@SU-AI.ARPA Subject: Definition time macros In-reply-to: Msg of 15 Jul 1986 15:40-EDT from Kent M Pitman No doubt about it, one can develop a cleaner semantics for a language without an interpreter. Cleaner still is to require all of the code to be presented at one time so that it can be compiled into a block and so that everything can be checked statically -- none of this incremental stuff. There are already lots of languages like that, and I'd hate to see Common Lisp become one of them. OK, this exaggerates your position, but I think that expanding macros just once, at "enclose time" is a step in that direction. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 16:02:10 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 15 Jul 86 12:41:34 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41906; Tue 15-Jul-86 15:42:13 EDT Date: Tue, 15 Jul 86 15:40 EDT From: Kent M Pitman Subject: Definition time macros To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: References: The message of 15 Jul 86 12:07-EDT from mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Message-ID: <860715154038.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue, 15 Jul 1986 14:55 EDT From: "Scott E. Fahlman" Date: 15 Jul 86 12:07-EDT From: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU I'd like to see this tightened up to indicate that macros expand once, as in a compiler, and are not expanded over and over each time an expression is interpreted. I feel very strongly that requiring this is a bad idea. I feel very strongly that requiring this would be a very good idea. I think Scheme has a big lesson to teach us here. They have made lexical analysis occur at a well-defined time and it has made program-understanding a much more straightforward issue. For example, in the current state of confusion, the fact that there is no definite time at which macro expansion occurs means that (DEFUN FOO (X) (IF X (BAR) (BAR))) can have its behavior depend on X in interpreted code but not compiled (assuming BAR is a macro that does not expand into a reference to X), especially if runtime macro caching is being done. This could be baffling to naive users and is quite irritating to some of us sophisticated users. I also believe there are a number of glaring uglinesses in the language which can be fairly directly attributed to the decision to not have a well-defined ENCLOSE time. Among these are the assymetry between interpreted and compiled "#," and the weird definition of EVAL-WHEN. I could and would make proposals to improve/fix both of these problems if we had a well-defined ENCLOSE time. All linguistic issues aside, it's also the case that since implementations are currently free to vary on this, the debugging skills a programmer learns in one implementation may not carry over to another. In fact, those skills may work against the programmer if he has a mindset that leads him to make assumptions as in the case of the FOO definitino above which don't pan out.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 15:07:41 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 11:57:36 PDT Received: ID ; Tue 15 Jul 86 14:56:06-EDT Date: Tue, 15 Jul 1986 14:55 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: mike%gold-hill-acorn@LIVE-OAK.LCS.MIT.EDU Cc: common-lisp@SU-AI.ARPA Subject: Definition time macros In-reply-to: Msg of 15 Jul 1986 12:07-EDT from mike%gold-hill-acorn at mit-live-oak.arpa I'd like to see this tightened up to indicate that macros expand once, as in a compiler, and are not expanded over and over each time an expression is interpreted. I feel very strongly that requiring this is a bad idea.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 13:47:41 EDT Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 10:31:06 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 4237; 15 Jul 86 13:27:48-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 29030; Tue 15-Jul-86 11:09:44-EDT Date: Tue, 15 Jul 86 11:07 EST Sender: mike%gold-hill-acorn@mit-live-oak.arpa To: kessler%utah-orion@utah-cs.arpa (Robert Kessler) From: mike%gold-hill-acorn@mit-live-oak.arpa Subject: Definition time macros Cc: common-lisp@su-ai.arpa Date: Mon, 14 Jul 86 20:32:27 MDT From: kessler%utah-orion@utah-cs.arpa (Robert Kessler) I also believe in the CL goal of the exact same semantics between the compiler and interpreter. Its hard enough teaching students Lisp when you also have to discuss the grungy details of the differences between compiled and interpreted code. However, one big hole in the CL scheme is that it is not specified that all macros must expand at definition time. That is the only way that one can force the same semantics. 1) Does CL say anything that forbids a system from expanding macros at function definition time? I think not. 2) Would it be reasonable to add this requirement to the standard? ........ Bob. On page 143 of CLtL, paragraph 4 indicates that a compiled semantics for macros is valid also for interpreted code, but it also states that "an implementation has great latitude in deciding exactly when to expand macro calls within a program". I'd like to see this tightened up to indicate that macros expand once, as in a compiler, and are not expanded over and over each time an expression is interpreted. In the interpreter they need not expand at definition time, but can expand at first evaluation using a "splicing macro" technique. ...mike beckerle Gold Hill Computers  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 12:15:03 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 15 Jul 86 09:03:42 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41634; Tue 15-Jul-86 12:04:38 EDT Date: Tue, 15 Jul 86 12:03 EDT From: Daniel L. Weinreb Subject: Re: GC, exit-to-system To: franz!fizzy!jkf@kim.berkeley.edu cc: common-lisp@SU-AI.ARPA In-Reply-To: <8607142240.AA10690@fizzy> Message-ID: <860715120338.5.DLW@CHICOPEE.SCRC.Symbolics.COM> The problem is that GC works so differently from one implementation to the next. If someone would try to make an explicit proposal for the addition of a GC function, I think this would become clear. Exactly what is the new proposed GC function supposed to do? Exactly what are the criteria by which I could know whether my Common Lisp implementation was in conformance with the spec regarding GC, or not? Can a spec be written that is specific enough that a program could usefully depend on the GC function in any way, without being so specific that some implementations could not conform to it reasonably? I don't think so. In order for the Common Lisp specification to include a GC function, the Common Lisp specification must include a concept of garbage collection: what it means, what it is defined to do and not do, etc. The function isn't really the hard part; the concept is the hard part. I feel the same way about the BYE function. Common Lisp would need a concept of "returning to the operating system" or something like that. Some implementations do not have any such thing. It is out of the scope of Common Lisp. The only way I can imagine that such functions would be acceptable would be if their definition said something like "In some implementations, this function is allowed to do absolutely nothing". They would therefore have to be considered part of a "user interface" rather than part of the language, since no portable program could sensibly call them. I think we should try to confine ourselves to the language business. We have more than enough work ahead of us in that department!  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 12:06:15 EDT Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 15 Jul 86 08:54:30 PDT Received: by kim.Berkeley.EDU (5.53/1.14) id AA27495; Tue, 15 Jul 86 08:55:24 PDT From: franz!fizzy!jkf@kim.berkeley.edu Received: from fizzy by franz (5.5/3.14) id AA05730; Tue, 15 Jul 86 07:56:34 PDT Received: by fizzy (4.12/3.14) id AA11721; Tue, 15 Jul 86 07:56:06 pdt Return-Path: Message-Id: <8607151456.AA11721@fizzy> To: "Scott E. Fahlman" Cc: common-lisp@su-ai.arpa Subject: Re: Proposals 2, 3, & 4 In-Reply-To: Your message of Mon, 14 Jul 86 21:46:00 EDT. Date: Tue, 15 Jul 86 07:56:04 PDT >> Your proposal may be a good alternative to proposal 4. It takes a bit >> of extra storage to put the & keywords into the list, but probably not >> enough to matter. Actually storing the & keywords in the list saves space overall since it then doesn't require you to have fixed, normally empty, slots to hold rest, optional and key symbols. >> A question facing both your proposal and proposal 4 is whether we should >> save the parameter names as symbols or as strings. You seem rather >> certain that symbols, in the proper package, are necessary. Do you have >> some application in mind where this would matter? Since a formal parameter can be a special variable, a string naming the special variable is ambiguous without the package information. For debugging interpreted code you would like the symbol for each of the formal parameters since that would permit the debugger to poke through the lexical environment an locate the current value of that argument. [You can imagine cases where using a string for the name would be ambiguous.] If symbols are to be used for interpreted code, then using strings for compiled code would be a pain. >> The debugging-type >> things I had in mind would get along just fine with strings, and symbols >> cost considerably more in storage. Most people tend to use the name parameter names over and over again. Recall that for the 627 functions in our lisp package, the total length of the parameter description lists is 1510. There are only 248 unique symbols in that list of 1510. I think that in this case saving the parameters as symbols saves a significant amount of space over saving the parameters as strings (unless you simulate a package by creating a hash table of parameter name strings, in which case it is hard to say which is more space efficient, it depends on how many of those 248 symbols would have existed anyway). >> I still think that we should keep FUNCTION-PARAMETERS and maybe >> FUNCTION-PARAMETER-RANGE as they are defined in the proposals 2 and 3. >> A lot of implementations have this information represented in their >> function objects in ways which are carefully optimized for quick access >> at function-call time. What you're saying is that one implementation's primitive is another implementation's higher level function. I agree. We can't force everyone to use the same primitive at this stage. I suggest this solution: 1. The language specification should pick the simplest primitive (which I believe is the argument list that I proposed) and write the other function-parameter-whatever functions in terms of that primitive. [This adds one more function to the proposed list of function parameter functions you proposed] 2. implementions are free to write any of the functions in terms of any of the other functions, and they are encouraged to make each function-parameter-whatever function as cheap to execute as possible (e.g. use caching for those functions that must do some work). - john foderaro Franz Inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 11:05:06 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 15 Jul 86 07:51:38 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA06933; Tue, 15 Jul 86 08:51:30 MDT Received: by cons.ARPA (4.30/4.40.2) id AA13707; Tue, 15 Jul 86 08:54:44 mdt Date: Tue, 15 Jul 86 08:54:44 mdt From: kessler%cons@utah-cs.arpa (Robert R. Kessler) Message-Id: <8607151454.AA13707@cons.ARPA> To: Fahlman@c.cs.cmu.edu Cc: common-lisp@su-ai.arpa In-Reply-To: "Scott E. Fahlman"'s message of Tue, 15 Jul 1986 10:36 EDT Subject: Definition time macros >I've been discussing the desirabilty of doing DEFUN-time expansion and >other source-level transforms with some of the H-P people since I >started using their system. In my view, the only reason to have an >interpreter around at all is that it is much easier to debug code if it >is still more or less what you wrote. Once the proverbial clever >compiler has come in and changed everything beyond recognition, you may >as well let it go ahead and finish compiling. Just doing the expansions >and source-level transforms gets you the worst of both worlds: the code >is unreadable, but not fast. > This is a good point that I had not considered. I agree that its important to have interpreted code present (one of the big loses of the ExperLisp system on the Macintosh is that its compiler only - that makes debugging very difficult). >... > >So it is a desirable goal to have interpreted code exactly match >compiled code, but it is also a desirable goal to have a good >source-language debugging environment in the interpreter. It's a >trade-off. In my experience, the differences introduced by expanding >macros at execution time, rather than definition time, are not >troublesome in practice and are not the kind of thing that a beginner is >going to run into. I can only say that in quite a number of times in teaching Lisp, I have seen the students "discover" that one can do anything one wants in a macro and invariably screw themselves. I think that some of it may be legitimate because of the lack of Fexprs. They don't seem to realize that its easy to write a macro to quote the arguments that then calls the auxillary function. As students typically do, they look for the short cut and combine it all into one macro. sigh... > ... (Actually, that statement assumes that the compiler >does macro-expansion and then code generation in the same recursive >descent. If all of the source-level transforms are done in a pre-pass, >as H-P likes to do, you can get some more glaring discrepancies, and >defun-time expansion looks a bit more important.) > >-- Scott > Bob.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 10:48:13 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 07:38:13 PDT Received: ID ; Tue 15 Jul 86 10:37:06-EDT Date: Tue, 15 Jul 1986 10:36 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: kessler%utah-orion@utah-cs.arpa (Robert Kessler) Cc: common-lisp@SU-AI.ARPA Subject: Definition time macros In-reply-to: Msg of 14 Jul 1986 22:32-EDT from kessler%utah-orion at utah-cs.arpa (Robert Kessler) I also believe in the CL goal of the exact same semantics between the compiler and interpreter. Its hard enough teaching students Lisp when you also have to discuss the grungy details of the differences between compiled and interpreted code. However, one big hole in the CL scheme is that it is not specified that all macros must expand at definition time. That is the only way that one can force the same semantics. 1) Does CL say anything that forbids a system from expanding macros at function definition time? This is legal, I think. Since the book explicitly gives permission to compile code on sight instead of having a real interpreter, it must follow that defun-time expansion of macros is legal. H-P currently does this, as I'm sure you know. 2) Would it be reasonable to add this requirement to the standard? In my opinion, it should not even be encouraged, let alone required. I've been discussing the desirabilty of doing DEFUN-time expansion and other source-level transforms with some of the H-P people since I started using their system. In my view, the only reason to have an interpreter around at all is that it is much easier to debug code if it is still more or less what you wrote. Once the proverbial clever compiler has come in and changed everything beyond recognition, you may as well let it go ahead and finish compiling. Just doing the expansions and source-level transforms gets you the worst of both worlds: the code is unreadable, but not fast. Before someone points it out, I know that with a couple of man-years of work, one can develop a memoizing system and matching debugging tools so that the compiler's alterations become invisible to the user most of the time, but these things never quite get the job done right, in my experience. So it is a desirable goal to have interpreted code exactly match compiled code, but it is also a desirable goal to have a good source-language debugging environment in the interpreter. It's a trade-off. In my experience, the differences introduced by expanding macros at execution time, rather than definition time, are not troublesome in practice and are not the kind of thing that a beginner is going to run into. (Actually, that statement assumes that the compiler does macro-expansion and then code generation in the same recursive descent. If all of the source-level transforms are done in a pre-pass, as H-P likes to do, you can get some more glaring discrepancies, and defun-time expansion looks a bit more important.) -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 10:33:12 EDT Received: from LIVE-OAK.LCS.MIT.EDU by SU-AI.ARPA with TCP; 15 Jul 86 07:21:54 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 4220; 15 Jul 86 10:23:09-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 29015; Tue 15-Jul-86 10:23:29-EDT Date: Tue, 15 Jul 86 10:20 EST From: mike%gold-hill-acorn@mit-live-oak.arpa To: Pavel.pa@Xerox.COM Reply-to: mike%gold-hill-acorn@mit-live-oak.arpa Subject: Re: DESCRIBE-ARGUMENTS Cc: oster%ucblapis@BERKELEY.EDU, common-lisp@su-ai.arpa Date: 15 Jul 86 00:51 PDT From: Pavel.pa@Xerox.COM Date: Mon, 14 Jul 86 16:36:46 pdt From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster) franz!fizzy!jkf in Mesg 14 suggests that DESCRIBE-ARGUMENTS return a list like: (a b c &optional d e &rest r &key x y &allow-other-keys) Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string should be returned instead. Is this a joke? Where are the ":-)"s? The function exists in Interlisp and is very useful. .... It is the case, however, that Xerox Common Lisp stores a list just exactly like that in every compiled function... Pavel Info is also lost if it is a string. Package qualifiers are needed to tell which variables are being bound if any of the symbols in the arglist are specvars. ...mike beckerle Gold Hill Computers  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 10:23:55 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Jul 86 07:13:34 PDT Received: ID ; Tue 15 Jul 86 10:12:02-EDT Date: Tue, 15 Jul 1986 10:11 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: oster%ucblapis@BERKELEY.EDU (David Phillip Oster) Cc: common-lisp@SU-AI.ARPA Subject: DESCRIBE-ARGUMENTS In-reply-to: Msg of 14 Jul 1986 19:36-EDT from oster%ucblapis at BERKELEY.EDU (David Phillip Oster) Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string should be returned instead. Is this a joke? Where are the ":-)"s? The function exists in Interlisp and is very useful. Well, I've spent a couple of days working on it, and now I think I see how to extract arg-counts and stuff like that from the incredibly obscure format that Foderaro proposes. I think we could write all of the necessary functions in under a week. <= BEWARE! ATTEMPTED SARCASM! What I was trying to say was that in a lot of implementations the kind of information that would be returned by FUNCTION-PARAMETERS is sitting around in already-parsed form so that the implementation can check for legal calls quickly. Given that, why pack it into a list that then has to be grovelled to get what you want. Various people have been arguing that this call needs to be fast and non-consing. The "difficulty" I was referring to was not the difficulty of writing the code, but the time required to extract the various kinds of useful info from this list format, as compared to keeping this around in some pre-digested format. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 04:05:38 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 15 Jul 86 00:51:27 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 86 00:51:38 PDT Date: 15 Jul 86 00:51 PDT From: Pavel.pa@Xerox.COM Subject: Re: DESCRIBE-ARGUMENTS In-reply-to: oster%ucblapis@BERKELEY.EDU (David Phillip Oster)'s message of Mon, 14 Jul 86 16:36:46 pdt To: oster%ucblapis@BERKELEY.EDU cc: common-lisp@su-ai.arpa Message-ID: <860715-005138-2891@Xerox> Date: Mon, 14 Jul 86 16:36:46 pdt From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster) franz!fizzy!jkf in Mesg 14 suggests that DESCRIBE-ARGUMENTS return a list like: (a b c &optional d e &rest r &key x y &allow-other-keys) Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string should be returned instead. Is this a joke? Where are the ":-)"s? The function exists in Interlisp and is very useful. Actually, the function in Interlisp doesn't put any of those new-fangled &-keywords in its result, since Interlisp doesn't have those features. It is the case, however, that Xerox Common Lisp stores a list just exactly like that in every compiled function... Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 Jul 86 02:23:35 EDT Received: from UCBVAX.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 23:15:50 PDT Received: by ucbvax (5.53/1.14) id AA12260; Mon, 14 Jul 86 23:16:34 PDT Received: by ucbjade.Berkeley.Edu (5.31 (CFC 4.21)/5.6.1) id AA13382; Mon, 14 Jul 86 16:37:00 PDT Received: by ucblapis.Berkeley.Edu (4.19/5.6) id AA04256; Mon, 14 Jul 86 16:36:46 pdt Date: Mon, 14 Jul 86 16:36:46 pdt From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster) Message-Id: <8607142336.AA04256@ucblapis.Berkeley.Edu> To: common-lisp@su-ai.arpa Subject: DESCRIBE-ARGUMENTS franz!fizzy!jkf in Mesg 14 suggests that DESCRIBE-ARGUMENTS return a list like: (a b c &optional d e &rest r &key x y &allow-other-keys) Fahlman@c.cs.cmu.edu says that a list is hard to parse and a string should be returned instead. Is this a joke? Where are the ":-)"s? The function exists in Interlisp and is very useful.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 22:52:18 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 19:44:05 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA01241; Mon, 14 Jul 86 20:44:07 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA13096; Mon, 14 Jul 86 20:44:00 MDT Date: Mon, 14 Jul 86 20:44:00 MDT From: kessler%utah-orion@utah-cs.arpa (Robert Kessler) Message-Id: <8607150244.AA13096@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: GC and BYE I'd like to put my vote in for these two functions. Especially BYE, QUIT or EXITLISP or whatever. I recently tried out the new HP Common Lisp. After experimenting for a few minutes, I decided to exit the lisp. I then had to find the documentation to see how one did it. It was a real pain. While we are on the subject, how about another feature. PSL had the ability to turn on a switch that specified that all future function definitions would be compiled instead of interpreted. It made for a very nice programming environment to switch between compiled and interpreted code. Its also much easier to turn on the switch instead of changing all function definitions to either: (defun foo ... ) (compile 'foo) -or- (compile 'foo #'(lambda ...)) 1) Should this kind of feature be system dependent? 2) Switches aren't really present in CL, is there a better way? Bob.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 22:41:28 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 19:32:31 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA01140; Mon, 14 Jul 86 20:32:31 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA13084; Mon, 14 Jul 86 20:32:27 MDT Date: Mon, 14 Jul 86 20:32:27 MDT From: kessler%utah-orion@utah-cs.arpa (Robert Kessler) Message-Id: <8607150232.AA13084@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Definition time macros I also believe in the CL goal of the exact same semantics between the compiler and interpreter. Its hard enough teaching students Lisp when you also have to discuss the grungy details of the differences between compiled and interpreted code. However, one big hole in the CL scheme is that it is not specified that all macros must expand at definition time. That is the only way that one can force the same semantics. 1) Does CL say anything that forbids a system from expanding macros at function definition time? 2) Would it be reasonable to add this requirement to the standard? By the way, I don't like the technique mentioned earlier where one may only specify patterns for macros. When writing macros, I want the full power of Lisp in order to generate the new code. Bob.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 21:59:26 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 18:46:10 PDT Received: ID ; Mon 14 Jul 86 21:46:23-EDT Date: Mon, 14 Jul 1986 21:46 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: franz!fizzy!jkf@KIM.BERKELEY.EDU Cc: common-lisp@SU-AI.ARPA Subject: Proposals 2, 3, & 4 Well, your proposal isn't as bad as I thought in terms of storage demands. Thanks for digging up the relevant facts. We'd probably all be better off if we used more facts and fewer hunches. Your proposal may be a good alternative to proposal 4. It takes a bit of extra storage to put the & keywords into the list, but probably not enough to matter. A question facing both your proposal and proposal 4 is whether we should save the parameter names as symbols or as strings. You seem rather certain that symbols, in the proper package, are necessary. Do you have some application in mind where this would matter? The debugging-type things I had in mind would get along just fine with strings, and symbols cost considerably more in storage. I still think that we should keep FUNCTION-PARAMETERS and maybe FUNCTION-PARAMETER-RANGE as they are defined in the proposals 2 and 3. A lot of implementations have this information represented in their function objects in ways which are carefully optimized for quick access at function-call time. To implement proposals 2 and 3, they would just have to develop ways of accessing this info (plus maybe keeping around a keyword list for keyword functions). Accessing this internal info would in many cases be quicker than extracting the same information from a list in the format you propose, even if that list is around. An implementor might choose to extract this info from a stored arglist instead, but we shouldn't require that or even encourage it. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 21:15:38 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 14 Jul 86 17:53:12 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41053; Mon 14-Jul-86 17:40:21 EDT Date: Mon, 14 Jul 86 17:38 EDT From: Kent M Pitman Subject: GC, exit-to-system To: RWK@SCRC-STONY-BROOK.ARPA, Moon@SCRC-STONY-BROOK.ARPA, franz!fizzy!jkf@kim.berkeley.edu cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <860714164119.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <860714173834.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> My experience with large portable programs that GC a lot suggests that trying to make a portable GC abstraction doesn't work for reasons related not only to what kind of GC is involved but also because of time requirements. eg, sometimes you want to call GC because you're about to dump a system and maybe then you don't care how long it will take. other times, you are calling it just because you learned to program in Maclisp where GC'ing was so fast you didn't care. eg, Maclisp GC was fast enough that although it would have slowed things down slightly, you could almost have gotten away with calling it every time you thought there might be garbage to collect. That certainly isn't true for some GC's I've run into. eg, if they take more than 5 seconds, I may not be willing to wait. Certainly if they take more than a minute, I am not willing to wait. Also, implementations differ in whether there will be garbage to collect. If you have the ephemeral GC running on the 3600, there may not be any point to trying to GC because the ephemeral GC is working well enough. What I'm getting at is that my initial reaction is that what I was doing was saying (DEFUN GC () #+3600 NIL #+ABC (GC) #+DEF (SYSTEM:GC-INTERNAL T NIL 3) #+GHI (GC:DO-IT) ...) but that I've found from experience that although I know what GC people would have provided me, I'm not happy with the performance of those GCs -- not in the sense that they don't do reasonable things, but in the sense that they do anything even remotely comparable. Each one was written by an implementor who had certain priorities in mind. eg, the folks on micros probably have fast GC's so they like to be able to call them, but the folks on machines that have big disks and big virtual memory areas and bad paging performance are in a different boat. In fact, I should underscore the fact that I'm sufficiently content with making (GC) just do nothing on the 3600 as long as the ephemeral GC is running that I'm really not trying to say that Symbolics somehow would be the one to suffer for this decision. I'm wearing my portable-code-writer's hat when I insist that I might want a GC that let me have all sorts of hairy keywords that said things like (GC :UNLESS-THERES-LOTS-OF-FREE-MEMORY T :UNLESS-IT-WILL-TAKE-LONGER-THAN-N-SECONDS 11 :ONLY-IF-IT-WOULD-RECLAIM-FUNCTION-SPACE T :ONLY-IF-MACLISP-STYLE-GCTWA-IS-SUPPORTED T ...) ... but I just don't think that something as blunt as a single function is going to cut it. Also, I think the whole point of GC is to optimize those features of the implementation which are beyond the scope of the CL spec, and I think that's a good hint that we're going in the wrong direction by suggesting that we can do such optimization with a blindfold on. By the way, it seems to me that the purpose of the GC is to be invisible to the user. Lisp is really organized around the idea that you don't think about memory management. If we can't even write reasonable, portable programs without having to call GC explicitly, I think there may be something more fundamentally wrong with the language. I'd probably suggest we introduce RECLAIM in CL before we introduce GC just because it is at least possible to define in a portable way -- albeit horribly dangerous, as anyone who's tried to use it in serious code has no doubt figured out.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 20:07:58 EDT Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 16:57:51 PDT Received: by kim.Berkeley.EDU (5.53/1.14) id AA13384; Mon, 14 Jul 86 16:58:41 PDT From: franz!fizzy!jkf@kim.berkeley.edu Received: from fizzy by franz (5.5/3.14) id AA01386; Mon, 14 Jul 86 15:57:46 PDT Received: by fizzy (4.12/3.14) id AA10715; Mon, 14 Jul 86 15:57:18 pdt Return-Path: Message-Id: <8607142257.AA10715@fizzy> To: "Scott E. Fahlman" Cc: common-lisp@su-ai.arpa Subject: Re: Proposals 2, 3, & 4 In-Reply-To: Your message of Mon, 14 Jul 86 14:18:00 EDT. Date: Mon, 14 Jul 86 15:57:15 PDT >> The primitive function would return a sequence something like this >> (a b c &optional d e &rest r &key x y &allow-other-keys) >> >> or a keyword signifying that it doesn't have the information. >> I don't like this approach at all. It seems to make more work for >> everyone and to require that all this information be carried around in >> an inefficient and hard-to-parse form. Inefficient? Actually this holds the minimum amount of information necessary to return the values in proposals 2 through 4 (if you must return symbols, and I think you must). I just did a check of the lisp package functions. The info is: 627 functions max length of above type of list: 13 total length of all lists: 1510 average size of list 2.4 functions with optional 105 functions with rest 69 functions with key 94 I've used a list to hold the information. A vector may be more space efficient, it depends on the overhead per vector since the average list size is small. Notice that there are few functions with rest and key arguments. Thus if you use a fixed size structure for holding the key and rest information, you will be wasting those slots most of the time. As for hard to parse, it is actually quite easy to parse, and as I said before the source code for functions to do the parsing and to return the information requested by proposals 2,3 and 4 should be part of the specification. - john foderaro Franz Inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 19:03:14 EDT Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 15:53:44 PDT Received: by kim.Berkeley.EDU (5.53/1.14) id AA11856; Mon, 14 Jul 86 15:54:32 PDT From: franz!fizzy!jkf@kim.berkeley.edu Received: from fizzy by franz (5.5/3.14) id AA01194; Mon, 14 Jul 86 15:40:28 PDT Received: by fizzy (4.12/3.14) id AA10690; Mon, 14 Jul 86 15:40:01 pdt Return-Path: Message-Id: <8607142240.AA10690@fizzy> To: Robert W. Kerns Cc: common-lisp@su-ai.arpa Subject: Re: GC, exit-to-system In-Reply-To: Your message of Mon, 14 Jul 86 16:41:00 EDT. <860714164119.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Mon, 14 Jul 86 15:39:58 PDT >> I think this would just encourage people to write non-portable >> code. Calling the GC from a program may make it work better on >> one implementation, while making it work not at all, or extremely >> poorly, on another. As you know, many implementations enable the user to explicitly invoke a gc. Are you saying that we would be better off if each implementation chose a different name for this function as that would discourage it's use in portable programs? This would certainly be a novel idea in portable language design. [and a poor one, in my opinion]. In my experience, the gc function is typically used before running benchmarks (and benchmarks seem to be the code that most people are porting between implementations at this time.) It is extremely unlikely that anyone would put a call to gc in their 'portable program'. - john foderaro Franz Inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 18:07:52 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 14:59:06 PDT Date: Mon, 14 Jul 86 18:00:13 EDT From: Jonathan A Rees Subject: DECLARE SPECIAL Considered Confusing To: RWK@SCRC-YUKON.ARPA cc: Common-Lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM, Moon@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Mon 14 Jul 86 16:46 EDT from Robert W. Kerns Message-ID: <[AI.AI.MIT.EDU].69829.860714.JAR> Date: Mon, 14 Jul 86 16:46 EDT From: Robert W. Kerns Date: 11 Jul 86 18:43 PDT From: Pavel.pa@Xerox.COM There are six primitive forms in Common Lisp that can both bind identifiers and carry declarations: LET LET* FLET LABELS MACROLET LAMBDA I will describe the scoping rules for declarations in each of these forms. You forgot DEFUN and DEFMACRO (and similar top-level definers). Those, I believe, would be unchanged by your proposal, no? Pavel was only talking about the -primitive- forms. DEFUN and DEFMACRO are macros. Presumably DEFUN has the obvious expansion in terms of LAMBDA, so that it follows the same rules as LAMBDA (which I think should be analogous to LET*, following the easy-to-remember principle that the scope of a declaration of something bound by an expression is the same as the scope of the binding itself). DEFMACRO, also presumably, has a somewhat more complicated expansion, but would also adhere to the principle. Technically speaking, the proposal (with this amendment about the meaning of LAMBDA as per a later message from Pavel, I think) consitutes a change in the *meaning* of DEFUN and DEFMACRO, although probably not in its implementation in terms of LAMBDA. In any case DEFUN should be consistent with LAMBDA. Jonathan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 18:01:03 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 14 Jul 86 14:52:01 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 JUL 86 14:51:43 PDT Date: 14 Jul 86 14:44 PDT From: Pavel.pa@Xerox.COM Subject: Re: DECLARE SPECIAL Considered Confusing In-reply-to: Robert W. Kerns 's message of Mon, 14 Jul 86 16:46 EDT To: RWK@YUKON.SCRC.Symbolics.COM cc: Common-Lisp@SU-AI.ARPA Message-ID: <860714-145143-2412@Xerox> Date: Mon, 14 Jul 86 16:46 EDT From: Robert W. Kerns You forgot DEFUN and DEFMACRO (and similar top-level definers). Those, I believe, would be unchanged by your proposal, no? Those are macros whose behaviour should be understood in terms of the special forms into which they are defined to expand. It is my opinion that the language spec should include a complete example macro definition of all macros so as to make their semantics absolutely clear. For example, I believe that the basic semantics of DEFUN are as follows: (defmacro defun (name args &body body decls doc) `(progn (setf (symbol-function ,name) `(lambda ,args ,@decls (block ,name ,@body))) (setf (documentation ,name 'function) doc))) It is thus made clear that the scope of the declarations in DEFUN is precisely as in an anonymous LAMBDA, just as they should be. It also, by the way, makes it clear what a non-top-level DEFUN means... Pavel PS- Sorry, I used the parse-body feature of &body that hasn't yet been approved, so shoot me.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 16:58:24 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 13:46:52 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54795; Mon 14-Jul-86 16:45:23 EDT Date: Mon, 14 Jul 86 16:46 EDT From: Robert W. Kerns Subject: Re: DECLARE SPECIAL Considered Confusing To: Pavel.pa@Xerox.COM cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA In-Reply-To: <860711-184339-1110@Xerox> Message-ID: <860714164620.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 11 Jul 86 18:43 PDT From: Pavel.pa@Xerox.COM In this message I will give a complete description of my proposal for declaration scoping. I won't attempt to argue for it on the basis of ``obviousness'' or clarity, though, because I think that there are people who find each of the two ways of scoping special declarations confusing. Rather, I like this way of doing things because it satisfies an important (to me) consistency criterion: the scope of \any/ declaration coincides with a particular lexical identifier scope. There are six primitive forms in Common Lisp that can both bind identifiers and carry declarations: LET LET* FLET LABELS MACROLET LAMBDA I will describe the scoping rules for declarations in each of these forms. You forgot DEFUN and DEFMACRO (and similar top-level definers). Those, I believe, would be unchanged by your proposal, no?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 16:55:12 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 13:42:00 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54785; Mon 14-Jul-86 16:40:22 EDT Date: Mon, 14 Jul 86 16:41 EDT From: Robert W. Kerns Subject: Re: GC, exit-to-system To: franz!fizzy!jkf@kim.berkeley.edu cc: David A. Moon , common-lisp@SU-AI.ARPA In-Reply-To: <8607110525.AA04054@fizzy> Supersedes: <860714164053.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <860714164119.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 10 Jul 86 22:25:30 PDT From: franz!fizzy!jkf@kim.berkeley.edu >> From: David Moon >> ... >> The concept of calling the GC at a particular >> time is not meaningful either; the GC runs in parallel with normal >> computation. I'm sure there are other implementations with different >> ideas about these concepts. They just don't make very much sense to >> standardize, because there is so much variation. I think that you may have missed the point. There are certain functions performed by many (but perhaps not all) of the implementations of common lisp. Such functions include stopping a computation and performing a garbage collection, and exiting to the operating system. It would be a good thing if the names for these functions were the same across all common lisps where such functionality exists. - john foderaro Franz Inc. I think this would just encourage people to write non-portable code. Calling the GC from a program may make it work better on one implementation, while making it work not at all, or extremely poorly, on another.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 16:11:28 EDT Received: from MCC.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 12:54:32 PDT Received: from pp.mcc.com by MCC.COM with TCP; Mon 14 Jul 86 14:41:26-CDT Posted-Date: Monday, 14 July 1986, 14:46-CDT Message-Id: <8607141944.AA03543@pp.mcc.com> Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA6710) id AA03543; Mon, 14 Jul 86 14:44:02 cdt Date: Monday, 14 July 1986, 14:46-CDT From: Sender: KRALL%pp@mcc.arpa Subject: Re: Proposals 2, 3, & 4 To: franz!fizzy!jkf@kim.berkeley.edu Cc: common-lisp@su-ai.arpa In-Reply-To: <8607141714.AA09863@fizzy> As regards: (a b c &optional d e &rest r &key x y &allow-other-keys) This is not unlike the problem of getting the command line information into an application program. There are two options: 1. pass it unedited to the application program, or 2. do some primitive parsing on it, then pass it to the program. #2 saves work for the user, but may lose information. #1 may be a pain, but should always work (even in a semi-portable fashion). I like your proposal. Some might object that the symbol names may be not carried around at run-time, so you could encode it (1 2 3 &optional 4 5 &rest 6 &key 7 8 &allow-other-keys) or even (shudder!) as the following signature "010203&O0405&R060&K0708&A" -Ed Krall Microelectronics and Computer Technology Corporation 9430 Research Blvd. Austin, Texas 78759 (512) 834-3406 ARPA: krall@mcc.arpa UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 15:09:42 EDT Received: from ATHENA.MIT.EDU by SU-AI.ARPA with TCP; 14 Jul 86 11:59:13 PDT Received: by ATHENA (5.45/4.7) id AA21344; Mon, 14 Jul 86 14:56:56 EDT Received: by HERA (5.45/4.7) id AA15195; Mon, 14 Jul 86 14:56:56 EDT Message-Id: <8607141856.AA15195@HERA> To: common-lisp@su-ai.arpa Subject: please take me off Date: Mon, 14 Jul 86 14:56:53 -0500 From: bradley@ATHENA.MIT.EDU The rate at which mail arrives on this list is far greater than I can manage reasonably; please take me off the list. -Steve  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 15:09:28 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 11:26:38 PDT Received: ID ; Mon 14 Jul 86 14:26:58-EDT Date: Mon, 14 Jul 1986 14:26 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: proposal #1 again In-reply-to: Msg of 14 Jul 1986 13:26-EDT from SANDRA Wouldn't it be more consistent to make the default behavior in the absence of optimize declarations *not* to require that the errors be signalled? The proposal is that the errors don't need to be signalled if the optimize safety setting is 0 or 1, and according to CLtL, the "usual" value of this parameter is 1. The question of what should be required if a system ignores certain declarations is not the same as what the default should be if the declarations are not present. If an implementation doesn't bother to check for optimize declarations, it should make the conservative assumption and do the error checking. If this were not the rule, proposal 1 would be meaningless. You do raise an interesting point, however. Since the default setting of OPTIMIZE SAFETY is 1 in the absence of any declaration to the contrary, maybe we should go back to requiring Class 2 errors to be signalled unless SAFETY = 0. It would be better to require the signalling unless the user specifically authorizes the system to omit such tests. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 14:36:02 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 11:19:28 PDT Received: ID ; Mon 14 Jul 86 14:18:53-EDT Date: Mon, 14 Jul 1986 14:18 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: franz!fizzy!jkf@KIM.BERKELEY.EDU Cc: common-lisp@SU-AI.ARPA Subject: Proposals 2, 3, & 4 In-reply-to: Msg of 14 Jul 1986 13:14-EDT from franz!fizzy!jkf at kim.berkeley.edu The primitive function would return a sequence something like this (a b c &optional d e &rest r &key x y &allow-other-keys) or a keyword signifying that it doesn't have the information. I don't like this approach at all. It seems to make more work for everyone and to require that all this information be carried around in an inefficient and hard-to-parse form. I am wavering on whether proposal 4 is a good idea in its current form. Maybe it should be dropped from the standard or replaced with a semi-standard form that just returns the arglist of a function or macro, probably as a string. But I think that we want to keep proposal 2 in its current form as a clean portable way of getting at a function's external calling conventions. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 14:22:04 EDT Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 14 Jul 86 10:59:25 PDT Received: by kim.Berkeley.EDU (5.53/1.14) id AA01769; Mon, 14 Jul 86 11:00:13 PDT From: franz!fizzy!jkf@kim.berkeley.edu Received: from fizzy by franz (5.5/3.14) id AA01701; Mon, 14 Jul 86 10:15:06 PDT Received: by fizzy (4.12/3.14) id AA09863; Mon, 14 Jul 86 10:14:38 pdt Return-Path: Message-Id: <8607141714.AA09863@fizzy> To: "Scott E. Fahlman" Cc: common-lisp@su-ai.arpa Subject: Re: Proposals 2, 3, & 4 In-Reply-To: Your message of Sun, 13 Jul 86 21:15:00 EDT. Date: Mon, 14 Jul 86 10:14:36 PDT We would be better off defining a primitive function which returns the argument list information in a 'raw' form and then define the various higher level functions such as function-parameters, function-parameter-range, function-parameter-names in terms of this primitive. These functions would be written in Lisp in the specification document (making them unambiguous and making it easy for user to modify them if he wants different information back). The primitive function would return a sequence something like this (a b c &optional d e &rest r &key x y &allow-other-keys) or a keyword signifying that it doesn't have the information. The various items in the sequence would be symbols, using strings loses package information. The various higher-level functions would probably want to cache their information to make repeated querys on the same function faster. - john foderaro Franz Inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 14:13:57 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 10:31:31 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19290; Mon 14-Jul-86 13:29:41 EDT Date: Mon, 14 Jul 86 13:31 EDT From: Daniel L. Weinreb Subject: Proposal #1 - minor revision To: Masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <860713-214849-1667@Xerox> Message-ID: <860714133103.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 13 Jul 86 21:48 PDT From: Masinter.pa@Xerox.COM 3) declarations about safety shouldn't affect the operation of correct programs. In this situation, any error in class #2 would violate principle (3). That's a very intersting point. I believe that that answer is that principle (3) should really read as follows: 3) If there are two correct Common Lisp programs, that are identical to each other except for the presence or absence of safety declarations, then they should behave identically. In the case of class #2 errors, there are programs which are valid Common Lisp programs when safety is declared to be 2 or more, but which are not valid Common Lisp programs otherwise. Under this interpretation, principle (3) is not violated. The presence or absence of the declaration is what makes the program valid.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 14:13:57 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 10:29:28 PDT Date: Mon 14 Jul 86 11:26:33-MDT From: SANDRA Subject: proposal #1 again To: fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Message-ID: <12222654520.9.LOOSEMORE@UTAH-20.ARPA> From: Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) Date: 14 Jul 86 15:43:00 GMT Similarly, implementations will still be free to ignore any declarations they want to. If they ignore the OPTIMIZE declaration, they will be required to signal all the class 2 errors. If they want to cut corners on this signalling requirement for speed or code compactness, then they will have to consult the OPTIMIZE declarations to see if this is OK. Wouldn't it be more consistent to make the default behavior in the absence of optimize declarations *not* to require that the errors be signalled? The proposal is that the errors don't need to be signalled if the optimize safety setting is 0 or 1, and according to CLtL, the "usual" value of this parameter is 1. -Sandra -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 13:33:26 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 14 Jul 86 10:19:23 PDT Received: from Concord.ms by ArpaGateway.ms ; 14 JUL 86 10:18:46 PDT Sender: "Marilyn_Hodgetts.ROCH"@Xerox.COM Date: 14 Jul 86 10:13:46 PDT (Monday) Subject: DL From: "Marilyn_Hodgetts.ROCH"@Xerox.COM To: common-lisp@SU-AI.Arpa Message-ID: <860714-101846-1968@Xerox> Please remove me from your mailing list. Thank you. Marilyn Hodgetts:Roch:Xerox  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 12:37:58 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 09:20:52 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 19246; Mon 14-Jul-86 12:18:43 EDT Date: Mon, 14 Jul 86 12:19 EDT From: David C. Plummer Subject: Proposal #1 To: Scott E. Fahlman , David C. Plummer cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860714121921.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 13 Jul 1986 23:33 EDT From: "Scott E. Fahlman" I don't think that your severity proposal can possibly fly. One of us is confused. I see Proposal#1 being to expand 2 classes of errors to 3. I see my extension doing the same thing but expanding to 5 classes instead of 3. We should probably just drop it. The decision about whether to signal an error is a function of two things: the severity of the effects of the error and the cost of detecting it. The cost of detecting various kinds of errors varies tremendously from one implementation to another (and the danger posed by non-detection can vary as well) so we can't really create a scalar ranking of errors and standardize it across all implementations. This is a multi-dimensional problem. I thought we had discussed your second point at some length, when Sandra Loosemore expressed dismay at having to provide two versions of all built-in functions, but I'll try again using your AREF example. ... OK. Sorry if this was already explained as explicitly as you did in some previous mail.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 11:54:59 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 14 Jul 86 08:43:06 PDT Received: ID ; Mon 14 Jul 86 11:43:27-EDT Date: Mon, 14 Jul 1986 11:43 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: proposal #1 In-reply-to: Msg of 14 Jul 1986 10:54-EDT from SANDRA For the Nth and hopefully last time, I guarantee you that you will not ever have to provide multiple versions of ANY built-in function in order to comply with proposal #1. You will have to provide exactly one version of each function, and that version will do full error checking for whatever we decide is a class 2 error. Please do not even consider providing quick-and-dirty versions as well. Very few implementations will do this, since the speed gain will be neglegible in most cases. Similarly, implementations will still be free to ignore any declarations they want to. If they ignore the OPTIMIZE declaration, they will be required to signal all the class 2 errors. If they want to cut corners on this signalling requirement for speed or code compactness, then they will have to consult the OPTIMIZE declarations to see if this is OK. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 11:07:05 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 07:56:20 PDT Date: Mon 14 Jul 86 08:54:31-MDT From: SANDRA Subject: proposal #1 To: common-lisp@SU-AI.ARPA cc: fahlman@C.CS.CMU.EDU Message-ID: <12222626842.16.LOOSEMORE@UTAH-20.ARPA> As long as the list of functions whose error-checking behavior relies on the safety switch is kept small, I can live with this proposal. I'm still against having to provide multiple definitions of functions, but if only a dozen or two functions that are normally compiled inline anyway are affected, most of the nastier issues are bypassed. (Perhaps if somebody could put together a list of these functions, it would give the rest of us more information as a basis for making a decision?) However, I agree with Masinter's remarks that saying something "is an error" in some contexts and "signals an error" in others is bogus. The situations in question should remain "an error", whether or not the error is signalled. I tend to think of this as a means of providing a more user-friendly error message -- in PSL/PCLS, for example, nearly all of the "is an error" situations end up signalling *some* error eventually, but it takes some detective work to figure out that the reason why you got an access violation is because you tried to do (CDR -3) from compiled code! Incidentally, currently implementations are free to ignore any declarations they don't feel like processing (p 161), so presumably if we tie signalling of errors to the optimize safety declaration, those implementations that choose to ignore this declaration will not be bound to signal these errors at all. This seems like another reason to make the signalling of errors in these situations something that is strongly encouraged rather than an absolute requirement. -Sandra -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 10:32:25 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 14 Jul 86 07:23:10 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA10504; Mon, 14 Jul 86 08:23:09 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA10135; Mon, 14 Jul 86 08:23:04 MDT Date: Mon, 14 Jul 86 08:23:04 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8607141423.AA10135@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Proposals 2, 3, & 4 Summary: Expires: References: Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article RAM@C.CS.CMU.EDU (Rob MacLachlan) writes: >It seems that it would be simpler and less restrictive >to have a function DESCRIBE-ARGUMENTS which takes a function and a >stream and prints useful information about how that function may be >used. > Rob I agree. Something like FUNCTION-PARAMETER-NAMES is likely to get used only for something like DESCRIBE-ARGUMENTS anyway, since a debugger is going to need a lot more help, for beating on stacks directly etc. Actually DESCRIBE-ARGUMENTS should maybe be subsumed by DESCRIBE, and the standard should give a lot more hints about what sort of useful things DESCRIBE might do. stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 01:22:32 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jul 86 22:11:25 PDT Received: from umass-cs by csnet-relay.csnet id an09342; 14 Jul 86 1:13 EDT Date: Sun, 13 Jul 86 21:44 EST From: STANKULI%cs.umass.edu@CSNET-RELAY.ARPA To: common-lisp@SU-AI.ARPA Subject: Golden Hill Common Lisp installation on DEC Rainbow (* this message was sent to info-dec-micro and no one there has replied with the Golden Hill - DEC Rainbow parameters for the GMACS key binding parameters. thought i would try here, but DEC-specific information is probably want i need. LISP implementors intended for microcomputers might read the last paragraph. *) i recently got Golden Hill's Common LISP running on my Rainbow 100A and i thought i would make some comments and a plea for help. the memory upgrade to 832K on my two Rainbows went alright. one of the memory boards i received was defective, but a call to the Atlanta DEC hot line produced a DEC repairman who replaced the defective board within a week. the software installation was pretty poor however. it took about 4+ hours to do the hard disk installation. following the instructions in the manual just did not work. some of the points in the 'known bugs' addendum took care of some of the problems, but the installation of the San Marco Explorer had to be done by hand. that was drag. i want to bind the GMACS editor functions to the Rainbow personal function keys and numeric keypad. GMACS has most of the editting functions i usually have in other word processing environments, but key binding does not seem covered in the installation manual. i called Golden Hill first and their tech people showed me the GCLISP\GMACS\EDCOMTAB.LSP which has the key definition functions as follows: (DEF-KEY #X080 ; key hexidecimal parameter (HELP key) *GMACS-HELP-COMMAND-TREE*) ; GMACS editor function the Golden Hill technical support could not give me the hex specifications for the function keys or the keypad. they said that they developed the IBM version and that someone in DEC did the Rainbow specific modifications. the guy i talked with said that DEC would not give them the technical specifications of the Rainbow sufficient for them to do the work. he said i had to talk with DEC about the key bindings. then i called Atlanta DEC again. this time i hit a brick wall. they never heard of Common LISP and said i had to buy software support before they would search any answers. when i found a problem in the hardware installation, they fixed it no problem, but apparently the same support of software is not given. they suggested i call Golden Hill-- full circle: no answers. i looked through PC100 Technical Specifications and found that the key hexidecimal specs were different from the few i could find in EDCOMTAB.LSP. but they were consistently distanced so i applied a conversion. unfortunately, the resultant file did not bind the keys. both DEC and Golden Hill said to ask around and find a hacker who has already bound keys and ask for help. anybody out there done this? its the pits that two professional technical support teams say to find a hacker and ask for help. another major bogus with the Golden Hill Common LISP is the use of keycard floppy disks and copy protection on their diskettes. the copy protection is why software installation took all afternoon. the keycard means that one of their original floppies has to be in drive A before Common LISP will install from the hard disk. when a floppy wears out, they expect a $30 replacement charge for what is a disservice to the user. i plan to break the copy and remove that keycard crap as soon as possible so the Common LISP i bought will operate as a computer utility on my machine rather than as a property interest of the publisher. when will software publishers learn (like Borland did) that their interests are protected through reasonable price, efficient operation, user support and revision services? stan [EOF]GCLISP.Mai  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 01:13:10 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 22:04:25 PDT Received: ID ; Mon 14 Jul 86 01:04:45-EDT Date: Mon, 14 Jul 1986 01:04 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: Proposals 2, 3, & 4 In addition to printing out the argument list for users, I had in mind things like trace functions and debuggers that might want to print ITEM: FOO LIST: (BAR BAH BURP) rather than Argument 1: FOO Argument 2: (BAR BAH BURP) One might argue that all such applications are implementation-dependent anyway, and one might be right about that. Anyway, that's what I had in mind in proposing this function in this particular form. Regarding Rob's specific objections: 1] There is no way to obtain the names of keyword arguments. These aren't interesting. We can get at the keywords themselves via FUNCTION-PARAMETERS. 2] There is no way to determine defmacro syntax... The situation with DEFMACRO is very complicated. The "lambda list" to DEFMACRO only gives part of the story, since some things are evaluated, others not, and others are used in even more complex ways. I grant that in many cases it is useful to look at the "lambda list" of the DEFMACRO 3] Returning the names as symbols has efficiency implications. Spice Lisp stores argument lists as strings to save space. The symbols could be extracted from a stored string fairly easily, modulo package problems. Then again, package problems could be serious here: we might not want to call this function if it would create a lot of symbols that would not otherwise exist at runtime. Perhaps it would be better to return a list of strings, each of which names one of the arguments. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 00:56:24 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Jul 86 21:48:31 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 86 21:48:49 PDT Date: 13 Jul 86 21:48 PDT From: Masinter.pa@Xerox.COM Subject: Proposal #1 - minor revision To: Common-Lisp@SU-AI.ARPA Message-ID: <860713-214849-1667@Xerox> There was an error in my message -- I deleted the wrong sentence in Case 1. Here's what I meant to say: - - - - - - - - - - - - The expressions of doubt that Scott alluded to in his message is summarized as follows. There are two situations: before there is an error system that defines what "signals an error" means, and after. In one, the distinction between class #2 and class #3 is moot. In the other, the distinction violates an important principle of Common Lisp declarations, namely, that they do not affect the results of correct programs. Until there is a standard for what "signals an error" means, 1) There is no semantic difference between "signals an error" and "is an error" other than the vague statement that "signals an error" will somehow "enter the debugger". However, no correct program can depend upon any condition signalling an error since the action of the debugger is undefined. 2) Implementors are already encouraged to signal errors in all "is an error" situation, and, presumably, SAFETY declarations might well have some effect on it. In this situation, the distinction between class #2 and class #3 errors is moot. After there is an error system which defines what "signals an error" means, 1) "signals an error" has program language semantics, and 2) "correct" programs can rely on "signals an error" to catch the error and process it in some standard way, and 3) declarations about safety shouldn't affect the operation of correct programs. In this situation, any error in class #2 would violate principle (3).  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 00:38:01 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Jul 86 21:29:35 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 86 20:56:08 PDT Date: 13 Jul 86 20:56 PDT From: Masinter.pa@Xerox.COM Subject: Re: Proposal #1 In-reply-to: "Scott E. Fahlman" 's message of Sun, 13 Jul 86 21:03 EDT To: Common-Lisp@SU-AI.ARPA Message-ID: <860713-205608-1644@Xerox> The expressions of doubt that Scott alluded to in his message is summarized as follows. There are two situations: before there is an error system that defines what "signals an error" means, and after. In one, the distinction between class #2 and class #3 is moot. In the other, the distinction violates an important principle of Common Lisp declarations, namely, that they do not affect the results of correct programs. Until there is a standard for what "signals an error" means, 1) There is no semantic difference between "signals an error" and "is an error" other than the general exhortation to implementors to try to signal all "is an error" situations. 2) Implementors are already encouraged to signal errors in all "is an error" situation, and, presumably, SAFETY declarations might well have some effect on it. In this situation, the distinction between class #2 and class #3 errors is moot. After there is an error system which defines what "signals an error" means, 1) "signals an error" has program language semantics, and 2) "correct" programs can rely on "signals an error" to catch the error and process it in some standard way, and 3) declarations about safety shouldn't affect the operation of correct programs. In this situation, any error in class #2 would violate principle (3).  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 Jul 86 00:28:43 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 21:20:48 PDT Received: ID ; Sun 13 Jul 86 23:59:34-EDT Date: Sun, 13 Jul 1986 23:58 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Proposals 2, 3, & 4 I am not very happy with proposal #4, FUNCTION-PARAMETER-NAMES. I have three main objections: 1] There is no way to obtain the names of keyword arguments. 2] There is no way to determine defmacro syntax. The arguments to the macro function are always the form and environment, which isn't very useful. 3] Returning the names as symbols has efficiency implications. Spice Lisp stores argument lists as strings to save space. Since the actual symbols naming the argument aren't stored, it would be difficult to return the names as symbols. I question that there is any legitimate portable use of the function other than simply obtaining the information so that it can be printed to the user. It seems that it would be simpler and less restrictive to have a function DESCRIBE-ARGUMENTS which takes a function and a stream and prints useful information about how that function may be used. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 23:43:10 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 20:34:07 PDT Received: ID ; Sun 13 Jul 86 23:33:53-EDT Date: Sun, 13 Jul 1986 23:33 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: Common-Lisp@SU-AI.ARPA Subject: Proposal #1 In-reply-to: Msg of 13 Jul 1986 22:53-EDT from David C. Plummer I don't think that your severity proposal can possibly fly. The decision about whether to signal an error is a function of two things: the severity of the effects of the error and the cost of detecting it. The cost of detecting various kinds of errors varies tremendously from one implementation to another (and the danger posed by non-detection can vary as well) so we can't really create a scalar ranking of errors and standardize it across all implementations. This is a multi-dimensional problem. I thought we had discussed your second point at some length, when Sandra Loosemore expressed dismay at having to provide two versions of all built-in functions, but I'll try again using your AREF example. If we adopt proposal #1 and then decide that aref-out-of-bounds is a Class 2 error, your SAFE-SLOW-2D-AREF must check for and signal such errors. So there must be a built-in AREF function that does this checking. I would be surprised to learn of an implementaiton that does not already provide this function. Under the same assumptions, your UNSAFE-FAST-2D-AREF would be allowed to call the same built-in function, or the implementors could choose to provide a second, quick and dirty AREF function that would be called instead. I doubt that many implementations will bother to provide this second version of AREF. People interested in speed will allow the system to compile their AREF calls inline, and that's where omitting the check can buy you some speed. In general, most of the potential Class 2 errors are things that really ought to be checked for, but where the error-checking can be too burdensome if the call is open-coded. The main burden to implementors will be to put optional error-checking code into various inline code expansions. Most implementations already compile in checks if the user asks for safety, but not all do. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 23:03:27 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 13 Jul 86 19:53:38 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 40498; Sun 13-Jul-86 22:54:34 EDT Date: Sun, 13 Jul 86 22:53 EDT From: David C. Plummer Subject: Proposal #1 To: Scott E. Fahlman , Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860713225300.9.DCP@FIREBIRD.SCRC.Symbolics.COM> I am in agreement that "is an error" and "signals an error" don't express enough variety and that more classes are needed in order to help us toward the goals mentioned on pages 1-3, with the addition of Robustness. [I don't really want to start a side discussion, but I think one of the goals >should be< that the language is Robust, meaning that it encourages the user to write correct code, both because of the definition and by run time checking. This isn't really mentioned on pages 1-3, even under the goals of Expressiveness or Power.] The following is a little off-the-wall, and can be ignored if nobody else sees any worth in it. There are some more substantive questions in the last paragraph that shouldn't be lightly ignored. I'm wondering if the three levels is enough. Given that there are four values of SAFETY, one could imagine five classes. Assign the five classes a "severity" number ranging from 0 to 4 (inclusive). A class arranges for the error to be signalled if its number is <= the setting of the safety switch. Therefore, Severity 0 errors ("Signals an error") always signals an error because 0 <= all safety settings. Severity 4 ("is an error") doesn't necessarily generate code, because all 4 is not <= any settings of safety. The third class you are proposing (that fits between), would be Severity 2, since 2 <= 2,3. [I don't really like the word "severity" because intuition says that higher severity implies a higher number.] This gives us a set of finer knobs, but on the other hand makes it harder for the language designers to assign a severity to each of the many possible cases. The not-so-light issue which I don't remember the answer to: Does safety affect the caller or the callee, or both, and what burden does this put on the implementor. For example, if I write: (defun safe-slow-2d-aref (array sub1 sub2) (declare (optimize (speed 0) (space 3) (safety 3)) (notinline aref)) (aref array sub1 sub2)) (defun unsafe-fast-2d-aref (array sub1 sub2) (declare (optimize (speed 3) (space 3) (safety 0)) (notinline aref)) (aref array sub1 sub2)) What does this imply about the AREF function? Is the implementor bound to implement a variety of functions that may be called by programs compiled with different switch settings, or is there one AREF function that always checks the number of arguments, always does bounds checking, etc? [I think this is more an issue for the builtin "subprimitives" than the more complex (e.g., FIND, REMOVE-IF-NOT, etc) functions, but the latter may need to be addressed too.]  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 21:39:43 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 18:15:26 PDT Received: ID ; Sun 13 Jul 86 21:15:48-EDT Date: Sun, 13 Jul 1986 21:15 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposals 2, 3, & 4 Last call for comments on these. They're all related, so I'll put all three in the smae message. I favor 2, 3A, and 4, though I really don't care much whether 3A or 3B is chosen. Most of the discussion centered around the exact format of these functions, whether a fast version as in 3A is needed, and whether we should do all of this with TYPE-OF instead. I think that the TYPE-OF idea hs been effectively shot down in later discussion. There has been little discussion of issue 4, the semi-standard interface for getting the parameter names, but I think that this is potentially quite useful and costs very little to adopt, since implmentors are free to make it a no-op. --------------------------------------------------------------------------- Proposal #2: Argument List Information Proposed Extension: (FUNCTION-PARAMETERS ) Takes one argument which must be a function, not a macro or special form. Returns the following six values: 1. Number of required parameters in the function's lambda list. 2. Number of optional parameters in the function's lambda list. 3. T if the function's lambda list contains the &REST lambda-keyword; NIL otherwise. 4. T if the function's lambda list contains the &KEY lambda-keyword; NIL otherwise. 5. A list of all keywords accepted by the function, in arbitrary order. This list may be pre-stored, so it should not be destructively modified by the user. 6. T if the function's lambda list contains the &ALLOW-OTHER-KEYS lambda-keyword; NIL otherwise. If return value 4 is NIL, 5 and 6 must also be NIL. --------------------------------------------------------------------------- Proposal #3: Argument List Information Two alternatives to choose from: #3A: Proposed extension: FUNCTION-PARAMETER-RANGE (function) The argument must be a function, not a macro or special form. Returns two values, the minimum legal number of arguments and the maximum legal number of arguments. If the function's argument list contains &rest or &key, the second return value is NIL, meaning that there is no maximum number of arguments. - OR - #3B: Modification to proposal #2: Add an implementation note to FUNCTION-PARAMETER recommending that implementations detect calls that will not use the 5th value, and that they compile such calls in a way that will not cons up a keyword list. --------------------------------------------------------------------------- Proposal #4: Argument Name Information Proposed extension: (FUNCTION-PARAMETER-NAMES ) Takes one argument which must be a function, not a macro or special form. This function returns the names of the parameters to a function, as specified in the argument list, if such information is available. An implementation may choose to provide this information for all functions, only for some, or for none. The final return value specifies whether the information is in fact available. If this is NIL, the other return values will also be NIL. Returns four values: 1. A list containing the symbols naming the required parameters, in order. 2. A list containing the symbols naming the optional parameters, in order. 3. A symbol naming the rest parameter, if any. 4. T if the information returned by this function is valid; NIL otherwise. Note: This function is included primarily for the convenience of users and to provide a uniform interface for portable debugging tools.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 21:39:30 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 18:18:02 PDT Received: ID ; Sun 13 Jul 86 21:18:24-EDT Date: Sun, 13 Jul 1986 21:18 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Oops Please ignore the sentence about TYPE-OF in the preamble to Proposal #1. That slipped in from the other proposal before I split them into two messages. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 21:10:49 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 18:02:50 PDT Received: ID ; Sun 13 Jul 86 21:03:16-EDT Date: Sun, 13 Jul 1986 21:03 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: Proposal #1 Last call for comments on the following, before the technical committee tries to make a decision on it. I am in favor of this proposal. Most of the comments have been favorable, except for some technical problems raised by Loosemore (I don't know if she is now satisfied) and some doubts expressed by Masinter. A few people favored doing this with TYPE-OF, but I think that option has been pretty well shot down in subsequent discussion. One change from what was discussed earlier is that the exemption from error signalling now would apply for SAFETY = 0 or 1, not just SAFETY = 0. This gives implementors the option of turning on some of the less expensive checks at Safety = 1, and the rest of them at SAFETY > 1. This flexibility may be useful in some systems. --------------------------------------------------------------------------- Proposal #1: Error signalling This is a proposed change, upward compatible from the user's point of view: Create three levels of errors: Class 1 errors must be deteced and signalled by any legal implementation. Class 2 errors must normally be detected and signalled, but implementations may choose to omit the error testing and signalling in code compiled with an OPTIMIZE SAFETY value of 0 or 1; in this case, the behavior if the error occurs is unpredictable, and perhaps fatal to the Lisp. Class 3 errors are considered to be errors, but it is left to the discretion of the implementor whether and under what conditions Class 3 errors are detected and signalled. There will be a usage note indicating that portable code should not depend for correct operation on Class 2 errors being signalled, since under some conditions of compilation they will not be. Note: CLtL has classes corresponding to Class 1 ("signals an error") and Class 3 ("is an error"). We intend to propose that certain errors, including wrong number of arguments to a function, array references out of bounds, and certain wrong-type errors, be moved from Class 3 to Class 2. However, such proposals will be discussed individually, after an error system has been adopted. The decision at this point is whether we should use the three-level error system as the working assumption in future discussions.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 20:57:14 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 17:49:52 PDT Received: ID ; Sun 13 Jul 86 20:50:14-EDT Date: Sun, 13 Jul 1986 20:50 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Decisions and Discussions One additional point: If people do peek at the ISSUES.TXT file and see something that looks wrong, or if you want to add some topics, it would be helpful if you would contact me directly by netmail and do not send a message to Common-Lisp. I'm afraid that such messages will start discussions of their own, and that we'll end up with too many discussions going on at once. If these discussions do get started, I'll ask people to suspend some of the topics while we work on others. As long as something is on the ISSUES list, it won't be forgotten. There are still many things that need to be added to the ISSUES list, including Guy's list of changes and things that were discussed shortly after the Boston meeting. I'll tell people when I think the list is complete, and THEN it would be appropriate to tell me about things that I missed. Thanks, Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 19:18:01 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 16:08:44 PDT Received: ID ; Sun 13 Jul 86 19:09:09-EDT Date: Sun, 13 Jul 1986 19:09 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Decisions I believe that we are ready to start making formal decisions on what should go into the new language definition that we will later propose to the standards organizations. The current plan is this: I am maintaining three online files: a list of issues, culled from old mail, that need to be resolved (not yet completed), a list of proposals that are before the technical committee, and a list of decisions that have been made by the technical committee. Issues will be raised and discussed on the Common Lisp mailing list, a few at a time (I hope!). Whenever I think the discussion has converged, as much as it is going to converge, I will send out a formal proposal on the issue, or a set of proposals representing the live alternatives. People will have an opportunity for a last round of comments on the proposals, and then the technical committee will make a decision. That decision will be recorded in the decisions file. Such decisions will be final unless the technical committee decides to re-open them. As of now, no such decisions have been made. The issues that have been discussed on the mailing list and tentatively settled since CLtL was written, including most of the issues on the list Guy distributed in Bosotn, will be run through the above process for formal approval. I hope that most such things will be approved quickly, without too much re-hashing of old arguments. We have a lot of ground to cover. We are also writing a new language definition document from scratch. It was too complicated to get the rights to use CLtL or other existing manuals without a lot of legal strings attached. The new document will differ in form from CLtL: it will be written as a specification, with emphasis on precision rather than tutorial value. The intent is that the language definition contained in this document will be exactly the language defined in CLtL, as modified by the approved changes. In the end, however, this document is what we will submit as a standard, and it will become the definitive text in the event of any discrepancy. There may also be a second edition of CLtL, updated by Guy Steele to match the new spec. This manual will aimed at meeting the needs of the working programmer, and it will explicitly point to the language definition document as the definitive specification of Common Lisp. I have encouraged Guy to produce such a thing, since I think this document will serve a useful purpose alongside the official definition, but this is not one of the things our committee has anything to do with. All of the files mentioned above, plus the evolving drafts of the language definition document, will be kept online on C.CS.CMU.EDU, a Dec-20 system, in directory PRVA:. These files can be FTP'ed to other arpanet sites with anonymous login. To find your way around, first read the READ-ME.TXT file. There is not much of interest in this directory now, except for the ISSUES.TXT file, which is still incomplete, but people are welcome to browse. I will send mail to this list when parts of the specificaiton document are ready for review and discussion, but that will not happen for a couple of months, at least. At the moment, there is no mechanism for distributing this stuff to sites that are unable to FTP it. I am hoping that ISI will soon be in a position to handle such distribution. The first few proposals will be sent out later this evening. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 17:28:54 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 13 Jul 86 14:04:07 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 86 13:56:36 PDT Date: 13 Jul 86 13:56 PDT From: Masinter.pa@Xerox.COM Subject: Re: functionp In-reply-to: Daniel L. Weinreb 's message of Fri, 11 Jul 86 10:19 EDT To: common-lisp@SU-AI.ARPA Message-ID: <860713-135636-1518@Xerox> DLW: "If in some implementation (functionp 3) returned T, I would not call that legitimate." I was using the word "legitimate" to mean "complying with what the book says", rather than in the sense of following good software design principles. I've known Lisp systems which overlayed some range of fixnums with "binary program space" (Lisp/360 did this, as did Interlisp-10) where the address of some system functions were indistinguishable from the address of the integer 3. In such a system, (FUNCTIONP 3) might well be true, since (symbol-function 'CAR) could return 3. FUNCALLing such a thing would just start executing that address. This isn't a great design, and I don't want to defend it, but my point is that there's nothing in the book to prevent it; there's no requirement on the FUNCTION type other than that it is true of symbols, lists that begin with LAMBDA, and of whatever FUNCTION and COMPILE might return. I suppose FUNCIONP requires a "clarification", but I'm not sure what the clarification would say. Here are some random ideas on how to clarify or modify FUNCTIONP. I don't like any of them very much: a) "the result of FUNCTIONP is implementation-dependent. Users should not rely on FUNCTIONP returning anything other than T, although implementations are encouraged to make the check as specific as possible. FUNCTIONP is intended for user-interface situations where a program wants to check as soon as possible whether or not something is a valid function." b) change the language to *require* that compiled function objects be a distinct data type. Define FUNCTIONP to be (defun functionp (x) (or (symbolp x) (consp x) (compiled-function-p x))) b') same, but change (consp x) to be (and (consp x) (eq (car x) 'lambda)) c) make a list of types that FUNCTIONP *has* to be disjoint from (NUMBER, things defined with DEFSTRUCT) but specificly warn that whether or not other types (VECTOR?) are allowed to intersect with things that are FUNCTIONP.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 13 Jul 86 18:17:54 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Jul 86 15:09:52 PDT Received: ID ; Sun 13 Jul 86 18:10:18-EDT Date: Sun, 13 Jul 1986 18:10 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Masinter.pa@XEROX.COM Cc: common-lisp@SU-AI.ARPA Subject: functionp In-reply-to: Msg of 13 Jul 1986 16:56-EDT from Masinter.pa at Xerox.COM We clearly need to develop a proposal on how to fix up the Function data-type. Probably Function is the union of Function-Name and Function-Object, where the things that qualify for each of these sub-classes are carefully enumerated. Certainly a concept like Compiled-Function has to be defined as something (we don't need to specify what) that the compiler produces and that we can test for. We need to replace the old wording about "suitable for use by APPLY" or whatever, and the correctness and well-formedness of the function should play no part in the type decision. If anyone wants to try to produce a comprehensive proposal on this, feel free: if not, I'll get to it sometime soon. -- Scott