Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 23:28:54 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 20:17:40 PDT Received: ID ; Wed 30 Jul 86 23:17:51-EDT Date: Wed, 30 Jul 1986 23:17 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Proposal #5 (aside) In-reply-to: Msg of 29 Jul 1986 22:46-EDT from David A. Moon Since when can macros expand into documentation strings? My reading of the manual on this point may be faulty or perhaps "rabbinical", but here is what I think the book says: On page 154, it says that it is permissible for a macro call to expand into a declaration and be recognized as such, provided that the macro call appears where a declaration may legitimately appear. On page 67 it says that declarations may follow a doc string. Suppose you have (defun foo (...) (MACRO1 ...) (MACRO2 ...) ... more forms...) Suppose MACRO1 expands into a string and MACRO2 expands into a DECLARE form. If we expand MACRO1 and get a string, I would say that this is the documentation string and we should then expand MACRO2 to see if it is a declaration, since it is in a place where a declaration may legitimately appear. That seems like the most reasonable interpretation to me. I agree that we could say that a string obtained from a leading MACRO is not allowed to be a doc-string, in which case it is a body form and we can stop looking for macros. The book doesn't seem to come down on one side or the other. Note, however, that it is allowed to expand all the macros at defun time (some implementations actually do this), and in that case my interpretation would fall out automatically unless special care is taken to disallow this. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 20:36:52 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:20:01 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52919; Wed 30-Jul-86 01:33:13 EDT Date: Wed, 30 Jul 86 01:32 EDT From: Kent M Pitman Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14 To: Fahlman@C.CS.CMU.EDU cc: Common-Lisp@SU-AI.ARPA In-Reply-To: References: , <12226310687.19.LOOSEMORE@UTAH-20.ARPA>, The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU, <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>, <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>, <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>, Message-ID: <860730013252.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Proposals #5, #5A: PARSE-BODY I think it's important to standardize on PARSE-BODY in some form, distinct from &BODY. Most people probably wouldn't need it, but those who did need it should -not- be encouraged to write their own. Don't call the argument DOCUMENTATION-ALLOWED-P. The issue isn't whether a doc string is accepted, it's whether a string in that position should be assumed to be a doc string or assumed to be a literal constant. (DEFUN FOO (X) "hi" X) would be a valid program even if there were no such thing as a doc string. Call the arg PARSE-DOCUMENTATION-P. The additional return values suggested in proposal 5A seem misguided to me. I prefer returning just body, declares, and doc in that order. I think the BODY should be a list of forms with the first form potentially macroexpanded since the pre-expanded form is easy to recover by doing something like: (CAR (LAST (LDIFF unparsed-body (CDR parsed-body)))) Actually, though, the macro might have smashed the macro call's argument list, perhaps not even leaving it in a semantically meaningful form, though more commonly just displacing the macro expansion in place. So claiming you were going to return an unexpanded form would be impossible to really do in the general case. Related questions: Is there anything in CLtL that specifies that the "foo" in (LAMBDA FOO () "foo") has a body form of "foo" and not just a doc string of "foo" with a null body list? Is there anything that says whether (LAMBDA (X) "foo" (DECLARE (IGNORE X))) is well-formed or what it returns? Regardless of the answers to these questions, having PARSE-BODY around would mean that individual users would not have to develop private heuristic solutions. When everyone's done with this initial round of comments, I'd want to see a reworked proposal so that I could give a boolean vote. Proposal #6: Parsing in &BODY I strongly lean toward the syntax I proposed. In addition to the issues of upward-compatibility with existing code and the argument about symmetry with &REST, it just involves less parens. Also, I'm inclined to agree with Sandra that &REST and &BODY need not be mutually exclusive. This would be properly consistent with the conjoined use of &REST and &KEY, and with the conjoined use of &WHOLE and other arguments. Proposal #7: TYPE-SPECIFIER-P I agree with Moon that this should only be called TYPE-SPECIFIER-P if it were going to really predicate type expressions and not type symbols. I'm content to include only TYPE-NAME-P for now. The need for this comes up in my error proposal implementation in a situation where SYMBOLP ends up sufficing (modulo reduced error checking). I think TYPE-NAME-P is an important primitive to have. Proposal #8: Clarifications to DEFCONSTANT I concur with most of Moon's remarks here. Also, I think it's pretty clear that EQUAL is an acceptable predicate since even in the case of (DEFCONSTANT FOO (LIST 'A 'B)) where the person is obviously going to work to get something less EQL than (DEFCONSTANT FOO '(A B)) would have gotten him, the compiler is under no contract to preserve that absence of sharing in the inlined code it outputs to binary files. Perhaps we should say explicitly that it is an error to side-effect a system constant, and permit systems to warn in compiled code about things like (SETF (CAR FOO) 3), to signal an error at runtime (eg, by putting such constants in read-only areas), etc. I would prefer that the warning about redefining a constant be refined to make the "is an error" part dependent on whether the programs have made assumptions about the value of the constant, not just whether they refer to the constant. eg, macros might have called functions which use the old value even if they do not themselves refer to the constant explicitly. I would also prefer that the warning about redefining constants refer not only to compiled code being invalidated but also to interpreted code. If particular implementations happen to not make assumptions about constants in interpreted code, that's ok but should not be part of any guarantee offered by CL. That way, implementations are not precluded from doing prelimary Scheme-style semantic analysis even in interpreted code. Proposal #9, #9A, #9B: Variable Name Conflicts My feeling is that &AUX and LET* should not be subject to the variable name conflict rule. I agree with completely with Dave Touretzky's comment that "outlawing duplicate names in LET* promotes too shallow a notion of consistency: one based on syntax rather than semantics." The case of DO* is interesting. Although superficially this seems similar to DO in the same way as LET* is to LET, I think at a deeper level it is not quite as analagous. Could someone please explain to me what a repeated variable would mean? Would the second one be a side-effect at the same level or would it actually shadow something? If shadowed, is the shadowing magically undone when you get to stepping the variable or do both steps refer to the value of the second variable in the init column? Unless someone can suggest a meaning for repeated variables in this context, I'd suggest that repeated var names in DO* be made illegal even if it's allowed in &AUX and LET*. In my mind, there's no real basis for Masinter's claim that the declaration issue needs to get involved here. If you have (DEFUN FOO (X &AUX (X (F X)) (X (G X))) (DECLARE (SPECIAL X)) (H X)) and you're wondering which of F, G, and H will see the special X, I think we should say arbitrarily -- only H. People should break up the &AUX into nested LET expressions with explicit declarations as appropriate if they want otherwise. Ditto for LET*. I cannot agree to any of #9, #9A, or #9B. Proposal #10: Forms That Allow Declarations I'd like to see declarations allowed in a LABELS or FLET. I agree with those who've suggested that this would not be appropriate for MACROLET. Unlike FLET, LABELS, LET, etc. which introduce semantic terms, MACROLET introduces only syntactic terms. If DECLARE was ever needed inside a MACROLET, it is probably just a coincidence and not a result of the MACROLET. Proposal #11: Contents of Tagbody I hate arbitrary little rules that say things like only symbols and integers are allowed. The reason we can get away with tags at all is that they're atoms and atoms can't have side-effects. I think all atoms should be allowed here. I think we should just define the predicate that gets used, and I think the predicate should be EQL. Maybe someone will come up with a creative use of character objects as tags. I see no reason to preclude that. I note that in your proposal 12, you say "... the same (EQL) tag ...", and I put that forth as evidence that this is how people already like to think about tag equivalence. Proposal #12: Unique Names For Tags This seems non-controversial. Proposal #13: Structure Sharing in Arguments In the case of &REST in macros, I see no reason to not simply say that the argument list is -always- shared. Is there an argument for why this might not always be possible? In the case of &BODY, it may not be possible to do the sharing, so I'm willing to leave this undefined and say it "is an error" to modify the list. For a function that takes &REST arguments, I would prefer that a copy always be made unless the interpreter or compiler can prove that it won't be necessary. If we cannot agree to do that, then it must be noted both that it "is an error" to modify such a list AND that it is an error to pass such a list to someone else using APPLY and then later modify it. eg, (PROGN (APPLY #'FOO L) (SETF (CDR L) ...)) may screw up state that FOO has encached for later use. Proposal #14: THE and VALUES I'm not happy with this form of the clarification. I agree with Moon that the discussion of &keywords in the VALUES declaration seems pretty out of place. We don't check number of return values or do &keyword-hacking on return values anywhere else so doing it here seems out of place. If we did keep it, though, I'd want (THE type form) to be equivalent to (THE (VALUES type &REST T) form) and would want any use of (VALUES ...) to mean that I expected exactly the indicated number of values. Others seem to be disagreeing, though, so it may be better to agree to think harder on the issue and for now not bother to try gratuitously "clarifying" something we don't adequately understand. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 20:36:03 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:20:47 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53212; Wed 30-Jul-86 12:27:06 EDT Date: Wed, 30 Jul 86 12:26 EDT From: David A. Moon Subject: Status of declare UNSPECIAL To: Common-Lisp@SU-AI.ARPA In-Reply-To: <860725110937.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <860730122659.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 25 Jul 86 11:09 EDT From: Daniel L. Weinreb For the record, I also remember that we decided explicitly not to have an "UNSPECAL" (whatever you call it) declaration, and I also don't remember why. Unfortunately, I remember this discussing occurring during a physical meeting, but someone should poke into the old archives and see if there was any good reasoning that we should all know about. Otherwise, I agree that there should be such a declaration. I don't remember either, but here is my guess. Maclisp and Zetalisp declaration scoping follows essentially the rules proposed by Bawden, in which all declarations are pervasive, and therefore they need UNSPECIAL. Once you switch to the current Common Lisp rules, in which a binding of a variable shadows a SPECIAL declaration of the same name in an outer contour, and creates a lexical binding rather than a special binding, you no longer need an UNSPECIAL declaration to get that lexical binding. UNSPECIAL was probably removed because of the mistaken argument that the above implies that UNSPECIAL is never needed. It is still possible to concoct more complicated situations where UNSPECIAL would not be a no-op in the current Common Lisp rules, which I think all involve UNSPECIAL applying to references rather than to a binding. Also of course UNSPECIAL is the only way to shadow a SPECIAL proclamation, but perhaps it was considered undesirable to allow that. Among the declaration types listed in chapter 9, the only ones that cannot be turned off by another declaration are SPECIAL, IGNORE, and DECLARATION. I'm not taking a stand on whether UNSPECIAL should or should not be included in the language, especially not until we have settled the scoping rules for declarations, but I thought the above facts and conjectures might be interesting. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 20:34:39 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:20:38 PDT Received: from SORA.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53172; Wed 30-Jul-86 12:12:39 EDT Date: Wed, 30 Jul 86 12:12 EDT From: Bernard S. Greenberg Subject: Re: exit-to-system To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA, gls%aquinas.think.com@CSNET-RELAY.ARPA, ida%u-tokyo.junet@CSNET-RELAY.ARPA In-Reply-To: <8607290714.AA22657@ccut.u-tokyo.junet> Message-ID: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM> Date: Tue, 29 Jul 86 16:14:11+0900 From: Masayuki Ida Date: Mon, 21 Jul 86 15:01 EDT From: Guy Steele Subject: Re: exit-to-system ... 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. ... ... --Guy I agree. The name QUIT sounds reasonable. ida@utokyo-relay.csnet ----- The name QUIT does not sound reasonable. Quit what? Is ease of typing an issue, for something which is typed once per session and probably appears once in even the largest subsystem? EXIT-LISP sounds much better. I can easily (and have) had internal functions, and macros called QUIT. I don't think the name should be used up in this way. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 20:29:25 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:19:09 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52899; Tue 29-Jul-86 22:46:42 EDT Date: Tue, 29 Jul 86 22:46 EDT From: David A. Moon Subject: Proposal #5 (aside) To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860729224641.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" Proposal #5: PARSE-BODY ....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. Since when can macros expand into documentation strings? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 17:48:45 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 14:34:34 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 86 14:29:22 PDT Date: 30 Jul 86 14:28 PDT Sender: Gregor.pa@Xerox.COM From: Gregor Kiczales Subject: Re: Motivation for PARSE-BODY In-reply-to: Masinter.pa's message of 30 Jul 86 10:46 PDT To: Masinter.pa@Xerox.COM cc: gls@Think.COM, common-lisp@su-ai.ARPA Message-ID: <860730-142922-1699@Xerox> From: Masinter.pa Even if PARSE-BODY were as generally useful as, say, splicing reader macros, the argument that it should be in Common Lisp because it >might be convenient< for writers of embedded languages is a very weak one. Independent of this sub-debate, I think the example the was already given (by MLY I think) of: (defmacro foo (&body body) (foo-internal body nil)) (defmacro foo* (&body body) (foo-internal body t)) (defun foo-internal (body sequentialp) (multiple-value-bind (decls doc real-body) (parse-body body) ...))) Is enough motivation for having PARSE-BODY. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 17:29:58 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 14:17:56 PDT Received: ID ; Wed 30 Jul 86 17:18:14-EDT Date: Wed, 30 Jul 1986 17:18 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Andy Freeman Cc: common-lisp@SU-AI.ARPA Subject: Proposal #9: Variable Name Conflicts In-reply-to: Msg of 30 Jul 1986 16:51-EDT from Andy Freeman Lambda and defun are not sequential binding forms; the order of argument evaluation is irrelevant. "Lambda and defun are sequential binding forms because the arguments they are applied to are evaluated sequentially" is the only interpretation of Fahlman's statement I could think of. I'm certain he had something else in mind; that's much like Masinter's position which neither Fahlman nor I agree with. Well, DEFUN and LAMBDA are partly sequential-binding forms. They process defaults and &aux vars sequentially. That's what I was referring to. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 17:13:08 EDT Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:58:08 PDT Date: Wed, 30 Jul 86 13:55:54 PDT From: Jeff Barnett To: common-lisp@SU-AI.ARPA cc: Fahlman@C.CS.CMU.EDU Subject: Re: Proposal #9 Status: Variable Name Conflicts It was assumed in this and a previous message that looking for duplicate names in the variable-list argument of a PROGV is an N**2 operation. Not true. In the first place, if the list is short N**2 is small. In the second place it can be done in N*log N time. To wit: (1) copy the list-- order n, (2) sort the list--order N*log N, and (3) search the ordered list for adjacent duplicates--order N. Jeff Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 17:11:07 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:55:37 PDT Date: Wed 30 Jul 86 13:51:18-PDT From: Andy Freeman Subject: Re: Proposal #9: Variable Name Conflicts To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <12226886097.79.FREEMAN@SUMEX-AIM.ARPA> Fahlman wrote: If I were to propose [something like let* can have repeated names], it would be to treat all of the sequential binding forms (including LAMBDA/DEFUN) in a consistent way. Lambda and defun are not sequential binding forms; the order of argument evaluation is irrelevant. "Lambda and defun are sequential binding forms because the arguments they are applied to are evaluated sequentially" is the only interpretation of Fahlman's statement I could think of. I'm certain he had something else in mind; that's much like Masinter's position which neither Fahlman nor I agree with. I didn't think Fahlman's proposal 9B wording was unfair; some of his "moderator's summary" wasn't as fair as it could have been. There is a reason for Proposal 9; it just doesn't apply to let* or do*. (Under Masinter's lambda model, all of 9 is wrong.) Fahlman's concerns (about let* and do*) can be included as a warning in the manual much like the *specials* *suggestion*. That's a compromise 9B that I could live with. Declarations (at least non-specials) should be decided before Proposal 9. I think pervasive declarations are a good idea and much more important than 9A vs 9B. If we settle on 9A, then that argues (weakly) against pervasive declarations. If we decide on pervasive declarations, then 9A vs 9B goes on its merits. -andy ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 17:06:06 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:39:22 PDT Received: ID ; Wed 30 Jul 86 16:39:34-EDT Date: Wed, 30 Jul 1986 16:39 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Handout at Lisp Conference We plan to hand out the following informational flier at the Lisp Conference registration. People who read it here won't have to take one. --------------------------------------------------------------------------- STATUS OF COMMON LISP STANDARDIZATION EFFORTS Common Lisp is fast becoming a de facto standard for Lisp, especially in the commercial world where the need for a standard, widely accepted Lisp dialect has long been felt. Almost all Lisp suppliers in the U.S. now offer, or intend to offer, implementations of Common Lisp. The language is now available on most of the workstations and mainframes that are used by the AI research community. Several Japanese companies have also been active in Common Lisp development, and a Japanese standardization committee has been established. Common Lisp is being used in Europe, and the European efforts at Lisp standardization are taking Common Lisp as one important input. At a meeting in Boston in December, 1985, representatives from the Common Lisp community agreed to form technical and steering committees to work on Common Lisp standardization. The technical committee is to develop a detailed language specification for Common Lisp; the steering committee is to work on the non-technical aspects of the standardization process. A group of people, including five key contributors to the original Common Lisp design, was chosen to select the members for these new committees; that task was completed in March of 1986. The technical committee members are Alan Bawden, Daniel Bobrow, Richard Gabriel, Martin Griss, David Moon, Jonathan Rees, Guy Steele, and Scott Fahlman (chairman). The steering committee members are Richard Gabriel, John McCarthy, Ronald Ohlander, Stephen Squires, Guy Steele, and Robert Mathis (chairman). It is expected that some non-U.S. members will be added to both committees in the near future. Both of these committees are interim bodies that will be integrated into the normal standards process, once that process is operating fully. A formal proposal was made to X3, the accredited U.S. standards committee for information processing systems, to establish a technical committee for Common Lisp standardization. This proposal was accepted; the Common Lisp committee is called X3J13. Plans are also being made for the establishment of an international committee for Lisp standardization under ISO. The formation of an X3 technical committee is the normal way for the U.S. to participate in ISO activities. Most of the technical discussion on Common Lisp occurs on the ARPAnet via the mailing list "common-lisp@@sail.stanford.edu", administered by Richard Gabriel (rpg@@sail.stanford.edu). A number of other networks have mail gateways to the ARPAnet, making it possible for almost all interested parties to participate in the technical discussions. Electronic mail communication has been established with participants in Japan and Europe. The first meeting of X3J13, the U.S. Technical Committee for the standardization of Lisp, will be Tuesday and Wednesday, September 23 and 24, 1986, in Washington, DC, at the headquarters of CBEMA, Suite 500, 311 First St, NW. On Tuesday (23) the meeting will be from 10am to 5pm; on Wednesday (24) the meeting will be from 9am to 3pm. No special hotel arrangements are being made. Membership in X3 technical committees is open to all who actively participate (attend meetings or correspond) and pay an annual service fee (about $175). US citizenship or residency is not required. The first meeting is important since policies and procedures for X3 technical committees will be discussed and specific plans for the Lisp activity will be made. Anyone interested in joining X3J13, and particularly anyone planning to attend the first meeting, should contact the convenor for X3J13: Dr. Robert Mathis, 9712 Ceralene Dr., Fairfax, VA 22032. Phone: (703) 425-5923. Arpanet: mathis@@b.isi.edu. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 16:48:31 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:29:25 PDT Received: by vaxa.isi.edu (4.12/4.7) id AA27668; Wed, 30 Jul 86 13:29:14 pdt From: berman@vaxa.isi.edu (Richard Berman) Message-Id: <8607302029.AA27668@vaxa.isi.edu> Date: 30 Jul 1986 1329-PDT (Wednesday) To: common-lisp@su-ai.arpa Subject: Conference Hi ya. I just found out that I'm going to the conference to meet with some developers and what-not. So...I haven't been following the conference info closely. Could somebody please post the times/locations for the Common Lisp specific events? Thanks. RB Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 16:14:12 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 12:59:44 PDT Received: by vaxa.isi.edu (4.12/4.7) id AA27427; Wed, 30 Jul 86 12:59:35 pdt From: berman@vaxa.isi.edu (Richard Berman) Message-Id: <8607301959.AA27427@vaxa.isi.edu> Date: 30 Jul 1986 1259-PDT (Wednesday) To: common-lisp@su-ai.arpa Cc: Subject: Conference Hi ya. I just found out that I'm going to the conference to meet with some developers and what-not. So...I haven't been following the conference info closely. Could somebody please post the times/locations for the Common Lisp specific events? Thanks. RB Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 16:06:44 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 86 12:52:02 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25613; Wed 30-Jul-86 14:38:14 EDT Date: Wed, 30 Jul 86 14:39 EDT From: David C. Plummer Subject: Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!)) To: common-lisp@SU-AI.ARPA Message-ID: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Alternate proposal that has a declarative syntax, and is probably a lot more comprehensible. [ &DECLARATIONS declares-var [ &DOC-STRING doc-string-var ]] &BODY body-var If somebody wants to call it &DOCUMENTATION-STRING, go ahead; CLtL usuually abbreviates "documentation-string" it to "doc-string". Full semantics: - Since &BODY can only be used in macros, these extensions may only be used in macros. - &DECLARATIONS may only appear if &BODY appears. - &DOC-STRING may only appear if &DECLARATIONS appears. - If any of these extensions appear, they appear in the order given, on the grounds that is the normal order found within code. It probably makes parsing defmacro's lambda-list a bit easier, and uniformity will make code easier to understand by other than the author. - declares-var is a catenation of the declarations. If the original body had (declare (ignore a)) (declare (ignore b) (inline aref)) then declares-var would get bound to ((ignore a) (ignore b) (inline aref)) - If &DOC-STRING is present, the first string of the unpruned body is the documentation string, and parsing/pruning stops with the second string, which is considered part of the implicit progn. [The exception is a string that is the last form of the body, in that case it is part of the implicit and not a doc-string, just like now.] - If &DOC-STRING is not present, then the first string stops the parsing/pruning of body. Any declares after a string are part of the implicit progn and "are an error". Presumably the code that groks implicit progns will complain about the presence of declares. - body-var is the body without the declarations and/or doc-string, and also with the first form NOT macroexpanded, even though macroexpansion was necessary to search for declarations and doc-strings. If the first form is a macro, it may get expanded again. Tough, macros shouldn't have side effects. I believe this nests correctly, as all the other defmacro destructuring does. [Example deleted because even the simplest one is 16 lines long.] I am willing to endorse this; I more-or-less believe it. I do not believe the original &BODY body-var [something-var [something-else-var]] because it is totally lacking in syntax and comprehensibility. Aside #1: I personally think &KEY and &BODY are mutually exclusive because of their semantics; more-so when we worry about the presence of declarations and a doc-string. This is because the semantics of a body includes an implicit progn, whereas the semantics of keyword/values is of markers and values. For those that do want &KEY and &BODY at the same time it is probably necessary to require that the &KEY parsing happens after the declarations/doc-string pruning. Aside #2: If we had a simply specified PARSE-BODY, the simple implementation of the above would be (multiple-value-bind (declares-var doc-string-var body-var) (parse-body original-body want-doc-string environment) ...) I think we should have a (simply specified) PARSE-BODY even if (some) extension to &BODY is adopted. The compiler and special-form groker need them for the same reason users want them for defmacro. I think PARSE-BODY and an &BODY extension should look very similar to each other. I believe the ideas in this messages show such a similarity. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 14:50:52 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 11:37:03 PDT Received: from boethius by Godot.Think.COM via CHAOS; Wed, 30 Jul 86 14:37:02 edt Date: Wed, 30 Jul 86 14:37 EDT From: Guy Steele Subject: Re: Proposal about lambda-list params To: NGALL@G.BBN.COM Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <[G.BBN.COM]29-Jul-86 09:50:57.NGALL> Message-Id: <860730143746.5.GLS@BOETHIUS.THINK.COM> Date: 29 Jul 1986 09:50-EDT From: NGALL@G.BBN.COM ... But under some of the new declaration-semantics proposals, the ignore decl. would apply to only one of the parameters, thus given (lambda (x y x z x) (declare (ignore x))...) a compiler should still warn (or signal an error) that two of the parameters illegally share a name. ... Maybe one should have to write (lambda (x y x z x) (declare (ignore x) (ignore x) (ignore x))...) to suppress all warnings. --Quux :-) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 13:59:35 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 10:48:41 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 86 10:47:07 PDT Date: 30 Jul 86 10:46 PDT From: Masinter.pa@Xerox.COM Subject: Re: Motivation for PARSE-BODY In-reply-to: Guy Steele 's message of Wed, 30 Jul 86 13:01 EDT To: gls@Think.COM cc: common-lisp@su-ai.ARPA Message-ID: <860730-104707-1440@Xerox> Guy, I refer you to the compatibility note on pp 364-365 in a book written by some random fellow, where there was a claim that "This design is an attempt to make the reader as simple as possible to understand, use, and implement." and "It is unnecessary, however, to cater to more complex lexical analysis or parsing than that needed for Common Lisp." Even if PARSE-BODY were as generally useful as, say, splicing reader macros, the argument that it should be in Common Lisp because it >might be convenient< for writers of embedded languages is a very weak one. As has been pointed out, anyone who wants to write an embedded language can write their own PARSE-BODY trivially relying only on MACROEXPAND and a few CONSes and EQLs. Maybe we could even put PARSE-BODY it in the (whatever-happened-to-the) yellow pages. Just as Common Lisp doesn't provide built-in support for BNF parsing, there's no reason to put something as awkward as parse-body into the standard. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 13:12:46 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 10:00:52 PDT Received: from boethius by Godot.Think.COM via CHAOS; Wed, 30 Jul 86 13:00:36 edt Date: Wed, 30 Jul 86 13:01 EDT From: Guy Steele Subject: Motivation for PARSE-BODY To: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu Cc: gls@AQUINAS In-Reply-To: <860728-140217-2923@Xerox> Message-Id: <860730130117.1.GLS@BOETHIUS.THINK.COM> Some of us, at least, use Lisp for the inventing of new embedded languages, and one of the great things about Lisp is that is lets you get at various tools that are used within the Lisp implementation itself (or were, at a time when a particular paradigm was standard). Examples of these are READ, PRINT, PROGV, ASSOC, and PAIRLIS. (You might not think of READ and PRINT as peculiarly part of the interpreter, but consider how many language implementations have a very complicated routine for reading and parsing programs but don't let the user get at it? Consider APL, for example, whose program editor is not invocable by user programs.) If I want to invent my own interpreter (and I often do), having PARSE-BODY around would be very convenient. --Guy Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 10:14:19 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 07:05:34 PDT Received: ID ; Wed 30 Jul 86 10:06:00-EDT Date: Wed, 30 Jul 1986 10:05 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Declarations in MACROLET I don't think that it would be correct for a declaration at the head of a macrolet to affect the bodies of any of the macros, since the bodies of the macros are defined to be in the null environment. The only use for declarations in this place would be to make pervasive declarations which affect the body of the MACROLET. Of course this could be done by LOCALLY. Rob Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 30 Jul 86 09:49:05 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 06:40:49 PDT Received: from Salvador.ms by ArpaGateway.ms ; 30 JUL 86 06:41:09 PDT From: MASINTER.PA@Xerox.COM Date: 30 Jul 86 6:40:17 PDT Subject: declarations in macrolet puzzle To: common-lisp@su-ai.ARPA Message-ID: <860730-064109-1194@Xerox> (macrolet ((specials () (specials) '(declare (special special-list ,@special-list)))) (specials) special-list)) since macros can expand into declarations and bodies have to have macros expanded before declarations can be seen yet macrolet macros are visible in the body then ... Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 22:29:46 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 19:20:05 PDT Received: ID ; Tue 29 Jul 86 22:20:14-EDT Date: Tue, 29 Jul 1986 22:20 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Proposal #9: Variable Name Conflicts Although I favor 9A, I have to point out that Fahlman has used his power as moderator to make proposal 9B look bad. Surely the real 9B would treat all of the sequential binding forms in a consistent way. If I were to propose something along these lines, it would be to treat all of the sequential binding forms (including LAMBDA/DEFUN) in a consistent way. I believe that Andy Freeman was the one who first argued for what became 9B, and he specifically said that LAMBDA/DEFUN should not allow multiple args of the same name. He couldn't decide about DO*. If, in summarizing, I replace the opposition's proposals with something I think is better, that's an abuse of power. If I faithfully report what was proposed when I know better, I'm making them look bad, and that's also an abuse of power. Oh, well. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 22:05:18 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:54:26 PDT Received: ID ; Tue 29 Jul 86 21:53:34-EDT Date: Tue, 29 Jul 1986 21:53 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Proposal #8: Clarifications to DEFCONSTANT In-reply-to: Msg of 28 Jul 1986 20:57-EDT from David A. Moon 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. Do you mean EQL or EQUAL? Consider the example (defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.") I don't see any good justification for reading and evaluating that form twice to be an error. Well, we prohibit compilers from replacing a constant reference with inline code that is merely EQUAL to the constant; it must be EQL. This was so that you could do things like (defconstant terminator '(nil)) and then do EQL testing for instances of TERMINATOR. Perhaps this is bogus, but if we keep that, we can't allow users to redefine constants to other values that are merely EQUAL, because it will break such code. I am not sure if it is safe to detect that the new constant value is EQUAL to the old one and, if so, to leave the old one in place. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 21:57:54 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:47:54 PDT Date: 29 Jul 1986 21:47-EDT Sender: NGALL@G.BBN.COM Subject: Re: Staus of proposals 10, 11, and 12 From: NGALL@G.BBN.COM To: Common-Lisp@SU-AI.ARPA Cc: Fahlman@C.CS.CMU.EDU Message-ID: <[G.BBN.COM]29-Jul-86 21:47:02.NGALL> In-Reply-To: <860729115038.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 29 Jul 86 11:50 EDT From: David C. Plummer I may have thought of one usage: (macrolet ((print-them (list) `(mapc #'print ,list))) (declare (notinline mapc)) ...) If anybody else believes this, perhaps it should be one of the examples? I don't believe it. The stuff inside the backquoted list is not code, it is data. Here's a similar one that I believe: (macrolet ((print-them (list) `(progn ,@(mapcar #'(lambda (item) `(print ',item)) list))) (declare (notinline mapcar)) ...) In this, the mapcar funcall form IS code. Note that this still is not a strong argument for decls in the body of a macrolet, since the decl could have been put in the body of the print-them macro definition. But I agree that we should allow decls in the body of a macrolet. -- Nick Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 21:46:33 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:35:08 PDT Date: 29 Jul 1986 21:33-EDT Sender: NGALL@G.BBN.COM Subject: Re: Proposal #9: Variable Name Conflicts From: NGALL@G.BBN.COM To: Moon@SCRC-STONY-BROOK.ARPA Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]29-Jul-86 21:33:23.NGALL> In-Reply-To: <860728221058.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 28 Jul 86 22:10 EDT From: David A. Moon Date: Sun, 27 Jul 1986 22:02 EDT From: "Scott E. Fahlman" Proposal #9A: It is an error for two parameters (including supplied-p and &aux parameters) in the same lambda list to be represented by the same (EQ) symbol. This also holds for parameters bound by LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. There is no such thing as MV-BIND; I expect you meant MULTIPLE-VALUE-BIND. You forgot PROG*. You omitted COMPILER-LET and PROGV, but I can't guess whether this was accidental or intentional. I think I submitted this list of var. binding forms. I abbreviated MULTIPLE-VALUE to MV, sorry if it wasn't clear. PROGV wasn't omitted (see?). The omission of compiler-let and prog* was accidental (compiler-let wasn't in the list on page 154 (which was all I looked at) and I guess I didn't see prog* under prog). -- Nick Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 20:46:27 EDT Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86 17:34:24 PDT Received: from sun.uucp by sun.com (3.2/SMI-3.0) id AA14484; Tue, 29 Jul 86 17:34:11 PDT Received: by sun.uucp (1.1/SMI-3.0) id AA12057; Tue, 29 Jul 86 17:34:55 PDT Received: by pyramid (4.12/3.14) id AA02084; Tue, 29 Jul 86 17:10:26 pdt Date: 29 Jul 1986 17:07-PDT From: David Bein Subject: closing standard channels To: common-lisp@su-ai.ARPA Message-Id: <523066026/bein@pyramid> I know this question may have been asked before.. What seems to be the consensus on closing streams like *terminal-io*,*standard-input*, etc? Should it be an error to try to close them, should it be a noop or what? --David Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 18:11:56 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 14:56:27 PDT Received: ID ; Tue 29 Jul 86 17:56:41-EDT Date: Tue, 29 Jul 1986 17:56 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposed moratorium (clarification) At the end of my suggestion for a Lisp Conference moratorium on technical mail, I said "this is only a suggestion, but I can't guarantee that mail arriving during that itme will be read." This was a feeble attempt at a joke. All mail will be read eventually. I still think it would be a good idea to ease up on the mail during this period, however. Sometimes I get comedy and tragedy confused, I'm afraid. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 16:53:01 EDT Date: 29 Jul 86 1255 PDT From: Dick Gabriel Subject: Yapper of the Month Club To: common-lisp@SAIL.STANFORD.EDU From May 14 through July 28 there were 690 messages to Common-Lisp, around 9 a day. Here are the top message senders with the number of messages sent during that period. There is a fairly sharp break between these folks and the rest, with several having 10 messages or so. 132 Fahlman 56 Plummer 44 Gall 30 Masinter 27 Steele 25 Moon 24 Weinreb 23 Pitman 20 Loosemore 18 Foderaro 18 Beckerle (Mike@a) 18 Shebs Er, congratulations. -rpg- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 15:30:45 EDT Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:34:24 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 5930; 29 Jul 86 12:57:53-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 31206; Tue 29-Jul-86 12:50:36-EDT Date: Tue, 29 Jul 86 12:47 EST Sender: mike%gold-hill-acorn@mit-live-oak.arpa To: Masinter.pa@Xerox.COM From: mike%gold-hill-acorn@mit-live-oak.arpa Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P cc: common-lisp@su-ai.arpa Date: 28 Jul 86 1301 PDT ...... From: Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P In-reply-to: "Scott E. Fahlman" 's message of Sun, 27 Jul 86 21:44 EDT ...... On some further thought, TYPE-SPECIFIER-P is ambiguous in some cases where the argument is a symbol: Suppose you have (deftype relatively-prime-to (n) `(satisfies (lambda (x) (= 1 (gcd x ,n))))) In this case, relatively-prime-to by itself is not "a valid type specifier". (relatively-prime-to 10) is a valid type specifier, and (relatively-prime-to t) is not. Your point about deftype can be looked at differently. If I have a deftype, i.e., (deftype mod (n) ...) etc. then "mod" is a parameterized type. The polymorphic lambda calculus has abstraction and beta reduction defined for types, so following its example, the type of "mod" might be (type-lambda (n) ), where type-lambda is the type abstraction. In the light of this, (type-specifier-p 'relatively-prime-to) should be true (independent of whether we add any type-abstraction notations to CL). { aside:: By the way, the polymorphic lambda calculus is fairly interesting, so for those of you interested in fixing up the type system, I suggest you look at it carefully. If you want, send me mail (NO NOT TO THE CL MAILING LIST!!) and I will send some references. :-) } Any attempt to make type-specifier-p tell you whether a type specifier specifies any real class of objects cannot work due to undecidability problems. What we want is a SYNTACTIC property. Is the intent "is this something I can hand to typep?" If so, it would be false for "relatively-prime-to". If the intent is "does this *name* a type-specifier" then we could allow it, but the usefulness of such a thing is unclear to me. Note that (typep 'relatively-prime-to...) should be invalid, since 'relatively-prime-to is not a type, but it IS a valid specifier. Note, there are no objects of type (type-lambda (n) ...) since those objects would be TYPES, not instances of types. ..... d) of all of the proposals to consider, proposals to add new constructs should get much lower priority than those to clarify or standardize current constructs. Amen. I just think we should plan to revise the type system somewhat, instead of just adding features. I agree that this is fairly low priority, and in the light of... e) there is another proposal (before the Object Oriented Programming committee in this case) which satisfies at least part of the original requirement in a different way. Most object-oriented stuff impacts the type system dramatically, so we should reexamine the type-system in light of object oriented extentions. ...mike beckerle Gold Hill Computers Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 15:28:45 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:34:11 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25108; Tue 29-Jul-86 11:49:59 EDT Date: Tue, 29 Jul 86 11:50 EDT From: David C. Plummer Subject: Staus of proposals 10, 11, and 12 To: Scott E. Fahlman , David C. Plummer cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860729115038.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 28 Jul 1986 23:53 EDT From: "Scott E. Fahlman" Proposal #10: Forms That Allow Declarations I did question the need/usefullness of allowing declarations in MACROLET. Nobody has responded and I still can't think of any. It would come as a nasty surprise to people if MACROLET were different from FLET and LABELS in this respect. I'm not saying we shouldn't do it, I'm saying we should acknowledge we don't know what to do with it yet. There have been parts of the Symbolics documentation that say "We think this is useful but haven't figured out for what yet. We encourage experimentation and reports of its usage." I may have thought of one usage: (macrolet ((print-them (list) `(mapc #'print ,list))) (declare (notinline mapc)) ...) If anybody else believes this, perhaps it should be one of the examples? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 15:28:23 EDT Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:25:29 PDT Received: from REAGAN.AI.MIT.EDU by SU-SCORE.ARPA with TCP; Tue 29 Jul 86 08:52:15-PDT Received: from RICKY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 41068; Tue 29-Jul-86 11:55:55-EDT Date: Tue, 29 Jul 86 11:54 EDT From: Richard Mlynarik Subject: Re: PARSE-BODY To: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu In-Reply-To: <860728-140217-2923@Xerox> Message-ID: <860729115443.3.MLY@RICKY.AI.MIT.EDU> Date: 28 Jul 86 13:43 PDT From: Masinter.pa@Xerox.COM I am (now) opposed to adding PARSE-BODY to the Common Lisp standard (as long as the parse-body option is added to the macro expansion argument list) for the following reasons: a) it is of little general utility Given the addition of &body variables for macros, I can think of no examples where I would want to directly call parse-body instead of just using the macro-expansion option. (I currently have lots of examples that call parse-body, but they're all in macros that could use the new &body options instead.) I disagree; here's an example, of which I could provide many more: [I named it extract-declarations in some code I wrote to avoid a possible conflict with anybody who had already implemented a function named PARSE-BODY] (defmacro condition-case (form &rest clauses &environment environment) "Execute FORM with conditions handled according to CLAUSES. Each element of CLAUSES specifies one or more condition names, and what to do if they are signalled. More specifically, each clause is a list: ( . ) is not evaluated, and should be either a condition name or a list of condition names to be handled. is either a list of a single symbol specifying a variable to be bound to the condition being handled, or () meaning that the clause is not interested in the particular condition object. are evaluated if a condition specified by is signalled. The value of the last of the forms is returned from CONDITION-CASE in this case. The clauses are considered in order, as in TYPECASE. If no clause is executed to handle a condition, the values of FORM are returned." #+lispm (declare (zwei:indentation 0 3 1 1)) (flet ((lose (&rest format) (apply #'lisp:error "Error macro-expanding ~S: ~?" 'condition-case format))) (dolist (clause clauses) (cond ((not (consp clause)) (lose "clauses must be lists: ~S" clause)) ((not (or (null (cadr clause)) (and (consp (cadr clause)) (null (cdr (cadr clause))) (symbolp (car (cadr clause)))))) (lose "second element of a clause must be () or a list of a variable to bind: ~S" clause)) ;... other error checks... )) (let ((gensym (gensym))) `(block ,gensym ;; this depends on the order in which condition-bind and condition-case ;; clauses are defined to be searched (condition-bind ;; I get a Gold Star for not using LOOP (,@(mapcar #'(lambda (clause) (multiple-value-bind (body decls) (extract-declarations (cddr clause) environment) `(,(car clause) #'(lambda ,(or (cadr clause) (list gensym)) (declare ,@(if (cadr clause) () `((ignore ,gensym))) ,@decls) #+symbolics ,@(if (cadr clause) () (list gensym)) (return-from ,gensym (progn ,@body)))))) clauses)) ,form))))) If anything, I think that PARSE-BODY is more essential than the proposed extensions to &BODY. (I am not overly fond of the &body-extensions because of their dissimilarity to other defmacro destructuring, but acknowledge their usefulness) ---------------------------------------------------------------------- b) it is controversial While every implementation will have SOMETHING like parse-body (if only to implement the handing of macro arguments) there seems to be little agreement on what its arguments might be or what values it might return. It would seem that every implementation wants something slightly different (e.g., it depends on whether you cache macro translations as for whether you want to save the macro translation & the work of obtaining it or recompute it.) The `controversy' I think you will find is over rather minor (even stupid) details. (Like order arguments and returned values, and the stuff you cite relating to Fahlman's 4th and 5th values) I find your last argument (about macroexpansion efficiency) rather spurious. ---------------------------------------------------------------------- c) it isn't very simple (This is isn't a simple argument to make, unfortunately.) The value of features is inversly proportional to the complexity of their interfaces. Functions that have a "process-it-this-way-p" arguments and "returns 3 values, but maybe just the first" should be viewed with suspicion, that they don't represent the "true" interface to what is going on in the system. That is, "parse-body" is just a piece of some more complex processing of macros, arguments & bodies that is part of the language writers toolkit, that isn't very isolated. Motivating it (what's this for?) would be difficult without a lot more context. Here's what I think is a pretty-much-adequate implementation (so much for complexity!) (defun extract-declarations (body &optional environment doc-string-valid-p) "Extract declarations and documentation string from BODY and return them. The first value is what is left of BODY after any doc string and decls are removed. It is BODY missing some number of its initial elements. The second value is the list of declarations found. Each element of a DECLARE found in body is a declaration and goes on this list. The third value is the doc string found in BODY, if there was one. However, doc strings are only processed if DOC-STRING-VALID-P is non-NIL." #+lmnil (declare (values body declarations doc-string)) (let (form (doc nil) (decls ())) (loop ;; Macro-expand the form, but don't worry if we get an error. ;; In that case, we will not see it as a declaration, ;; it will get macroexpanded again, and generate a warning then. ;;>> We can't use condition:condition-case since in this toy ;;>> implementation MACROEXPAND probably doesn't signal `our' errors (setq form #+lmnil (si:condition-case () (macroexpand (car body) environment) (si:error (return))) #+lucid ;is buggy for (macroexpand '(declare)) [bugous?] ; Of course, this means we lose if DECLARE is ; lexically defined in ENVIRONMENT. (if (and (consp (car body)) (eq (caar body) 'declare)) (car body) ;; this is about as good as I could figure ;; out without sources or a disassembler (let ((tem (lucid::with-error-trapping (macroexpand (car body) environment)))) (if (and (consp tem) (member (car tem) '(lisp:error lisp:cerror)) (consp (cdr tem)) (string= (cadr tem) "Error") (consp (cddr tem)) (stringp (caddr tem)) (consp (cdddr tem)) (listp (cadddr tem))) form tem))) ;; other implementations probably have some way to hack ;; ignore-errors #-(or lmnil lucid) (macroexpand (car body) environment) ) (cond ((and doc-string-valid-p (stringp form)) ;; If the string is the last thing in the body, ;; don't inhale it, since it needs to be the return value. (or (cdr body) (return)) ;; We skip any number of strings, but use only the first. (or doc (setq doc form))) ((and (consp form) (eq (car form) 'declare)) ;; silently ignore badly-formed declare forms. Probably should warn. (let ((decl (remove-if-not #'consp (the list (cdr form))))) ;; hack the DOCUMENTATION declaration specially (let ((tem (assoc 'documentation decl))) (when (and tem doc-string-valid-p) (when (and (null doc) (stringp (cadr tem))) (setq doc (cadr tem))) (setq decl (delete 'documentation decl :key #'car)))) (if decl ;; We allow any number of DECLAREs, and process them all. (setq decls (append decl decls))))) (t (return))) (pop body)) (values body decls doc))) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 15:27:52 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86 11:41:19 PDT Received: from Salvador.ms by ArpaGateway.ms ; 29 JUL 86 11:38:09 PDT Date: 29 Jul 86 11:37 PDT From: Miller.pa@Xerox.COM Subject: Re: Proposal about lambda-list params In-reply-to: David A. Moon 's message of Mon, 28 Jul 86 21:58 EDT To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA Message-ID: <860729-113809-3801@Xerox> Date: Mon, 28 Jul 86 21:58 EDT From: David A. Moon Date: 23 Jul 1986 23:55-EDT From: NGALL@G.BBN.COM The following thought just struck me. If we change CL to outlaw things like (lambda (x x ...)...), then people who have been writing code like (lambda (ignore x ignore) (declare (ignore ignore))...) may be upset when their code breaks. Since it "is an error", not "signals an error", those people are free to criticize their compiler for wasting their time with worthless warnings if it warns about this. It seems clear enough that warning about duplicate parameter names when the parameters are explicitly ignored does no one any good. "it is an error" means that a correct compiler may generate arbitrary and worthless code when it encounters this case. If "(lambda (ignore x ignore) (declare (ignore ignore))...)" is an error, then it may do worse than break. This should either be legal, specified to signal an error, or at least specified that, if not caught, will be harmless (not one of the error catagories I know of) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 14:31:07 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:23:59 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25110; Tue 29-Jul-86 11:54:38 EDT Date: Tue, 29 Jul 86 11:55 EDT From: David C. Plummer Subject: Re: PARSE-BODY To: Masinter.pa@XEROX.COM, common-lisp@sail.stanford.edu In-Reply-To: <860728-140217-2923@Xerox> Message-ID: <860729115514.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 28 Jul 86 13:43 PDT From: Masinter.pa@Xerox.COM a) it is of little general utility Given the addition of &body variables for macros, I can think of no examples where I would want to directly call parse-body instead of just using the macro-expansion option. (I currently have lots of examples that call parse-body, but they're all in macros that could use the new &body options instead.) (defmacro condition-bind (list &body body) (expand-condition-bind ''t list body)) (defmacro conditin-bind-if (predicate list &body body) (expand-condition-bind predicate list body)) Why should I be forced to destructure the body in the defmacro instead of the common expansion routine? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:14:17 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:32 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51850; Mon 28-Jul-86 21:54:06 EDT Date: Mon, 28 Jul 86 21:54 EDT From: David A. Moon Subject: Proposal #13: Structure Sharing in Arguments To: common-lisp@SU-AI.ARPA In-Reply-To: , <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>, <860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>, <860723142439.9.MILLER@UR-CASHEW.ARPA>, The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" , <8607232003.AA00325@tekchips.TEK>, <860724141621.4.DCP@FIREBIRD.SCRC.Symbolics.COM>, , , <8607251827.AA05634@utah-orion.ARPA>, <860725150616.3.GLS@IGNATIUS.THINK.COM>, <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM>, , <860726171228.4.DLW@CHICOPEE.SCRC.Symbolics.COM>, , The message of 26 Jul 86 18:38 EDT from SCOTT , <8607262326.AA01397@utah-orion.ARPA>, , Message-ID: <860728215406.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 25 Jul 86 15:06 EDT From: Guy Steele I think the lesson here is that, in general, you shouldn't ever clobber a CONS if you don't know where it has been. Certain CL primitives do guarantee to cons up fresh lists, and you can safely clobber their results. Everything else you ought to be careful with, and that includes &rest arguments, the results of PARSE-BODY, the results of FOO, and so on. Unless a function or other construct is clearly documented to indicate that it is okay to clobber its result, then you should avoid doing so. I agree so strongly with the above statement that I'm going to waste hundreds of people's time by including it in my message so that they have to read it again. The negation of this statement is practically the definition of poor programming practice. Date: Tue, 22 Jul 86 21:39:37 pdt From: hpfclp!diamant@hplabs.HP.COM ....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). Symbolics has always agreed that this aspect of our implementation is not in conformance with Common Lisp, and have said so in our documentation. We just haven't gotten around to fixing the bug yet, for engineering reasons that I won't bore you by expounding. No one should think that we oppose Diamant's statement above. Date: Sun, 27 Jul 1986 23:01 EDT From: "Scott E. Fahlman" 13A: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy. Therefore, if this argument is destructively modified, the originl text of the macro may also be altered. Agreed. Make sure the word is "might", not "must", where you now use the ambiguous word "may" in two places. Vanroggen brought up &WHOLE. The manual already implies that the &WHOLE argument is required to be the original form, and not a copy, but this should be made more explicit. Is this big enough to be a separate issue? 13B: Specify explicitly that the &REST argument in a function has indefinite extent and may, for example, be returned to the function's caller. Agreed. 13C: The &REST list in a function is not necessarily a freshly-consed list. If the function is called with APPLY, the &REST list may share top-level structure with the last argument to the APPLY. Users should keep this in mind if they are considering destructive modifications to such a list. Agreed, but the wording should be changed to say that an &REST argument might share structure with something else regardless of how the function was called, and simply use APPLY as an example. There is no reason to put extra restrictions on the implementation here. - OR - 13C': The &REST list in a function is freshly consed upon function entry. It shares no top-level structure with any pre-existing list. It's a bad idea to base the language specification on the idiosyncracies of a particular implementation. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:13:44 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:56:42 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25036; Tue 29-Jul-86 09:54:51 EDT Date: Tue, 29 Jul 86 09:55 EDT From: David C. Plummer Subject: Proposal #5 status To: Scott E. Fahlman , David C. Plummer cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860729095530.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 28 Jul 1986 23:16 EDT From: "Scott E. Fahlman" As I pointed out in another message, the argument should be called stop-parsing-on-string-p or something like that. I gave examples that the current definition of parse-body implies are errors. FYI, The normal way things appear in the manual is { declaration | doc-string }* and that is also the order I have seen it (declarations before doc-string) in code at Symbolics. ?? I assume somebody has convinced themselves that the ordering or separation of declares has no semantic meaning in CL? Yes, unless you have a counter-example. I can't think of any, but I wanted to make sure somebody has convinced themselves. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:10:52 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:49:45 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25028; Tue 29-Jul-86 09:47:45 EDT Date: Tue, 29 Jul 86 09:48 EDT From: David C. Plummer Subject: Proposal #5 status To: Scott E. Fahlman , David C. Plummer cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860729094823.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 28 Jul 1986 23:16 EDT From: "Scott E. Fahlman" 4. The macro-expansion for the first form in return value 3, if any. Why the macroexpansion of the first form of the body? Why not the body with the first form possibly expanded? It saves a CONS. As if macroexpansion doesn't cons up the wazoo? It saves a CONS. What's a CONS among friends? It saves a CONS. Let the GC take care of it. It saves a CONS. Since when does saving a single CONS dictate language design? Why not toss in the kitchen sink? It looks to me like design-by-committee disease is striking. Why is it always the guy who endlessly nit-picks every last unimportant detail who accuses others of design by committee? If there isn't at least one nit-picking asshole (who unfortunately doesn't read the 2 messages about etiquette burried in the middle of 30 messages before responding to half of the remaining 28), there is the possibility that real issues won't be raised and that what some people think are unimportant issues might turn out to be huge timebombs. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:08:25 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:54 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51857; Mon 28-Jul-86 22:10:57 EDT Date: Mon, 28 Jul 86 22:10 EDT From: David A. Moon Subject: Proposal #9: Variable Name Conflicts To: common-lisp@SU-AI.ARPA In-Reply-To: , <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" , <12225052592.76.FREEMAN@SUMEX-AIM.ARPA>, <[G.BBN.COM]23-Jul-86 21:39:54.NGALL>, <[G.BBN.COM]23-Jul-86 23:55:15.NGALL>, <12225270515.16.ANDY@Sushi.Stanford.EDU>, , The message of 25 Jul 86 00:30 EDT from Dave.Touretzky@A.CS.CMU.EDU, <[G.BBN.COM]25-Jul-86 01:45:01.NGALL>, The message of 25 Jul 86 09:15 EDT from "BACH::VANROGGEN" , <860725174559.4.GLS@IGNATIUS.THINK.COM>, <12225647140.10.ANDY@Sushi.Stanford.EDU>, , <[G.BBN.COM]26-Jul-86 12:50:48.NGALL>, <12225811022.11.ANDY@Sushi.Stanford.EDU>, , <860726-182347-1898@Xerox>, , <[AI.AI.MIT.EDU].76153.860726.ALAN>, Message-ID: <860728221058.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 22:02 EDT From: "Scott E. Fahlman" Proposal #9A: It is an error for two parameters (including supplied-p and &aux parameters) in the same lambda list to be represented by the same (EQ) symbol. This also holds for parameters bound by LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. There is no such thing as MV-BIND; I expect you meant MULTIPLE-VALUE-BIND. You forgot PROG*. You omitted COMPILER-LET and PROGV, but I can't guess whether this was accidental or intentional. --------------------------------------------------------------------------- Proposal #9B: Same, but don't include LET*. --------------------------------------------------------------------------- Although I favor 9A, I have to point out that Fahlman has used his power as moderator to make proposal 9B look bad. Surely the real 9B would treat all of the sequential binding forms in a consistent way. This appears to be one of those situations where the answer is obviously correct, but the obviously correct answer is different for different individuals. The only comment I can add is that no matter which proposal is adopted, it is very easy for the proponents of the other proposal to define a LET+ macro which is LET* done the way they wanted, and similarly for the other sequential binding forms. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:05:10 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:52:40 PDT Date: 29 Jul 1986 09:50-EDT Sender: NGALL@G.BBN.COM Subject: Re: Proposal about lambda-list params From: NGALL@G.BBN.COM To: Moon@SCRC-STONY-BROOK.ARPA Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]29-Jul-86 09:50:57.NGALL> In-Reply-To: <860728215820.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 28 Jul 86 21:58 EDT From: David A. Moon Date: 23 Jul 1986 23:55-EDT From: NGALL@G.BBN.COM The following thought just struck me. If we change CL to outlaw things like (lambda (x x ...)...), then people who have been writing code like (lambda (ignore x ignore) (declare (ignore ignore))...) may be upset when their code breaks. Since it "is an error", not "signals an error", those people are free to criticize their compiler for wasting their time with worthless warnings if it warns about this. It seems clear enough that warning about duplicate parameter names when the parameters are explicitly ignored does no one any good. But under some of the new declaration-semantics proposals, the ignore decl. would apply to only one of the parameters, thus given (lambda (x y x z x) (declare (ignore x))...) a compiler should still warn (or signal an error) that two of the parameters illegally share a name. [Perhaps this can be used as an argument against the proposal that a decl only affect only one of the identically named entities to which it refers.] -- Nick Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:03:28 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:11 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51834; Mon 28-Jul-86 21:07:53 EDT Date: Mon, 28 Jul 86 21:07 EDT From: David A. Moon Subject: Proposal #11: Contents of Tagbody To: common-lisp@SU-AI.ARPA In-Reply-To: , <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" , Message-ID: <860728210754.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" Proposal #11: Contents of Tagbody 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.] I prefer Steele's original proposal, which was: Specify explicitly that anything in a TAGBODY other than a symbol, integer, or list is an error. The manual already implies this, so the change would not be incompatible. I can see nothing but user confusion resulting from allowing strings or any other object that is not self-evidently either a form or a tag. I'm more than willing to take (tagbody #1="bar" (print 1) (go #1#)) out of the Symbolics interpreter (the compiler already complains). I think we should continue to allow integers as tags, for two reasons. (1) Removing them would be an unnecessary incompatibility. (2) Some people may be used to using integers as tags in other languages (Basic, Pascal, Fortran) and these are the people most likely to be using GO directly (rather than as part of the expansion of a macro). Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 10:02:36 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:43:26 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51852; Mon 28-Jul-86 21:58:19 EDT Date: Mon, 28 Jul 86 21:58 EDT From: David A. Moon Subject: Re: Proposal about lambda-list params To: NGALL@G.BBN.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]23-Jul-86 23:55:15.NGALL> Message-ID: <860728215820.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Jul 1986 23:55-EDT From: NGALL@G.BBN.COM The following thought just struck me. If we change CL to outlaw things like (lambda (x x ...)...), then people who have been writing code like (lambda (ignore x ignore) (declare (ignore ignore))...) may be upset when their code breaks. Since it "is an error", not "signals an error", those people are free to criticize their compiler for wasting their time with worthless warnings if it warns about this. It seems clear enough that warning about duplicate parameter names when the parameters are explicitly ignored does no one any good. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 09:59:15 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:16 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51845; Mon 28-Jul-86 21:21:50 EDT Date: Mon, 28 Jul 86 21:21 EDT From: David A. Moon Subject: Proposal #14: THE and VALUES To: common-lisp@SU-AI.ARPA In-Reply-To: , <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, , <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>, <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>, <[G.BBN.COM]23-Jul-86 22:40:33.NGALL>, Message-ID: <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" 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). I agree completely with MacLachlan's comments, enclosed. Both parts of the proposal should be rejected. I do have one query; see below. Plummer's suggestion of a standardized way to coerce a result to a particular number of values sounds useful but should be raised as a separate issue. 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." My question is whether the quoted text (CLtL p.48) is a mistake. It could have been accidentally retained from the days when multiple-value-bind allowed & keywords, or it could be intentional. 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. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 09:56:51 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:04 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51809; Mon 28-Jul-86 20:57:55 EDT Date: Mon, 28 Jul 86 20:57 EDT From: David A. Moon Subject: Proposal #8: Clarifications to DEFCONSTANT To: common-lisp@SU-AI.ARPA In-Reply-To: , <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, Message-ID: <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" Proposal #8: Clarifications to DEFCONSTANT Clarify that using DEFCONSTANT to redefine any constant described in the Common Lisp specification is an error. Non-controversial. 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. Non-controversial, and "is an error" seems clearly the right level, rather than "signals an error." 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.] Do you mean EQL or EQUAL? Consider the example (defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.") I don't see any good justification for reading and evaluating that form twice to be an error. Consider that many Lisp dialects consider EQUAL constants equivalent and coalesce them into EQ objects. Of course EQUAL isn't exactly the right test either, since (equal #(1 2 3) #(1 2 3)) is nil. The appropriate test would be one that compares all elements of structured objects and compares atoms with EQL, which doesn't exist as a predefined function in Common Lisp. Equality was one of the areas where we decided to punt in the interests of getting a language specification out in a finite time, since there wasn't complete agreement on what to do. Perhaps parts 2 and 3 of this proposal properly belong to the system environment, rather than to the programming language, especially when you start talking about such concepts as "compiled code files". Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 09:54:03 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:41:50 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51598; Mon 28-Jul-86 17:32:55 EDT Date: Mon, 28 Jul 86 17:32 EDT From: David A. Moon Subject: Some easy ones (?) To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728173256.1.MOON@EUPHRATES.SCRC.Symbolics.COM> I would find it much easier to follow these discussions if there weren't ten discussions going on simultaneously in the -same- messages. If each discussion was conducted in a different set of messages, I could sort the messages into individual discussions and read each discussion as an uninterrupted, coherent whole. To practice what I preach, I am going to respond to each of the ten proposals in your message of 21 July with a separate message (except for the ones that I don't respond to at all). Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 09:32:06 EDT Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:23:30 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43549; Mon 28-Jul-86 20:24:25 EDT Date: Mon, 28 Jul 86 20:24 EDT From: David A. Moon Subject: Proposal #7: TYPE-SPECIFIER-P To: common-lisp@SU-AI.ARPA In-Reply-To: , <860721-221520-2564@Xerox>, <860722-102542-2911@Xerox>, <860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>, <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>, <860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>, <8607272237.AA21099@lmi-angel.ARPA>, , , <860728111011.1.DCP@FIREBIRD.SCRC.Symbolics.COM>, <860728-123623-2787@Xerox> Message-ID: <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM> TYPE-SPECIFIER-P is an appropriate name for a function that takes an (OR SYMBOL LIST) and tells whether it's a valid specifier. If you're going to replace this with a function that takes a SYMBOL and tells whether it's the name of a type, call it TYPE-NAME-P. However, I agree with Masinter's comment that we should concentrate on fixing what is wrong with the language rather than adding more features. I have no objection to either of TYPE-SPECIFIER-P or TYPE-NAME-P if someone can show why these are needed to fix something wrong with the language. Perhaps Guy can comment on why the original proposal 51 in his clarifications list was tagged with an asterisk indicating that it corrects an important flaw or resolves an ambiguity in the specification. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 06:38:00 EDT Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 03:28:11 PDT Received: from utokyo-relay by csnet-relay.csnet id ac01013; 29 Jul 86 6:31 EDT Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA18879; Tue, 29 Jul 86 16:30:28+0900 Received: by ccut.u-tokyo.junet (4.12/6.1Junet) id AA22657; Tue, 29 Jul 86 16:14:11+0900 Date: Tue, 29 Jul 86 16:14:11+0900 From: Masayuki Ida Message-Id: <8607290714.AA22657@ccut.u-tokyo.junet> To: common-lisp@SU-AI.ARPA, gls%aquinas.think.com@CSNET-RELAY.ARPA, ida%u-tokyo.junet@CSNET-RELAY.ARPA Subject: Re: exit-to-system Date: Mon, 21 Jul 86 15:01 EDT From: Guy Steele Subject: Re: exit-to-system ... 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. ... ... --Guy I agree. The name QUIT sounds reasonable. ida@utokyo-relay.csnet ----- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 01:38:51 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 22:27:13 PDT Received: ID ; Tue 29 Jul 86 01:27:26-EDT Date: Tue, 29 Jul 1986 01:27 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposed moratorium A significant fraction of the readers of this mailing list will be at the Lisp Conference next week. Your moderator will be among them. We all dread the thought of returning to blown-out mailboxes. I would like to request that people refrain from sending technical messages to Common-Lisp from Saturday, August 2, through Thursday, August 7. This brief interlude can be used for catching up on old Common Lisp mail, thinking up new issues, or interacting with the real world (whatever THAT is). This is just a suggestion, but I can't guarantee that mail arriving during that period will be looked at. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 00:08:57 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:54:57 PDT Date: 28 Jul 1986 23:52-EDT Sender: NGALL@G.BBN.COM Subject: Re: Proposal #5 status From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]28-Jul-86 23:52:11.NGALL> In-Reply-To: <860728114007.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 28 Jul 86 11:40 EDT From: David C. Plummer Date: Sun, 27 Jul 1986 18:23 EDT From: "Scott E. Fahlman" The default for documentation-allowed-p is NIL, meaning that this form is NOT allowed to have a documentation string. Can somebody PLEASE give me an example of (a) where this is useful and (b) where this makes a difference? As you point out, forms such as multiple-value-bind, flet, dotimes, etc. are forms that 'are not allowed to have' or 'do not have' doc-strings. Using your example: (multiple-value-bind (a b) (compute) (declare (ignore a b)) "frob" (compute-something-else)) This is still valid. It isn't the greatest style, but there is nothing wrong with it. "frob" is a constant compiled for effect. As I understand the current proposal, calling parse-body on the above "body" would result in an error, which is wrong. The argument should be called no-doc-string-p. It directs the parser to >>stop parsing<< when it encounters a doc-string; it doesn't tell the parser to signal an error. You misunderstood the current proposal. Calling parse-body with doc-string-allowed-p true, would return "frob" as the doc-string, and only one form in the list of 'body' forms. Calling parse-body with doc-string-allowed-p false, would return nil as the doc-string value and two forms (the first being "frob") in the list of body forms. This is how doc-string-allowed-p makes a difference for legal bodies. 1. A documentation string (or NIL if none is present). Why isn't the body first. What if there is more than one doc string? Because the order of the values reflects the order of the components of a body. Why should body be first? There can't be two doc-strings. The second string in a body is always considered a form. 2. A combined list of declaration specs, extracted from all DECLARE forms found at the start of the body, whether present in the body itself or obtained via macro-expansion. This isn't explicit enough. Do I get ((declare (ignore a)) (declare (ignore b))) or do I get (declare (ignore a) (ignore b)) or do I get ((ignore a) (ignore b)) You get the last alternative, 'a list of decl specs'; the other two alternatives are declarations (which contain decl specs). ?? I assume somebody has convinced themselves that the ordering or separation of declares has no semantic meaning in CL? I assumed everyone had. 4. The macro-expansion for the first form in return value 3, if any. Why the macroexpansion of the first form of the body? Why not the body with the first form possibly expanded? Why should I always ,first-form-expanded ,@(rest body) instead of ,@expanded-body ?? As was discussed, some macro expanders may want to see ALL body forms (after decls and doc) before expansion, thus parse-body MUST return all body forms unexpanded. 5. T if return 4 is a valid macro-expansion for the first form in return 3, NIL otherwise. What is an invalid macro expansion? What would this possibly be used for? When could it possibly make a difference? I suppose the same difference that the second value from macroexpand could make. Why not toss in the kitchen sink? It looks to me like design-by-committee disease is striking. What functionality is useful and needed, and what do we need to express it? Ok, I'll bite, what? -- Nick Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Jul 86 00:04:24 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:53:01 PDT Received: ID ; Mon 28 Jul 86 23:53:04-EDT Date: Mon, 28 Jul 1986 23:53 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: Common-Lisp@SU-AI.ARPA Subject: Staus of proposals 10, 11, and 12 In-reply-to: Msg of 28 Jul 1986 11:55-EDT from David C. Plummer Proposal #10: Forms That Allow Declarations I did question the need/usefullness of allowing declarations in MACROLET. Nobody has responded and I still can't think of any. It would come as a nasty surprise to people if MACROLET were different from FLET and LABELS in this respect. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 23:53:52 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:44:40 PDT Received: ID ; Mon 28 Jul 86 23:44:43-EDT Date: Mon, 28 Jul 1986 23:44 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 #7 Status: TYPE-SPECIFIER-P In-reply-to: Msg of 28 Jul 1986 11:10-EDT from David C. Plummer It returns T if it is a meaningful second argument to TYPEP and NIL if not. Is that specific enough? No. "Meaningful" covers a lot of ground, some of it undecidable. But Steele's proposal IS specific enough, in my view. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 23:26:14 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 20:16:38 PDT Received: ID ; Mon 28 Jul 86 23:16:37-EDT Date: Mon, 28 Jul 1986 23: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: Proposal #5 status In-reply-to: Msg of 28 Jul 1986 11:39-EDT from David C. Plummer Can somebody PLEASE give me an example of (a) where this is useful and (b) where this makes a difference? In addition to parsing built-in body-taking forms, this would make it relatively easy for the user to define new macros that take bodies and declarations, with or without a doc string. It was pointed out long ago that every implementation has something like this internally, so we might as well make it accessible to users. 1. A documentation string (or NIL if none is present). Why isn't the body first. What if there is more than one doc string? Things appear in this order in the body (though the doc string and declarations may be swapped), so people suggested that the returns follow the "natural" order. It is an error if more than one doc string is present (page 67). 2. A combined list of declaration specs, extracted from all DECLARE forms found at the start of the body, whether present in the body itself or obtained via macro-expansion. I thought this was clear, at least in context. You get ((ignore a) (ignore b)), without the DECLARES. ?? I assume somebody has convinced themselves that the ordering or separation of declares has no semantic meaning in CL? Yes, unless you have a counter-example. 4. The macro-expansion for the first form in return value 3, if any. Why the macroexpansion of the first form of the body? Why not the body with the first form possibly expanded? It saves a CONS. Why not toss in the kitchen sink? It looks to me like design-by-committee disease is striking. Why is it always the guy who endlessly nit-picks every last unimportant detail who accuses others of design by committee? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 21:59:10 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 18:47:56 PDT Received: ID ; Mon 28 Jul 86 21:45:19-EDT Date: Mon, 28 Jul 1986 21:45 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: [gls: Proposal #7 amendment] This proposal from Guy Steele looks good to me. I think it checks a reasonable amount of stuff and stops short of falling into the abyss. -- Scott --------------------------------------------------------------------------- Proposal #7 amendment (1) First, not directly related to type specifiers, I propose a primitive APPLICABLE that takes arguments just like APPLY, but rather than actually doing the application it just returns T if the application is okay with respect to argument-passing and NIL otherwise. This can be build on top of FUNCTION-PARAMETERS. (2) I propose that there be primitives TYPE-EXPAND and TYPE-EXPAND-1 that are similar to MACROEXPAND and MACROEXPAND-1 but operate on type specifiers. (3) I propose that TYPE-SPECIFIER-P behave as follows: if the argument is a symbol, see whether it is a valid type specifier. If the argument is a list whose car is a symbol, then there are two cases. If it is the name of a primitive type specifier, then check the format of that type specifier, using TYPE-SPECIFIER-P recursively where necessary. If it is the name of a DEFTYPE, then use APPLICABLE to be sure that the type specifier expansion function is getting valid arguments. If not, return NIL; if so, then use TYPE-EXPAND-1 and recur on the result. In summary, TYPE-SPECIFIER-P will make sure a DEFTYPE'd specifier has approximately the right format, but if the code in the specifier function ever signals an error then TYPE-SPECIFIER-P won't catch that. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 21:49:56 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 18:38:52 PDT Received: ID ; Mon 28 Jul 86 21:39:07-EDT Date: Mon, 28 Jul 1986 21:39 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: proposal #6 (&body parsing) In-reply-to: Msg of 28 Jul 1986 12:10-EDT from SANDRA (1) If &rest and &body are not going to be the same anymore, will they remain mutually exclusive? (I can imagine some situations where you might want both a "parsed" and "unparsed" body -- although you could call parse-body yourself instead to get this effect.) I think they should remain mutually exclusive. As you say, the user can always call parse-body directly, in the very rare case where both forms are needed. (2) Will we continue to allow both &body and &key together? This does not make a great deal of sense to me, as a list of keyword/value pairs is not what one typically thinks of as a "body". One would probably never want to use &body and &key together, but I see no reason to go out of our way to outlaw this. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 21:41:15 EDT Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 18:30:15 PDT Date: Mon, 28 Jul 86 21:31:15 EDT From: Alan Bawden Subject: Proposal #9: Variable Name Conflicts To: common-lisp@SU-AI.ARPA In-reply-to: Msg of 28 Jul 86 15:52 PDT from Masinter.pa at Xerox.COM Message-ID: <[AI.AI.MIT.EDU].76807.860728.ALAN> Date: 28 Jul 86 15:52 PDT From: Masinter.pa at Xerox.COM I'd like to request that discussion of this proposal be suspended until after the question of the scope of declarations gets considered. My reason is that one of the primary arguments against duplicate names in a binding form is the ambiguity of referent for declarations. Some of the proposals for declaration scoping would remove the ambiguity. Funny, I was going to suggest exactly the opposite. I was going to suggest that we delay the declarations issue until after we decide the scoping issue. The two clearly have an interaction, the question is do you want the crufty rules for declarations to drive the scoping rules, or vice versa? My instincts say that the variable scoping rules should be clarified first, but clearly other people may see things the other way, so perhaps we can do no better than to continue to deal with them both simultaneously. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 19:40:56 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 16:24:33 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 16:19:42 PDT Date: 28 Jul 86 15:49 PDT From: Masinter.pa@Xerox.COM Subject: Re: Proposal #6 Status: Parsing in &BODY In-reply-to: David C. Plummer 's message of Mon, 28 Jul 86 09:59 EDT To: DCP@QUABBIN.SCRC.Symbolics.COM cc: common-lisp@su-ai.ARPA Message-ID: <860728-161942-3071@Xerox> It was unclear to me whether you are for the &body extension, against it, or have an alternative to propose. I don't think anyone was proposing that (defmacro defun (name bvl &body body) ...) would call parse-body. Only (defmacro defun (name bvl &body body decls) ...) would call parse-body. I suggest rephrasing Proposal #6A to removing the reference to "parse-body", since there's some disagreement about what that function might be. E.g.: Proposal #6A': Extend the syntax of an &BODY parameter to DEFMACRO to allow writing (DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...) If declarations-var is present, then, the original body is parsed, looking for declarations and, when doc-string-var is present, for documentation strings. Body-var is bound to the remaining body, while declarations-var is bound to a list of (declare ...) forms and (when present) doc-string-var to the first documentation string found. During the course of processing the original body, macros are expanded to see if they expand into declarations, although the macro expansion itself is not kept if no declarations are found. Note that a documentation string cannot be the @i[last] element in a body, according to the syntax on p. xxx. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 19:40:19 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 16:24:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 16:23:39 PDT Date: 28 Jul 86 15:52 PDT From: Masinter.pa@Xerox.COM Subject: Re: Proposal #9: Variable Name Conflicts To: common-lisp@SU-AI.ARPA Message-ID: <860728-162339-3074@Xerox> I'd like to request that discussion of this proposal be suspended until after the question of the scope of declarations gets considered. My reason is that one of the primary arguments against duplicate names in a binding form is the ambiguity of referent for declarations. Some of the proposals for declaration scoping would remove the ambiguity. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 18:37:29 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 15:11:26 PDT Date: 28 Jul 1986 17:39-EDT Sender: VERACSD@A.ISI.EDU Subject: Re: Remaining issues From: VERACSD@A.ISI.EDU To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Message-ID: <[A.ISI.EDU]28-Jul-86 17:39:15.VERACSD> In-Reply-To: Please explain what ":-)" means. I've been curious about it for a while, especially after I saw a graphical joke using it. Thanks. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 17:28:48 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 14:01:59 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 14:02:17 PDT Date: 28 Jul 86 13:43 PDT From: Masinter.pa@Xerox.COM Subject: Re: PARSE-BODY To: common-lisp@sail.stanford.edu Message-ID: <860728-140217-2923@Xerox> I am (now) opposed to adding PARSE-BODY to the Common Lisp standard (as long as the parse-body option is added to the macro expansion argument list) for the following reasons: a) it is of little general utility Given the addition of &body variables for macros, I can think of no examples where I would want to directly call parse-body instead of just using the macro-expansion option. (I currently have lots of examples that call parse-body, but they're all in macros that could use the new &body options instead.) b) it is controversial While every implementation will have SOMETHING like parse-body (if only to implement the handing of macro arguments) there seems to be little agreement on what its arguments might be or what values it might return. It would seem that every implementation wants something slightly different (e.g., it depends on whether you cache macro translations as for whether you want to save the macro translation & the work of obtaining it or recompute it.) c) it isn't very simple (This is isn't a simple argument to make, unfortunately.) The value of features is inversly proportional to the complexity of their interfaces. Functions that have a "process-it-this-way-p" arguments and "returns 3 values, but maybe just the first" should be viewed with suspicion, that they don't represent the "true" interface to what is going on in the system. That is, "parse-body" is just a piece of some more complex processing of macros, arguments & bodies that is part of the language writers toolkit, that isn't very isolated. Motivating it (what's this for?) would be difficult without a lot more context. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 17:12:05 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 13:17:11 PDT Date: Mon 28 Jul 86 11:39:52-PDT From: James Rice Subject: Proposal #7A - Type-Specifier-P To: Common-Lisp@SU-AI.ARPA Message-ID: <12226337882.76.RICE@SUMEX-AIM.ARPA> It seems to me that the proposed function Type-Specifier-P is in fact Type-Name-P, since it cannot be called with an arbitrary CL type specifier. Perhaps its name should be changed accordingly. Personally, I would prefer to have (Typep foo 'Type-Specifier) - but then again I'd like all types to be represented by objects of type Type too. Rice ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:45:26 EDT Date: 28 Jul 86 1224 PDT From: System Files Subject: Proposal #6 Status: Parsing in &BODY Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:16:31 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24563; Mon 28-Jul-86 09:58:37 EDT Date: Mon, 28 Jul 86 09:59 EDT From: David C. Plummer Subject: Proposal #6 Status: Parsing in &BODY To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728095907.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 21:01 EDT From: "Scott E. Fahlman" Nobody seems to oppose this. One or two people have questioned its usefulness, but the discussion we had on this a year or so ago demonstrated considerable demand for this as an alternative to making users handle environment objects directly. Most people who commented on this prefer KMP's proposed syntax, though there seems to be little enthusiasm for the inclusion of default and supplied-p values. (Speaking for myself, I'm happy to go along with this if we don't get into default/supplied-p complexities.) So, we have a revised proposal: --------------------------------------------------------------------------- Proposal #6A: Parsing in &BODY Extension: Extend the syntax of an &BODY parameter to DEFMACRO to allow writing (DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...) If DECLARATIONS-VAR is present, it means to give the original body to PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is present) This will break existing code. One can no longer write (defmacro defun (name bvl &body body) ...) because doc-string-var is not supplied and therefore PARSE-BODY, given the direction people want to be taking it, will err because documentation-allowed-p will be false. 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. Sorry for the broken record: A body is a body is a body is a body... A body has declarations and a doc string. 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. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:44:54 EDT Date: 28 Jul 86 1220 PDT From: System Files Subject: Proposal #13: Structure Sharing in Arguments Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:15:21 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24557; Mon 28-Jul-86 09:31:04 EDT Date: Mon, 28 Jul 86 09:31 EDT From: David C. Plummer Subject: Proposal #13: Structure Sharing in Arguments To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728093136.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 23:01 EDT From: "Scott E. Fahlman" The first part of this seems to have generated no controversy. The second part, about &REST arguments, has generated a lot of controversy, in part because it is stated in a way that seems to presuppose that it is OK to destructively modify most lists. We seem to be in agreement that &REST args must be true lists, and must not evaporate when passed upwards or stored in stable storage ; this should be made explicit since it is an occasional source of confusion, as it was in the discussion of this issue. (The issue here is not whether implementations currently comply with this, or even whether they plan to comply with in the future; the issue is what the language spec requires.) We also seem to agree that a good rule is that a list should not ever be destructively modifed unless the programmer understands where it came from and who else might be holding onto it. The remaining contentious issue is whether users may assume that the &REST list in a function is a freshly-consed list, or whether the &REST list may incorporate the list (or part of it) passed as the last argument to APPLY. (Speaking for myself, I initially favored the fresh-consed option as being cleaner, but Weinreb has convinced me that the APPLY optimization is important for some kinds of code. I now believe that we should not outlaw this optimization just so that people can smash &REST args without thinking about the consequences. We're weighing a real source of efficiency against the freedom to do something that most programmers will rarely want to do, and in those cases they can copy to be safe.) It is important that programmers not avoid the &REST feature because they believe it is universally expensive in time and storage. Clarifications: 13A: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy. Therefore, if this argument is destructively modified, the originl text of the macro may also be altered. 13B: Specify explicitly that the &REST argument in a function has indefinite extent and may, for example, be returned to the function's caller. 13C: The &REST list in a function is not necessarily a freshly-consed list. If the function is called with APPLY, the &REST list may share top-level structure with the last argument to the APPLY. Users should keep this in mind if they are considering destructive modifications to such a list. - OR - 13C': The &REST list in a function is freshly consed upon function entry. It shares no top-level structure with any pre-existing list. My opinion still stands: it depends on how hard you look. I still think 13B and 13C are in conflict: (defun copy-list (list) (apply #'list list)) (defun list (&rest list) list) I think 13C' implies global inefficiency and may detract programmers from using &REST. I think the necessary >>semantics<< are 13B and 13C', and that a compiler that can prove the &REST list is being in only downward ways (all destructive modification should be considered "upward") is allowed to keep the list "consed on the stack" in the implementations that work that way, or "shared with last arg to APPLY" in the implementatins that work that way as well/instead. &KEY is essentially a standard deconding of an &REST arg, and &KEY is completely downward and never (unless accompanied by an explicit &REST) needs to freshly cons the implicit &REST arg. We may want to decide on the name of a declaration to override the case when the compiler can't figure it out. (defun 3arg-format (stream string args) (apply #'format stream string args)) (defun send-it (string &rest args) (declare (sys:downward-&rest-arg)) (3arg-format t string args)) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:41:40 EDT Date: 28 Jul 86 1153 PDT From: System Files Subject: Proposal #5 status Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:53:09 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24585; Mon 28-Jul-86 11:39:04 EDT Date: Mon, 28 Jul 86 11:39 EDT From: David C. Plummer Subject: Proposal #5 status To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: References: , <860727-200655-2208@Xerox> Message-ID: <860728113936.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 18:23 EDT From: "Scott E. Fahlman" Here is the first of the status reports on pending proposals. This is culled from a lot of old mail; my apologies in advance if I missed some key suggestion. I suggest that we use this as the starting point for further discussion of this issue (and similarly with the others) and that we try to converge on a final set of proposals for the technical committee fairly soon. All of these summaries are from me as moderator; where I have seen fit in inject one of my personal opinions on some technical matter, that is marked. -- Scott --------------------------------------------------------------------------- There seems to be no opposition to the idea of PARSE-BODY per se. There have been numerous suggestions about the exact form of the arguments and return values, and I have incorporated most of these suggestions into revised proposal 5A below: making the environment and doc-p arguments optional, reordering the returns into what some consider a more natural order, and returning the declarations as a combined list of decl-specs (as the book calls them), without the surrounding DECLAREs. One suggestion by Nick Gall is to add a declaration-allowed-p form. If this is NIL, then PARSE-BODY has the task of ensuring that the body does NOT contain declarations. Some people have responded that this functionality does not belong in PARSE-BODY. (Speaking as SEF, I agree with this view. Nick is free to pursue this further if he wants to, but I suspect that the idea is not going anywhere.) One complex issue is whether the body should be returned in its original form or with any macro-expansion that was computed while looking for initial decls replacing the original body forms. (There will only be one of these, since the first non-declaration stops the expansion.) One would like to avoid doing the work of expansion a second time, but sometimes it is necessary to get at the original body. In 5A below, I propose a solution that may get get the best of both worlds: the body is returned in original form, but there are two additional return values, one indicating the availability of a macro-expansion for the first body form, and the other being that expansion. (Two extra values are necessary because the macro might perversely expand into NIL after doing a lot of work.) --------------------------------------------------------------------------- Proposal #5A: PARSE-BODY Extension: [I somewhat agree with Masinter.] Add a new function: (PARSE-BODY body &optional environment documentation-allowed-p) The default for environment is NIL, meaning to use a null lexical environment. The default for documentation-allowed-p is NIL, meaning that this form is NOT allowed to have a documentation string. Can somebody PLEASE give me an example of (a) where this is useful and (b) where this makes a difference? I can think of one example where it can make a difference, but it also shows that this argument is misguided. There are probably others in the same class. The example is multiple-value-bind, which takes declarations but does not take a doc-string. Now, a doc-string isn't illegal; a string doesn't get interpreted as a string. Consider these cases: (multiple-value-bind (a b) (compute) (declare (ignore a b)) "frob") This is completely reasonable. "frob" isn't a doc-string (even if doc strings were "allowed") because there aren't any forms following. (multiple-value-bind (a b) (compute) (declare (ignore a b)) "frob" (compute-something-else)) This is still valid. It isn't the greatest style, but there is nothing wrong with it. "frob" is a constant compiled for effect. As I understand the current proposal, calling parse-body on the above "body" would result in an error, which is wrong. The argument should be called no-doc-string-p. It directs the parser to >>stop parsing<< when it encounters a doc-string; it doesn't tell the parser to signal an error. (multiple-value-bind (a b) (compute) (declare (ignore a)) "frob" (declare (ignore b)) (compute-something-else)) This IS an error, but since multiple-value-bind doesn't take doc-strings, it will stop parsing when it gets to "frob" and you simply have to let the implicit-progn handler figure it out. PARSE-BODY extracts the documentation string and declarations from BODY, expanding initial macros as necessary to determine if they contain declarations. It returns five values: [A lot of rationale is missing.] 1. A documentation string (or NIL if none is present). Why isn't the body first. What if there is more than one doc string? 2. A combined list of declaration specs, extracted from all DECLARE forms found at the start of the body, whether present in the body itself or obtained via macro-expansion. This isn't explicit enough. Do I get ((declare (ignore a)) (declare (ignore b))) or do I get (declare (ignore a) (ignore b)) or do I get ((ignore a) (ignore b)) ?? I assume somebody has convinced themselves that the ordering or separation of declares has no semantic meaning in CL? 3. The remainder of the BODY argument, following any initial doc-strings, declarations, or forms that expand into declarations. 4. The macro-expansion for the first form in return value 3, if any. Why the macroexpansion of the first form of the body? Why not the body with the first form possibly expanded? Why should I always ,first-form-expanded ,@(rest body) instead of ,@expanded-body ?? 5. T if return 4 is a valid macro-expansion for the first form in return 3, NIL otherwise. What is an invalid macro expansion? Why not toss in the kitchen sink? It looks to me like design-by-committee disease is striking. What functionality is useful and needed, and what do we need to express it? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:41:08 EDT Date: 28 Jul 86 1155 PDT From: System Files Subject: Proposal #5 status Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:54:30 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24586; Mon 28-Jul-86 11:39:35 EDT Date: Mon, 28 Jul 86 11:40 EDT From: David C. Plummer Subject: Proposal #5 status To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: References: , <860727-200655-2208@Xerox> Supersedes: <860728113936.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860728114007.3.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 18:23 EDT From: "Scott E. Fahlman" Here is the first of the status reports on pending proposals. This is culled from a lot of old mail; my apologies in advance if I missed some key suggestion. I suggest that we use this as the starting point for further discussion of this issue (and similarly with the others) and that we try to converge on a final set of proposals for the technical committee fairly soon. All of these summaries are from me as moderator; where I have seen fit in inject one of my personal opinions on some technical matter, that is marked. -- Scott --------------------------------------------------------------------------- There seems to be no opposition to the idea of PARSE-BODY per se. There have been numerous suggestions about the exact form of the arguments and return values, and I have incorporated most of these suggestions into revised proposal 5A below: making the environment and doc-p arguments optional, reordering the returns into what some consider a more natural order, and returning the declarations as a combined list of decl-specs (as the book calls them), without the surrounding DECLAREs. One suggestion by Nick Gall is to add a declaration-allowed-p form. If this is NIL, then PARSE-BODY has the task of ensuring that the body does NOT contain declarations. Some people have responded that this functionality does not belong in PARSE-BODY. (Speaking as SEF, I agree with this view. Nick is free to pursue this further if he wants to, but I suspect that the idea is not going anywhere.) One complex issue is whether the body should be returned in its original form or with any macro-expansion that was computed while looking for initial decls replacing the original body forms. (There will only be one of these, since the first non-declaration stops the expansion.) One would like to avoid doing the work of expansion a second time, but sometimes it is necessary to get at the original body. In 5A below, I propose a solution that may get get the best of both worlds: the body is returned in original form, but there are two additional return values, one indicating the availability of a macro-expansion for the first body form, and the other being that expansion. (Two extra values are necessary because the macro might perversely expand into NIL after doing a lot of work.) --------------------------------------------------------------------------- Proposal #5A: PARSE-BODY Extension: [I somewhat agree with Masinter.] Add a new function: (PARSE-BODY body &optional environment documentation-allowed-p) The default for environment is NIL, meaning to use a null lexical environment. The default for documentation-allowed-p is NIL, meaning that this form is NOT allowed to have a documentation string. Can somebody PLEASE give me an example of (a) where this is useful and (b) where this makes a difference? I can think of one example where it can make a difference, but it also shows that this argument is misguided. There are probably others in the same class. The example is multiple-value-bind, which takes declarations but does not take a doc-string. Now, a doc-string isn't illegal; a string doesn't get interpreted as a string. Consider these cases: (multiple-value-bind (a b) (compute) (declare (ignore a b)) "frob") This is completely reasonable. "frob" isn't a doc-string (even if doc strings were "allowed") because there aren't any forms following. (multiple-value-bind (a b) (compute) (declare (ignore a b)) "frob" (compute-something-else)) This is still valid. It isn't the greatest style, but there is nothing wrong with it. "frob" is a constant compiled for effect. As I understand the current proposal, calling parse-body on the above "body" would result in an error, which is wrong. The argument should be called no-doc-string-p. It directs the parser to >>stop parsing<< when it encounters a doc-string; it doesn't tell the parser to signal an error. (multiple-value-bind (a b) (compute) (declare (ignore a)) "frob" (declare (ignore b)) (compute-something-else)) This IS an error, but since multiple-value-bind doesn't take doc-strings, it will stop parsing when it gets to "frob" and you simply have to let the implicit-progn handler figure it out. PARSE-BODY extracts the documentation string and declarations from BODY, expanding initial macros as necessary to determine if they contain declarations. It returns five values: [A lot of rationale is missing.] 1. A documentation string (or NIL if none is present). Why isn't the body first. What if there is more than one doc string? 2. A combined list of declaration specs, extracted from all DECLARE forms found at the start of the body, whether present in the body itself or obtained via macro-expansion. This isn't explicit enough. Do I get ((declare (ignore a)) (declare (ignore b))) or do I get (declare (ignore a) (ignore b)) or do I get ((ignore a) (ignore b)) ?? I assume somebody has convinced themselves that the ordering or separation of declares has no semantic meaning in CL? 3. The remainder of the BODY argument, following any initial doc-strings, declarations, or forms that expand into declarations. 4. The macro-expansion for the first form in return value 3, if any. Why the macroexpansion of the first form of the body? Why not the body with the first form possibly expanded? Why should I always ,first-form-expanded ,@(rest body) instead of ,@expanded-body ?? 5. T if return 4 is a valid macro-expansion for the first form in return 3, NIL otherwise. What is an invalid macro expansion? What would this possibly be used for? When could it possibly make a difference? Why not toss in the kitchen sink? It looks to me like design-by-committee disease is striking. What functionality is useful and needed, and what do we need to express it? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:40:19 EDT Date: 28 Jul 86 1147 PDT From: System Files Subject: Re: REDUCE args Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:44:47 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24559; Mon 28-Jul-86 09:48:45 EDT Date: Mon, 28 Jul 86 09:49 EDT From: David C. Plummer Subject: Re: REDUCE args To: Skef Wholey , Guy Steele , DCP@QUABBIN.SCRC.Symbolics.COM, NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <860725121309.3.SKEF@WENCESLAS.THINK.COM>, <860725175113.5.GLS@IGNATIUS.THINK.COM> Message-ID: <860728094914.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 25 Jul 86 12:13 EDT From: Skef Wholey From: David C. Plummer Date: Fri, 25 Jul 86 09:55 EDT From: Skef Wholey In the meantime, you can of course do something like: (reduce #'fun (map 'vector #'key sequence)) Somebody brought up this method the last time. I had at least two reactions: (1) It doesn't really express the intent of the programmer, and (2) I don't care what kind of machine you are on, you should care about efficiency and consing. However, it is very easy to write a compiler transform that turns the above into a call to a hidden function that does what the above does without consing. The sequence functions are the most obvious, easiest target for source-level optimization in a Common Lisp compiler. If the above were listed as an idiom in the manual, then such optimizers might appear in implementations. This is a real alternative, not some pie-in-the-sky "a smart compiler could..." argument. I agree this is a real alternative. The in-English thing being expressed is "compute the sum of the car of each element of the sequence." To me "compute the sum of ... the sequence" translates to (reduce #'+ sequence ...) and "the car of" translates to :KEY #'CAR. To you "Compute the sum of" translates to (reduce #'+ ...) and "the car of the sequcnce" translates to (map 'vector #'CAR sequence). Both translations are valid and both are probably correct given today's ideas about programming. Here's my justification for mine: My high level goal is to do something to a sequence. Since I am only doing one thing to the sequence, I want only one sequence operation to be expressed in my code. I feel the argument about consistent use of :KEY, :TEST, and :TEST-NOT still holds. I don't object to adding a field selector argument to REDUCE, but I don't think that it should be called :KEY. One might introduce a new function, REDUCE-FIELD (or whatever), or a new keyword. I've thought about this a little. :TEST/:TEST-NOT should apply before the key is extracted. We can either declare that this test must validiate the key (and must therefore also know how to extract it), or we can add a :KET-TEST arg, defaulting to #'TRUTH (not #'IDENTITY !), which validates the key. Therefore, you could get (defun sum-numeric-cadrs-whose-car-is (expected-car sequence) (reduce #'+ sequence :test #'(lambda (element) (eq (car element) expected-car)) :key #'cadr :key-test #'numberp)) Date: Fri, 25 Jul 86 17:51 EDT From: Guy Steele Date: Fri, 25 Jul 86 11:39 EDT From: David C. Plummer Date: Fri, 25 Jul 86 09:55 EDT From: Skef Wholey In the meantime, you can of course do something like: (reduce #'fun (map 'vector #'key sequence)) Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines, Somebody brought up this method the last time. I had at least two reactions: (1) It doesn't really express the intent of the programmer, and (2) I don't care what kind of machine you are on, you should care about efficiency and consing. I buy your argument (2), but (1) seems to be a bit spurious. Why isn't the intent "take all those keys and reduce them"? If that is the intent, why can't that be expressed as "(take all those keys) and (reduce them)"? Is it that you had rather in mind "reduce all them thar keys" and don't consider the other an equivalent formulation? I think I explained this above. Indeed, (1) probably is a bit spurious. It depends on how you view the problem. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:37:38 EDT Date: 28 Jul 86 1147 PDT From: System Files Subject: Proposal #9 Status: Variable Name Conflicts Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 11:46:30 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24588; Mon 28-Jul-86 11:52:07 EDT Date: Mon, 28 Jul 86 11:52 EDT From: David C. Plummer Subject: Proposal #9 Status: Variable Name Conflicts To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728115240.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Doing the multiple variable name check for PROGV would require an N^2 check at runtime instead of compile time. Consider as an extreme (multiple-value-bind (vars1 vals1) (get-some-vars-and-vals) (multiple-value-bind (vars2 vals2) (get-some-more-vars-and-vals-that-can-override) (progv (append vars1 vars2) (append vals1 vals1) ...implicit-progn...))) One could counter argue that I should be using two PROGVs. I will counter-counter it probably shouldn't make an iota of difference. ps: I only recently read the mail about etiquette. pps: Some context is needed. There was one message about DEFCONSTANT saying everybody agreed. Since I don't have the proposals tacked to my wall, I could barely remember what it was we were all agreeing about. It also took a while to recache what Proposal #9 was all about. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 16:18:56 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:41:05 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 JUL 86 12:36:23 PDT Date: 28 Jul 86 11:52 PDT From: Masinter.pa@Xerox.COM Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P In-reply-to: "Scott E. Fahlman" 's message of Sun, 27 Jul 86 21:44 EDT To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <860728-123623-2787@Xerox> On some further thought, TYPE-SPECIFIER-P is ambiguous in some cases where the argument is a symbol: Suppose you have (deftype relatively-prime-to (n) `(satisfies (lambda (x) (= 1 (gcd x ,n))))) In this case, relatively-prime-to by itself is not "a valid type specifier". (relatively-prime-to 10) is a valid type specifier, and (relatively-prime-to t) is not. Is the intent "is this something I can hand to typep?" If so, it would be false for "relatively-prime-to". If the intent is "does this *name* a type-specifier" then we could allow it, but the usefulness of such a thing is unclear to me. If the notion is "does this symbol name a class of Common Lisp objects," there may be a better way to get at this (e.g., CommonLoops defines classes and it makes sense to ask, is there a class with this name). With all of that, I'd argue against adding this, at this time, for the following reasons: a) it doesn't have well defined semantics, and attempts to narrow the range in order to avoid ambiguity haven't succeeded b) no one has offered a prototypical implementation, or even suggested that they had an implementation for their common lisp against which we could measure its use c) this is a request for a feature, but there's little evidence that there are significant, meaningful, portable uses for it. (Portable = a program written with one Common Lisp's version is likely to run with another Common Lisp's version.) d) of all of the proposals to consider, proposals to add new constructs should get much lower priority than those to clarify or standardize current constructs. e) there is another proposal (before the Object Oriented Programming committee in this case) which satisfies at least part of the original requirement in a different way. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 15:42:51 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:15:21 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24557; Mon 28-Jul-86 09:31:04 EDT Date: Mon, 28 Jul 86 09:31 EDT From: David C. Plummer Subject: Proposal #13: Structure Sharing in Arguments To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728093136.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 23:01 EDT From: "Scott E. Fahlman" The first part of this seems to have generated no controversy. The second part, about &REST arguments, has generated a lot of controversy, in part because it is stated in a way that seems to presuppose that it is OK to destructively modify most lists. We seem to be in agreement that &REST args must be true lists, and must not evaporate when passed upwards or stored in stable storage ; this should be made explicit since it is an occasional source of confusion, as it was in the discussion of this issue. (The issue here is not whether implementations currently comply with this, or even whether they plan to comply with in the future; the issue is what the language spec requires.) We also seem to agree that a good rule is that a list should not ever be destructively modifed unless the programmer understands where it came from and who else might be holding onto it. The remaining contentious issue is whether users may assume that the &REST list in a function is a freshly-consed list, or whether the &REST list may incorporate the list (or part of it) passed as the last argument to APPLY. (Speaking for myself, I initially favored the fresh-consed option as being cleaner, but Weinreb has convinced me that the APPLY optimization is important for some kinds of code. I now believe that we should not outlaw this optimization just so that people can smash &REST args without thinking about the consequences. We're weighing a real source of efficiency against the freedom to do something that most programmers will rarely want to do, and in those cases they can copy to be safe.) It is important that programmers not avoid the &REST feature because they believe it is universally expensive in time and storage. Clarifications: 13A: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy. Therefore, if this argument is destructively modified, the originl text of the macro may also be altered. 13B: Specify explicitly that the &REST argument in a function has indefinite extent and may, for example, be returned to the function's caller. 13C: The &REST list in a function is not necessarily a freshly-consed list. If the function is called with APPLY, the &REST list may share top-level structure with the last argument to the APPLY. Users should keep this in mind if they are considering destructive modifications to such a list. - OR - 13C': The &REST list in a function is freshly consed upon function entry. It shares no top-level structure with any pre-existing list. My opinion still stands: it depends on how hard you look. I still think 13B and 13C are in conflict: (defun copy-list (list) (apply #'list list)) (defun list (&rest list) list) I think 13C' implies global inefficiency and may detract programmers from using &REST. I think the necessary >>semantics<< are 13B and 13C', and that a compiler that can prove the &REST list is being in only downward ways (all destructive modification should be considered "upward") is allowed to keep the list "consed on the stack" in the implementations that work that way, or "shared with last arg to APPLY" in the implementatins that work that way as well/instead. &KEY is essentially a standard deconding of an &REST arg, and &KEY is completely downward and never (unless accompanied by an explicit &REST) needs to freshly cons the implicit &REST arg. We may want to decide on the name of a declaration to override the case when the compiler can't figure it out. (defun 3arg-format (stream string args) (apply #'format stream string args)) (defun send-it (string &rest args) (declare (sys:downward-&rest-arg)) (3arg-format t string args)) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 15:42:49 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:16:31 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24563; Mon 28-Jul-86 09:58:37 EDT Date: Mon, 28 Jul 86 09:59 EDT From: David C. Plummer Subject: Proposal #6 Status: Parsing in &BODY To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728095907.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 21:01 EDT From: "Scott E. Fahlman" Nobody seems to oppose this. One or two people have questioned its usefulness, but the discussion we had on this a year or so ago demonstrated considerable demand for this as an alternative to making users handle environment objects directly. Most people who commented on this prefer KMP's proposed syntax, though there seems to be little enthusiasm for the inclusion of default and supplied-p values. (Speaking for myself, I'm happy to go along with this if we don't get into default/supplied-p complexities.) So, we have a revised proposal: --------------------------------------------------------------------------- Proposal #6A: Parsing in &BODY Extension: Extend the syntax of an &BODY parameter to DEFMACRO to allow writing (DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...) If DECLARATIONS-VAR is present, it means to give the original body to PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is present) This will break existing code. One can no longer write (defmacro defun (name bvl &body body) ...) because doc-string-var is not supplied and therefore PARSE-BODY, given the direction people want to be taking it, will err because documentation-allowed-p will be false. 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. Sorry for the broken record: A body is a body is a body is a body... A body has declarations and a doc string. 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. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 15:42:31 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:16:17 PDT Received: ID ; Mon 28 Jul 86 15:06:41-EDT Date: Mon, 28 Jul 1986 15:06 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 #9 Status: Variable Name Conflicts In-reply-to: Msg of 28 Jul 1986 11:52-EDT from David C. Plummer Doing the multiple variable name check for PROGV would require an N^2 check at runtime instead of compile time. So don't check. This "is an error", not "signals an error". Besides, PROGV is a special-case hack that is inherently slow compared tot eh things people actually use a lot. ps: I only recently read the mail about etiquette. Please read it a couple more times and then meditate on how it might apply to this batch of posts you have just sent. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 15:42:06 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:17:35 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24581; Mon 28-Jul-86 11:09:39 EDT Date: Mon, 28 Jul 86 11:10 EDT From: David C. Plummer Subject: Proposal #7 Status: TYPE-SPECIFIER-P To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728111011.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 21:44 EDT From: "Scott E. Fahlman" Several people have proposed that this be restricted to take only symbols, since that is the most important use, and it becomes hard to specify exactly what things must be checked for correctness in the myriad of more complex cases. (Speaking for myself, I favor this change.) This is proposed in 7A below. This restriction potentially removes some of its usefulness. I can imagine (defun typep (object type-specifier) (assert (type-specifier-p type-specifier) (type-specifier) "~S is not a valid type-specifier" type-specifier) ...etc...) and therefore it can't be restricted to a symbol and indeed must do full semantic checking of the type specifier to make sure it is OK. Therefore, (type-specifier-p '(complex array array)) is legal and returns NIL. If someone wants to argue in favor of handling the more complex type-specifiers as well, I would ask you to provide a specific and detailed proposal for exactly what things must be examined in each case. It returns T if it is a meaningful second argument to TYPEP and NIL if not. Is that specific enough? It was also suggested that we do this by (TYPEP arg 'TYPE-SPECIFIER), but some opposition to this idea has also been expressed, on the grounds that TYPE-SPECIFIER is not really a type in the usual sense. Also, if we did this, it would be awkward to restrict the argument to being a symbol. --------------------------------------------------------------------------- Proposl #7A: TYPE-SPECIFIER-P Proposed extension: Add a new function (TYPE-SPECIFIER-P arg), where ARG must be a symbol. If ARG is a valid type specifier, this returns T; else it returns NIL. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 15:41:26 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 12:20:36 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66682; Mon 28-Jul-86 11:57:11 EDT Date: Mon, 28 Jul 86 11:55 EDT From: David C. Plummer Subject: Staus of proposals 10, 11, and 12 To: Scott E. Fahlman , Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860728115558.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sun, 27 Jul 1986 22:16 EDT From: "Scott E. Fahlman" Proposal #10: Forms That Allow Declarations [This] proposal seems to have generated no controversy. That's fine with me! I did question the need/usefullness of allowing declarations in MACROLET. Nobody has responded and I still can't think of any. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 12:56:20 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 09:44:07 PDT Date: 28 Jul 1986 12:00:48 EDT (Mon) From: Dan Hoey Subject: Re: Proposal #13: Structure Sharing in Arguments To: Common-Lisp@SU-AI.ARPA Message-Id: <522950449/hoey@nrl-aic> In-Reply-To: Daniel L. Weinreb's message of Sat, 26 Jul 86 1712 EDT I would ask for freshly consed &REST lists for all functions, because the alternative is too bug-prone. I am not convinced by the argument against consing APPLY args: Date: Sat, 26 Jul 86 17:12 EDT From: Daniel L. Weinreb ... One of the things that's very useful to do with &rest arguments is to "pass them on down" to further functions, using apply. Having used &rest for a long time, we've found this usage pattern to be extremely common. For example, we have many functions that take several arguments, followed by a FORMAT control string, followed by an arbitrary number of format arguments. We have programs that do this passing-down to many levels of depth. By requiring that the entire list be copied for every such call, the cost of function calling is raised very considerably.... I believe this sort of programming style is best done by passing the &REST arg itself to the lower-level functions, rather than by calling APPLY. In the case of FORMAT, the modification is simply to use "~?". I do not intend this argument to apply to macro arguments. I lean towards the view that macro arguments should NOT be consed--that the &REST argument to a macro should be the list itself. Dan Hoey Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 12:31:11 EDT Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 09:21:49 PDT Date: Mon 28 Jul 86 10:21:58-MDT From: SANDRA Subject: proposal #5 (parse-body) To: common-lisp@SU-AI.ARPA Message-ID: <12226312777.27.LOOSEMORE@UTAH-20.ARPA> Returning 5 values from parse-body seems like overkill to me. I can't think of any examples where it wouldn't be acceptable to return the declarations expanded and the body not. I'd also like to second the proposal to change the syntax to make the doc-allowed-p argument required and only the environment argument optional. -Sandra ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 12:24:55 EDT Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86 09:11:05 PDT Date: Mon 28 Jul 86 10:10:29-MDT From: SANDRA Subject: proposal #6 (&body parsing) To: common-lisp@SU-AI.ARPA Message-ID: <12226310687.19.LOOSEMORE@UTAH-20.ARPA> Two questions: (1) If &rest and &body are not going to be the same anymore, will they remain mutually exclusive? (I can imagine some situations where you might want both a "parsed" and "unparsed" body -- although you could call parse-body yourself instead to get this effect.) (2) Will we continue to allow both &body and &key together? This does not make a great deal of sense to me, as a list of keyword/value pairs is not what one typically thinks of as a "body". -Sandra ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 11:27:56 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jul 86 08:14:33 PDT Received: from kant by Godot.Think.COM via CHAOS; Mon, 28 Jul 86 11:14:44 edt Date: Mon, 28 Jul 86 11:15 EDT From: Guy Steele Subject: Proposal #13: Structure Sharing in Arguments To: DLW@QUABBIN.SCRC.Symbolics.COM, willc%tekchips.tek.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <860728111529.2.GLS@KANT.THINK.COM> Date: Sat, 26 Jul 86 13:55 EDT From: Daniel L. Weinreb Date: 23 Jul 86 13:03:26 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA in any reasonable implementation the &REST argument will have been freshly consed. That's an extremely odd idea. The entire reason that we have &REST arguments at all is to avoid the need for consing the list. Had we intended for the list to be freshly consed, we would never have implemented &REST at all; we'd have just let the caller cons up a list and pass it as a regular argument. Well, Dan, maybe it would be more accurate to say that the entire reason for having &REST arguments is that we want to have N-ary functions such as + but find the old MacLISP LEXPR ("NARGS") mechanism unappealing. The entire reason, in turn to want &REST argument list-structure to have dynamic extent is to avoid consing. In the past I argued that a sufficiently clever compiler (SCC) could do some data flow analysis and recognize when &REST arguments were being used only in certain "safe" ways (such as being fed to a DOLIST) and avoid consing in that case. I now lean more toward also having something like the NARGS mechanism, yukky as it was. --Guy Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 03:36:53 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:01:10 PDT Received: ID ; Sun 27 Jul 86 23:01:24-EDT Date: Sun, 27 Jul 1986 23:01 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #13: Structure Sharing in Arguments The first part of this seems to have generated no controversy. The second part, about &REST arguments, has generated a lot of controversy, in part because it is stated in a way that seems to presuppose that it is OK to destructively modify most lists. We seem to be in agreement that &REST args must be true lists, and must not evaporate when passed upwards; this should be made explicit since it is an occasional source of confusion, as it was in the discussion of this issue. (The issue here is not whether implementations currently comply with this, or even whether they plan to comply with in the future; the issue is what the language spec requires.) We also seem to agree that a good rule is that a list should not ever be destructively modifed unless the programmer understands where it came from and who else might be holding onto it. The remaining contentious issue is whether users may assume that the &REST list in a function is a freshly-consed list, or whether the &REST list may incorporate the list (or part of it) passed as the last argument to APPLY. (Speaking for myself, I initially favored the fresh-consed option as being cleaner, but Weinreb has convinced me that the APPLY optimization is important for some kinds of code. I now believe that we should not outlaw this optimization just so that people can smash &REST args without thinking about the consequences. We're weighing a real source of efficiency against the freedom to do something that most programmers will rarely want to do, and in those cases they can copy to be safe.) Clarifications: 13A: Specify that the &REST or &BODY argument to a macro may be the very list from the macro call, and not a copy. Therefore, if this argument is destructively modified, the originl text of the macro may also be altered. 13B: Specify explicitly that the &REST argument in a function has indefinite extent and may, for example, be returned to the function's caller. 13C: The &REST list in a function is not necessarily a freshly-consed list. If the function is called with APPLY, the &REST list may share top-level structure with the last argument to the APPLY. Users should keep this in mind if they are considering destructive modifications to such a list. - OR - 13C': The &REST list in a function is freshly consed upon function entry. It shares no top-level structure with any pre-existing list. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 03:36:30 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:45:13 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 27 JUL 86 20:45:30 PDT Date: 27 Jul 86 20:45 PDT From: Miller.pa@Xerox.COM Subject: Re: Proposal #9B suggested modification In-reply-to: "Scott E. Fahlman" 's message of Sun, 27 Jul 86 22:02 EDT To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <860727-204530-2232@Xerox> Proposal #9B: Same, but don't include LET* or DO* Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 03:36:22 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:46:02 PDT Received: from Salvador.ms by ArpaGateway.ms ; 27 JUL 86 20:46:16 PDT From: masinter.PA@Xerox.COM Date: 27 Jul 86 20:45:26 PDT Subject: Re: discussion In-reply-to: Your message of Sun, 27 Jul 86 23:12 EDT, To: FAHLMAN@C.CS.CMU.EDU cc: common-lisp@su-ai.ARPA Message-ID: <860727-204616-2233@Xerox> I reread my message, and lest anyone think otherwise, I think you're doing a great job as moderator and want to thank you for taking up a difficult task. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 03:36:13 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:06:46 PDT Received: from Salvador.ms by ArpaGateway.ms ; 27 JUL 86 20:06:55 PDT From: masinter.PA@Xerox.COM Date: 27 Jul 86 20:06:05 PDT Subject: Re: Proposal #5 status In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Sun, 27 Jul 86 18:23 EDT, To: FAHLMAN@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <860727-200655-2208@Xerox> the reason I gave you only 7 points out of 10 on being a moderator (besides that I'm a tough grader) is that you took the opportunity under the guise of "summarizing" to submit another proposal. I don't like returning 5 values when 3 well chosen ones will do, like Swiss Army Knife software. Of all of the proposals, I liked the one which returned any declarations expanded and the body non-expanded the best; I liked it better than your new synthesis, where in the common case the parse-body code has to return more, and the caller has to discard more. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Jul 86 03:36:03 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 20:08:19 PDT Received: ID ; Sun 27 Jul 86 23:05:03-EDT Date: Sun, 27 Jul 1986 23:05 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Remaining issues Issue 14 (about THE and VALUES) and the declaration scope stuff are in a messy state right now. I'll try to sort them out, but it won't happen for another day or two. I just didn't want you all to panic because you weren't getting enough mail from me. :-) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 22:33:04 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 19:16:08 PDT Received: ID ; Sun 27 Jul 86 22:16:27-EDT Date: Sun, 27 Jul 1986 22:16 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: Staus of proposals 10, 11, and 12 Proposal #10: Forms That Allow Declarations Proposal #11: Contents of Tagbody Proposal #12: Unique Names For Tags These proposal seems to have generated no controversy. That's fine with me! Someone asked why we allow numbers as tags. This was done because it seemed harmless and some old code had such things. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 22:18:23 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 19:02:29 PDT Received: ID ; Sun 27 Jul 86 22:02:48-EDT Date: Sun, 27 Jul 1986 22:02 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #9 Status: Variable Name Conflicts It was proposed by Gall to extend this to cover LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. It was argued by Freeman and later by Masinter that LET* should not be on this list, since it is not ambiguous what should happen in these contexts. Fahlman argued in favor of Gall's proposal, on the grounds of simplicity, the LET* exception being of very dubious value. It was agreed that this is a matter of taste and that both forms should go to the technical committee. --------------------------------------------------------------------------- Proposal #9A: Clarification: It is an error for two parameters (including supplied-p and &aux parameters) in the same lambda list to be represented by the same (EQ) symbol. This also holds for parameters bound by LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG. --------------------------------------------------------------------------- Proposal #9B: Same, but don't include LET*. --------------------------------------------------------------------------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 22:06:00 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:50:16 PDT Received: ID ; Sun 27 Jul 86 21:48:26-EDT Date: Sun, 27 Jul 1986 21:48 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #8 Status: Clarifications to DEFCONSTANT There seems to have been no disagreement with this one. Maybe there are SOME easy issues after all. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 22:00:47 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:44:23 PDT Received: ID ; Sun 27 Jul 86 21:44:43-EDT Date: Sun, 27 Jul 1986 21:44 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #7 Status: TYPE-SPECIFIER-P Several people have proposed that this be restricted to take only symbols, since that is the most important use, and it becomes hard to specify exactly what things must be checked for correctness in the myriad of more complex cases. (Speaking for myself, I favor this change.) This is proposed in 7A below. If someone wants to argue in favor of handling the more complex type-specifiers as well, I would ask you to provide a specific and detailed proposal for exactly what things must be examined in each case. It was also suggested that we do this by (TYPEP arg 'TYPE-SPECIFIER), but some opposition to this idea has also been expressed, on the grounds that TYPE-SPECIFIER is not really a type in the usual sense. Also, if we did this, it would be awkward to restrict the argument to being a symbol. --------------------------------------------------------------------------- Proposl #7A: TYPE-SPECIFIER-P Proposed extension: Add a new function (TYPE-SPECIFIER-P arg), where ARG must be a symbol. If ARG is a valid type specifier, this returns T; else it returns NIL. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 21:54:15 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:38:18 PDT Received: ID ; Sun 27 Jul 86 21:27:41-EDT Date: Sun, 27 Jul 1986 21:27 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Bob Krajewski Cc: common-lisp@SU-AI.ARPA Subject: PARSE-BODY In-reply-to: Msg of 27 Jul 1986 18:35-EDT from Bob Krajewski ...I'm still confused about the macroexpansion to find documentation strings and declarations: did the spec for Common Lisp ever have a say on this issue ? Yes, see pages 153 and 154. It was discovered some time later that this, coupled with the existence of macro-let, requires body-parsing macros to get hold of the appropriate lexical environment (at least the part of it that defines local macros) in order to correctly do this expansion. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 21:25:46 EDT Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:10:35 PDT Date: Sun, 27 Jul 86 21:21:05 EDT From: Alan Bawden Subject: Ordering suggestion To: Common-Lisp@SU-AI.ARPA Message-ID: <[AI.AI.MIT.EDU].76316.860727.ALAN> I suggest that the PARSE-BODY and &BODY extension issues really should be delayed until after the declaration scoping issue has been resolved. Given that under most declaration proposals it is difficult to write a macro that correctly redistributes the declarations found in a macro call to the proper places in the expansion, it might be reasonable to use PARSE-BODY to further classify declarations somehow. Please note that I am not proposing to do this (yet), I'm not even certain I think this is a good idea. Debate on the merits of the suggestion are probably out of line. I'm just suggesting that we finish the declaration issue before any more work on PARSE-BODY/&BODY. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 21:23:26 EDT Received: from MIT-EDDIE.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:07:20 PDT Received: by EDDIE (5.31/4.7) id AA07721; Sun, 27 Jul 86 18:36:34 EDT Received: by lmi-angel.ARPA (4.12/4.7) id AA21083; Sun, 27 Jul 86 18:35:58 edt Date: Sun, 27 Jul 86 18:35:58 edt From: Bob Krajewski Message-Id: <8607272235.AA21083@lmi-angel.ARPA> To: common-lisp@sail.stanford.edu Subject: PARSE-BODY Perhaps the argument list of PARSE-BODY should be (BODY DOCUMENTATION-ALLOWED-P &OPTIONAL ENVIRONMENT) to correspond with MACROEXPAND and friends (ENVIRONMENT being optional). The most reasonable order of values would seem to be body, declarations (as an alist, as MLY suggested), and the documentation string (that should go last since forms do not always allow it. I'm still confused about the macroexpansion to find documentation strings and declarations: did the spec for Common Lisp ever have a say on this issue ? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 21:22:50 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 18:01:13 PDT Received: ID ; Sun 27 Jul 86 21:01:31-EDT Date: Sun, 27 Jul 1986 21:01 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #6 Status: Parsing in &BODY Nobody seems to oppose this. One or two people have questioned its usefulness, but the discussion we had on this a year or so ago demonstrated considerable demand for this as an alternative to making users handle environment objects directly. Most people who commented on this prefer KMP's proposed syntax, though there seems to be little enthusiasm for the inclusion of default and supplied-p values. (Speaking for myself, I'm happy to go along with this if we don't get into default/supplied-p complexities.) So, we have a revised proposal: --------------------------------------------------------------------------- Proposal #6A: Parsing in &BODY Extension: Extend the syntax of an &BODY parameter to DEFMACRO to allow writing (DEFMACRO name (... &BODY body-var [declarations-var [doc-string-var]]) ...) If DECLARATIONS-VAR is present, it means to give the original body to PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is present) 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. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 19:52:03 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 16:36:33 PDT Received: ID ; Sun 27 Jul 86 19:36:28-EDT Date: Sun, 27 Jul 1986 19:36 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Bob Krajewski Cc: common-lisp@SU-AI.ARPA Subject: TYPE-SPECIFIER-P In-reply-to: Msg of 27 Jul 1986 18:37-EDT from Bob Krajewski I agree with you. TYPE-SPECIFIER doesn't seem like a type to me, but rather like some sort of meta-thing. I would find it a bit confusing to include it among the types, though this is not one of the issues I can get very passionate about. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 19:09:02 EDT Received: from MIT-EDDIE.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 86 15:53:39 PDT Received: by EDDIE (5.31/4.7) id AA07726; Sun, 27 Jul 86 18:36:40 EDT Received: by lmi-angel.ARPA (4.12/4.7) id AA21099; Sun, 27 Jul 86 18:37:02 edt Date: Sun, 27 Jul 86 18:37:02 edt From: Bob Krajewski Message-Id: <8607272237.AA21099@lmi-angel.ARPA> To: common-lisp@sail.stanford.edu Subject: TYPE-SPECIFIER-P I'm not sure if there really needs to a new type specifier (TYPE-SPECIFIER), to go along with this. The Common Lisp type system should be used for the discrimination of Lisp objects, whereas type specifiers are a kind of ``application'' of Lisp objects for a special purpose (the representation of types). TYPE-SPECIFIER doesn't have the same kind of intrinsic quality that STRING or VECTOR does. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 18:38:50 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 15:23:43 PDT Received: ID ; Sun 27 Jul 86 18:24:02-EDT Date: Sun, 27 Jul 1986 18:23 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #5 status Here is the first of the status reports on pending proposals. This is culled from a lot of old mail; my apologies in advance if I missed some key suggestion. I suggest that we use this as the starting point for further discussion of this issue (and similarly with the others) and that we try to converge on a final set of proposals for the technical committee fairly soon. All of these summaries are from me as moderator; where I have seen fit in inject one of my personal opinions on some technical matter, that is marked. -- Scott --------------------------------------------------------------------------- There seems to be no opposition to the idea of PARSE-BODY per se. There have been numerous suggestions about the exact form of the arguments and return values, and I have incorporated most of these suggestions into revised proposal 5A below: making the environment and doc-p arguments optional, reordering the returns into what some consider a more natural order, and returning the declarations as a combined list of decl-specs (as the book calls them), without the surrounding DECLAREs. One suggestion by Nick Gall is to add a declaration-allowed-p form. If this is NIL, then PARSE-BODY has the task of ensuring that the body does NOT contain declarations. Some people have responded that this functionality does not belong in PARSE-BODY. (Speaking as SEF, I agree with this view. Nick is free to pursue this further if he wants to, but I suspect that the idea is not going anywhere.) One complex issue is whether the body should be returned in its original form or with any macro-expansion that was computed while looking for initial decls replacing the original body forms. (There will only be one of these, since the first non-declaration stops the expansion.) One would like to avoid doing the work of expansion a second time, but sometimes it is necessary to get at the original body. In 5A below, I propose a solution that may get get the best of both worlds: the body is returned in original form, but there are two additional return values, one indicating the availability of a macro-expansion for the first body form, and the other being that expansion. (Two extra values are necessary because the macro might perversely expand into NIL after doing a lot of work.) --------------------------------------------------------------------------- Proposal #5A: PARSE-BODY Extension: Add a new function: (PARSE-BODY body &optional environment documentation-allowed-p) The default for environment is NIL, meaning to use a null lexical environment. The default for documentation-allowed-p is NIL, meaning that this form is NOT allowed to have a documentation string. PARSE-BODY extracts the documentation string and declarations from BODY, expanding initial macros as necessary to determine if they contain declarations. It returns five values: 1. A documentation string (or NIL if none is present). 2. A combined list of declaration specs, extracted from all DECLARE forms found at the start of the body, whether present in the body itself or obtained via macro-expansion. 3. The remainder of the BODY argument, following any initial doc-strings, declarations, or forms that expand into declarations. 4. The macro-expansion for the first form in return value 3, if any. 5. T if return 4 is a valid macro-expansion for the first form in return 3, NIL otherwise. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 12:52:26 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 86 09:36:19 PDT Received: ID ; Sun 27 Jul 86 12:36:38-EDT Date: Sun, 27 Jul 1986 12:36 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Summary of current issues This is your moderator: The following issues are currently under discussion: Proposals 1 - 4 if anyone feels that they were deprived of a chance to comment on these because of the speed with which they went by. The proposals have been sent to the technical committee, but voting will probably not be completed before the Lisp conference. Proposals 5 - 14. I will send out a message on each of these later today, summarizing as best I can where the debate stands on each of them. The proposed changes to the scoping rules for Special and other declarations. I will try to formulate the various suggestions into a couple of specific alternative proposals we can shoot at. The proposal to eliminate the FIXNUM data type or to hide it in the SYSTEM package. I believe that the proponents of this change are now willing to accept a clearer warning in the new specification about the portability issues raised by the use of the FIXNUM declaration. Unless someone requests an official decision from the technical committee on this, I propose to drop this issue and retain the status quo (with the stronger warning). The proposal to add something like GC and BYE functions to the language. Many variations on this theme have been proposed. However, I believe that there is a substantial body of opposition to the whole idea, on the grounds that it is very hard to come up with any sort of definition for these things that makes sense across all implementations, and that these things are therfore handled better as system-specific environment extensions, outside the standard. We have many more essential issues to discuss now, so I propose to put these issues back on the queue as part of an item on what environment interface functions we want to have in the standard, if any. If there are other things that were touched on in recent debate and that you want to add to the discussion queue, contact me directly. Please do not send new issues to the mailing list directly. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 02:09:28 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 22:53:17 PDT Received: ID ; Sun 27 Jul 86 01:53:35-EDT Date: Sun, 27 Jul 1986 01:53 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Rules clarification In-reply-to: Msg of Sat 26 Jul 86 18:38 ??? from SCOTT This is your moderator again: [ Messages from me in the role of moderator will carry some version of the above label. Otherwise, just assume that it is Scott Fahlman, one of the many random participants in various design debates. I will try to keep these roles separate, though it won't always be easy. ] This mailing list is not ONLY for proposals and formal debate. We also need a technical communication channel for use by the Common Lisp community, and at present we have only the one mailing list. We may need to fix that -- let's see how this goes. Queries about what is currently legal, in the opinion of the rest of us, are allowed. So are queries about how people have implemented various things. If these queries result in debates or proposed clarifications, then at some point we must invoke the formal mechanism that regulates such things, or we'll be swamped all over again. In the case of Safier's message, it was already a proposal, not a query, and was on an issue likely to result in some debate. That's why he should not have introduced it directly onto the list in the middle of other discussions, instead of going through the moderator. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 01:47:14 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 22:26:28 PDT Received: ID ; Sun 27 Jul 86 01:26:29-EDT Date: Sun, 27 Jul 1986 01:26 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: SCOTT Cc: common-lisp@SU-AI.ARPA Subject: Proposal 13 In-reply-to: Msg of Sat 26 Jul 86 18:38 ??? from SCOTT This is your moderator speaking: Scott Safier collects the first flame under the new dictatorial policy. We'll make it a gentle one this time. The business about limits on &rest args is a new issue disguised as discussion of issue 13. PLEASE DO NOT RESPOND TO THIS. if he wants to discuss this new issue, I have descirbe the proper procedure for introducing it. (No, I didn't put him up to this, but I should have.) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Jul 86 01:21:02 EDT Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 26 Jul 86 22:02:16 PDT Received: from cgi by csnet-relay.csnet id aa11866; 27 Jul 86 1:04 EDT Date: Sat, 26 Jul 86 18:38 ??? From: SCOTT To: common-lisp@SU-AI.ARPA Subject: RE: Proposal 13 I beleive that proposal 13 is a good one. A user of common lisp should be warned that an implemenation of &rest might share structure with some other list, or that &rest arguments may not be "freshly consed". However, some implementations of common lisp which cons &rest arguments from the stack have also imposed a limit on the number of values which &rest can take. The upper limit for the particular implementation in question seems to be 212 values. If any more than 212 values are passed as an &rest argument, some internal stack overflows. This implementation restriction makes it extremely difficult to write portable code (and possibly impossible to code the particular task that we are currently working on). Although common lisp implementations should be allowed to cons &rest arguments from the stack, they should not be allowed to impose a limit on the number of values which can be passed to an &rest. -Scott Safier Carnegie Group Inc (SAFIER@CGI.CSNET) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Jul 86 22:29:56 EDT Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 19:13:29 PDT Date: Sat, 26 Jul 86 22:23:50 EDT From: Alan Bawden Subject: Some easy ones (?) To: common-lisp@SU-AI.ARPA, masinter.PA@XEROX.COM In-reply-to: Msg of 26 Jul 86 18:22:55 PDT from masinter.PA at Xerox.COM Message-ID: <[AI.AI.MIT.EDU].76153.860726.ALAN> Date: 26 Jul 86 18:22:55 PDT From: masinter.PA at Xerox if you want simplicity, allowing duplicate names and just saying that the last one shadows all the rest, ... (defun foo () (let((a 1)(a 2)) a)) would return 2, etc.... I was going to suggest exactly this. The only thing I would add is that in cases like the above, a good compiler should issue a warning about the variable named "A" that was bound but never referenced. Thus most (not all) cases where a duplicated variable was the result of programmer error will be brought to the programmer's attention. Other cases, such as the LET* examples recently exhibited, will not provoke this warning from the compiler. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Jul 86 22:12:22 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 18:55:17 PDT Received: ID ; Sat 26 Jul 86 21:49:33-EDT Date: Sat, 26 Jul 1986 21:49 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: Some easy ones (?) In-reply-to: Msg of 26 Jul 1986 21:22-EDT from masinter.PA at Xerox.COM if you want simplicity, allowing duplicate names and just saying that the last one shadows all the rest, both for references & for declarations, would be the simplest rule. By no conceivable stretch of the imagination (mine, anyway) is this rule simpler than saying "it is an error". I can't even figure out what you mean by "the last one shadows all the rest for declarations", though I could probably guess. As I said earlier, we've got a matter of design taste here and further discussion is probably not going to change any minds. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Jul 86 21:41:59 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jul 86 18:24:48 PDT Received: from Salvador.ms by ArpaGateway.ms ; 26 JUL 86 18:23:47 PDT From: masinter.PA@Xerox.COM Date: 26 Jul 86 18:22:55 PDT Subject: Re: Some easy ones (?) In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Sat, 26 Jul 86 15:55 EDT, To: FAHLMAN@C.CS.CMU.EDU cc: Andy Freeman , common-lisp@SU-AI.ARPA Message-ID: <860726-182347-1898@Xerox> if you want simplicity, allowing duplicate names and just saying that the last one shadows all the rest, both for references & for declarations, would be the simplest rule. (defun foo (a a ) (declare (special a)) ...) then the second a would get the special binding. (defun foo () (let((a 1)(a 2)) a)) would return 2, etc. Its a very simple rule. Its probably an easier rule to understand than "its illegal, but lots of interpreters & compilers don't check for illegality". Its not hard to implement in the interpreter or the compiler, you just have to be careful about what order you do things in. There's lots of things you can do in Common Lisp that are bad style. There's no reason to omit language features just because they're bad programming style... the compiler isn't a style-checker. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Jul 86 19:48:53 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 16:26:00 PDT Received: ID ; Sat 26 Jul 86 19:26:18-EDT Date: Sat, 26 Jul 1986 19:26 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Mailing list etiquette I was about to send a message of my own on mailing list etiquette when RPG's mail went by. I endorse everything he says (in that message!), and would like to add a few things. As you all have seen by now, the volume of mail on this list is tremendous. A number of people, including some members of the technical committee, are having trouble keeping up, and the task of catching up if you're off the network for a couple of days is daunting. Important issues are being buried by less important ones. I intend to slow down the pace a bit. People are travelling in the summer, and some have objected at the speed with which issues 1 - 4 went by. It was probably a mistake to introduce 10 new issues at once; I forgot that there are NO easy issues in language design. On the other hand, we cannot slow things down too much. A glance at the issues file reveals that we've got something like 100 small issues to decide as of now, with more to come, plus several very large ones like the error and object-oriented facilities. We have to keep moving at a fast pace or this will take years. Also, as things are going now, if I were to slow down the pace, others would slip more issues of their own into the gaps. If we are to make progress at a reasonable rate and not burn out a lot of people whose inputs we need, we are going to have to slow up the pace somewhat and work hard to make the discussions more coherent. I'm hoping that this can be accomplished by a certain amount of informal pressure from the moderator (me). If not, we'll have to consider more radical measures, such as moving a lot of these discussions to another list with fewer people on it. Nobody likes that idea, so we'll avoid it as long as possible. Let me suggest some guidelines for this discussion. If you don't like these guidelines, reply to me privately; the last thing we need right now is a discussion on this mailing list about the rules for discussions on this mailing list. 1. Only the moderator (that's me) gets to introduce NEW issues for discussion. If you've got some issue or proposal that you think we should discuss, send it to me. I'll either send it on to the mailing list, queue it on the issues list for later discussion, try to talk you out of this idea, or work with you to debug the idea. Anyone who sends a random new proposal directly to Common Lisp will get flamed at by the moderator. Anyone who starts discussing an out-of-order proposal will be flamed at as well. If flaming doesn't work, we have other methods for neutralizing repeat offenders. 2. I will from time to time remind people of what topics are currently on the table. Each proposal will have a number; messages relating to a specific proposal should include that proposal's number in the header. (I haven't been doing this consistently myself, but I will start.) Issues that have not yet matured into proposals will be given some other unique identifier such as "Scope of special declarations". 3. From time to time I will try to close off discussions that have reached the point of diminishing returns. Sometimes this will take the form of sending the issues on to the technical committee. Sometimes I will declare that a proposal seems to be going nowhere and should be dropped. In the latter case, the proposer may demand that the full technical committee rule on his decision, since I alone am not able to make binding technical decisions. In such cases, the issue will be sent to the technical committee, along with my comments, for appropriate action. (As a one time exception, since some people were taken by surprise, comments on issues 1 - 4 are still allowed up until the time when the technical committee's decision is announced.) 4. It is legitimate to endorse proposals, argue against them, or propose amendments. If you're not sure whether an amendment is worth proposing (for example, if you are not sure whether it is "too radical a change to consider" I encourage you to send it to me or to some other person whose judgement you respect to get a second opinion before you send this on to the whole list. At the least, this will help to insure that amendments are not obviously absurd or ill-formed; we all have blind spots. As moderator, I reserve the right to rule certain amendments out of order if I think that they are really totally new topics in disguise or if I think that they will distract people from more important discussions that are going on. We'll come back to such amendments later, unless the proposer agrees to withdraw them. 5. PLEASE try to keep your messages short and to the point. As RPG suggested, include only those parts of earlier messsages that are necessary to establish context. When replying to another message, the person you are addressing should be in the TO field and Common Lisp in the CC field; don't let a lot of other names accumulate in the CC's. If a you've fallen behind in your mail reading, read through all the new messages FIRST, then go back and respond if you must. The most irritating kind of message to get is one that jumps into the middle of an old argument after the protagonists have reached a reasonable conclusion (or the moderator has ruled the discussion out of order). 6. Always take the time to compose the clearest message you can, and when you're done ask yourself once again whether sending the message is really useful. Becoming the #1 message generator will make you famous in the lisp community, but it may not be the kind of fame you want. As moderator, I sometimes will need to respond quickly to keep the debate from wandering off in useless directions; the rest of you don't have that excuse. Don't put too much into any one message, and don't try to toss out more than one really clever idea per week; NOBODY has more than one clever idea per week. If we all try to follow these guidelines, we may be able to finish this job in finite time. It remains to be seen whether a task of this complexity can be done by a group of this size, but it certainly cannot be done if things go on as they have been. Your servant (for as long as I can stand the pace), Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Jul 86 19:44:05 EDT Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 26 Jul 86 16:26:27 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA19126; Sat, 26 Jul 86 17:26:37 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA01397; Sat, 26 Jul 86 17:26:34 MDT Date: Sat, 26 Jul 86 17:26:34 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8607262326.AA01397@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Proposal #13: Structure Sharing in Arguments 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 Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes: >We are then left with something like Guy's rule: In general, it is not >safe to do destructive operations on a list unless you know where it >came from and who else might be holding on to it. We teach our students this already, although most textbooks seem to have only a token warning against it. Perhaps the new standard should print this in red with purple polka-dots? stan Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 17:49:15 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 14:32:58 PDT Received: ID ; Sat 26 Jul 86 17:33:08-EDT Date: Sat, 26 Jul 1986 17:33 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: Proposal #13: Structure Sharing in Arguments In-reply-to: Msg of 26 Jul 1986 17:12-EDT from Daniel L. Weinreb Well, OK, if calling APPLY on a rest-arg really is not as rare as I thought because of applications like the one you describe, then maybe it is important to allow implementations to skip the copying in this case. We are then left with something like Guy's rule: In general, it is not safe to do destructive operations on a list unless you know where it came from and who else might be holding on to it. A list obtained as a rest arg is just one of the cases you have to copy before mashing, and when in doubt you have to copy. Something like this rule probably needs to be stated explicitly anyway, since some people seem to assume that it is OK to bash lists unless you can prove that it isn't OK. -- Scott Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 17:29:19 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 26 Jul 86 14:11:18 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50754; Sat 26-Jul-86 17:10:46 EDT Date: Sat, 26 Jul 86 17:12 EDT From: Daniel L. Weinreb Subject: Proposal #13: Structure Sharing in Arguments To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860726171228.4.DLW@CHICOPEE.SCRC.Symbolics.COM> OK, I was exaggerating or overstating to the point of misstating myself; I apologize. The reason for the &rest feature, as defined, is so that functions can take arbitrary numbers of arguments, without going through the obscure locution of consing up a semantically unnecessary list, and without various problems of the Maclisp "LEXPR" construct, and without undue inefficiency. However, I don't think it's acceptable to require that the list be freshly consed. Your message disregards an important case. One of the things that's very useful to do with &rest arguments is to "pass them on down" to further functions, using apply. Having used &rest for a long time, we've found this usage pattern to be extremely common. For example, we have many functions that take several arguments, followed by a FORMAT control string, followed by an arbitrary number of format arguments. We have programs that do this passing-down to many levels of depth. By requiring that the entire list be copied for every such call, the cost of function calling is raised very considerably. Such an extreme penalty will strongly encourage programmers either to stay away from function calling in such circumstances, or go back to explicitly consing up lists in order to prevent the cost of copying. I hope this clarifies what I was trying to say. Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 17:01:01 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 13:34:23 PDT Received: ID ; Sat 26 Jul 86 16:34:30-EDT Date: Sat, 26 Jul 1986 16:34 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: Proposal #13: Structure Sharing in Arguments In-reply-to: Msg of 26 Jul 1986 13:55-EDT from Daniel L. Weinreb From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA in any reasonable implementation the &REST argument will have been freshly consed. That's an extremely odd idea. The entire reason that we have &REST arguments at all is to avoid the need for consing the list. Had we intended for the list to be freshly consed, we would never have implemented &REST at all; we'd have just let the caller cons up a list and pass it as a regular argument. THAT's an extremely odd idea, in my view. It seems to me that the entire reason we have &REST args is to allow users to call functions with arbitrary numbers of arguments, and we inherited the &REST syntax from MUDDLE or somewhere. If the idea was to avoid consing up a list, why in the world did we specify that &REST returns a list, instead of defining some version of LEXPR that passes back the extra args one by one upon request. (As I said earlier, I will be proposing soon that we add something along those lines. The lack of a non-consing way of handling arbitrary numbers of arguments is a big omission in the language.) If we ignore stack-consing, we see that in the overwhelming majority of cases the &REST list will necessarily be freshly consed from distinct arguments that were passed to the function. Only in the case of the last arg to APPLY is there a pre-existing list around that could be incorporated into the &rest structure, and I now believe that we should just require this list to be copied so the the whole issue goes away. It won't affect overall efficiency in any noticeable way. -- Scott Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 16:57:35 EDT Date: 26 Jul 86 1308 PDT From: Dick Gabriel Subject: An Etiquette Request from your Mailing List Maintainer To: common-lisp@SU-AI.ARPA Having been away from the Bay Area for 1 week, I returned to 260 Common Lisp messages. I found the topics and arguments intriguing, but I found the mail itself maddening. The problem is that almost all of the messages that were responses to others included the text of the messages to which they were responding. That is, many messages looked like this: I would like to suggest that people who send comments to this list spend some time thinking about how to best present their comments in such a way that the duplication of messages is minimized. I realize that sometimes the original messages must be partially included. Examples of message-senders who send well-presented messages are Weinreb and Fahlman. Please try to imitate their message-sending style. When you feel you must send parts of other messages, only send the parts required and only enough of the header to identify the exact message for people who wish to consult their own archives for the original. One aspect of message-response that I wish to pessimize is the message-responder's effort. Taking the time to compose a well-presented response gives you time to think about your response and whether it is truly necessary to send. Your mail goes to many hundreds, if not thousands, of people. Thank you. -rpg- Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 16:15:08 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jul 86 12:55:50 PDT Received: ID ; Sat 26 Jul 86 15:56:03-EDT Date: Sat, 26 Jul 1986 15:55 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Andy Freeman Cc: common-lisp@SU-AI.ARPA Subject: Some easy ones (?) In-reply-to: Msg of 26 Jul 1986 14:25-EDT from Andy Freeman CL has thus far avoided most prescriptive style issues. This is not a prescriptive style issue per se. It is a question of whether we should add a complex epicycle to the language in order to accommodate a style that some of us think is worthless at best and confusing at worst. I don't think the language spec should go out of its way to stop you from using a confusing style, but I don't think it should bend over backwords to make this possible. This has come down to a matter of taste. I think that you're asking for an ugly exception in order to support a deeply bogus piece of programming style; you think that this is not an exception, but recognizes some "difference" between LET* and other forms such as LET and LAMBDA, and you also think that this funny use of LET* is more obvious than the equivalent form using SETQs or nested LET's. OK, since it's a just a matter of design taste -- we both agree that it will work either way -- I'll propose both alternatives and we'll see what the technical committee decides. I think we've stated our respective cases at sufficient length. -- Scott P.S. Just so nobody gets the wrong idea from your humorous comment: I don't prefer SETQ to LET without regard to context. I do prefer SETQ to LET when you are in fact successively "refining" a particular value. There are times when you want to rebind, but if you're diddling around with a value the way you seem to be, SETQ works just fine. Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 14:45:33 EDT Received: from SUSHI.STANFORD.EDU by SU-AI.ARPA with TCP; 26 Jul 86 11:27:33 PDT Date: Sat 26 Jul 86 11:25:44-PDT From: Andy Freeman Subject: Re: Some easy ones (?) To: Fahlman@C.CS.CMU.EDU cc: common-lisp@Sail.Stanford.EDU In-Reply-To: Message-ID: <12225811022.11.ANDY@Sushi.Stanford.EDU> There are currently several declaration proposals. The following two forms are equivalent under all those with pervasive declarations. (let ((a (make-a))) (let ((a (refine-a a))) )) (let* ((a (make-a)) (a (refine-a a))) ) I believe that shadowing within let* is no more misunderstandable than shadowing in general. Almost everyone uses the same name in separate functions for objects of a given class. Does that confuse anyone? Pervasive declarations are attractive because most of us use the same convention locally. Repeated names in let* are merely one instance of this. CL has thus far avoided most prescriptive style issues. (I find it strange that Fahlman prefers setq to let. :-)) I have no objection to a note in the manual suggesting that some people think it's bad style to repeat names in let*, much like it suggests that special variables should be surrounded by *'s. If we are opening up prescriptive style, I'm sure Falhman, Gall and I agree that the latter is a more important issue. (If special variables have to be *starred*, special declarations and all of the associated confusion goes away.) -andy ------- Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 14:10:12 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 26 Jul 86 10:54:08 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50688; Sat 26-Jul-86 13:53:22 EDT Date: Sat, 26 Jul 86 13:55 EDT From: Daniel L. Weinreb Subject: Proposal #13: Structure Sharing in Arguments To: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8607232003.AA00325@tekchips.TEK> Message-ID: <860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 23 Jul 86 13:03:26 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA in any reasonable implementation the &REST argument will have been freshly consed. That's an extremely odd idea. The entire reason that we have &REST arguments at all is to avoid the need for consing the list. Had we intended for the list to be freshly consed, we would never have implemented &REST at all; we'd have just let the caller cons up a list and pass it as a regular argument. Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jul 86 13:10:35 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Jul 86 09:54:14 PDT Date: 26 Jul 1986 12:50-EDT Sender: NGALL@G.BBN.COM Subject: Re: Some easy ones (?) From: NGALL@G.BBN.COM To: Fahlman@C.CS.CMU.EDU Cc: ANDY@SU-SUSHI.ARPA, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]26-Jul-86 12:50:48.NGALL> In-Reply-To: Date: Sat, 26 Jul 1986 10:59 EDT From: "Scott E. Fahlman" To: Andy Freeman Subject: Some easy ones (?) In-Reply-To: Msg of 25 Jul 1986 23:25-EDT from Andy Freeman Message-ID: .... I don't want to get into an argument about style -- at least not on this mailing list. My point is simply that allowing multiple use of the same variable in a single LET* does break what would otherwise be a simple and uniform rule, it hairs up the declaration scoping rules, and there's no good reason to allow this since in the rare case where you want to do this there are alternatives that are at least as good and arguably better. -- Scott Hear, Hear! -- Nick Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Jul 86 11:20:50 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 86 07:59:21 PDT Received: ID ; Sat 26 Jul 86 10:59:37-EDT Date: Sat, 26 Jul 1986 10:59 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Andy Freeman Cc: common-lisp@SU-AI.ARPA Subject: Some easy ones (?) In-reply-to: Msg of 25 Jul 1986 23:25-EDT from Andy Freeman Summary: The "no repeated names" rule removes a potential ambiguity for let; let* doesn't have that ambiguity.. Since they are different, exempting let* from the rule merely acknowledges their difference rather than introducing an exception. Repeated variable names are better than some obvious alternatives. OK, we agree that the main ambiguity that this clarification is trying to address comes up only in the parallel-binding forms and not in the sequential-binding forms. So it is possible to come up with rules that would allow the same variable to be bound N times in a single LET* form without ambiguity. Nobody is claiming that this is impossible. I am suggesting that repeatedly binding the same variable within a single binding form is an inherently confusing thing to do and that we shouldn't introduce an exception into what otherwise could be a clean and simple rule -- a variable is bound only once by any one binding form -- in order to make this weird style possible. (It may be that you find this less confusing than I do because you think of LET* as nested LAMBDAS while I think of it as a funny kind of LET, but I don't think I'm alone in this.) One nasty issue we would have to face if we allowed LET* to bind the same variable multiple times is what to do about declarations that affect the multiply-bound variable. This is particularly nasty if we go with the proposed scheme (any of them) that ties such declarations tot he scope of the variable being bound. Now you've got two or more scopes for variable FOO, and only one place to put the declaration. In this case, I think that nested LET* forms would indeed be less confusing. Your example of code that is best expressed with multiple rebindings in a LET* is unconvincing to me. I don't understand exactly what you mean by "successively refining" an object, and I find your code example quite confusing not only are you referring to two different locally-bound variables, both named SUCCESS, but you've got free references to SUCCESS and FAILURE in there as well. I can sort this out, but in the presence of a declaration or two, it might be pretty tough. (let* ((success (build-success code1 success failure)) (failure (build-failure code2 success failure)) (success (build-success code3 success failure))) ) So, to answer your question, I do find the version with three SETQs much easier to follow, and a version with three nested LET forms would be better if it is really important to do this with rebinding and not with SETQ. So I still have not seen any code where multiple rebinding within a LET* is the least confusing way to do something. I admit that this is a matter of taste and that reasonable people may differ on this, but I suspect your proposed example would be confusing to a substantial fraction of Common Lisp programmers, which makes it bad style in general. I don't want to get into an argument about style -- at least not on this mailing list. My point is simply that allowing multiple use of the same variable in a single LET* does break what would otherwise be a simple and uniform rule, it hairs up the declaration scoping rules, and there's no good reason to allow this since in the rare case where you want to do this there are alternatives that are at least as good and arguably better. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 23:54:42 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86 20:34:09 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50007; Fri 25-Jul-86 12:26:24 EDT Date: Fri, 25 Jul 86 12:28 EDT From: Daniel L. Weinreb Subject: (declare (type fixnum ---)) considered etc. To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860725122802.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 24 Jul 1986 14:28 EDT From: Rob MacLachlan I don't think we should have people who never use type declarations telling those of us who do what kind of declarations we can and can't use. Nor do I think a company should change Common Lisp so that everyone has to buy their machines to run fast. I don't think we should make language design issues on the basis of ad hominem attacks. A point is valid no matter who makes it. Common Lisp language design is made by virtue of reason, not attacks. Furthermore, nobody is proposing to change Common Lisp. I'm getting tired of this discussion. Why doesn't everyone just admit we aren't going to get agreement on this issue. The split seems to be drawn largely along special-hardware/standard-hardware lines, and neither community is going to go away. This simply isn't true. If I were only using standard-hardware machines, I would still be quite concerned that a program that declared something to be a "fixnum" might suddenly not port to another standard-hardware machine if it had a different word size. In any case, flushing the fixnum declaration is not one of the proposals we are supposed to be discussing. If it were, it would be unlikely to pass, since under the criteria for changes, approval would have to be near-unanimous, which it isn't. "Flushing the fixnum declaration"? To quote the mail that you are attacking: Date: Thu, 24 Jul 86 13:59 EDT From: Robert A. Cassels Subject: (declare (type fixnum ---)) considered etc. To: RAM@C.CS.CMU.EDU, Cassels@STONY-BROOK.SCRC.Symbolics.COM I didn't say we shouldn't have type FIXNUM. I said we should put it somewhere where it would be obvious that programs using it are probably not portable. Don't you think you ought to read the message before flaming at the sender? Let me make it clear again: Cassels is not advocating removing the FIXNUM declaration. Nor am I. Got it? Now, the point in Cassels's message that I don't agree with is the very last paragraph, which might be the one that stimulated your reply: Date: Thursday, 24 July 1986 13:59-EDT From: Robert A. Cassels Re: (declare (type fixnum ---)) considered etc. If you want the freedom to be sloppy, or you really can't limit the range, you must either pay the price of reduced performance or buy a machine which doesn't need declarations to get performance. [I never use type declarations in my CL programs.] The disagreement is with the last sentence, which, while true, is deceptive because his CL programs are not trying to be both portable and effective (i.e. fast on standard hardware). I think it was intended to be a lighthearted comment, but wasn't taken that way. (1) Omit numeric declarations altogether. Pro: It's very easy to do. Pro: The program is portable. Con: The program could be slowed down if not on special hardware. (2) Use careful (INTEGER 0 X) declarations. Con: It takes work to figure out what precision is really needed. Pro: The program is portable. Pro: The program runs fast everywhere. (3) Use FIXNUM declarations. Pro: It's pretty easy to do. Con: The program is not necessarly portable. Pro: The programs runs fast everywhere that it does run. Common Lisp should and does allow all three. The point is to make it clear, through proper phrasing in the specification and documentation, that this is what is going on. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 23:48:33 EDT Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 20:27:09 PDT Date: Fri 25 Jul 86 20:25:31-PDT From: Andy Freeman Subject: Re: Some easy ones (?) To: Fahlman@C.CS.CMU.EDU cc: common-lisp@Sail.Stanford.EDU In-Reply-To: Message-ID: <12225647140.10.ANDY@Sushi.Stanford.EDU> Summary: The "no repeated names" rule removes a potential ambiguity for let; let* doesn't have that ambiguity.. Since they are different, exempting let* from the rule merely acknowledges their difference rather than introducing an exception. Repeated variable names are better than some obvious alternatives. I'll get to &aux and &optional names at the end of this message. Let* is different from let because it REQUIRES multiple lambda expressions. Disallowing repeated names makes almost as much sense as disallowing shadowing. There is a reason to forbid repeated names in lambda-expressions (and therefore let), do, labels, and the like. That reason is to avoid ambiguity. Let* (and possibly do*, I'm not sure about it) with repeated names is NOT ambiguous. Pervasive declarations don't make it ambiguous; the declaration affects the outermost instance of a name. I use let* and repeated names when I am refining two or more objects together. (I also use repeated names when I am successively refining one object because it's easier to read than composing and allows me to pass the unrefined object in multiple places to the refining function.) It lets me use the same descriptive name everywhere for a given class of object; scoping guarantees that I always have the right one. For example: (let* ((success (build-success code1 success failure)) (failure (build-failure code2 success failure)) (success (build-success code3 success failure))) ) None of the following are clearer. Are there clearer alternatives? (let* ((code1-success (build-success code1 success failure)) (failure (build-failure code2 success failure)) (success (build-success code3 success failure))) ) (let* ((success (build-success code1 success failure)) (failure (build-failure code2 success failure))) (let ((success (build-success code3 success failure))) )) (progn (setq success (build-success code1 success failure)) (setq failure (build-failure code2 success failure)) (setq success (build-success code3 success failure)) ) &optional variables fall in a grey area. If the caller passes enough arguments, they are just like other variables. If not, they are sort of like &aux variables. Consistency tips the balance, &optional variables should be handled like non-optional names when it comes to the no-repeated-names rule. As to &aux, CLtL says it's a matter of style whether one uses it or not. I chose not to so I don't care if repeated names are forbidden even though they wouldn't be if the programmer used let*. (It would be an exception to a useful rule, "all names in a lambda-expression must be unique", to allow shadowing &aux variables. I'd rather flush &aux though.) -andy ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 20:34:34 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 17:06:53 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 25 JUL 86 15:57:23 PDT Date: 25 Jul 86 12:51 PDT From: Masinter.pa@Xerox.COM Subject: Re: FIXNUM considered useful In-reply-to: "Scott E. Fahlman" 's message of Fri, 25 Jul 86 11:36 EDT To: common-lisp@su-ai.ARPA Message-ID: <860725-155723-1043@Xerox> Its possible to be more explicit about the implementation dependent range of fixnums without resorting to red ink. In explicit terms of CLtL, I'd propose the following changes in wording: On pp 14-15, move the paragraph "In every Common Lisp implementation ...." to the end of the section on "Integer" (rather than the middle) and put it in an Implementation Note rather than in the running text. Change "In every Common Lisp implementation..." to "In most Common Lisp implementations ..." and change "... is visible to the user in only a few places where the efficiency of representation is important." to "... is usually only visible to the user in cases where fixnum operations are substantially more efficient than those that admit bignums." The "efficiency of representation" is bogus: (signed-byte 8) is more efficient in representation than fixnum. Fixnum declarations are not for efficiency of representation but rather for efficiency of operations such as + and *. Add, after the sentence "Exactly which integers are fixnum is implementation-dependent ..." a sentence: "For this reason, references to the distinction between fixnum and bignum should be avoided in portable code when more explicit integer ranges can be supplied." Add, to the list of tokens to "See" the names "integer", "signed-byte". Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 18:17:14 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 14:50:40 PDT Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 17:50:32 edt Date: Fri, 25 Jul 86 17:51 EDT From: Guy Steele Subject: Re: REDUCE args To: DCP@QUABBIN.SCRC.Symbolics.COM, Skef@THINK.COM, NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <860725113911.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-Id: <860725175113.5.GLS@IGNATIUS.THINK.COM> Date: Fri, 25 Jul 86 11:39 EDT From: David C. Plummer Date: Fri, 25 Jul 86 09:55 EDT From: Skef Wholey In the meantime, you can of course do something like: (reduce #'fun (map 'vector #'key sequence)) Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines, Somebody brought up this method the last time. I had at least two reactions: (1) It doesn't really express the intent of the programmer, and (2) I don't care what kind of machine you are on, you should care about efficiency and consing. I buy your argument (2), but (1) seems to be a bit spurious. Why isn't the intent "take all those keys and reduce them"? If that is the intent, why can't that be expressed as "(take all those keys) and (reduce them)"? Is it that you had rather in mind "reduce all them thar keys" and don't consider the other an equivalent formulation? --Guy Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 18:16:11 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 14:45:21 PDT Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 17:45:18 edt Date: Fri, 25 Jul 86 17:45 EDT From: Guy Steele Subject: duplicate names in LET* To: Dave.Touretzky@A.CS.CMU.EDU, Fahlman@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <8607250432.AA09415@Zarathustra.Think.COM> Message-Id: <860725174559.4.GLS@IGNATIUS.THINK.COM> Date: 25 Jul 86 00:30 EDT From: Dave.Touretzky@A.CS.CMU.EDU The rule in Common Lisp should be that you can't have duplicate names in the same LEXICAL ENVIRONMENT. ... Perhaps you meant "lexical contour"? --Guy Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 16:22:14 EDT Received: from IMSSS by SU-AI with PUP; 25-Jul-86 12:33 PDT Date: 25 Jul 1986 1155-PDT From: Rem@IMSSS Subject: Accidental clobbering of pnames etc. To: COMMON-LISP@SU-AI As an alternative to current anarchy and my earlier proposal to have extra runtime types for readonly-string etc., perhaps we could have a way to declare things readonly. There are two kinds: (1) This function is guaranteed not to modify this particular argument; (2) This returned value must not be modified by anyone. The compiler can then be fixed so that it's ok to pass (2) data as (1) args, but not as non-(1) args. User functions can be declared not to ever modify their args, and the compiler can verify this is indeed true when compiling those functions. Global variables can be declared (3) this variable may contain data that should never be modified, then it's permissible to store (2) data in that variable and impermissible to destructively modify anything stored there. Any time data is picked out of a readonly variable or a readonly returned value, that sub-data is also considered to be readonly, and the compiler enforces that nobody tries to modify it or put it where somebody else would be allowed to modify. Of course when a total copy (including copying bytes of strings etc.) of data occurs that resultant data is no longer considered readonly. This is overkill in the sense that if you have one little piece of readonly data which you insert into something else, that whole large object is readonly, and if then a part is extracted from some place unrelated to the truly readonly data that part is unnecessarily readonly, but the programmer can avoid that by copying the little readonly piece in the first place before sticking it into the big structure. Anyway, compiled code will then never clobber PNAMEs etc. with this proposal implemented. (Maybe even a super-smart interpretor could respect the declarations??) ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 15:48:38 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 12:06:06 PDT Received: from ignatius by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 15:05:44 edt Date: Fri, 25 Jul 86 15:06 EDT From: Guy Steele Subject: Structure sharing in arguments To: miller@UR-ACORN.ARPA, DCP@QUABBIN.SCRC.Symbolics.COM Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <860723142439.9.MILLER@UR-CASHEW.ARPA> Message-Id: <860725150616.3.GLS@IGNATIUS.THINK.COM> Date: Wed, 23 Jul 86 14:24 EDT From: Brad Miller Date: Wed, 23 Jul 86 13:21 EDT From: David C. Plummer 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) ... [Yes, Symbolics uses stack-consed &rest lists, and they will screw you every now and then. ...] 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. ... Now wait a second. (defun foo (&rest x) x) is not destroying the rest argument. The problem is that the programmer who uses the result of foo may destroy that result. Should he have to know how foo is implemented to know what he is allowed to do to the result? I should think not.... I think the lesson here is that, in general, you shouldn't ever clobber a CONS if you don't know where it has been. Certain CL primitives do guarantee to cons up fresh lists, and you can safely clobber their results. Everything else you ought to be careful with, and that includes &rest arguments, the results of PARSE-BODY, the results of FOO, and so on. Unless a function or other construct is clearly documented to indicate that it is okay to clobber its result, then you should avoid doing so. --Guy Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 15:24:16 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 11:57:31 PDT Received: from CCC.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 JUL 86 15:00:12 EDT Date: 25 Jul 1986 14:45:51-EDT From: uucp@MIT-CCC From gjc%LMI-ANGEL.ARPA Fri Jul 25 14:41:42 1986 remote from lmi-angel Received: from LMI-LAMBDA-2-B by lmi-angel.ARPA (4.12/4.7) with CHAOS id AA02405; Fri, 25 Jul 86 14:38:56 edt Date: Friday, 25 July 1986, 14:39-EDT From: George Carrette Subject: FIXNUM considered unportable To: mitccc!common-lisp%SU-AI%mc@angel.ARPA Message-Id: <[LMI-LAMBDA-2-B].25-Jul-86 14:39:27.GJC> What all this discussion says to me as a compiler implementor is that I should give a warning when somebody uses type FIXNUM. Ah, but show now I can think of a use of type FIXNUM from MACSYMA (DOE-MACSYMA, CL-MACSYMA whatever), and it seems quite reasonable. Given that we know that fixnum operations are more efficient than non-fixnum we choose to do our math modulo various prime numbers that fit in a fixnum. Macsyma has a list of the 10 or so bigest primes that fit in a fixnum for each machine it runs on, and/or it can compute these on the fly, using the (LSH -1 -1) idiom (or other more common-lisp ways of finding the greatest fixnum). Well, thats part of the justification, the code would look something like: (COND ((TYPEP *MODULUS* 'FIXNUM) (LET () (DECLARE (FIXNUM *MODULUS*)) ....frob... frob... frob...)) ('ELSE ..... frob ... frob ...)) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 14:50:41 EDT Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 11:26:55 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA05914; Fri, 25 Jul 86 12:27:08 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA05634; Fri, 25 Jul 86 12:27:04 MDT Date: Fri, 25 Jul 86 12:27:04 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8607251827.AA05634@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Proposal #13: Structure Sharing in Arguments Summary: Expires: References: <8607232003.AA00325@tekchips.TEK> 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 <8607232003.AA00325@tekchips.TEK> willc%tekchips.tek.csnet@CSNET-RELAY.ARPA writes: > > 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. > >This clarification will imply that any accurate account of the semantics >of Common Lisp must explain the procedure call mechanism in terms of >linked lists. This doesn't make any sense. The clarification *simplifies* the semantics of Common Lisp because it leaves undefined the situation in which someone destructively modifies an &rest argument. "Bottom" is simpler than anything else, eh? > It will imply that people who care about portable code >must make a habit of copying every &REST argument themselves, despite >the fact that in any reasonable implementation the &REST argument will >have been freshly consed. It will force people who care about efficiency >to write non-portable code. This clarification is a very bad thing. People who go about writing lots of destructive operations are best off making copies of their data structures before starting to beat on them. It's not perfect referential transparency, but it goes a long way to getting predictable code. "Reasonable implementation" is a pretty loaded term. If &rest args are all freshly consed, then it compromises efficiency *all* the time, not just the cases where someone decides that destructive operations are the thing to do. >Does anyone claim that this clarification is a good thing? I do. (It is of course only a coincidence that PCLS *does* share arglist pieces!) This clarification fits well with those parts of the standard that don't promise whether DELETE and REMOVE have distinguishable behavior, or how many bits are in a short float, etc. stan Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 13:50:12 EDT Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 10:17:47 PDT Received: from tektronix by csnet-relay.csnet id ae23107; 25 Jul 86 12:57 EDT Received: by tektronix.TEK (5.31/6.16) id AA09523; Wed, 23 Jul 86 13:00:56 PDT Received: by tekchips.TEK (5.31/6.16) id AA00325; Wed, 23 Jul 86 13:03:27 PDT Message-Id: <8607232003.AA00325@tekchips.TEK> To: common-lisp@SU-AI.ARPA Cc: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Subject: Proposal #13: Structure Sharing in Arguments Date: 23 Jul 86 13:03:26 PDT (Wed) From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA 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. This clarification will imply that any accurate account of the semantics of Common Lisp must explain the procedure call mechanism in terms of linked lists. It will imply that people who care about portable code must make a habit of copying every &REST argument themselves, despite the fact that in any reasonable implementation the &REST argument will have been freshly consed. It will force people who care about efficiency to write non-portable code. This clarification is a very bad thing. Does anyone claim that this clarification is a good thing? Peace, William Clinger Tektronix Computer Research Laboratory Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 12:47:27 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 09:12:13 PDT Received: from wenceslas by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 12:12:21 edt Date: Fri, 25 Jul 86 12:13 EDT From: Skef Wholey Subject: Re: REDUCE args To: DCP@QUABBIN.SCRC.Symbolics.COM, Skef@THINK.COM, NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: common-lisp@SU-AI.ARPA In-Reply-To: <860725113911.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-Id: <860725121309.3.SKEF@WENCESLAS.THINK.COM> From: David C. Plummer Date: Fri, 25 Jul 86 09:55 EDT From: Skef Wholey In the meantime, you can of course do something like: (reduce #'fun (map 'vector #'key sequence)) Somebody brought up this method the last time. I had at least two reactions: (1) It doesn't really express the intent of the programmer, and (2) I don't care what kind of machine you are on, you should care about efficiency and consing. However, it is very easy to write a compiler transform that turns the above into a call to a hidden function that does what the above does without consing. The sequence functions are the most obvious, easiest target for source-level optimization in a Common Lisp compiler. If the above were listed as an idiom in the manual, then such optimizers might appear in implementations. This is a real alternative, not some pie-in-the-sky "a smart compiler could..." argument. I feel the argument about consistent use of :KEY, :TEST, and :TEST-NOT still holds. I don't object to adding a field selector argument to REDUCE, but I don't think that it should be called :KEY. One might introduce a new function, REDUCE-FIELD (or whatever), or a new keyword. --Skef Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 12:31:28 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 09:02:03 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23986; Fri 25-Jul-86 12:01:05 EDT Date: Fri, 25 Jul 86 12:01 EDT From: David C. Plummer Subject: Re: Some easy ones (?) To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA cc: Fahlman@C.CS.CMU.EDU In-Reply-To: <[G.BBN.COM]24-Jul-86 15:29:46.NGALL> Message-ID: <860725120119.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 24 Jul 1986 15:29-EDT From: NGALL@G.BBN.COM Yes. PARSE-BODY called with DECLARATIONS-ALLOWED-P of NIL would be used to verify that an implicit PROGN does not begin with decls (it could be used with 'bodies' other than implicit PROGNs, but only if such bodies do not allow a declaration-like syntax (unlike CASE and COND (boy, did I pick a bad example!)). Yes. Its contract would be to make sure there aren't any declarations. This was the point I was trying (and failing so miserably) to make. PARSE-BODY currently has no contract to make sure declarations are only at the beginning. To do so it might have to expand macros (needlessly). Therefore it isn't suitable for your intent of using it to verify implicit PROGNs. Consider (when (predicate) (print 'foo) (declare (inline xyzzy)) (print 'bar)) which is illegal. PARSE-BODY is for parsing bodies. Period. Implicit PROGNs are not bodies. Really. PARSE-BODY's contract should be simple: extract the three components of a body: the declarations, the documentation, and the implicit PROGN. That is what a body is. Something that isn't that isn't a body. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 12:05:25 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jul 86 08:40:40 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23972; Fri 25-Jul-86 11:39:04 EDT Date: Fri, 25 Jul 86 11:39 EDT From: David C. Plummer Subject: Re: REDUCE args To: Skef Wholey , DCP@QUABBIN.SCRC.Symbolics.COM, NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <860725095514.1.SKEF@WENCESLAS.THINK.COM> Message-ID: <860725113911.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 25 Jul 86 09:55 EDT From: Skef Wholey In the meantime, you can of course do something like: (reduce #'fun (map 'vector #'key sequence)) Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines, Somebody brought up this method the last time. I had at least two reactions: (1) It doesn't really express the intent of the programmer, and (2) I don't care what kind of machine you are on, you should care about efficiency and consing. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 12:01:52 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Jul 86 08:39:37 PDT Received: ID ; Fri 25 Jul 86 11:36:28-EDT Date: Fri, 25 Jul 1986 11:36 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: FIXNUM considered useful In-reply-to: Msg of 25 Jul 1986 10:55-EDT from Daniel L. Weinreb Scott, I feel that the only point is to recognize explicitly in the spec and manual that using FIXNUM creates a real hazard that your program may not be portable... As long as it's clear what FIXNUM does mean and does not mean, then people can make a well-informed choice about whether to use it or not, and everything should be fine. But in a language spec that is devoted to providing program portability, any language feature that has known non-portable aspects to it should be clearly marked as such. I agree with this. It's what I've said about this all along. Too bad the spec won't have red ink for such things, so nobody could claim they missed it. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 11:28:01 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86 08:09:11 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49880; Fri 25-Jul-86 11:07:57 EDT Date: Fri, 25 Jul 86 11:09 EDT From: Daniel L. Weinreb Subject: Status of declare UNSPECIAL To: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860725110937.0.DLW@CHICOPEE.SCRC.Symbolics.COM> For the record, I also remember that we decided explicitly not to have an "UNSPECAL" (whatever you call it) declaration, and I also don't remember why. Unfortunately, I remember this discussing occurring during a physical meeting, but someone should poke into the old archives and see if there was any good reasoning that we should all know about. Otherwise, I agree that there should be such a declaration. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 11:13:09 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Jul 86 07:54:32 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49855; Fri 25-Jul-86 10:53:57 EDT Date: Fri, 25 Jul 86 10:55 EDT From: Daniel L. Weinreb Subject: FIXNUM considered useful To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860725105530.8.DLW@CHICOPEE.SCRC.Symbolics.COM> Scott, I feel that the only point is to recognize explicitly in the spec and manual that using FIXNUM creates a real hazard that your program may not be portable. You, personally, clearly understand what the issue is, and I'm sure you know that even though within your own environment you haven't run into problems, nevertheless different programs, or more exotic implementations, might cause a program to not port correctly. The only real point here is that everyone who reads the spec should understand it, too. As long as it's clear what FIXNUM does mean and does not mean, then people can make a well-informed choice about whether to use it or not, and everything should be fine. But in a language spec that is devoted to providing program portability, any language feature that has known non-portable aspects to it should be clearly marked as such. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 10:12:28 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 06:54:14 PDT Received: from wenceslas by Godot.Think.COM via CHAOS; Fri, 25 Jul 86 09:54:29 edt Date: Fri, 25 Jul 86 09:55 EDT From: Skef Wholey Subject: Re: REDUCE args To: DCP@QUABBIN.SCRC.Symbolics.COM, NGALL@G.BBN.COM, ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Cc: common-lisp@SU-AI.ARPA In-Reply-To: <860724145929.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-Id: <860725095514.1.SKEF@WENCESLAS.THINK.COM> From: David C. Plummer From: ALR%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: REDUCE args Does anybody else wish that REDUCE took a KEY argument, similarly to MEMBER. i.e. (reduce #'+ list-of-objects :KEY #'object-quantity) would apply the function OBJECT-QUANTITY to each element of the list-of-objects before reducing it with +. Ditto. I think GLS made some comment about this usage of :KEY being different than most. Maybe that was in a different discussion. There are possibly other related operations that should take KEY. One could also add :TEST to avoid calling the operator on objects you don't want to. Maybe this was Steele's point: Does the key apply before or after the test? I think the intuitive usage is backwards from the other usages. It "being different than most" was my reaction, too. In all other cases, the :KEY argument is used to specify a "field" to be used for selection (via :TEST or :TEST-NOT). If :KEY were added to REDUCE in a manner consistent with the rest of the language, it would only be useful in conjunction with :TEST and :TEST-NOT, to either include or exclude elements of the sequence from the reduction, which isn't what everyone here seems to want. Read pages 245-256. Count one vote against, in the name of maintaining the (somewhat pudding-like) consistency the language has. In the meantime, you can of course do something like: (reduce #'fun (map 'vector #'key sequence)) Now-living-on-a-3600-and-not-caring-too-much-about-consing-or-81-character-lines, Skef Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 08:35:20 EDT Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 25 Jul 86 05:19:02 PDT Date: 25 Jul 86 08:15:00 EST From: "BACH::VANROGGEN" Subject: duplicate LET* variables To: "common-lisp" cc: vanroggen Reply-To: "BACH::VANROGGEN" Although I agree with Touretzky's reasoning about not having duplicate names in the same lexical environment (I might as well add: except when covered by the shadowing rules), I thought the problem with LET* was the ambiguity regarding declarations, which is why LET* isn't the same as a bunch of nested LETs. ---Walter ------ Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 02:06:07 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 22:47:51 PDT Date: 25 Jul 1986 01:45-EDT Sender: NGALL@G.BBN.COM Subject: Re: duplicate names in LET* From: NGALL@G.BBN.COM To: Dave.Touretzky@A.CS.CMU.EDU Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]25-Jul-86 01:45:01.NGALL> In-Reply-To: The message of 25 Jul 86 00:30 EDT from Dave.Touretzky@A.CS.CMU.EDU Date: 25 Jul 86 00:30 EDT From: Dave.Touretzky@A.CS.CMU.EDU To: "Scott E. Fahlman" Subject: duplicate names in LET* In-Reply-To: The rule in Common Lisp should be that you can't have duplicate names in the same LEXICAL ENVIRONMENT. This rules out duplicate names in a lambda list or a LET, and duplicate tags in a tagbody. But it should not rule out duplicate names in a LET* because the variables in a LET* are bound in different lexical environments. ... Wait a second. The optional and keyword parameters are NOT in the same lexical environment, they are in nested ones, e.g., ((lambda (&optional (v1 e1) (v2 e2) (v3 e3)) body)) is semantically equivalent to (let* ((v1 e1) (v2 e2) (v3 e3)) body) So why should lamda-lists be treated differently than LET*? Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 01:54:16 EDT Received: from KIM.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 22:35:49 PDT Received: by kim.Berkeley.EDU (5.53/1.14) id AA26959; Thu, 24 Jul 86 22:36:06 PDT Received: by franz (5.5/3.14) id AA09731; Thu, 24 Jul 86 22:11:10 PDT Date: Thu, 24 Jul 86 22:11:10 PDT From: franz!smh@kim.Berkeley.EDU (Steve Haflich) Message-Id: <8607250511.AA09731@franz> To: common-lisp@su-ai.arpa In-Reply-To: ucbkim!mit-ems.ARPA!NGALL%G.BBN.COM's message of 23 Jul 1986 23:18-EDT Subject: (declare (type fixnum ---)) considered etc. Date: 23 Jul 1986 23:18-EDT From: NGALL%G.BBN.COM My solution is to write (integer 0 #.array-dimension-limit). It works just fine. -- Nick Of course this `works fine', but perhaps what better captures your intended efficiency is an *exclusive* upper limit: (integer 0 (#.array-dimension-limit)) But note that with such a declaration on the array index i, this innocuous code could fail: (let ((len (length my-array))) (do ((i 0 (1+ i))) ((> i len)) ...)) Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 00:48:53 EDT Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 21:31:21 PDT Date: 25 Jul 86 00:30 EDT From: Dave.Touretzky@A.CS.CMU.EDU To: "Scott E. Fahlman" Subject: duplicate names in LET* CC: common-lisp@SU-AI.ARPA In-Reply-To: The rule in Common Lisp should be that you can't have duplicate names in the same LEXICAL ENVIRONMENT. This rules out duplicate names in a lambda list or a LET, and duplicate tags in a tagbody. But it should not rule out duplicate names in a LET* because the variables in a LET* are bound in different lexical environments. Writing (let* ((v1 e1) (v2 e2) (v3 e3)) body) should be semantically equivalent to (let ((v1 e1)) (let ((v2 e2)) (let ((v3 e3)) body))) It is NOT clear what to do when duplicate names appear in a lambda list or tagbody; ignoring all but the first occurrence is a quick and dirty fix that is not justified by the rules of lexical scoping. But in the LET expression above it is perfectly clear what should happen when v1, v2, and v3 are the same symbol. The equivalent LET* expression therefore has a well-defined meaning. Outlawing duplicate names in LET* promotes too shallow a notion of consistency: one based on syntax rather than semantics. -- Dave PS: We should also outlaw duplicate names in DO, but not DO*. Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Jul 86 00:08:25 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:51:11 PDT Received: ID ; Thu 24 Jul 86 23:51:20-EDT Date: Thu, 24 Jul 1986 23:51 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Andy Freeman Cc: common-lisp@SU-AI.ARPA Subject: Some easy ones (?) In-reply-to: Msg of 24 Jul 1986 12:56-EDT from Andy Freeman If let* doesn't allow duplicate names, then we'll end up writing nested let* expressions (which is senseless, let* was invented to avoid nested let expressions) or using setq more than necessary. I can't imagine any reasonable piece of code that would use the same name twice in a LET*. At least, I can't imagine any such code that would not be much clearer if done some other way. So I don't think that we'll end up writing nested LET* forms if we outlaw duplicate variable names in a LET*. Unless oyu can supply a reasonable example, I think we're better off not making an exception for this one case. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 23:56:35 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:34:46 PDT Received: ID ; Thu 24 Jul 86 23:34:44-EDT Date: Thu, 24 Jul 1986 23:34 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Declaration before variable In-reply-to: Msg of 23 Jul 1986 22:01-EDT from NGALL at G.BBN.COM In response to the following suggestion by REM: (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 idea has some merit, but in my view it is too radical a change to consider now. Keep this in mind for Common Lisp 2000. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 23:35:45 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:20:07 PDT Received: ID ; Thu 24 Jul 86 23:18:45-EDT Date: Thu, 24 Jul 1986 23:18 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: Structure sharing in arguments By the way, one thing I proposed a long time ago, and plan to re-propose now, is a new &MORE construct that would allow functions to take arbitrary numbers of arguments in the style of LEXPR, keeping them on the stack until asked for and not consing them into a list. I don't want to debate this now -- give me a chance to propose it properly first -- but I thought I'd better mention this as a piece of context that might keep people from getting too tense about the efficiency of &rest args. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 23:28:45 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 20:10:10 PDT Received: ID ; Thu 24 Jul 86 23:09:58-EDT Date: Thu, 24 Jul 1986 23:09 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: Structure sharing in arguments In-reply-to: Msg of 23 Jul 1986 13:21-EDT from David C. Plummer The question of whether &rest args can be destructively modified has become muddled together with the related question of whether they can be returned from a function or otherwise passed outward. The old Lisp Machine trick of stack-consing these things loses in such situations. Setting aside, for now, the question of destructive modificationof &rest args, I would like to get a clarification on the stack-consing business. DCP says: [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.] My understanding, from the last time we discussed this, was that everyone agreed that this behavior was illegal in Common Lisp (the &rest arg is supposed to be a LIST, and not some object that disappears on you), and that the Symbolics position was that their system should detect those situations where stack-consing is unsafe and copy those rest-lists to the heap. I think I heard that this was already being done, but maybe this is one of those "in release 27, not yet delivered" kinds of things. Do we agree that it is illegal for rest-arg lists to evaporate, or is that another issue that we have to discuss? -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 21:29:30 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 18:02:18 PDT Received: ID ; Thu 24 Jul 86 21:02:26-EDT Date: Thu, 24 Jul 1986 21:02 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: Status of declare UNSPECIAL In-reply-to: Msg of 24 Jul 1986 16:36-EDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White) The introduction of an UNSPECIAL declaration is on my list of issues to raise at some point. Jonathan Rees has asked for this several times over the past few years and has asked why is isn't in the language already. I don't remember, and nobody else seems to either. Since this obviously interacts with the scope-of-declarations stuff, let's consider this as part of the same discussion. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 21:00:16 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 17:32:21 PDT Received: ID ; Thu 24 Jul 86 20:32:09-EDT Date: Thu, 24 Jul 1986 20:32 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: David Singer Cc: common-lisp@SU-AI.ARPA Subject: Case of symbols and their print-names In-reply-to: Msg of 24 Jul 1986 13:05-EDT from David Singer The case-sensitivity/case-conversion wars were long and bloody, and that particular battlefield is still radioactive. We might take one last look at this sometime down the road, after lots of other issues have been decided and we're all in a good mood, but PLEASE let's not reopen this issue now. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 19:42:53 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 14:45:46 PDT Received: by navajo.stanford.edu; Thu, 24 Jul 86 14:44:33 PDT Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA21387; Thu, 24 Jul 86 13:23:48 pdt Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA07304; Thu, 24 Jul 86 13:29:12 PDT Date: Thu, 24 Jul 86 13:29:12 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8607242029.AA07304@bhopal.edsel.uucp> To: navajo!DCP%QUABBIN.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!common-lisp%SU-AI.ARPA@navajo.stanford.edu In-Reply-To: David C. Plummer's message of Thu, 24 Jul 86 13:34 EDT Subject: (declare (type fixnum ---)) considered etc. Re: If you really want to go least-common-denominator, you will probably have to settle for 7 guarenteed bits, or maybe 8 or 9; I can't remember how big MacLisp fixnums are. MacLisp's fixnums are 36 bits in width; Interlisp-D's fixnums are 32 bits wide (they are called FIXP's in Interlisp parlance). There seems to be some confusion between the type FIXNUM with the (informal) type "non-consing, small fixnum". Interlisp call's the latter variety SMALLP's, and on the D machines they are 17 bits wide; MacLisp generally guarantees non-consing behaviour only for a modest subrange of fixnums, but the infamous NCOMPLR handles full 36-bit fixnums and generally avoids consing them by using "strong typing" compiler techniques. -- JonL -- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 19:38:16 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 14:46:05 PDT Received: by navajo.stanford.edu; Thu, 24 Jul 86 14:44:53 PDT Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA21414; Thu, 24 Jul 86 13:31:27 pdt Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA07326; Thu, 24 Jul 86 13:36:47 PDT Date: Thu, 24 Jul 86 13:36:47 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8607242036.AA07326@bhopal.edsel.uucp> To: navajo!common-lisp%su-ai@navajo.stanford.edu Subject: Status of declare UNSPECIAL Was there ever a clear consensus one way or the other on this? I remember it being brought up several times over the years, but don't remember how it turned out. In a previous note, I used the syntax (declare (notype x)). This was a lapse into Maclisp style -- the common-lisp equivalent would probably be (declare (type t x)). -- JonL -- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 19:16:38 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Jul 86 14:38:13 PDT Received: ID ; Thu 24 Jul 86 17:38:21-EDT Date: Thu, 24 Jul 1986 17:38 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: FIXNUM considered useful The language as it stands provides a perfectly good mechanism for people who want to specify the range of certain integers in a strictly portable way. It also provides the more convenient FIXNUM declaration for people who want to use that. Like many constructs in the language, the latter is implementation-dependent in certain ways that are carefully spelled out (though not in the optimal place in the manual -- that will be fixed). I see no need to remove FIXNUM declarations from the language. I promise to convert all (FIXNUM foo) declarations to (INTEGER foo) in any code I send to Xerox and Symbolics in the future, or to explain to them how they can do this themselves using the wonders of modern editor technology. Our code has a lot of FIXNUM declarations in it, and it ports just fine among all the stock-hardware machines we have around here. We're not willing to do a lot of work now to figure out the tightest possible integer range limits for each fixnum in order to make things work on a hypothetical tiny-fixnum machine. If people think that this is a matter of principle -- something either is ABSOLUTELY PORTABLE or not -- then flonums have to go, along with all character objects that are not standard-char-p, and a couple of dozen other things. In my view, portability is a goal, not a mathematical predicate. Like Rob, I think that this debate has about run its course and should be allowed to die a quiet death. Both sides are dug in, and the status quo is going to win. -- Scott Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 19:15:22 EDT Received: from SRI-KL.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:38:55 PDT Date: Thu 24 Jul 86 10:05:49-PDT From: David Singer Subject: Case of symbols and their print-names To: common-lisp%SU-AI@SRI-KL I agree with the common-lisp decision to equate case; what I do not like is the decision to upper-case on input. I would much prefer it if the print-name of a symbol was maintained in the case in which it was first presented, even if for symbol-searching/matching/internal purposes, an upper-case string is also recorded. Then print functions can output the mixed-case print-name (without escape characters, to preserve print-read consistency). Without this, editors which behave like interlisp Dedit will be unpleasant, because they'll upper-case your programs for presentation back to you. ------- Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Jul 86 19:06:42 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 24 Jul 86 12:38:58 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49159; Thu 24-Jul-86 15:37:45 EDT Date: Thu, 24 Jul 86 15:39 EDT From: Daniel L. Weinreb