Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Dec 85 12:49:07 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Dec 85 09:35:09 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 19 Dec 85 12:35:08 est Date: Thu, 19 Dec 85 12:35 EST From: Guy Steele Subject: READ-DELIMTED-LIST and dots To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <851219123523.7.GLS@THINK-JEHOSEPHAT.ARPA> I propose that READ-DELIMITED-LIST be extended by adding one more optional argument, dot-permitted-p, defaulting to nil, that if true allows the delimited list to contain dot notation, and if false forbids dot notation. Right now the manual does not address the question of dot notation in this context, and at least one implementation does not permit dot notation in delimited lists, which makes that function useless for simulating the action of "(".  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Dec 85 12:47:39 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Dec 85 09:32:49 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Thu, 19 Dec 85 12:32:45 est Date: Thu, 19 Dec 85 12:32 EST From: Guy Steele Subject: XOR To: KMP@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-Id: <851219123258.6.GLS@THINK-JEHOSEPHAT.ARPA> Date: Tue, 17 Dec 85 10:45 EST From: Kent M Pitman * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR) I dunno. That goes way back into history. * Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV, ORC1, ANDC2, ... which do the other logical operations. If there were, such forms (whatever they were named), some would have very peculiar rules about when evaluation could be allowed to stop, and I'm not sure if I'd want to have to learn them. One problem is that NAND and NOR are not associative. They could reasonably be restricted to being two-place. So could XOR, for that matter.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Dec 85 15:04:35 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 11:53:51 PST Received: from Cabernet.ms by ArpaGateway.ms ; 18 DEC 85 11:23:17 PST Date: 18 Dec 85 11:23 PST From: Gregor.pa@Xerox.ARPA Subject: what do :copiers do? To: common-lisp@SU-AI.ARPA Message-ID: <851218-112317-1434@Xerox> Assuming that the functionality of being able to copy a structure and get back a structure of the same type and the functionality of being able to copy a particular "sub-type part" of a structure are worthwhile, here is a scheme which seems nice: Remember that: (defstruct person name) (defstruct (astronaut (:include person)) helmet-size) In the scheme I am proposing: - copy-person of an astronaut returns a person - a "new" function, copy, which given an astronaut returns an astronaut More abstractly, COPY-xxx as defined by a defstruct returns a structure of that defstruct's type. COPY returns a structure of the same type as its argument.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Dec 85 11:53:27 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 08:38:23 PST Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 18 DEC 85 11:40:47 EST Date: Wed, 18 Dec 85 11:39:11 EST From: RAMBO%AI.AI.MIT.EDU@MC.LCS.MIT.EDU Subject: recent request for assistance To: dlw@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[AI.AI.MIT.EDU].8969.851218.RAMBO> We learned of this through our usual sources inside the DIA. I am at your disposal if the need arises. For all the overworked implementors on this mailing list, may I suggest the relaxation of my winter insurgency training camp.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Dec 85 10:11:39 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 07:01:42 PST Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/5.6) id AA00787; Wed, 18 Dec 85 09:02:27 CST Message-Id: <8512181502.AA00787@gswd-vms.ARPA> Date: Wed, 18 Dec 85 09:02:19 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: XOR /**** ccvaxa:commonlisp / KMP@SCRC-STON / 11:42 pm Dec 17, 1985 ****/ From @SU-AI.ARPA:KMP@SCRC-STONY-BROOK.ARPA Tue Dec 17 23:41:59 1985 From: Kent M Pitman Subject: XOR Steele@THINK-AQUINAS.ARPA In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> ... On the more serious side, if we did introduce XOR, people might eventually want reasonable answers to the following related issues, which would be left open... * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR) ---------- Actually, I don't like calling GLS's proposed function XOR. An exclusive or should be true if exactly one of the arguments is true, not if any odd number of arguments is true. The proposed XOR isn't exclusive enough ... -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Dec 85 06:40:03 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Dec 85 03:30:41 PST Received: from MIT-JANIS by MIT-OZ via Chaosnet; 18 Dec 85 06:30-EST Date: Wed, 18 Dec 85 06:30 EST From: Christopher Fry Subject: Re: clarifications To: masinter.pa@XEROX.ARPA, cfry@OZ.AI.MIT.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <851216-143751-1352@Xerox> Message-ID: <851218063059.1.CFRY@JANIS.AI.MIT.EDU> Some pathnames don't denote disks, and yet "free-space" is a meaningful concept. Why not "free-space" or "file-free-space" at least, instead of "disk-free-space"? Yes. You've helped clarify the intended semantics which is, If I saved a file with pathname P, how big could it be before it ran out of room? "free-space" could mean: how much virtual memory have I got left? "file-free-space" disambiguates, however, we might want to disambiguate based on the type of the argument [with maybe a few keywords]. There could be a whole set of free-space functions for: virtual-memory [ROOM prints out a user useful answer, not a number that could be used by a program] arrays [returns number of elements between fill pointer and the real length] numbers of various kinds [how much more they can grow before they reach their limit. If number is negative, how much more they can grow downward? This should probably be disambiguated with a keyword. One problem is, you'd like to return a number of the same type, which would be impossible to do for, say, a number that was negative, to represent the distance to its positive max.] hash-table [how much room before a rehash is necessary. This is necessarily implementation dependent Also, if there is a maximum size for a hash-table, how much room until then?] package how many more symbols can I stick in this package readtable how many dispatch macros are undefined for the dispatch char C, which would default to # . stream You might want to open a stream for writting and specify a limit. Free-space would tell you how far until that limit. list sequence For lists and sequences, you might be adding to them sequentially, after having initially creted them with some "empty" value such as NIL. free-space could find out how much space there was from the end until the first "non-empty" element. The empty value would default to nil. Think of free-space like we've been thinking of undo, copy, setf .... a generally useful concept that can be reasonably applied to a lot of different data types. It would make it easier to implement this free-space in terms of another class of fns, SIZE or LENGTH. There is already an attempt to make LENGTH work generically in sequences. Why not with files, etc? In fact, a bunch of the sequence operators could be meaningfully applied to other data types. I recognize that these concepts mesh with ideas from new flavors and commonloops.  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Dec 85 01:23:49 EST Received: from SEISMO.CSS.GOV by SU-AI.ARPA with TCP; 17 Dec 85 21:41:18 PST Return-Path: Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Wed, 18 Dec 85 00:37:39 EST From: mcvax!delphi.UUCP!beppe@seismo.CSS.GOV Received: by mcvax.UUCP; Wed, 18 Dec 85 05:56:13 +0100 (MET) Received: by mcvax.UUCP; Wed, 18 Dec 85 05:56:03 +0100 (MET) Received: by delphi.uucp (2.0/SMI-2.0) id AA20558; Tue, 17 Dec 85 16:50:45 -0100 Date: Tue, 17 Dec 85 16:49:05 MET Subject: mailing list To: common-lisp@su-ai.arpa Message-Id: <85/12/17 1649.144@delphi> Could you please add my name to the Common Lisp mailing list? Thank you. Giuseppe Attardi  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Dec 85 01:07:09 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 21:38:24 PST Date: Tue, 17 Dec 85 23:47:46 EST From: Jonathan A Rees Subject: "lexical" globals? To: edsel!jonl@SU-NAVAJO.ARPA cc: common-lisp@SU-AI.ARPA, ram@C.CS.CMU.EDU In-reply-to: Msg of Tue 17 Dec 85 10:50:24 pst from edsel!jonl at su-navajo.arpa (Jon L White) Message-ID: <[MIT-MC.ARPA].758912.851217.JAR> Date: Tue, 17 Dec 85 10:50:24 pst From: edsel!jonl at su-navajo.arpa (Jon L White) Perhaps you, and/or the other people who have volunteered opinions on this topic, can comment on whether a GLOBAL declaration, in parallel to the SPECIAL declaration, would be satisfactory; or whether there is a need for a more scheme-like mechanism also. I liked your message. I think that a (PROCLAIM '(GLOBAL FOO)) proclamation would do the trick. A DEFGLOBAL macro analogous to DEFVAR would be convenient, and symmetrical with DEFVAR and the other DEF's. Much as I like the feature, I think that adding the full generality of the MIT/Yale Schemes' fluid-let would confuse too many people and anger too many implementors. I only mentioned it for its educational value. As far as forbidding LAMBDA-binding of globals, this hadn't occurred to me, but it's probably the right thing, for similar reasons. Again, I'm a fan of block structured languages, but Common Lisp simply is NOT block structured, and this feature would be too confusing. Forbidding lambda-binding globals sort of defeats the idea of lexical scoping, but then so does (PROCLAIM '(SPECIAL ...)). Also, it's a conservative approach, since it doesn't preclude possible later relaxation of the language. If Common Lisp hadn't re-cycled LAMBDA for the two different purposes of lexical and dynamic binding, we wouldn't be having these problems now. But c'est la vie. I can't really complain, since I didn't make a stink about it when the decisions were being made. Maybe we'll get it right next time around.  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Dec 85 00:35:47 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 16:32:45 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375936; Tue 17-Dec-85 10:44:57-EST Date: Tue, 17 Dec 85 10:45 EST From: Kent M Pitman Subject: XOR To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 16:44 EST From: David C. Plummer Subject: XOR To: Guy Steele , Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA> Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 13:05 EST From: Guy Steele Date: Sun, 15 Dec 85 16:35 EST From: David A. Moon The XOR function in your list of suggested language improvements handed out last week was intended to be a joke, wasn't it? I assumed it was, but other people on the mailing list are taking it seriously, so I'm asking for clarification. Of all the functions not in Common Lisp that I use day-to-day on my 3600, this is the one I use most frequently. I admit that I have been, among other things, constructing logic models of various kinds. However, I also find it useful in random COND clauses. Maybe the rest of you will decide it is not useful, but in any case it is not a joke. One argument I have heard against XOR is that, unlike AND and OR, it must evaluate all of its forms. Actually, that doesn't bother me. All three share the property that they evaluate forms left to right until they have enough information to decide. The fact that "enough information" is available early for AND and OR shouldn't be held against XOR, which has other great properties to offer in exchange. Of course, MLB once sent an amusing thing describing an XOR that returns the right answer but somehow knows what the forms evaluate to so it can stop early after the things it doesn't know a priori !-} (:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-) On the more serious side, if we did introduce XOR, people might eventually want reasonable answers to the following related issues, which would be left open... * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR) * Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV, ORC1, ANDC2, ... which do the other logical operations. If there were, such forms (whatever they were named), some would have very peculiar rules about when evaluation could be allowed to stop, and I'm not sure if I'd want to have to learn them. Certainly I've had a lot more use for NAND and NOR than for XOR. A possibly reasonable alternative proposal might be to introduce a full set of functional (ie, not special form) versions of all these operators. That way, we'd simulataneously solve the problem that AND and OR cannot be applied (by providing functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR, *CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and interestingly optimized in predicate positions without needing to be special forms. Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Dec 85 19:45:46 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 16:32:45 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375936; Tue 17-Dec-85 10:44:57-EST Date: Tue, 17 Dec 85 10:45 EST From: Kent M Pitman Subject: XOR To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <851217104550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 16:44 EST From: David C. Plummer Subject: XOR To: Guy Steele , Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA> Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 13:05 EST From: Guy Steele Date: Sun, 15 Dec 85 16:35 EST From: David A. Moon The XOR function in your list of suggested language improvements handed out last week was intended to be a joke, wasn't it? I assumed it was, but other people on the mailing list are taking it seriously, so I'm asking for clarification. Of all the functions not in Common Lisp that I use day-to-day on my 3600, this is the one I use most frequently. I admit that I have been, among other things, constructing logic models of various kinds. However, I also find it useful in random COND clauses. Maybe the rest of you will decide it is not useful, but in any case it is not a joke. One argument I have heard against XOR is that, unlike AND and OR, it must evaluate all of its forms. Actually, that doesn't bother me. All three share the property that they evaluate forms left to right until they have enough information to decide. The fact that "enough information" is available early for AND and OR shouldn't be held against XOR, which has other great properties to offer in exchange. Of course, MLB once sent an amusing thing describing an XOR that returns the right answer but somehow knows what the forms evaluate to so it can stop early after the things it doesn't know a priori !-} (:- Sure. eg, (WITHOUT-INTERRUPTS (XOR (FOO) (NOT (CAR X)) (CAR X))) :-) On the more serious side, if we did introduce XOR, people might eventually want reasonable answers to the following related issues, which would be left open... * Why is OR not called IOR? (Or, why is LOGIOR not called LOGOR) * Why aren't there special forms called NAND, NOR, CLR, SET(!), EQV, ORC1, ANDC2, ... which do the other logical operations. If there were, such forms (whatever they were named), some would have very peculiar rules about when evaluation could be allowed to stop, and I'm not sure if I'd want to have to learn them. Certainly I've had a lot more use for NAND and NOR than for XOR. A possibly reasonable alternative proposal might be to introduce a full set of functional (ie, not special form) versions of all these operators. That way, we'd simulataneously solve the problem that AND and OR cannot be applied (by providing functions that could be). eg, just as a straw man I'll propose *AND, *IOR, *XOR, *CLR, *SET, *EQV, *ORC1, ... Such functions could be known the the compiler and interestingly optimized in predicate positions without needing to be special forms. Also, (MAPCAR #'*AND (FOO)) or (APPLY #'*XOR (BAR)) would be possible.  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Dec 85 15:57:13 EST Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 11:29:09 PST Received: by su-navajo.arpa with Sendmail; Tue, 17 Dec 85 11:26:10 pst Received: by edsel.uucp (2.2/SMI-2.0) id AA04609; Tue, 17 Dec 85 10:51:50 pst Date: Tue, 17 Dec 85 10:51:50 pst From: edsel!jonl@su-navajo.arpa (Jon L White) Message-Id: <8512171851.AA04609@edsel.uucp> To: navajo!common-lisp@su-ai Subject: Functions for special operators [Following what appeared to be the majority opinion of some time ago, I'm refering to "special forms" as "special operators"] It's certainly consistent with the rest of Common Lisp for symbol-function of a special operator to be "is an error" -- early versions of VAX/NIL put a "trap" function there, with the interpreter dispatching through a table which was completely independent of the symbol's function cell. Putting any old random value [like, NIL] in the symbol-function cell would be also be consistent. But this does beg a question of implementation technology. Background on this "question" is the following assertion, rooted in antiquity: ''The only "special operators" needed by Lisp are Lambda and Quote'' [sure, the lambda calculus reduced it to only one -- lambda -- but before extending the discussion on this point, try to remember that Lisp isn't exactly the lambda calculus]. For example, COND could be implemented as a macro (defmacro COND (&rest clauses) `(COND-SUBR (QUOTE ,clauses))) and then COND-SUBR would be written in the typical way that parts of an interpreter are written. So it may appear that putting the code for COND-SUBR directly into the symbol-function cell of COND is perfectly fine, and maybe even a good way to distribute the code of the interpreter. After all, it is only *how* the interpreter goes about fetching an argument for COND that is somewhat odd; after the fetch has been completed, it doesn't matter whether it dispatches through the symbol-function cell of COND, or to another function obtained in another manner. The three implementation technologies I've seen over the years are: 1) essentially nothing in the symbol-function cell of special operators; the interpreter "discerns" and dispatches all special operators through some other mechanism such as the table mentioned above; the compiler also has a lot of special cases in it for them. Although this may be closer to the spirit of CLtL, section 5.1.3, it is less commonly used. 2) extend the set of applicable, function-like objects to include FSUBRs and MSUBRs; the former, when found in a symbol's function cell, makes it a special operator, and the latter, when found in a symbol's function cell, makes it a macro. The beauty of this approach is that it disconnects the macro/special-operator question from any property of the particular symbol which holds it; this is generally good since it supports renaming easily, but it really isn't feasible for a Common Lisp implementation -- as page 57 of CLtL says "... the predicates 'macro-function' and 'special-form-p' may both be true of the same symbol". Nevertheless, it has been used in other Lisp implementations. 3) a variant of (2) -- only true functions are put into the symbol-function cell, but some other property of the symbol [like, a bit in a "header" word?] determines whether the meaning of that function is FSUBR of MSUBR. There seems to be some good advantage to upgrading the macro-function idea into an MSUBR, for it would simplify code which moves definitions around. The mark against upgrading special operators into FSUBRs, however, is the explicit desire of CLtL *not* to facilitate "moving special operators around" except where there is also a macro definition (which would, of course, occupy the symbol-function cell). -- JonL -- P.S. Nit-picking addenda: (i) "symbol-function cell" merely means a certain data abstraction, and doesn't constrain the implementational technology. (ii) the above macro definition for COND won't really work -- it would at least have to have an &environment argument -- but it is only a simplification for purposes of illustration.  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Dec 85 14:42:54 EST Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 17 Dec 85 11:29:02 PST Received: by su-navajo.arpa with Sendmail; Tue, 17 Dec 85 11:26:01 pst Received: by edsel.uucp (2.2/SMI-2.0) id AA04592; Tue, 17 Dec 85 10:50:24 pst Date: Tue, 17 Dec 85 10:50:24 pst From: edsel!jonl@su-navajo.arpa (Jon L White) Message-Id: <8512171850.AA04592@edsel.uucp> To: navajo!ram@c.cs.cmu.edu Cc: navajo!common-lisp@su-ai Subject: "lexical" globals? Distinguishing dynamic variables from truly global variables came up at Lucid last spring, and I think (but am not fully sure) that what you are calling "lexical globals" is subsumed by the general issue of having a GLOBAL declaration/proclamation. I've appended to the end of this note the paper I circulated back then to a couple dozen people. Since it wasn't a pressing issue, we didn't raise it in the mailing list, although I spoke, verbally, at length with a few more people about the problem [in particular, GLS, since I had imagined that ThinkCo would be interested in deep-bound implementations of Common Lisp]. The reason that I'm not 100% sure that simple global variables cover what you are calling "lexical globals" is the volume of discussion about (let ((a )) (defun foo ...) (defun bar ...)) In this example, it's entirely possible that a "global" value cell for "a" will be allocated, which is essentially different from the top-level global value for "a". Something like this is possible with "block compilation" in Interlisp -- the BLOCK declaration disconnects most of the names appearing therein from the outside world, and the compiled image doesn't even have to have symbols existing with those names (because the code is compiled in a fashion similar to the more vanilla, strongly-typed languages,in which "global variables" are just names for specific runtime memory cells). Also, some comments in the recent discussion seem to be misleading as to how a deep-bound implementation works; there is no "re-binding" of the toplevel global value cell, but rather a stackframe which binds a special variable will have a value cell right in that frame (and will also have the name of the variable in the frame, at least implicitly if not directly present in the frame). I'm not sure if there is a good reference on deep binding in general -- the "spaghetti stack" papers are one source -- but several implementations which I've seen have independently invented similar sorts of "wheels" for accelerating performance. [Or, at least they did so after a year's experience using the "oval wheels" they started out with!] Perhaps you, and/or the other people who have volunteered opinions on this topic, can comment on whether a GLOBAL declaration, in parallel to the SPECIAL declaration, would be satisfactory; or whether there is a need for a more scheme-like mechanism also. -- JonL -- --------------------------------------------------------------------------- A "white paper" from March 1985 --------------------------------------------------------------------------- A serious shortfall exists in the defined capabilities for treating variables either as global or as dynamic, which will badly impact the user trying to write sensible code runnable both in a deep bound implementation and in a shallow bound one. Common Lisp has gone on record as not being limited to shallow-bound implementations, and with the appearance of multi-processor work-stations and "computers", the issue of a deep-bound implementation of CL is coming to reality. This note is rather long, so I've organized the remainder into four sections, with the the more important items first. ** Statement of the Problem ** Comparisons with Deep- and Shallow-Bound Interlisps ** A Noticeable Semantic Distinction ** Benefits of Distinction Statement of the Problem In Commonlisp Lisp, there is no means to specify that a variable's references are "global" rather than dynamic [of course, this only applies to free variable references -- global variables may not be bound]. Section 5.3.2 of the CL manual recommends 'defvar' as the means to declare a variable as special, and (unwisely, I think) suggests this as the means of defining "globally defined variables"; defconstant adddresses an issue not really related to "variables", but rather to named constants (i.e., you cannot setq a symbol which has been defined by defconstant); defparameter isn't quite right either, depending on one's implementation (most implementations I've seen cause defparamater to do a SPECIAL proclaimation on the variable). Comparisons with Deep- and Shallow-Bound Interlisps Interlisp-10 is a shallow-bound implementation, whereas Interlisp-D and Interlisp/VAX are deep bound; so this problem of distinction has already been faced in that world. Since the shortfall is hardly perceptible to the user of a shallow-bound implementation, I recommend reading that part of the Interlisp reference manual dealing with the differences between the functions GETTOPVAL, GETATOMVAL, and EVALV. [This is found in section 2.4.1 of the Oct 1983 version of the IRM, and at the end of section 5.1 of the Oct 1978 version]. The comments therein about performance implications are not just theoretical, but have been observed to account for an order-of-magnitude difference between a poorly ported application and a properly ported one. Interlisp's EVALV corresponds by definition to CL's 'symbol-value' [note well: symbol-value is *not* defined by reference to a "value cell", but rather to the dynamic binding environment]; but there is no CL equivalent to GETTOPVAL, and GETATOMVAL. A Proffered Solution Actually, defvar "proclaims" a variable to be special; to meet the problems of this shortfall, there would need to be a declaration of globality for variables, just as there is a declaration of dynamic scoping for them (see the "special" section of section 9.2 in the manual). The observable differences between a variable of global scope and one of dynamic, or special, scope are: (1) it is an error to bind a global variable, but setq'ing is ok; and (2) a deep-bound implementation would do a "shallow" value-cell fetch for global references, rather than the kind of free-variable lookup it must do for dynamic references. Additionally, there should be a 'defglobalvar' which proclaims a variable to be of global scope, just as defvar proclaims one to be of dynamic scope. A Noticeable Semantic Distinction In addition to the perceived performance loss (in the deep-bound case) of not making accurate global declarations, there is in fact a semantic difference discernible in both deep and shallow. (setq x "Topval for x") (defun lookat () (let ((x "Random dynamic val for x")) (declare (special x)) (list (see-special) (see-global)))) (defun see-special () (declare (special x)) x) (defun see-global () (declare (global x)) x) When the global declaration is correctly done, the result of (lookat) will be ("Random dynamic val for x" "Topval for x") rather than ("Random dynamic val for x" "Random dynamic val for x") [Let me forstall any side-tracking discussion about the inadvisibility of using a variable both globally and specially in the same module. This example is only for illustrative purposes; the issue is really the protection of one module's usages against those of others, just as a local variable in one function needs to be sheilded from the dynamic bindings in another, lexically different, function.] Benefits of Distinction For the record, I will say that I believe programmers have in general overused dynamic variables in the past, ** particularly when attempting to define global state variables -- I've seen a lot of code that mistakenly defines some global variable, which in fact holds something that is process dependent, or application dependent. I think this will change in the future, due to the influence of Scheme and to the insistence by this community for correct lexical scoping in Lisp interpreters. This statement is only a generalization, but it comes from observing much code that had to be re-thought very carefully in the face of a multi-processing Lisp. One must distinguish global state in a machine, such as *modules* (section 11.8 of CL manual), or, say, *network-routing-table* from dynamic state such as *package* or *read-base* or, say, *standard-output* (which will be process-specific, at least) Properly used, each has their own place, that will become more individually secure as deep-bound implementations of CL come into being. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Dec 85 13:37:23 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 17 Dec 85 10:23:32 PST Date: 17 Dec 85 11:50:00 EST From: "BIZET::VANROGGEN" Subject: more comments To: "common-lisp" cc: vanroggen Reply-To: "BIZET::VANROGGEN" Comments on clarifications/minor changes: 1 UNDO is too vague. I suggest something like either (UNPROCLAIM '(CONSTANT FOO)) or (PROCLAIM '(NOTCONSTANT FOO)) Same for SPECIAL. We'll need a PROCLAIM CONSTANT too. But wait--what will it mean to make incompatible proclamations? As is said in [clarification 56,58], redefining a constant is an error. Then surely making a constant a variable ought to be at least as dangerous. This problem is more general than just wanting to be able to "undo" a definition--we need to decide how to change definitions. For example, if one first (PROCLAIM '(FTYPE (FUNCTION STRING INTEGER) FOO)) and then (DEFUN FOO (S I) (DECLARE (TYPE SEQUENCE S) (TYPE FIXNUM I)) ...), is the DECLARE in error or does it supersede the proclamation, or does it just shadow the proclamation for the body of the function? What if later (DEFUN FOO (A B C) (DECLARE (FLOAT A B C)) ...)? Or if there's a PROCLAIM to that effect? I hope we can define some reasonable behavior, but I think there will always be some conflict between "static" proclamations and the "dynamic" redefinitions done during program development until some notion of "state" is introduced. Also, should DEFVAR update the documentation string even when the variable already had a value and thus didn't get reset? 47 The problem with the idiosyncratic use of &REST in a function type specifier is that we really need a more general list-type description without resorting to arbitrary predicates. Although &REST (INTEGER 0) is a cute idea, I'm mildly opposed. 60 Yes, "an error" to have two parameters be the same symbol. I assume "same (EQL) name" isn't really meant here, since the following should be OK: (DEFUN FOO (PACK1:X PACK2:X) ...) 82 XOR seems to be stretching the analogy between control constructs and logical operations a bit. BTW, there ought to be a mention of EVERY and SOME in the descriptions of AND and OR if one wants to apply their functionalities. 107,144 Would life, the language, and everything be simpler if MACROLET didn't exist? 145 I'd prefer (BODY &OPTIONAL DOCP ENV) for PARSE-BODY where DOCP defaults to NIL. 145 Is it OK to destroy the non-top-level list provided by &REST? Should this be different for macros than for functions? 158 No, this should be an error only if the types conflict. 161 Should be OK if there are fewer returned values if they still match the type specified. (I.e., if NIL is TYPEP the given type). 249 Hmmm. For now we can state that circular lists are "an error", just so the language can be more precisely defined. 307 Also watch out for a slot named "P". 321 EVAL doesn't need an environment arg--what's wrong with the existing EVALHOOK function? 439 I didn't mean that COMPILE had to save the interpreted definition for COMPILEDP to potentially return. Rather, +if+ COMPILE had saved it, COMPILEDP would return it and UNCOMPILE would restore it. Also, COMPILEDP is supposed to work on names and can be true for macros (and special forms, though that's not relevant), which distinguishes it from COMPILED-FUNCTION-P. COMPILEDP should be false for a closure over a compiled function, but COMPILED-FUNCTION-P should be true. ---Walter ------  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Dec 85 13:36:17 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 17 Dec 85 07:59:50 PST Received: from ignatius by GODOT.THINK.COM via CHAOS; Tue, 17 Dec 85 10:59:39 est Date: Tue, 17 Dec 85 10:58 EST From: Guy Steele Subject: Questions, comments and clarifications on clarifications To: DLW@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <851217105855.3.GLS@THINK-IGNATIUS.ARPA> Date: Mon, 16 Dec 85 14:05 EST From: Daniel L. Weinreb Date: Mon, 16 Dec 85 13:01 EST From: Guy Steele ... If this is what you mean, it should be made clear that (1) the model of a "file" is that it has a single associated element-type, and (2) if you use the new form of file-length, and you pass in :element-type, then the value must be the same as the actual element-type of the file, or else it is an error (the result is undefined). (Put more crudely, there should be no defined way to write a file in units of X and then ask for its length in units of Y, that claims to be portable.) I agree. I think that (1) was already, if not clear, then at least translucent from the existing description of FILE-LENGTH. Clearly (2) is a necessary consequence for portability.  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Dec 85 11:20:00 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 17 Dec 85 07:59:50 PST Received: from ignatius by GODOT.THINK.COM via CHAOS; Tue, 17 Dec 85 10:59:39 est Date: Tue, 17 Dec 85 10:58 EST From: Guy Steele Subject: Questions, comments and clarifications on clarifications To: DLW@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <851217105855.3.GLS@THINK-IGNATIUS.ARPA> Date: Mon, 16 Dec 85 14:05 EST From: Daniel L. Weinreb Date: Mon, 16 Dec 85 13:01 EST From: Guy Steele ... If this is what you mean, it should be made clear that (1) the model of a "file" is that it has a single associated element-type, and (2) if you use the new form of file-length, and you pass in :element-type, then the value must be the same as the actual element-type of the file, or else it is an error (the result is undefined). (Put more crudely, there should be no defined way to write a file in units of X and then ask for its length in units of Y, that claims to be portable.) I agree. I think that (1) was already, if not clear, then at least translucent from the existing description of FILE-LENGTH. Clearly (2) is a necessary consequence for portability.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 23:51:52 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Dec 85 20:41:53 PST Received: ID ; Mon 16 Dec 85 23:41:16-EST Date: Mon, 16 Dec 1985 23:41 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: Non-top-level DEFUN In-reply-to: Msg of 16 Dec 1985 23:18-EST from Daniel L. Weinreb Whether or not Weinreb was confused, the larger point remains: The notion of "top-level form" is a complete disaster and should be abolished. We should flush this in favor of a careful specification of just what things the compiler is required to handle in well-defined ways and which things are left to the discretion of the implementor. We've got enough experience by now that we can tie down some things that we were afraid to specify earlier. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 23:26:11 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 20:18:11 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375729; Mon 16-Dec-85 23:17:43-EST Date: Mon, 16 Dec 85 23:18 EST From: Daniel L. Weinreb Subject: Non-top-level DEFUN To: common-lisp@SU-AI.ARPA Message-ID: <851216231823.7.DLW@CHICOPEE.SCRC.Symbolics.COM> In recent mail, I said that I wasn't sure that DEFUNs inside a top-level LET were valid CL. This was a completely error on my part, resulting from my having spent too much time in design discussions to remember how they came out. Yes, it's legal Common Lisp. And the Symbolics implementation supports it correctly, too. Sorry about that.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 20:14:18 EST Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 17:01:39 PST Received: by glacier with Sendmail; Mon, 16 Dec 85 17:00:25 pst Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7) id AA10372; Mon, 16 Dec 85 16:30:09 pst Received: by escargot.UUCP (4.12/4.7) id AA04100; Mon, 16 Dec 85 16:29:10 pst Date: Mon, 16 Dec 85 16:29:10 pst From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8512170029.AA04100@escargot.UUCP> To: masinter.pa@Xerox.ARPA Cc: common-lisp@SU-AI.ARPA In-Reply-To: glacier!masinter.pa@Xerox.ARPA's message of 16 Dec 85 13:03 PST Subject: Re: Special Form Question Date: 16 Dec 85 13:03 PST From: glacier!masinter.pa@Xerox.ARPA It would be more consistent and portable to define (symbol-function 'quote) => nil. under the theory that "symbol-function" really means to return a function rather than "what this symbol means when seen as car of something to be EVAL'd." Similarly, it would be more consistent and portable to require that after (defmacro foo --) that (symbol-function 'foo) also return nil. This would mean that values returned by symbol-function could be assumed to be functions, in the "funcall-able" sense. It is likely that implementations will want to have some internal "really give me what this symbol means when you see it as the CAR of a form about to be EVALd" for use by the interpreter, but its not clear to me why that primitive has to be "symbol-function". Alternatively, you could leave symbol-function as the thing that accesses a symbol's "function cell", and provide a new function that is the same as FUNCTION, except that its argument is evaluated. It could be applied to things other than symbols (e.g. lists with CAR = LAMBDA). Call it FEVAL?? Then you could eliminate lambda expressions as functions (the only argument for them was that you needed to be able to construct functions on the fly -- now you can construct lambda expressions and use FEVAL to turn them into functions).  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 18:33:59 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 15:23:58 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 375442; Mon 16-Dec-85 16:42:38-EST Date: Mon, 16 Dec 85 16:44 EST From: David C. Plummer Subject: XOR To: Guy Steele , Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA> Message-ID: <851216164401.5.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 13:05 EST From: Guy Steele Date: Sun, 15 Dec 85 16:35 EST From: David A. Moon The XOR function in your list of suggested language improvements handed out last week was intended to be a joke, wasn't it? I assumed it was, but other people on the mailing list are taking it seriously, so I'm asking for clarification. Of all the functions not in Common Lisp that I use day-to-day on my 3600, this is the one I use most frequently. I admit that I have been, among other things, constructing logic models of various kinds. However, I also find it useful in random COND clauses. Maybe the rest of you will decide it is not useful, but in any case it is not a joke. One argument I have heard against XOR is that, unlike AND and OR, it must evaluate all of its forms. Of course, MLB once sent an amusing thing describing an XOR that returns the right answer but somehow knows what the forms evaluate to so it can stop early after the things it doesn't know a priori !-}  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 18:27:49 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 15:17:59 PST Received: from Cabernet.ms by ArpaGateway.ms ; 16 DEC 85 14:37:51 PST Date: 16 Dec 85 14:37 PST From: masinter.pa@Xerox.ARPA Subject: Re: clarifications In-reply-to: Christopher Fry 's message of Mon, 16 Dec 85 06:03 EST To: cfry@OZ.AI.MIT.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <851216-143751-1352@Xerox> Some pathnames don't denote disks, and yet "free-space" is a meaningful concept. Why not "free-space" or "file-free-space" at least, instead of "disk-free-space"?  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 17:23:36 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 14:12:39 PST Date: Mon, 16 Dec 85 17:15:19 EST From: "Glenn S. Burke" Subject: get-setf-method To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].756838.851216.GSB> I had thought it had been established long ago that the environment argument is necessary. Not only for the reason Dave Plummer notes, but also for the correct macroexpansion of macros from within setf methods (such as LDB). I have no objections to the environment argument to get-setf-method being required, although I would be inclined to make it optional just as it is to macro-expand. Although one could argue for the environment arg to macro-expand being required, similarly...  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 17:10:12 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 14:00:20 PST Received: from Salvador.ms by ArpaGateway.ms ; 16 DEC 85 13:04:11 PST Date: 16 Dec 85 13:03 PST From: masinter.pa@Xerox.ARPA Subject: Re: Special Form Question To: common-lisp@SU-AI.ARPA Message-ID: <851216-130411-1214@Xerox> It would be more consistent and portable to define (symbol-function 'quote) => nil. under the theory that "symbol-function" really means to return a function rather than "what this symbol means when seen as car of something to be EVAL'd." Similarly, it would be more consistent and portable to require that after (defmacro foo --) that (symbol-function 'foo) also return nil. This would mean that values returned by symbol-function could be assumed to be functions, in the "funcall-able" sense. It is likely that implementations will want to have some internal "really give me what this symbol means when you see it as the CAR of a form about to be EVALd" for use by the interpreter, but its not clear to me why that primitive has to be "symbol-function". Larry  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 15:06:33 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Dec 85 11:53:44 PST Received: ID ; Mon 16 Dec 85 14:14:20-EST Date: Mon, 16 Dec 1985 14:14 EST Message-ID: From: Rob MacLachlan To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: list of proposed changes to Common Lisp In-reply-to: Msg of 16 Dec 1985 12:34-EST from Guy Steele Date: Monday, 16 December 1985 12:34-EST From: Guy Steele Re: list of proposed changes to Common Lisp Presumably COPY-PERSON, when applied to an ASTRONAUT, returns something that is a PERSON but not an ASTRONAUT; that is, it makes a copy of just the PERSON part of an ASTRONAUT? Well, so maybe it's not so clear-cut. I thought the obvious interpretation was that COPY-PERSON was the same thing as COPY-ASTRONAUT when applied to an astronaut. It now seems we have three possible interpretations: 1] It is illegal to use a copier for an included structure on an instance of the including structure. 2] The copier for the included structure returns an object of the same type as the included structure, containing only the included slots. 3] The copier for the included structure also copies instances of any structure which include it. If there are three modedately reasonable interpretations, is even more important to specify which applies. One thing worth considering is how well the interpretation fits into possible object-oriented programming systems such as Common Loops. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 15:03:49 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 11:49:12 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228643; Mon 16-Dec-85 14:43:43-EST Date: Mon, 16 Dec 85 14:57 EST From: Daniel L. Weinreb Subject: Another omission: global lexicals To: gls@THINK-AQUINAS.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <851216131407.7.GLS@THINK-JEHOSEPHAT.ARPA> Message-ID: <851216145707.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 13:14 EST From: Guy Steele (defvar foo 3) (defun baz () foo) (baz) => 3 (defglobal foo 5) (baz) => 5 the DEFGLOBAL changes the meaning of the variable reference in BAZ. In the only semantics that currently seems to make sense to me, the DEFGLOBAL does not change the meaning. Since FOO is still declared special, the FOO in the body of BAZ is still a special reference. Unless you are assuming that DEFGLOBAL does a sort of (PROCLAIM (UNSPECIAL)), which I am not. Right now the meaning of FOO within BAZ can be determined by inspection of only BAZ: because there is no *lexically apparent* lexical binding, the reference to FOO must be special. With DEFGLOBAL as proposed, the meaning of FOO cannot be understood out of context. I'm not sure I concur with this logic. The meaning of FOO within BAZ depends on non-lexically-local information, namely whether FOO has been proclaimed special. In present CL as I know it, FOO is either a special reference or an error depending on whether FOO is proclaimed special; in the new proposal, semantics as I am assuming, FOO is either a special reference or a local reference or an error, depending on whether FOO is proclaimed special and on whether FOO is part of the global lexical environment or not. So the DEFGLOBAL is just another thing like a special proclaimation. Again, I'm not trying to support anything or object to anything, just trying to nail down what it is that the proposal means.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 14:35:03 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 10:58:04 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228614; Mon 16-Dec-85 13:52:25-EST Date: Mon, 16 Dec 85 13:58 EST From: David C. Plummer Subject: get-setf-method To: Common-Lisp@SU-AI.ARPA Message-ID: <851216135850.0.DCP@NEPONSET.SCRC.Symbolics.COM> Excuse me if this has already been cleared up, but (get-setf-method (macroexpand form env)) just won't cut it. Consider this example: (defmacro raster-aref (raster-array x y) ...code-to-ensure-order-of-evaluation... `(aref ,raster-array ,y ,x)) (defsetf raster-aref ...) Now, (raster-aref array (foo) (bar)) expands into (in our system, at least) (let ((.gensym-for-raster-array. array) (.gensym-for-bar. (bar))) (aref .gensym-for-raster-array. .gensym-for-bar. (foo))) Since when does LET have a DEFSETF method? I agree with whoever said the environment should be a required argument.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 14:12:23 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 10:57:43 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228613; Mon 16-Dec-85 13:52:07-EST Date: Mon, 16 Dec 85 14:05 EST From: Daniel L. Weinreb Subject: Questions, comments and clarifications on clarifications To: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <851216130145.5.GLS@THINK-JEHOSEPHAT.ARPA> Message-ID: <851216140512.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 16 Dec 85 13:01 EST From: Guy Steele Sorry it wasn't clean. FILE-LENGTH is defined to return the length of a file measured in units of ELEMENT-TYPE. FILE-LENGTH now is guaranteed to work only on an open stream, and it uses the ELEMENT-TYPE specified when the stream was opened. The proposal is to allow FILE-LENGTH to take any pathname, but in that case it may be necessary to specify an ELEMENT-TYPE explicitly in order to get the answer you want. If this is what you mean, it should be made clear that (1) the model of a "file" is that it has a single associated element-type, and (2) if you use the new form of file-length, and you pass in :element-type, then the value must be the same as the actual element-type of the file, or else it is an error (the result is undefined). (Put more crudely, there should be no defined way to write a file in units of X and then ask for its length in units of Y, that claims to be portable.)  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 13:50:51 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:34:12 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:34:12 est Date: Mon, 16 Dec 85 13:34 EST From: Guy Steele Subject: &ALLOW-OTHER-KEYS To: wagner%fang@GSWD-VMS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <8512161458.AA08881@gswd-vms.ARPA> Message-Id: <851216133412.0.GLS@THINK-JEHOSEPHAT.ARPA> Date: Mon, 16 Dec 85 08:57:27 cst From: wagner%fang@gswd-vms (Fran Wagner) In the clarifications that Guy distributed in Boston, mention is made of &ALLOW-OTHER-KEYWORDS (p.1). In CLtL and in implementations I could check, this lambda-list keyword is named &ALLOW-OTHER-KEYS. The KEYWORDS form is more natural, but it is a mistake, right? --Fran Yes, I made a mistake. Thanks for pointing it out. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 13:46:32 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:31:48 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:31:44 est Date: Mon, 16 Dec 85 13:31 EST From: Guy Steele Subject: meta corrections to CLtL To: cfry@OZ.AI.MIT.EDU Cc: common-lisp@SU-AI.ARPA In-Reply-To: <851216055254.2.CFRY@JANIS.AI.MIT.EDU> Message-Id: <851216133143.9.GLS@THINK-JEHOSEPHAT.ARPA> Date: Mon, 16 Dec 85 05:52 EST From: Christopher Fry I updated my copy of CLtL to include all of your comments, except that I think you made a few errors in the Corrections doc: 189 fewethings => few things Your habit of typing e where SPACE should be is pretty confusing! I forgot to mention this at the conference: the handouts I produced were printed on a laser printer that was placed a bit too far from its host (on a long cable) or something. Some electrical glitch causes it to randomly turn a space into "a" or "e". This seems to occur only when the space immediately follows a "w". --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 13:32:23 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:14:16 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:14:09 est Date: Mon, 16 Dec 85 13:14 EST From: Guy Steele Subject: Another omission: global lexicals To: RAM@C.CS.CMU.EDU, DLW@SCRC-QUABBIN.ARPA Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <851216131407.7.GLS@THINK-JEHOSEPHAT.ARPA> Date: Sun, 15 Dec 1985 18:40 EST From: Rob MacLachlan Yes, we seem to be talking about the same thing. I believe you have the right model for interaction with specials: there is none. Unfortunately this means that shallow-binding implementations would have to have separate lexical and special value cells, since you could do something like this: (defglobal foo :global) (let ((foo :special)) (declare (special foo)) (bar)) (defun bar () (format t "~S or ~S, take you pick." foo (locally (declare (special foo)) foo))) This doesn't mean that your symbol needs another slot though. You could keep the lexical value cells somewhere else (such as on the PLIST!!), since you only need to locate the value cell at load time. Rob I think it is a bad idea to let "global lexicals" and specials be completely independent, for the simple reason that in (defvar foo 3) (defun baz () foo) (baz) => 3 (defglobal foo 5) (baz) => 5 the DEFGLOBAL changes the meaning of the variable reference in BAZ. Right now the meaning of FOO within BAZ can be determined by inspection of only BAZ: because there is no *lexically apparent* lexical binding, the reference to FOO must be special. With DEFGLOBAL as proposed, the meaning of FOO cannot be understood out of context. Here is a different model for DEFGLOBAL: it is just like DEFCONSTANT except you are allowed to SETQ it. So you can change its value with a side effect (or even make it unbound), but it is an error to bind it. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 13:17:10 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:05:05 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:05:08 est Date: Mon, 16 Dec 85 13:05 EST From: Guy Steele Subject: XOR To: Moon@SCRC-STONY-BROOK.ARPA, Steele@THINK-AQUINAS.ARPA Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <851215163550.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <851216130507.6.GLS@THINK-JEHOSEPHAT.ARPA> Date: Sun, 15 Dec 85 16:35 EST From: David A. Moon The XOR function in your list of suggested language improvements handed out last week was intended to be a joke, wasn't it? I assumed it was, but other people on the mailing list are taking it seriously, so I'm asking for clarification. Of all the functions not in Common Lisp that I use day-to-day on my 3600, this is the one I use most frequently. I admit that I have been, among other things, constructing logic models of various kinds. However, I also find it useful in random COND clauses. Maybe the rest of you will decide it is not useful, but in any case it is not a joke.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 13:15:16 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 10:01:58 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 13:01:46 est Date: Mon, 16 Dec 85 13:01 EST From: Guy Steele Subject: Questions, comments and clarifications on clarifications To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <851215163501.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <851216130145.5.GLS@THINK-JEHOSEPHAT.ARPA> Date: Sun, 15 Dec 85 16:35 EST From: Daniel L. Weinreb 425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the proposal doesn't say what it means. I'd like to hear what this argument is supposed to be defined to mean, expressed in a way that is implementation-independent in any sense, such that this argument could ever be used in a portable program and relied upon to do any specific thing in particular. Sorry it wasn't clean. FILE-LENGTH is defined to return the length of a file measured in units of ELEMENT-TYPE. FILE-LENGTH now is guaranteed to work only on an open stream, and it uses the ELEMENT-TYPE specified when the stream was opened. The proposal is to allow FILE-LENGTH to take any pathname, but in that case it may be necessary to specify an ELEMENT-TYPE explicitly in order to get the answer you want. 439: What is COMPILEDP defined to do if you give it a lexical closure over a function that is compiled? I would say it should return T. 443: Do you also want to say that APROPOS might find some specific symbols more than once, assuming that 187 is accepted? Yep.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 12:44:53 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 16 Dec 85 09:34:52 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Mon, 16 Dec 85 12:34:48 est Date: Mon, 16 Dec 85 12:34 EST From: Guy Steele Subject: list of proposed changes to Common Lisp To: RAM@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <851216123446.3.GLS@THINK-JEHOSEPHAT.ARPA> Date: Sat, 14 Dec 1985 00:46 EST From: Rob MacLachlan (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do not perform macro-expansion on the given form ... This won't work, as it prohibits defining setf methods for macros. GET-SETF-METHOD needs the environment so that it can expand macros one level at a time, checking if the result has a setf method. I also suggest that the environment argument not be optional, as any user code which doesn't supply it is surely broken. Right you are. 312 It should be explicitly noted somewhere that defstruct copiers work on structures which are a subtype by inclusion, e.g. COPY-PERSON works on an astronaut. This is a natural consequence of the subtype semantics of inclusion, but isn't necessarily obvious to pea-brained implementors. Presumably COPY-PERSON, when applied to an ASTRONAUT, returns something that is a PERSON but not an ASTRONAUT; that is, it makes a copy of just the PERSON part of an ASTRONAUT? --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 10:13:51 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 07:03:21 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374918; Mon 16-Dec-85 10:03:00-EST Date: Mon, 16 Dec 85 10:11 EST From: Daniel L. Weinreb Subject: Another omission: global lexicals To: RAM@C.CS.CMU.EDU cc: JAR@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851216101119.7.DLW@CHICOPEE.SCRC.Symbolics.COM> I thought we were in agreement, but now I'm not sure. What does this program print? (defglobal g 4) (set 'g 5) (defun foo () (setq g 6)) (foo) (print g) In my interpretation of your original proposal, (print g) is referring to g lexically, since nobody ever declared it special. foo is referring to g lexically also. The value of the symbol named g is irrelevant; the program prints 6. Before I continue this message, is it your current claim that it prints 6, or that it prints 5?  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 10:10:14 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 06:57:42 PST Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6) id AA08881; Mon, 16 Dec 85 08:58:46 CST Message-Id: <8512161458.AA08881@gswd-vms.ARPA> Date: Mon, 16 Dec 85 08:57:27 cst From: wagner%fang@gswd-vms (Fran Wagner) To: common-lisp@su-ai.arpa Subject: &ALLOW-OTHER-KEYS Cc: wagner%fang@gswd-vms In the clarifications that Guy distributed in Boston, mention is made of &ALLOW-OTHER-KEYWORDS (p.1). In CLtL and in implementations I could check, this lambda-list keyword is named &ALLOW-OTHER-KEYS. The KEYWORDS form is more natural, but it is a mistake, right? --Fran  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 09:51:44 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 06:41:15 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374896; Mon 16-Dec-85 09:40:13-EST Date: Mon, 16 Dec 85 09:48 EST From: Daniel L. Weinreb Subject: Another omission: global lexicals To: GJC@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, RAM@C.CS.CMU.EDU In-Reply-To: <[MIT-MC.ARPA].755061.851215.GJC> Message-ID: <851216094829.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sun, 15 Dec 85 18:05:36 EST From: "George J. Carrette" Seriously Dan, if you fellows go before the ISO and say that "The oft-discussed:" is vague with respect to legality in Common Lisp the USA is going to look pretty wimpy. You're right, George. I'll never again say that anything is vague with respect to legality. Every issue is clear-cut. We'll see if we can get Rambo for the technical committee.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 06:13:24 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Dec 85 03:03:28 PST Received: from MIT-JANIS by MIT-OZ via Chaosnet; 16 Dec 85 06:02-EST Date: Mon, 16 Dec 85 06:03 EST From: Christopher Fry Subject: clarifications To: common-lisp@SU-AI.ARPA Message-ID: <851216060351.3.CFRY@JANIS.AI.MIT.EDU> 130: Self-evaluating forms (such as strings] in tagbodies are no-ops but otherwise harmless. Its not worth it to make a special case to rule them out. Code (or humans) that write/modify other code shouldn't have to worry about what's in the body that its wrapping a tagbody around. 268: Can the proposed COPY be installed like SETF? Call it COPYF. Depth of copying could be specified with an integer. 425: Along with FILE-LENGTH, it would be nice to be able to ask the operating system how much disk-space is available in a given directory, so you could have some control when attempting to write too-large files without going through some error mechanism. (disk-free-space pathname) => number of bytes available.  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 00:43:33 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 21:34:03 PST Received: ID ; Mon 16 Dec 85 00:33:45-EST Date: Mon, 16 Dec 1985 00:33 EST Message-ID: From: Rob MacLachlan To: Jonathan A Rees Cc: common-lisp@SU-AI.ARPA Subject: Another omission: global lexicals Now that I'm done editing, let's try again: ________________________________ Beautiful: I knew there was a justification for the obvious implementation. A special binding is actually a binding of the global value cell. Each symbol potentially has one global value cell. This value cell is used to store the value of global variables and constants. The functions SYMBOL-VALUE, BOUNDP and MAKUNBOUND operate on this value cell. In a shallow-binding lisp, all global references can go directly to this cell. In a deep-binding lisp, global references other than special references can go direct; special references potentially involve a search. In fact I think it wouldn't break any Common Lisp programs (certainly not any tasteful ones) to allow dynamic bindings on any variable. It would only make a difference in contorted cases where there is both a lexical binding and a special binding of the same name in the same lexical scope. I doubt this exists outside of the example in the manual. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Dec 85 00:37:42 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 21:26:35 PST Received: ID ; Mon 16 Dec 85 00:26:15-EST Date: Mon, 16 Dec 1985 00:26 EST Message-ID: From: Rob MacLachlan To: Jonathan A Rees Cc: common-lisp@SU-AI.ARPA Subject: Another omission: global lexicals In-reply-to: Msg of 15 Dec 1985 21:58-EST from Jonathan A Rees Each symbol potentially has one global value cell. This value cell is used to store the value of global variables and constants. The functions SYMBOL-VALUE, BOUNDP and MAKUNBOUND operate on this value cell. References to global lexical variables and constants may use this cell directly. In a shallow-binding Lisp, a special binding shallow-binds this cell, and a special reference reads this cell. In a deep-binding Lisp, some search needs to be done for a special reference or store. You are right. In fact I think it wouldn't break any Common Lisp programs (certainly not any tasteful ones) to allow dynamic bindings on any variable. It would only make a difference in contorted cases where there is both a lexical binding and a special binding of the same name in the same lexical scope. I doubt this exists outside of the example in the manual. If even this slight possibility scares you, then you could say that a special binding always binds the global value cell for the symbol.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 22:44:28 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 19:35:09 PST Received: ID ; Sun 15 Dec 85 22:34:59-EST Date: Sun, 15 Dec 1985 22:34 EST Message-ID: From: Rob MacLachlan To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: list of proposed changes to Common Lisp (*) 158 Specify that it is an error for more than one TYPE declaration for a given variable to appear in a group of declarations (those all at the head of the same body), or more than one FTYPE or FUNCTION declaration for a given function name, or both an INLINE and a NOTINLINE declaration for the same function. I think this is excessively restrictive. The obvious meaning of multiple type declarations for the same variable is that the value of the variable is of *both* types. (declare (type a foo) (type b foo)) is the same as (declare (type (and a b) foo)). This feature could actually be used to good effect. Suppose a clever writer of the DOTIMES macro realized that the variable will always be of type (INTEGER 0), and added such a declaration in the expansion. The user of DOTIMES might know that the upper bound is always a fixnum, and write (dotimes (i x) (declare (fixnum i)). The compiler could then determine that the step variable is in fact a non-negative fixnum, which might be a useful piece of information. Note that if the declared types are known to be disjoint, the variable will have effectively been declared to be of type NIL, thus the binding (not the declaration) is illegal, since its initial value cannot be of type NIL. Note also that this interpretation won't break anything; the variable belongs to all the types, thus an implementation which uses any one will still be correct. An FTYPE declaration is identical to a type declaration except for specifying the result of functional evaluation, so the same reasoning holds. A FUNCTION declaration is in fact a (TYPE FUNCTION ...) declaration, so this is also reasonable. I have no objection of saying that conflicting INLINE and NOTINLINE declarations are illegal, but due to the advisory nature of INLINE declarations, it might be reasonable to say the compiler can obey whichever declaration it feels like. While we are talking about types, I will mention that there is a missing type specifier, namely REAL, which is probably the same as (OR FLOAT RATIONAL). Although probably useless as a declaration, it is useful for things like CHECK-TYPE. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 22:06:21 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 18:55:41 PST Date: Sun, 15 Dec 85 21:58:18 EST From: Jonathan A Rees Subject: Another omission: global lexicals To: RAM@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].755383.851215.JAR> Date: Sun, 15 Dec 1985 14:53 EST From: Rob MacLachlan It is also worth noting that it should be trivial to add global lexicals to any implementation. The value is kept in the global value cell, just as for a special; the only difference is that there is no special annotation. I interpret your suggestion as saying that DEFGLOBAL means the same thing as SETQ, except that it lets compilers know that you really do want a global lexical variable, so they shouldn't generate warning messages that they might otherwise be inclined to generate ("FOO declared special"). If you dynamically bind one, everyone sees the dynamic binding. I agree that this would be nice. You have to make sure you know how implementations which use deep binding for special variables are going to deal with this; my interpretation of your proposal makes different implementation demands from Weinreb's interpretation. However, I think deep-bound Common Lisps can simply cause references to DEFGLOBAL'ed variables to always go through its top-level value cell (presumably one still exists, even if the variable has been dynamically bound). SYMBOL-VALUE would still always get the special binding. I think one could go either as you suggest or as Weinreb suggests on this. My reading of your proposal seems to be a less radical departure from common lisp. But it's important to keep in mind the distinction and consider the ramifications and possible generalizations of any proposal. I'm also frustrated by the absence of global lexical variables. There's no way you can PREVENT a LET or LAMBDA from doing dynamic binding if the variable obtained its top-level binding with DEFVAR. To make matters worse, some implementations (viz. the one I use) even discourage you from doing top-level references and SETQ's on variables which haven't been declared or proclaimed SPECIAL - you get "FOO declared special" messages (fortunately it does a DECLARE and not a PROCLAIM!). I asked the list a while ago if anyone could remember why there was no UNSPECIAL declaration in the language, and I didn't get any answer. If UNSPECIAL existed, you could redefine LET, LAMBDA, etc. to put implicit DECLARE UNSPECIAL's in their bodies, and get the effect of global lexicals just by using DEFVAR. The only reason I can think of to exclude UNSPECIAL is to avoid putting constraints on deep-bound or hybrid implementations. The solution I ended up using is this: I use SETQ, never DEFVAR to introduce a top-level binding; I always write (locally (declare (special x)) x) to reference the global "x" (to inhibit the compiler's automatic DECLARE SPECIAL and its annoying warning message); I use (let ((temp (compute-value ...))) (setq x temp)) to make an assignment (for the same reasons - and macroized, of course); and I never use implicit (proclaimed) SPECIAL declarations - if I want to do a special binding I use a DECLARE. Of course, my code will very likely stop working if I ever run it in a deep-bound implementation. In short: DEFGLOBAL is an important addition to the language, and very easy to implement. (It will probably wreak havoc on the manual - how many places implicitly assume that global variables are always special?) ----- [Aside: MIT Scheme and T have a generalization of this which allows ANY lexical variable to be dynamically bound. As in your proposal, top-level lexicals and top-level specials live in the same place. Specials are lexically shadowed by lexical bindings of the same name, but any lexical variable, not just a top-level lexical variable, can be dynamically bound. Dynamicness is not a property of variables (names), but of binding. I would expect people who haven't thought about this before to be confused. I certainly was when I first saw it. Here is an example. (setq y 'top) (defun foo1 () (let ((y 'lexical)) (bar #'(lambda (f) (fluid-let ((y 'fluid)) (funcall f))) ;scheme dynamic binding #'(lambda () y)))) (defun foo2 () (let ((y 'lexical)) (bar #'(lambda (f) (let ((y 'fluid)) (declare (special y)) ;CL dynamic binding, for comparison (funcall f))) #'(lambda () y)))) (defun bar (g h) (funcall g #'(lambda () (list (funcall h) y)))) (foo1) => (FLUID TOP) (foo2) => (LEXICAL FLUID) ;[probably, at least in shallow implementations] The semantics of (fluid-let ((x value)) body) is similar to (let ((temp x)) (setq x value) (unwind-protect body (setq x temp))) except of course that it interacts properly with context switches. It turns out this facility is moderately useful. And it works in either shallow-bound implementations or deep-bound ones (both MIT Scheme and T use shallow binding right now, but T is changing to deep binding). I think this is subsumed by Zetalisp's LETF, for those of you familiar with that.] - Jonathan  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 20:09:22 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 16:58:04 PST Received: ID ; Sun 15 Dec 85 19:57:50-EST Date: Sun, 15 Dec 1985 19:57 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: unclarities: defstruct print functions Another issue in need of resolution is that of communicating the current depth in the printing when there are user-defined print functions. Guy said that what had in mind was that the user would bind *print-level* according to the depth arg supplied to the print function, but there were several problems with this. Most of the tasteful solutions involved adding new args to WRITE which indicated the nature of the recursive use of the printer. Others objected that nobody uses WRITE, so that isn't a real fix. This was discussed about a month ago. Only God knows how many unresolved issues lie buried and forgotten in the Common Lisp archive. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 19:30:15 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 16:21:20 PST Received: ID ; Sun 15 Dec 85 19:21:06-EST Date: Sun, 15 Dec 1985 19:20 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Minor package unclarity It says on 177 that "There is no way to inherit the internal symbols of another package; to refer to an internal symbol, the user must either make the symbol's home package current, use a qualifier, or import that symbol into the current package." This not really true, since a symbol may be internal in some packages and external in others. The real vaguery is in the phrase "internal symbol"; there is no such thing. A symbol is only internal with respect to a particular package. This may seem like a quibble, but it can cause confusion. Naive users have enough problems without encouraging misconceptions. It is a misconception that internalness or externalness is a property of a symbol. This misconception should be thouroughly stamped out. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 18:50:10 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 15:41:38 PST Received: ID ; Sun 15 Dec 85 18:41:02-EST Date: Sun, 15 Dec 1985 18:40 EST Message-ID: From: Rob MacLachlan To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: Another omission: global lexicals In-reply-to: Msg of 15 Dec 1985 17:55-EST from Daniel L. Weinreb Yes, we seem to be talking about the same thing. I believe you have the right model for interaction with specials: there is none. Unfortunately this means that shallow-binding implementations would have to have separate lexical and special value cells, since you could do something like this: (defglobal foo :global) (let ((foo :special)) (declare (special foo)) (bar)) (defun bar () (format t "~S or ~S, take you pick." foo (locally (declare (special foo)) foo))) This doesn't mean that your symbol needs another slot though. You could keep the lexical value cells somewhere else (such as on the PLIST!!), since you only need to locate the value cell at load time. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 18:13:00 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 15:02:59 PST Date: Sun, 15 Dec 85 18:05:36 EST From: "George J. Carrette" Subject: Another omission: global lexicals To: DLW@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, RAM@C.CS.CMU.EDU In-reply-to: Msg of Sun 15 Dec 85 16:38 EST from Daniel L. Weinreb Message-ID: <[MIT-MC.ARPA].755061.851215.GJC> Seriously Dan, if you fellows go before the ISO and say that "The oft-discussed:" (let ((a 4)) (defun foo (x) ...) (defun bar (y) ...) ) is vague with respect to legality in Common Lisp the USA is going to look pretty wimpy. Maybe it wouldn't be so vague if more implementations took the extra trouble (or, what is better, the extra level of uniformity and generality of treatment) to implement it. Certainly anybodies CL interpreter would have to either be very broken or being going out of its way to make this not work at top level: (let ((a 4)) (setf (symbol-function 'foo) #'(lambda (x) ...)) (setf (symbol-function 'bar) #'(lambda (y) ...))) So whats the big deal about passing the same thing to a compiler? Some compilers may not compile the lambda expressions, but a user could rightly say that is a bug, the compiler generating slow code instead of good machine code.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 18:05:29 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 14:54:53 PST Received: from IMSSS by Score with Pup; Sun 15 Dec 85 14:52:06-PST Date: 15 Dec 1985 1449-PST From: Rem@IMSSS Subject: Elegant rule for what to copy To: COMMON-LISP%SU-AI@SCORE Here's an elegant rule for what to recursively copy and what to stop at when doing a recusive copy operation. Stop at anything that has an interned name (whereby READing in that name will give that same object) and recurse through anything else. The idea is that copying a structure will be the same as PRIN1ing it out and READing it back in but more efficient. Thus a named array (does CL have them?) will be a stop point, wheras an anonymous array will be recursed through. Interned symbols (IDs) will be stop points, but GENSYMs will be recursed through, with another GENSYM of exactly the same name replacing it, and with copies of the value and plist and function. (In that case READing it back in would accidently INTERN all the former GENSYMs, so COPY is more "right" than PRIN1-READ.) There's a slight problem for numbers, where you're supposed to recurse through them but there's nothing much to recurse through, so the elegant rule does have a little deficiency there. Of course for circular structure and to-be-preserved shared structure we have an alternate more expensive printing routine and likewise should have a more expensive copy routine. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 18:00:58 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 14:47:01 PST Received: ID ; Sun 15 Dec 85 17:46:51-EST Date: Sun, 15 Dec 1985 17:46 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Another Common Lisp unclarity While we are discussing issues needing to be resolved, I will drag out yet another problem which has been discussed in the past. It would be nice if someone would keep track of these things starting *now* so that we don't have to iterate N times. The problem is with the notion of "top level forms" and things containing a EVAL-WHEN (COMPILE), possibly implicit. Examples of forms with implicit compiler evaluation are PROCLAIM, DEFMACRO and DEFCONSTANT. Other possibles are package manipulation. The question is whether the compile-time action is done when the form appears in a context where it is not obvious that the form will ever be evaluated at run time. What happens if the compiler finds this? (if (oddp (get-universal-time)) (defmacro foo ...) (defmacro foo ...)) My answer is that the compiler always does the evaluation, no matter where the forms appears. The manual seems to support this interpretation. See the definition of EVAL-WHEN on 69 and DEFMACRO on 146. If this is the correct interpretation, then the manual should say so, possibly illustrating with an example, since this can result in non-obvious problems, especially for naive users who foolishly believe that programs do the same thing when compiled as when interpreted. There is some question about what to do with the package functions. Probably they only want to be evaluated when the function appears "really at top level". We wouldn't want compilation of this function to die with an unbound-symbol error: (defun my-export (syms) (export syms "MY-PACKAGE")) This contradicts the manual, since on page 182 it says that these functions are implicitly wrapped in an EVAL-WHEN (COMPILE LOAD EVAL). Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 17:59:15 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 14:47:05 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374652; Sun 15-Dec-85 17:46:48-EST Date: Sun, 15 Dec 85 17:55 EST From: Daniel L. Weinreb Subject: Another omission: global lexicals To: RAM@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851215175503.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Oh. OK, I see what you're saying: top level forms, instead of being considered to be in the null lexical environment as they are now, are instead considered to be in a particular distinguished unique lexical environment, the "global" lexical environment. All lexical environments "inherit from" (whatever) this one. In addition, there is a macro or special form called DEFGLOBAL that side-effects this global environment by adding to it a new variable/value pair. If foo is a global lexical, and your top-level defun function makes a reference to foo that's free with respect to the defun, then it refers to the global lexical variable foo. But if your function does a LET of foo, it gets a new lexical variable, just as if foo had not been in the global lexical environment at all. This all seems semantically consistent. One could ask why it's possible to side-effect this lexical environment when it isn't possible to side-effect any other lexical environment. I'm not sure that's really relevant or interesting, but I thought I'd bring it up in case someone else does think so. As for your questions "Is a global lexical BOUNDP? Can you MAKUNBOUND it?", the answers are clearly "No" and "No", just as for any other lexical variable. If you do (defglobal foo 3) and then do (boundp'foo), the latter is asking about the symbol foo, which has nothing to do with the lexical variable. If you (set 'foo 3), the lexical variable is likewise unaffected. If you do a special proclaimation on the same name, then all references and LETs and so on will refer to the symbol (the special variable); the global lexical variable still exists, but there is no way to get at it. (Except maybe if you make a closure over it before you evaluate the proclaimation!) I'll refrain from making any comments about implementation issues, until we're sure that we have worked out the semantics so that we know what we're talking about and we are all talking about the same thing.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 17:16:51 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 13:50:03 PST Received: ID ; Sun 15 Dec 85 16:49:24-EST Date: Sun, 15 Dec 1985 16:49 EST Message-ID: From: Rob MacLachlan To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: Another omission: global lexicals In-reply-to: Msg of 15 Dec 1985 16:38-EST from Daniel L. Weinreb Date: Sunday, 15 December 1985 16:38-EST From: Daniel L. Weinreb To: RAM, common-lisp at SU-AI.ARPA Re: Another omission: global lexicals The oft-discussed (let ((a 4)) (defun foo (x) ...) (defun bar (y) ...) ) would be a way to get global lexicals, if it were Common Lisp. The current manual is ambiguous, or at least vague, about whether this is construct is part of valid portable Common Lisp or not. This is clearly legal; any implementation which doesn't allow it is broken. There is some confusion about the meaning "top level forms" such as PROCLAIM within such a construct, but I don't see any other problems. The lexical scope of a global lexical is everything. If you insist on thinking about it this way, a global lexical is a global special which isn't special, i.e. bindings of that name are lexical instead of special. You can also think of a global lexical as being syntactic sugar for wrapping a let around all the code in the world. The only issue that seems murky to me is the interaction between global specials and global lexicals. What happens if you do a DEFGLOBAL and then a special procalamation on the same name? Is a global lexical BOUNDP? Can you MAKUNBOUND it? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 17:06:09 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 13:41:30 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374601; Sun 15-Dec-85 16:40:32-EST Date: Sun, 15 Dec 85 16:35 EST From: David A. Moon Subject: XOR To: Steele@Aquinas.Think.COM cc: Common-Lisp@SU-AI.ARPA Message-ID: <851215163550.2.MOON@EUPHRATES.SCRC.Symbolics.COM> The XOR function in your list of suggested language improvements handed out last week was intended to be a joke, wasn't it? I assumed it was, but other people on the mailing list are taking it seriously, so I'm asking for clarification.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 16:55:19 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 13:30:04 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374588; Sun 15-Dec-85 16:29:42-EST Date: Sun, 15 Dec 85 16:38 EST From: Daniel L. Weinreb Subject: Another omission: global lexicals To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851215163801.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sun, 15 Dec 1985 14:53 EST From: Rob MacLachlan I suggest this syntax: DEFGLOBAL [] And what semantics do you suggest? That is, OK, it's lexical, so what is its lexical scope? The oft-discussed (let ((a 4)) (defun foo (x) ...) (defun bar (y) ...) ) would be a way to get global lexicals, if it were Common Lisp. The current manual is ambiguous, or at least vague, about whether this is construct is part of valid portable Common Lisp or not.  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 16:37:42 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Dec 85 13:26:58 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374583; Sun 15-Dec-85 16:26:45-EST Date: Sun, 15 Dec 85 16:35 EST From: Daniel L. Weinreb Subject: Questions, comments and clarifications on clarifications To: common-lisp@SU-AI.ARPA In-Reply-To: <8512150230.AA01849@edsel.uucp> Message-ID: <851215163501.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sat, 14 Dec 85 18:30:16 pst From: edsel!eb@su-navajo.arpa (Eric Benson) 82. Is it gratuitous pseudo-generality to allow an arbitrary number of arguments to XOR, instead of requiring exactly two? Give an example. One could argue that XOR should take an arbitary number of arguments for symmetry with AND and OR, even if we can't come up with a satisfying example. Symmetry is important to keep the language self-consistent and easier to learn. As long as I'm sending mail, here are a few more quick comments: 249: There continues to be widespread disagreement among the expert users I know about circular list arguments to mapping functions. Several feel that it's natural, elegant, and seriously useful. I do not have any strong personal opinion, and I do not tend to use this style personally, but I don't think this issue is nearly as clear-cut as many of the others in "clarifications.text". 268: I suspect that COPY needs to be defined more specifically than it is in "clarifications.text" before we can decide whether it ought to be in the language. While I like the basic idea very much, I'm worried about a number of details. Someone already brought up the question of whether copying an array means preserving all of its attributes, such as displacement. If you COPY an interned symbol, is the result interned or uninterned, and what's the symbol-package? Are the conses of the property list copied also, or are the property lists shared? What if you copy a keyword symbol? Can you copy a package, and if so what is the name of the copy? If you copy a pathname, is the result allowed to be EQ to the argument? Can you copy a stream object that's open to a file and positioned 254 characters into the file? Can you copy an output stream that's in the middle of writing characters to a file that it's creating itself? If you copy a closure, do you get a new closure that shares the variable environment with the original, or does the environment get copied too? What other such issues might there be? I'd rather not express an opinion on COPY until a more detailed specification is proposed. 425: A new argument, :ELEMENT-TYPE, to FILE-LENGTH is proposed, but the proposal doesn't say what it means. I'd like to hear what this argument is supposed to be defined to mean, expressed in a way that is implementation-independent in any sense, such that this argument could ever be used in a portable program and relied upon to do any specific thing in particular. 439: What is COMPILEDP defined to do if you give it a lexical closure over a function that is compiled? 439: [The following is not well thought out; I apologize in advance.] All this stuff about the COMPILE function retaining the interpreted definition is starting to make me nervous about the line between a programming language and a programming environment. This, and also the "how do you undefine an X" issue, point out that the current design is wavering between trying to be a language specification and trying to be a programming environment specification. Obviously, in Lisp it's hard to draw the line. However, we are all assuming that there is some kind of distinction. To pick an extreme but illustrative example, suppose there were a purported Common Lisp implementation in which the CAR function, before returning the car of a cons, printed out some message on the terminal. Most of us would consider this a violation of the Common Lisp spec; that is, if I tried to port my program and my program failed to work because of this message, I'd blame the CL implementation, not my program. But LOAD is defined in CLtL just as much as CAR is, and I haven't heard anybody complain that a Lisp is out of conformance with the standard because LOAD prints out a message. I don't have any specific constructive suggestions at this time, but I think if we don't figure this stuff out, we may be letting ourselves in for trouble and surprising portability problems. 443: Do you also want to say that APROPOS might find some specific symbols more than once, assuming that 187 is accepted?  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Dec 85 15:04:38 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 15 Dec 85 11:53:31 PST Received: ID ; Sun 15 Dec 85 14:53:24-EST Date: Sun, 15 Dec 1985 14:53 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Another omission: global lexicals It is truly silly that there is no way to define a global lexical variable in Common Lisp. Many places where defvar is used there is no need for dynamic binding, since the variable is never bound. If a variable is known to be a global lexical then various optimizations can be made which are otherwise impossible: 1] A global lexical cannot be unbound, therefore there is no need to check that is bound before accessing it. 2] Since it cannot be globally rebound, there is no need to search for the value in an implementation which deep-binds specials. This is significant since shallow-binding doesn't work in multi-processor implementations. A global lexical is also less dangerous to use than a global special, since a global lexical doesn't magically specialify other lexical uses of the same name. Dynamic binding is overkill in many applications. I believe that programs would be clearer if it was more obvious which variables are actually bound dynamically. It is also worth noting that it should be trivial to add global lexicals to any implementation. The value is kept in the global value cell, just as for a special; the only difference is that there is no special annotation. I suggest this syntax: DEFGLOBAL [] Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Dec 85 23:08:31 EST Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 19:53:24 PST Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 19:50:34 pst Received: by edsel.uucp (2.2/SMI-2.0) id AA01849; Sat, 14 Dec 85 18:30:16 pst Date: Sat, 14 Dec 85 18:30:16 pst From: edsel!eb@su-navajo.arpa (Eric Benson) Message-Id: <8512150230.AA01849@edsel.uucp> To: navajo!Common-Lisp@SAIL Subject: Questions, comments and clarifications on clarifications 82. Is it gratuitous pseudo-generality to allow an arbitrary number of arguments to XOR, instead of requiring exactly two? Give an example. 107. GET-SETF-METHOD should definitely take an optional environment argument. Calling MACROEXPAND is seldom a good thing to do in a program, even a compiler, since there may be intermediate macros which require special handling. In this case an intermediate macro may have a setf method. Even though a user program is probably incorrect if it does not supply the environment argument to GET-SETF-METHOD, we should make it optional for maximum compatibility with the existing standard. Along with allowing an optional environment argument to GET-SETF-METHOD, it is important to allow DEFINE-SETF-METHOD to take an &ENVIRONMENT argument. It is also important that macros defined with DEFINE-MODIFY-MACRO correctly pass the environment to GET-SETF-METHOD; this belongs in an implementation note. A hard question: Does MACROLET shadow a setf method or not? (DEFUN LOSER (X) (CAR X) (DEFUN SET-LOSER (X Y) (SETF (CAR X) Y)) (DEFSETF LOSER SET-LOSER) (DEFUN LOSSAGE (X Y) (MACROLET ((LOSER (X) `(SYMBOL-VALUE ,X))) (SETF (LOSER X) Y))) Does LOSSAGE call SET-LOSER or SET? 130. I think it is better to say that anything other than a symbol or an integer at the top level in a TAGBODY is evaluated normally, rather than having special rules. This is not a major point, however. 144. Can an FLET shadow a DEFMACRO? (DEFMACRO FOO () ) (DEFUN BAR () (FLET ((FOO () ...)) (MACROLET ((BAZ (&ENVIRONMENT ENV) (IF (MACRO-FUNCTION 'FOO ENV) "Lose" "Win"))) (BAZ)))) Does (BAR) return "Win" or "Lose"? (See if you can guess what I think it should do.) 268. There's no need to mention that COPY uses the user-specified copy function for structures, since the user only specifies a @i(name) for the function; the system supplies the definition. Along the same lines, there really should be a true structural equality comparison function, i.e. a case-sensitive EQUALP, or EQUAL which descends into arrays and structures. It would also be nice to have a graph isomorphism comparison function, but perhaps this is beyond the scope of Common Lisp. I only brought it up because it cannot be written portably so that it descends into all structures. How about graph isomorphism modulo gensyms? 293. ROW-MAJOR-AREF should be SETFable. 295. Also include SETF of AREF, ROW-MAJOR-AREF, and SETF of ROW-MAJOR-AREF among the functions which can access beyond the fill pointer of an array.  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Dec 85 23:07:55 EST Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 19:53:28 PST Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 19:50:43 pst Received: by edsel.uucp (2.2/SMI-2.0) id AA01946; Sat, 14 Dec 85 18:55:35 pst Date: Sat, 14 Dec 85 18:55:35 pst From: edsel!eb@su-navajo.arpa (Eric Benson) Message-Id: <8512150255.AA01946@edsel.uucp> To: navajo!Common-Lisp@SAIL Subject: More clarifications Here are a couple more items which should be included in the clarifications: In the description of FUNCTIONP (p. 76) it says that FUNCTIONP is always true of symbols. Shouldn't that be changed to say that FUNCTIONP is true of symbols for which FBOUNDP is true? In the description of Decoded Time format (p. 444), the Time-zone component is required to be an integer which is the number of hours west of GMT. (The latest term is Coordinated Universal Time, or UTC, by the way). Since time zones are not always an integral number of hours west of GMT, this should be changed to either (a) a non-complex, non-negative number which is the number of hours west of GMT, or (b) an integer which is the number of {minutes, seconds} west of GMT. My personal preference is for (b) for ease of implementation, but (a) might be preferable for compatibility with the existing standard. On the other hand, most programs dealing with time will probably want to deal with integral time units. Having the time zone bias introduce a ratio or a float by contagion is probably undesirable. Because of this, and because Universal Time is defined in units of seconds, I believe the best course is (b) with seconds, in spite of the incompatibility. (There are 86400 seconds in 24 hours.)  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Dec 85 21:03:29 EST Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 14 Dec 85 17:52:27 PST Received: by su-navajo.arpa with Sendmail; Sat, 14 Dec 85 17:49:43 pst Received: by edsel.uucp (2.2/SMI-2.0) id AA01705; Sat, 14 Dec 85 17:40:07 pst Date: Sat, 14 Dec 85 17:40:07 pst From: edsel!eb@su-navajo.arpa (Eric Benson) Message-Id: <8512150140.AA01705@edsel.uucp> To: navajo!Common-Lisp@SAIL Subject: Undoing global side-effects I went through the Common Lisp manual looking for functions which have global side-effects and came up with the following list, along with suggested functions for removing those side effects: PROCLAIM SPECIAL DEFVAR DEFPARAMETER These should all be undoable by MAKUNBOUND and an UNSPECIAL proclamation. UNSPECIAL should be restricted to use in PROCLAIM and not allowed in DECLARE. This will prevent a major incompatible change in declaration processing. DEFCONSTANT DELETE-CONSTANT should make a symbol unbound, unspecial and inconstant (yes, it's a real English word). DEFUN DEFMACRO SETF of SYMBOL-FUNCTION SETF of MACRO-FUNCTION These are undone by FMAKUNBOUND. In some implementations, DEFUN and DEFMACRO record information other than the function definition. Since this is outside the scope of Common Lisp, the language standard need not include a way to undo it. DEFSETF DEFINE-SETF-METHOD These are undone by the DELETE-SETF-METHOD function previously described. DEFTYPE The DELETE-TYPE function should undo this. It should signal an error if any other type is a subtype of the specified type. It "is an error" to DELETE-TYPE any of the built-in Common Lisp types. DEFSTRUCT There ought to be a DELETE-DEFSTRUCT function which undoes all the effects of the DEFSTRUCT, by removing all function definitions (including compiler database entries for inline compilation), removing any type database entry, removing the :PRINT-FUNCTION entry, and removing any information from DEFSTRUCT's own database (that which allows a name to be used in the :INCLUDE option). It should signal an error if any other structure type has :INCLUDEd the given type (unless that structure type has also been deleted). MAKE-PACKAGE This is undone by the DELETE-PACKAGE function previously described. SHADOW Document the fact that SHADOW can be undone by UNINTERN, causing any otherwise inherited symbol to become accessible again. SETF of DOCUMENTATION SET-MACRO-CHARACTER SET-DISPATCH-MACRO-CHARACTER These should all be undoable by using NIL as the new value. This must be documented. Thus there are five new functions DELETE-PACKAGE DELETE-SETF-METHOD DELETE-CONSTANT DELETE-TYPE DELETE-DEFSTRUCT and one new proclamation, UNSPECIAL. It doesn't seem to me to be worth inventing some new SETF-like meta-deletion macro to handle these. If we like this naming convention it might a good idea to add the names DELETE-VALUE and DELETE-FUNCTION as synonyms for MAKUNBOUND and FMAKUNBOUND, eventually phasing out the latter names.  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Dec 85 00:58:35 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 21:46:35 PST Received: ID ; Sat 14 Dec 85 00:46:29-EST Date: Sat, 14 Dec 1985 00:46 EST Message-ID: From: Rob MacLachlan To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: list of proposed changes to Common Lisp In-reply-to: Msg of 13 Dec 1985 15:15-EST from Guy Steele (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do not perform macro-expansion on the given form, and that in most contexts the usage should be (GET-SETF-METHOD (MACROEXPAND form env)). Indeed, the simplified example version of SETF given on page 108 should be changed to: (DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV) (MULTIPLE-VALUE-BIND (...) (GET-SETF-METHOD (MACROEXPAND REFERENCE ENV)) ...)) [Alternatively, we could specify that GET-SETF-METHOD should take an environment as an additional, optional argument, but that would be a change to the language rather than simply a clarification.] This won't work, as it prohibits defining setf methods for macros. GET-SETF-METHOD needs the environment so that it can expand macros one level at a time, checking if the result has a setf method. I also suggest that the environment argument not be optional, as any user code which doesn't supply it is surely broken. 268 Have a function COPY that can copy any single object. For a structure, it would use the user-specified copy function, if any. For a CONS cell it would copy just that CONS. Whether (EQ X (COPY X)) for X a character or number is implementation-dependent. What does this function do in the presence of displaced and adjustable arrays? Are these attributes preserved, or is the result just structurally identical? How about a COPY-ALL function which descends into structure until it finds something not needing to be copied? I have some of my own unclarities and clarifications: If we're allowed to clarify things by adding new functions, then I propose my own: a structural equality predicate. It descends into arrays and structures, but compares leaves with EQL. This is what EQUAL should have been, but couldn't for hysterical reasons. ("Descending into arrays is too inefficient.", to which I reply "Not if you want to compare arrays.") As far as equality predicates go, arrays are still second-class citizens of the language. 312 It should be explicitly noted somewhere that defstruct copiers work on structures which are a subtype by inclusion, e.g. COPY-PERSON works on an astronaut. This is a natural consequence of the subtype semantics of inclusion, but isn't necessarily obvious to pea-brained implementors. 416 I think that the DEFAULTS argument to MAKE-PATHNAME should be allowed to be an arbitrary thing, rather than being constrained to being a pathname. All other pathname args can be any thing accepted by PATHNAME. 413,424 The semantics of TRUENAME and PROBE-FILE on open streams needs to be clarified. The requirement that PROBE-FILE never return NIL on an open file is clearly broken. Spice Lisp currently implements TRUENAME and PROBE-FILE in the same way, except that TRUENAME errors instead of returning NIL. Someone (Moon, I believe) suggested that (PROBE-FILE ) was the same as (PROBE-FILE (PATHNAME )), but that (TRUENAME ) was somehow different. There also needs to be some discussion of the meaning of operations on closed streams. The manual never says which operations may be done on closed streams, let alone what the operations do. 410 There should be some clarification of what can be expected from implementations where some of the pathname components are meaningless, i.e. host and version. Must these fields actually exist in the pathname object? What must the operations do with these fields? 419 Are implementations really required to support all those element types? (signed-byte 1234567)? I guess arbitrary restrictions would be allowed by the implementation note on 421, but it doesn't really apply here. It is possible in any filesystem to implement I/O of all these things. The question is whether it's worth the effort. 419 I believe that everyone agreed that :DIRECTION :PROBE was silly and should be flushed. 438 There should be some discussion of the semantics of compilation on literal constants (things appearing in quoted structure in code). 1] What types of objects may be constants? Surely not any, as some implementations find it impossible to dump things such as compiled function objects. 2] To what degree is sharing and non-sharing preserved? Many implementations both introduce and remove sharing. Probably most don't dump circular structures. 3] How does symbol dumping and loading work? Since the reference model for compilation is that "it may run faster", it seems that ideally the semantics of loading a compiled file should be indentical to those of loading the source. This goal is unrealistic, since the reading of the source by the compiler loses information. A better model is that compilation and loading should be similar to printing and reading again. This is probably excessively restrictive, but may also be too liberal in that it suggests that circular structures can be dumped. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 22:14:49 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 19:02:35 PST Received: ID ; Fri 13 Dec 85 22:02:13-EST Date: Fri, 13 Dec 1985 22:02 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Re: Special Form Question In-reply-to: Msg of 13 Dec 1985 13:56-EST from NGALL@BBNG.ARPA I think the best position to take is the following: Symbols that name special forms do have symbol-function slots, just like any other symbol. Wrong. A CL symbol does not have a function as a "user-visible component" (i.e., slot; cf. pg. 163). Since CLtL goes out of its way to point this out, I think it is a good idea to not slip back into definition by implementation (are any implementtations NOT using function cells?). All right, on page 163 it says that Symbol-function is not necessarily a slot in the symbol object, but on page 90 it says that symbol-function returns an object that "may be a function or may be an object representing a special form or macro". However, it is an error if you try to invoke an object of the latter kind as a function. I think that this is consistent with the behavior I suggested, though I should not have referred to Symbol-Function as fetching something from a slot. If we decide to go with this description of the required behavior, some wording on page 9 needs to be clarified. It says that a error IS SIGNALLED if you do Symbol-Function on a symbol with no funciton definition, but then seems to indicate that this error would not be signalled if the definition is a macro or special form. Alternatively, we could specify that the error is signalled unless the symbol defines a function in the strict sense, but if we do that a lot of implementaitons would have to be fixed in ways that might hurt efficiency. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 21:56:06 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 18:46:32 PST Received: ID ; Fri 13 Dec 85 21:46:17-EST Date: Fri, 13 Dec 1985 21:46 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Rem @ MIT-MC.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: What about advising special forms? In-reply-to: Msg of 13 Dec 1985 18:45-EST from Rem at IMSSS Are we saying in CL we can't ever advise (trace etc.) a special operator because we can't be sure that (SETF (FUNCTION-CELL 'FUNNY-NAME) (FUNCTION-CELL 'ORIGINAL-SPECIAL-OPERATOR)) will work at all in the interpretor? We are saying that the ability to advise (trace etc) special forms is not something that you can do in a strictly portable way, depending on the above sort of replacement. Implementations that want to provide this facility are free to do this if it happens to be feasible. One cannot just call the normal TRACE function on a special form in any event, since the handling of arguments is different and since the trace is liable to get into an infinite loop if you don't take some care to prevent this. So I see no great loss in saying that this case will not work in general. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 20:16:46 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 17:02:57 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 374163; Fri 13-Dec-85 19:26:59-EST Date: Fri, 13 Dec 85 19:22 EST From: David A. Moon Subject: Re: Special Form Question To: NGALL@BBNG.ARPA cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: <[BBNG.ARPA]13-Dec-85 13:56:25.NGALL> Message-ID: <851213192202.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 13 Dec 1985 13:56-EST From: NGALL@BBNG.ARPA ....If this "strange object" is to be completely unspecified, then the section of the defintion of special-form-p (pg. 91) that DOES specify what this strange object "typically" is, should be made an Implementation Note. special-form-p is not the same function as symbol-function and does not (necessarily) return the same strange unspecified objects.  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 19:32:30 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 16:06:17 PST Received: from IMSSS by Score with Pup; Fri 13 Dec 85 15:46:50-PST Date: 13 Dec 1985 1545-PST From: Rem@IMSSS Subject: What about advising special forms? To: COMMON-LISP%SU-AI@SCORE A common debugging technique is to advise a function by splicing some I/O code or case-checking code between the function name and the code in its function cell. The most common example is tracing a function. One common implementation is to make up a funny name and copy the code pointer into that new function cell, and then make the original function cell point to a piece of code that does the advising and calls the new-name function. Are we saying in CL we can't ever advise (trace etc.) a special operator because we can't be sure that (SETF (FUNCTION-CELL 'FUNNY-NAME) (FUNCTION-CELL 'ORIGINAL-SPECIAL-OPERATOR)) will work at all in the interpretor? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 17:14:45 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 14:01:26 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA02288; Fri, 13 Dec 85 15:01:05 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA24274; Fri, 13 Dec 85 15:00:55 MST Date: Fri, 13 Dec 85 15:00:55 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8512132200.AA24274@utah-orion.ARPA> To: gls@aquinas.think.com Subject: Re: Clarification Comments (long) Cc: common-lisp@su-ai.arpa Comments on comments on comments on clarifications: Date: Fri, 13 Dec 85 16:19 EST From: Guy Steele 47 This is OK, although it feels a little uncomfortable to include the name of a local keyword variable in a proclamation that may be in another file. Bye bye alpha conversion... The example was poorly chosen. The name of the local keyword variable can be anything, but is normally the same (but in a different package) as the name of the keyword that the caller needs to use. Perhaps the example should have read (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T) (:START (INTEGER 0 ())) (:END (INTEGER 0 ())) (:INITIAL-VALUE T)) T) REDUCE) Now that I think of it, I was trying to follow the rule that the declaration should look like the parameter list, but with types substituted for the variable names and with init forms (and supplied-p parameters) omitted. It is tempting to use the flatter syntax (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T :START (INTEGER 0 ()) :END (INTEGER 0 ()) :INITIAL-VALUE T) T) REDUCE) but that confuses call syntax with parameter-list syntax. Now that I have enunciated the principle, I now see that the truly consistent syntax is not either of the two example above; to match parameter-list syntax exactly another level of parentheses is needed: (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T)) ((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ()))) ((:INITIAL-VALUE T))) T) REDUCE) These extra parentheses could be unambiguously elided in type specifiers, but the corresponding parentheses may not be elided in parameter lists. I like the last solution (without the extra parens!). 130 I didn't realize until now that tagbody does have a restriction on body contents. That seems wrong to me. Presumably lots of things will macroexpand into tagbodies, and every one inherits the same restriction. Worse, one implementation's dolist will macroexpand into a tagbody, while in another, it will be a special form. Why not say that integers and symbols are tags, and everything else is a form? Or that all non-lists are tags? But all objects other than symbols and lists are either constants or erroneous when treated as forms. Someone has suggested that strings be permitted in a TAGBODY as comments. I don't think we want floating-point tags. After poring over the book, it seems that it is specified as to which things have tagbodies and which do not. I have no problem with this clarification then. 186 Doesn't seem *wrong*, but not clear why one can't explicitly test symbol-package and intern instead. Sounds like a frob. INTERN cannot take a symbol, only a string. OK, OK, so I left out a step... I still don't understand why import needs extra features - is it just to prevent what would otherwise be an error? 239 This one seems really unmotivated - why the bits and not the font anyway? Perhaps we could add keywords to char comparison to tell which parts of the char are to be considered :-) The book already specifies that the fonts may or may not be examined, depending on the implementation, and an example is given to explain why. Now that I look at the book, it all makes sense. Yes, bits should be considered, in an implementation-dependent manner. stan  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 16:33:11 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85 13:19:55 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 16:19:46 est Date: Fri, 13 Dec 85 16:19 EST From: Guy Steele Subject: Clarification Comments (long) To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <8512131955.AA23353@utah-orion.ARPA> Message-Id: <851213161945.4.GLS@THINK-JEHOSEPHAT.ARPA> A few comments on the comments from SHEBS: 47 This is OK, although it feels a little uncomfortable to include the name of a local keyword variable in a proclamation that may be in another file. Bye bye alpha conversion... The example was poorly chosen. The name of the local keyword variable can be anything, but is normally the same (but in a different package) as the name of the keyword that the caller needs to use. Perhaps the example should have read (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (:FROM-END T) (:START (INTEGER 0 ())) (:END (INTEGER 0 ())) (:INITIAL-VALUE T)) T) REDUCE) Now that I think of it, I was trying to follow the rule that the declaration should look like the parameter list, but with types substituted for the variable names and with init forms (and supplied-p parameters) omitted. It is tempting to use the flatter syntax (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY :FROM-END T :START (INTEGER 0 ()) :END (INTEGER 0 ()) :INITIAL-VALUE T) T) REDUCE) but that confuses call syntax with parameter-list syntax. Now that I have enunciated the principle, I now see that the truly consistent syntax is not either of the two example above; to match parameter-list syntax exactly another level of parentheses is needed: (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY ((:FROM-END T)) ((:START (INTEGER 0 ()))) ((:END (INTEGER 0 ()))) ((:INITIAL-VALUE T))) T) REDUCE) These extra parentheses could be unambiguously elided in type specifiers, but the corresponding parentheses may not be elided in parameter lists. 130 I didn't realize until now that tagbody does have a restriction on body contents. That seems wrong to me. Presumably lots of things will macroexpand into tagbodies, and every one inherits the same restriction. Worse, one implementation's dolist will macroexpand into a tagbody, while in another, it will be a special form. Why not say that integers and symbols are tags, and everything else is a form? Or that all non-lists are tags? But all objects other than symbols and lists are either constants or erroneous when treated as forms. Someone has suggested that strings be permitted in a TAGBODY as comments. I don't think we want floating-point tags. 186 Doesn't seem *wrong*, but not clear why one can't explicitly test symbol-package and intern instead. Sounds like a frob. INTERN cannot take a symbol, only a string. 239 This one seems really unmotivated - why the bits and not the font anyway? Perhaps we could add keywords to char comparison to tell which parts of the char are to be considered :-) The book already specifies that the fonts may or may not be examined, depending on the implementation, and an example is given to explain why. 439 This constrains the implementation to save source code somewhere, which is more of a nuisance than a hardship. This is really another one of those user convenience things. Yes, it's "just" a convenience. Only COMPILE is so constrained; files produced by COMPILE-FILE are not required to retain the source code as well for later loading. 440 Sure, with the same proviso as for inline functions, that a macro call may not be traceable because it's been expanded already. Good point.  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 15:35:07 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85 12:15:29 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 15:15:17 est Date: Fri, 13 Dec 85 15:15 EST From: Guy Steele Subject: list of proposed changes to Common Lisp To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <851213151511.1.GLS@THINK-JEHOSEPHAT.ARPA> The following is the text, verbatim, of the handout I made available this past Monday at the Common Lisp meeting. One exception: in the entry for page 293, the second occurrence of (DISPLACED-ARRAY-P NEW-ARRAY) has been deleted because it was a typographical error. ------------------------------------------------------------------------ These are changes that I (Guy Steele) think are important but must not be made without the general approval of the Common Lisp community. Items that I think particularly important (because they correct important flaws or resolve ambiguity in the specification) are marked (*). 1 DELETE-SETF-METHOD takes the name of an access-fn and removes the SETF data associated with that name. DELETE-PACKAGE takes a package, uninterns all symbols in that package, unuses all packages it uses, and gets rid of the package. An error is signalled if the package is used by any other package. Maybe other things, such as DELETE-TYPE (undoes a DEFTYPE), UNDEFUN, UNDEFVAR, UNDEFCONSTANT, and so on are needed as well. One suggestion is to have a single special form UNDO, allowing one to write such things as (UNDO DEFUN FOO), (UNDO DEFINE-SETF-METHOD FOO), and so on (syntax negotiable). Presumably (UNDO SETQ FOO) means roughly the same as (MAKUNBOUND 'FOO)--or does it? What of the scoping of FOO? We need some way to do these things, but I have no concrete suggestion as yet. (*) 47 Specify that, in a FUNCTION type specifier, following the &KEY marker one should use items of the form (keyword type-specifier) instead of just a type-specifier: (DECLARE (FTYPE (FUNCTION (FUNCTION SEQUENCE &KEY (FROM-END T) (START (INTEGER 0 ())) (END (INTEGER 0 ())) (INITIAL-VALUE T)) T) REDUCE)) Specify that such a declaration implies that no other keywords may be used unless the declaration also contains &ALLOW-OTHER-KEYWORDS; in other words, one must explicitly declare types for all keyword arguments or else use &ALLOW-OTHER-KEYWORDS. Specify that a type specifier for a &REST argument indicates the type of each argument, not the type of a rest-argument list (which is always a list, after all): (DECLARE (FTYPE (FUNCTION (ARRAY &REST (INTEGER 0 ())) T) AREF)) (*) 51 Add a new function TYPE-SPECIFIER-P that is true of valid type specifiers and false of all other Lisp objects. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time. (*) 56, 68 Clarify that using DEFCONSTANT to redefine any constant described in the Common Lisp specification is an error. Clarify that if the user defines a constant, compiles code that refers to that constant, and then redefines the constant, then behavior of the compiled code may be unpredictable. (Perhaps it ``is an error'' to execute such code.) (*) 60 Specify that it is an error for two parameters (including supplied-p parameters) in the same lambda-list to have the same (EQL) name. (An alternative is to say that it is not an error, and the effective binding order is from left to right, as you would expect from the rules for init forms. This is no worse than LET*, but somehow does not appeal to me. A possible compromise is that no two required arguments may have the same name.) 82 Have a function XOR of any number of arguments that returns T if an odd number of its arguments are non-NIL, and otherwise returns NIL. This complements AND and OR (but there is no point in making it a special form as all arguments must be evaluated). (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do not perform macro-expansion on the given form, and that in most contexts the usage should be (GET-SETF-METHOD (MACROEXPAND form env)). Indeed, the simplified example version of SETF given on page 108 should be changed to: (DEFMACRO SETF (REFERENCE VALUE &ENVIRONMENT ENV) (MULTIPLE-VALUE-BIND (...) (GET-SETF-METHOD (MACROEXPAND REFERENCE ENV)) ...)) [Alternatively, we could specify that GET-SETF-METHOD should take an environment as an additional, optional argument, but that would be a change to the language rather than simply a clarification.] (*) 113 Permit declarations before the body of a LABELS, FLET, or MACROLET. (*) 120 In addition to DEFUN, the following macros should implicitly wrap a BLOCK around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE. This should be encouraged as a philosophy of style for user-written macros. Also, LABELS, FLET amd MACROLET should wrap a block around the bodies of the locally defined functions. (*) 130 Specify explicitly that anything in a TAGBODY other than a symbol, integer, or list is an error. (*) 130 Specify that it is an error for the same (EQL) tag to appear more than once in the body of a TAGBODY. (However, a TAGBODY may have the same tag as another TAGBODY in which it nests, in which case the tag in the outer TAGBODY is shadowed, as already specified.) (*) 144 Delete the third paragraph of the description of MACRO-FUNCTION, which specifies that MACRO-FUNCTION cannot be used to access macro functions defined by MACROLET. Change MACRO-FUNCTION to take an optional environment argument so that it can get at macros defined by MACROLET. Specify that when SETF is used with MACRO-FUNCTION, only one argument may be given to MACRO-FUNCTION. (*) 145 Add a new function PARSE-BODY, taking arguments body, environment, and documentation-allowed-p. It pulls apart the body into three parts: a list of DECLARE forms, a documentation string (or NIL if none), and the body proper. These are returned in the order body, declarations, and doc-string as three values. PARSE-BODY may perform macro-expansion (using the given environment) in order to determine whether a macro-call expands into a DECLARE form (or documentation string??). 145 Extend the syntax of an &BODY parameter to DEFMACRO to allow writing &body (body-var [declarations-var [doc-string-var]]). If only body-var appears in parentheses, it means the same as a body-var with no parentheses. Otherwise, it means to give the original body to PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is specified) and then bind the variables to the corresponding values returned by PARSE-BODY. This is purely a syntactic convenience for the user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then call PARSE-BODY himself. (*) 145 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 as &REST argument should not destroy it because its top-level list structure might might share with a list that the user gave as the last argument to APPLY. (*) 158 Specify that it is an error for more than one TYPE declaration for a given variable to appear in a group of declarations (those all at the head of the same body), or more than one FTYPE or FUNCTION declaration for a given function name, or both an INLINE and a NOTINLINE declaration for the same function. Proclamations produce no such conflict; the most recent proclamation supersedes all others. (*) 159 Clarify that in the following example (DEFUN FOO (X) (DECLARE (INLINE BAR)) (BAR X) ;first (FLET ((BAR (Z) (BAR (+ Z 1)))) ;second (BAR X)) ;third (BAR X)) ;fourth the first, second, and fourth calls to BAR are affected by the INLINE declaration, but not the third one. (*) 159 For consistency with the FUNCTION type specifier, change the syntax of the FUNCTION declaration to (FUNCTION name arglist result-type) with a note to the effect that types of multiple values are expressed as (FUNCTION name arglist (VALUES result-type-1 result-type-2 ...)). (*) 161 Specify that (THE type form) where type is not (VALUES ...) means the same as (THE (VALUES type) form), and that in (THE (VALUES ...) form) the form may return more values, but not fewer, than the number of types specified in the (VALUES ...), and that any extra values are of unrestricted type. (*) 172 Revise the paragraph beginning ``As a verb'' to reflect the fact that INTERN cannot take a symbol, only a string. One ought to speak of interning a name in a package, producing a symbol. 186 Modify the definition of IMPORT as follows: if any symbol to be imported has no home package, then IMPORT sets the home package of the symbol to the specified package being imported to. (*) 187 Modify description of DO-SYMBOLS to specify that it may execute the body more than once for some symbols. (*) 202 Define (LCM) to return 1 (the manual is incorrect in claiming that the result should be infinity). 212 Change the branch cuts of the ATAN function to follow W. Kahan's recommendations. (Paul Penfield intends to recommend the same change to the APL community.) 226 Add a function SIGNED-LDB that is like LDB but sign-extends the extracted byte. 239 Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP, CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be different if their bits attributes are different. 249 What is the effect of giving circular lists to MAP, MAPCAR, SOME, EVERY, etc.? Specify that there is an error? Is it good style to write (MAPCAR \#' CONS X (STAR Y)) for (MAPCAR \#' (LAMBDA (Z) (CONS Z Y)) X) where (DEFUN START (X) (RPLACD X X) X)? I recommend that this be considered an error. 268 Have a function COPY that can copy any single object. For a structure, it would use the user-specified copy function, if any. For a CONS cell it would copy just that CONS. Whether (EQ X (COPY X)) for X a character or number is implementation-dependent. (*) 275 Clarify that (TAILP NIL X) returns NIL for all lists X. The second sentence in the description of TAILP is incorrect. 283 Functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD, HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return the appropriate current information. (*) 293 Add a function ROW-MAJOR-AREF, taking an array and a single subscript, that accesses an array element according to the row-major ordering. Add a function DISPLACED-ARRAY-P, which takes an array and returns NIL and 0 if it is not displaced or the array displaced to and the displaced-index-offset if it is displaced. These allow certain code efficiencies, and also allow array displacement to be explained in terms of Lisp primitives: (DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS) (LABELS ((FOO (ARRAY INDEX) (MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY) (IF (NULL NEW-ARRAY) (ROW-MAJOR-AREF ARRAY INDEX) (MULTIPLE-VALUE-CALL #'FOO NEW-ARRAY (+ INDEX OFFSET))))) (FOO ORIGINAL-ARRAY (APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS)))) As a bow to efficiency, note the fact that if array A is displaced to B with offset M, and B is displaced to C with offset N, and B is not adjustable, then DISPLACED-ARRAY-P of A might return either array B with offset M or array C with offset (+ M N). This generalizes to chains of non-adjustable arrays. (*) 295 Specify that ADJUST-ARRAY is another important exception to the general rule about operating only on active elements of arrays. (See proposed clarifications of ADJUST-ARRAY.) (*) 297 Here are the interactions of ADJUST-ARRAY with displacement. Suppose we are adjusting array A, which is perhaps displaced to B before adjustment and perhaps to C after adjustment. (1) Not displaced before or after. The dimensions of A are altered, and the contents rearranged as appropriate. Additional elements of A are taken from the :initial-element. The use of :initial-contents causes all old contents to be discarded. (2) Not displaced before, but displaced afterwards to C. As already specified, none of the original contents of A appears in A afterwards, but rather the contents of C without any rearrangement of C. (3) Displaced beforehand to B, and afterward to C. As in case (2), no contents of B appear in A afterward. If :DISPLACED-INDEX-OFFSET is not specified in this case, it defaults to zero; the old offset (into B) is not retained. (4) Displaced beforehand to B, but not displaced afterward. A gets a new "data region", and contents of B are copied into it as appropriate to maintain the existing old contents; additional elements of A are taken from the :initial-element. However, the use of :initial-contents causes all old contents to be discarded. (*) 297 Specify that the fill pointer is ignored for the purposes of deciding whether a given element of a new array resulting from ADJUST-ARRAY should take its value from the old array contents or from the specified :INITIAL-ELEMENT. (*) 307 Allow a call to DEFSTRUCT to have no slot-descriptions. (*) 307 Specify that it is an error for two slots in a single DEFSTRUCT to have the same name. If structure A includes structure B, then no additional slot of A may have the same name as any slot of B. (*) 321 Modify EVAL to have an optional environment argument. (*) 322 At end of second paragraph on *APPLYHOOK*, clarify that the apply hook function is not used when special forms are evaluated. (*) 328 Remove the requirement that *STANDARD-INPUT*, etc., must be initially bound to synonym streams to *TERMINAL-IO*; demote this to the level of an implementation suggestion. This is to allow flexibility of implementation, for example to allow UNIX [TM and all the usual deferences that people for some reason pay to UNIX but not to Kleenex or Coke or Star Wars] redirection to win. (I don't mind noting the trademark status of UNIX; it just bugs me that people who do so are not so consistently diligent about other trademarks.) 425 Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument. (*) 439 Clarify that if DISASSEMBLE is given a symbol whose function definition is interpreted, that definition is indeed compiled and then disassembled, but the resulting compiled definition does not replace the interpreted one as the symbol's function definition. 439 COMPILEDP takes a function and returns non-NIL if it is a compiled function, and NIL if it is not. If the function is a symbol whose compiled-function definition was installed by the COMPILE function, then the non-NIL value returned is the interpreted definition that was compiled. 439 UNCOMPILE takes a symbol and restores the previous interpreted definition of that symbol if that symbol previously had an interpreted definition and was then given to COMPILE; otherwise no action is taken. 440 Specify explicitly that one may trace macros as well as functions (but not special forms). (*) 443 Modify description of APROPOS to replace the words ``available in'' to ``accessible in,'' and specify that APROPOS on a given package finds the same symbols that DO-SYMBOLS would. 447 The USER-NAME function returns a string identifying the user of the Common Lisp system, or NIL if that cannot be determined.  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 15:34:51 EST Received: from THINK.COM by SU-AI.ARPA with TCP; 13 Dec 85 12:17:06 PST Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 13 Dec 85 15:16:58 est Date: Fri, 13 Dec 85 15:16 EST From: Guy Steele Subject: Typographical corrections to Common Lisp book To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <851213151656.2.GLS@THINK-JEHOSEPHAT.ARPA> The following is the text, verbatim, of the other handout I made available this past Monday at the Common Lisp meeting. ---------------------------------------------------------------------- Corrections to first printing of Common Lisp: The Language Thanks to the many people who noticed these problems, and especially to Dr. Masayuki Ida, who found over fifty of them. -- Guy Steele, December 1985 6 line 4 from bottom: Definition 1-1 => Table 1-1 7 line 2 from bottom: Definition 1-2 => Table 1-2 8 line 3 Definition 1-3 => Table 1-3 8 line 7 Definition 1-4 => Table 1-4 8 line 9 from bottom: Definition 1-5 => Table 1-5 9 line 17 A\( B => A\(B (blank should be deleted) 9 Under \, "a symbol whose name is consists of the" => "a symbol whose name consists of the". 10 First two paragraphs should have monospace comma and colon, respectively, at the left margin. 18 3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted). 20 line 1 "#," (bad printing) 35 line 12 "where x is subtype of common" => "where x is a subtype of common" 43 Table 43-1 should include the names "signed-byte" and "unsigned-byte". 44 Delete both compatibility notes. 67 "The defun special form" => "The defun macro" 67 The comment in (defun discriminant ...) is wrong, because the code works for complex coefficients. Change the line The quadratic equation a*x^2+b*x+c=0 has real, multiple to be the two lines If the coefficients a, b, and c are all real numbers, then the quadratic equation a*x^2+b*x+c=0 has real, multiple 69 Top line, last word but one, should be "replace", not "replaces". 69 Clarify that EVAL-WHEN returns the value of the last form in its body. 73 In the compatibility note, observe that Common Lisp ATOM corresponds to Interlisp NLISTP. 75 line 5 from bottom: vectorp => simple-vector-p 80 Delete the first compatibility note. 87 Rewrite the second sentence in the description of FUNCTION as follows: "In particular, if fn is a symbol, then the functional definition of that name is returned, which is that established by the innermost lexically enclosing FLET, LABELS, or MACROLET construct, if there is one, or else the global functional definition of the symbol (see SYMBOL-FUNCTION)." 92 line 13 setf => psetf 94 line 11 from bottom: "newvalue2)" => "newvalue2" 99 line 8 place => place1 99 In first line of second paragraph, delete the italicized word "newvalue". 108 In the compatibility note, observe that Interlisp APPLY*, unlike Common Lisp FUNCALL, can be used to apply special forms. 118 In the compatibility note, observe that Interlisp SELECTQ has a syntax different from that of Common Lisp CASE in having a separate trailing "else" form. 122 line 2 from bottom: "init" should be italic 122 line 1 from bottom: "var" should be italic 125 Line 9: Delete first sentence and replace with: "As an example of nested loops, consider a data structure that is a list of conses." (Remove spurious reference to "env".) 128 Delete compatibility note. 132 line 15 from bottom: "Mismatch-gleep!S" => "Mismatch-gleep!~S" 132 line 2 from bottom: (same as P132 B15L) 145 Three lines from the bottom, the term "&environment" should appear at the left in monospace. 147 Last line on this page should be deleted; it duplicates first line on page 148. 154 Add to the table of forms allowing declarations in their bodies WITH-OPEN-STREAM, WITH-OPEN-FILE, WITH-OUTPUT-TO-STRING, and WITH-INPUT-FROM-STRING. 157 In third line, "declaration-form" should be "decl-spec" (in italics). 159 After the line "... entirely equivalent to" the next line should read (ftype (function arglist (values result-type-1 result-type-2 ...)) name) 189 In the code comments, "just a few thing" => "just a few things". 190 In LEAD-TO-GOLD, "(phlogiston:heat-flow x)" => "(phlogiston:heat-flow 1/137 x x)". 191 Before HEAT-FLOW definition, insert "(DEFVAR *FEELING-WEAK* NIL)" and rename FEELING-WEAK => *FEELING-WEAK*. (Actually, maybe we can come up with a more realistic example of two modules for the next edition.) 200 At the end of the first paragraph "returns the result." add the sentence "It is an error if any argument other than the first is zero." After "With one argument, / reciprocates the result" add the sentence "The argument must not be zero." 204 Halfway down, the last line of a paragraph "#C(0.5 1.73205)." should say "#C(1.0 1.73205)." 205 line 7 from bottom: "x" should be italic 206 line 5 "number" should be italic 206 line 7 "x" should be italic 209 Delete the last two sentences of the compatibility note, as the information about Interlisp is not (or is no longer) correct. 214 line 1 from bottom: "x" should be italic 215 line 2 "x" should be italic 216 Alter "The divisor may be any non-complex number." to read "The divisor may be any non-zero non-complex number." 216 Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to "For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...". [Actually, it would be better to rewrite this whole section, but this fix at least makes it accurate.] 216 Before last paragraph, insert this new paragraph: Note that while (floor 5 2) and (floor (/ 5 2)) return the same first value, they return different remainders as the second value: (floor 5 2) => 2 1 (floor (/ 5 2)) => 2 1/2 This is why @f[values] was used above in the remark that (values (floor 5 2)) @EQ (values (floor (/ 5 2))). 222 Occurrences of "logiorc1" and "logiorc2" should be "logorc1" and "logorc2". 226 In definition of haipart, the occurrence of "n" should be "count". 227 line 8 from bottom: "dpb" => "deposit-field" 230 In second line of description of make-random-state, the occurrence of random-state should be make-random-state. 246 line 13 "item" and "seq" should be italic, and "seq" => "sequence" 265 line 12 "'a b c" => "'a 'b 'c" 276 Halfway down, in the display line before "See pushnew.", the phrase "(fn item)" should be "(funcall fn item)", with "funcall" in monospace and "fn" and "item" in italics as before. 283 In the last sentence of the compatibility note, replace the last clause with "and in Common Lisp the cases of NIl as a value and no entry in the hash table can be distinguished." 284 "means the approximately the same as" => "means approximately the same as" 287 In the last line, :type should be :element-type. 295 In example use of bit-andc1, result should be #*0010, not #*0100. 297 Clarify that if an array with a fill pointer is adjusted and no new :FILL-ARRAY specification is given, or one is given with the value T, then the fill pointer retains its old value. It is an error to adjust the array to be smaller than the (old or explicit new) fill pointer. If one specifies :FILL-POINTER NIL explicitly to ADJUST-ARRAY, then it is an error if the array to be adjusted does have a fill pointer. 301 Change the compatibility note to "string= is similar to the Interlisp function strequal." 307 In the header line for "defstruct", "{slot-description}+" should be "{slot-description}*" (star instead of plus). 309 First paragraph should end "see section 19.6)." not "see section 19.6."; there is a missing parenthesis. 315 Under ":type list", ":unnamed" => "not :named". 323 line 19 "applications." => "applications," 324 In the second and third lines, replace "2" with "3". 325 The name of the variable "-" does not appear in the header line. 344 In the compatibility note, delete the reference to the Interlisp RADIX function, and move it to page 372 as a comment on the *print-radix* variable. 348 line 1 horizontal line should be moved to before compatibility note. 347-348 The page layout is a bit confused here; some connection should be made between the description of ";" and the example. 349 Before the first complete paragraph, there should be a heading line consisting of a single monospace backquote (accent grave). 349 In the first example of the use of backquote, the character just before " (print ,x)" is a "t". (It is badly printed in several copies.) 357 All occurrences of "constructor macro" should read "constructor function". 365 "The user is encouraged to" => "The user may, for some applications, wish to". 373 Third and sixth lines from bottom: "print-array" in monospace should be "*print-array*". 394 "~Scale factor" => "~%Scale factor" 394 "(- k 5) 3.14159))" => "(- k 5) (- k 5) 3.14159))" 396 Fourth line: "x x x))" => "x x x x))" 396 Line 12: "314.2$+10" => "314.0$+10" and "3.14L+12" => "3.14E+12" 412 line 20 version. => version). 422 Observe that if :IF-EXISTS NIL or :IF-DOES-NOT-EXIST NIL is used with WITH-OPEN-FILE then the variable may be bound to NIL, and the body should test for this case before attempting to use the stream. 430 The sixth line on the page should be "(funcall fn)", not "(funcall fn))". 432 "*break-on-warnings" should be "*break-on-warnings*" (in the heading for that item). 437 The first argument to CCASE should be called "keyplace", not "keyform". 440 line 3 [function] in the right margin. 449 Replace reference 9 with a reference to the following: IEEE Standard for Binary Floating-Point Arithmetic ANSI/IEEE Std 754-1985 (approved July 26, 1985) IEEE, 345 E 47 St. NY, NY 10017 (stock number SH10116 price $6.50) 452 right column, line 27 from bottom: (entry for characters, macros) 246-351 => 346-351 454 In index entry for "defun", first page number should be 67, not 57. 458 Entry for function "keyword" should be for "keywordp". 458 First reference for "macrolet" should be 113-114, not 93-94. 459 Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384, 397". 459 left column, line 19 from bottom: "parsing" => "passing" 459 left column, line 9 from bottom: 1325 => 135 461 right column, column, line 18 from bottom: replacd => rplacd 462 First reference to "shadow function" should be 186-187, not 182-183. 463 left column, line 26 from bottom: 382;420 => 332;420 463 left column, line 21 from bottom: comparison 300-306 => 300-302 464 "unread char function" => "unread-char function" 465 right column, line 11 ~: => ~| 465 right column, line 12 :~ => ~; 465 right column, line 20 from bottom: >E => ~E 465 right column, line 19 from bottom: >F => ~F [END]  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 15:07:49 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:55:13 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA00503; Fri, 13 Dec 85 12:55:43 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA23353; Fri, 13 Dec 85 12:55:38 MST Date: Fri, 13 Dec 85 12:55:38 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8512131955.AA23353@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Clarification Comments (long) The following long message is a set of knee-jerk reactions to Guy's list of suggested clarifications. They are (more or less) keyed by page, as in the printed list handed out at the meeting. You'll need the list, since I left out context to save space. 1 There are at least two reasons for having undo operations. The most obvious is for user-friendliness and mistake-fixing, while the other reason is to support really arcane things. I would put the various "un" package functions into the first category, while something like makunbound is more in the second. If CL is the subset used for portable programs, then it seems to me that functions whose sole purpose is to improve the user interface are less important; they are unlikely to show up in programs to be ported. From that point of view, a general undo is not appropriate for CL, although certain specific things like delete-package might be OK. If an implementation *does* have an undo, I would like to see it as elaborate as the facilities in Interlisp - fixing a mistaken (setq *macroexpand-hook* #'tailp) shouldn't result in (makunbound '*macroexpand-hook*)! 47 This is OK, although it feels a little uncomfortable to include the name of a local keyword variable in a proclamation that may be in another file. Bye bye alpha conversion... 51 Yes! 56, 58 Go for it. 60 Yes, on the principle that it might allow more optimization (I have here in my hand a list of 203 known compiler optimizations that this would make possible...). 82 Sounds like a good idea - I even thought back over old code to see it would simplify any complicated conditionals. Sadly, I couldn't remember any. 107 Yup, on the principle of decoupling functionality. 113 Sounds OK, but do I vaguely remember battles on possibly difficult problems with this one? 120 Yes, on the principle of orthogonality, but it'll fatten up the code a bit (unless of course one has the fabled "sufficiently good" compiler). 130 I didn't realize until now that tagbody does have a restriction on body contents. That seems wrong to me. Presumably lots of things will macroexpand into tagbodies, and every one inherits the same restriction. Worse, one implementation's dolist will macroexpand into a tagbody, while in another, it will be a special form. Why not say that integers and symbols are tags, and everything else is a form? Or that all non-lists are tags? 130 Might have same problems as previous point, but it seems less likely to be a problem. OK by me (but needs more thought). 144 Seems reasonable, although I'm sure there's some subtle point I'm missing about why macro-function should be defined this way, and symbol-function should not. 145 Yes! Although it needs a fairly careful specification. Should parse-body work on all def* bodies? 145 Yes. 145 Yes. (Why so many clarifications for macros anyway? :-) 158 Yup. 159 Good. 162 OK. 172 Yes, although it breaks much code... 186 Doesn't seem *wrong*, but not clear why one can't explicitly test symbol-package and intern instead. Sounds like a frob. 187 Ah yes, making the spec conform to reasonable implementations! 202 Sure. 212 Isn't a proposal that's *already* been accepted that we could follow? 226 "All in all, it's just another frob in the spec..." 239 This one seems really unmotivated - why the bits and not the font anyway? Perhaps we could add keywords to char comparison to tell which parts of the char are to be considered :-) 249 I think the effect of mapping over circular lists should be to delete the offending program and harass the user every time he/she starts up the Lisp thereafter. Trying to make all of the functions work on arbitrarily hairy list structure involves too many imponderables - mapcar and "circular" lists is just the tip of the iceberg. 268 Yes - I always assumed this one slipped through the cracks. Should it work on circular lists? :-) 275 Yes. 283 Yes. Does anybody actually have an implementation for which these functions would be more than structure accessors that already exist internally? 293 Yes. The array functions are, shall we say, sketchy; these seem like worthwhile additions. There are probably others. 295 Yes - how would anyone adjust *part* of an array? 297 Sounds OK to me, but I haven't studied the issues closely. 297 Yes, to be consistent with p. 295 clarification. 307 Yes. 307 Yes, and should this be extended to cover both plain slot names and ones with conc-names added? Or is the normal "functions stepping on each other" protocol sufficient? 321 Seems like a frob, but there's no real reason not to do it. 322 Makes sense. 328 Yes, but I would go further and say that there are no requirements *at all* about which streams are bound to which, or whether any are bound at all! But then one would have to define more behavior (the issue has already come up of yes-or-no-p being called when one is running a batch job, and doesn't plan to login until next week). 425 Yes. 439 Pretty dramatic clarification! This isn't even hinted at in the book. OK by me, although made unnecessary if uncompile is defined. 439 Yeah. 439 This constrains the implementation to save source code somewhere, which is more of a nuisance than a hardship. This is really another one of those user convenience things. 440 Sure, with the same proviso as for inline functions, that a macro call may not be traceable because it's been expanded already. 443 Now we know how to implement apropos! :-) 447 What's another function when you've got hundreds? Sure. stan  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 14:21:04 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:09:25 PST Date: 13 Dec 1985 14:05-EST Sender: NGALL@BBNG.ARPA Subject: Re: Special Form Question From: NGALL@BBNG.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[BBNG.ARPA]13-Dec-85 14:05:25.NGALL> In-Reply-To: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 13 Dec 85 13:17 EST From: David A. Moon To: Scott E. Fahlman Subject: Special Form Question In-Reply-To: Message-ID: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM> ... I agree. I'd like to propose a clarification about macros. If a symbol is the name of a macro, then symbol-function returns an unspecified object that it is an error to funcall or apply, however sticking that object into the symbol-function slot of another symbol does make that other symbol name the same macro. The alternative would be to say that it's just as illegal for macros as for special forms. -------------------- What about symbols that have both a macro definition and are special-form names? I prefer the alternative. Use macro-function to get the macro, special-form-p to "typically" get the fexpr :-), and symbol-function for honest-to-god functions. Otherwise, implementations that don't just return the value of the function cell will be forced to put macro and special-form accessing machinery into symbol-function. -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 14:15:19 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 11:00:54 PST Date: 13 Dec 1985 13:56-EST Sender: NGALL@BBNG.ARPA Subject: Re: Special Form Question From: NGALL@BBNG.ARPA To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Message-ID: <[BBNG.ARPA]13-Dec-85 13:56:25.NGALL> In-Reply-To: Date: Fri, 13 Dec 1985 11:03 EST From: "Scott E. Fahlman" To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Subject: Special Form Question In-Reply-To: Msg of 12 Dec 1985 21:36-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs) Message-ID: You do come up with the most imaginative questions... We clearly do not require that (setf (symbol-function 'foo) (symbol-function 'quote)) somehow makes foo act like quote. Nor do we explicitly require this to signal an error. The case that you describe is so perverse that I do not think it is worthwhile for those implementations that use something like internal FEXPRs in the interpreter to bother checking that they are being called in a legitimate way. I think the best position to take is the following: Symbols that name special forms do have symbol-function slots, just like any other symbol. Wrong. A CL symbol does not have a function as a "user-visible component" (i.e., slot; cf. pg. 163). Since CLtL goes out of its way to point this out, I think it is a good idea to not slip back into definition by implementation (are any implementtations NOT using function cells?). The implementation is allowed, but not required, to put some strange object in that slot, and we cannot prevent users from getting their hands on this object if it exists. However, the nature of this object, if it exists, is completely unspecified and users cannot count on doing anything useful with it. It is an error to funcall or apply this thing, If this "strange object" is to be completely unspecified, then the section of the defintion of special-form-p (pg. 91) that DOES specify what this strange object "typically" is, should be made an Implementation Note. or to stick it in a symbol-function slot of some symbol and then evaluate a form with that symbol as the Car. -- Scott -------------------- -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 13:33:33 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 10:22:22 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 228016; Fri 13-Dec-85 13:17:12-EST Date: Fri, 13 Dec 85 13:17 EST From: David A. Moon Subject: Special Form Question To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851213131726.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 13 Dec 1985 11:03 EST From: "Scott E. Fahlman" We clearly do not require that (setf (symbol-function 'foo) (symbol-function 'quote)) somehow makes foo act like quote. Nor do we explicitly require this to signal an error. The case that you describe is so perverse that I do not think it is worthwhile for those implementations that use something like internal FEXPRs in the interpreter to bother checking that they are being called in a legitimate way. I think the best position to take is the following: Symbols that name special forms do have symbol-function slots, just like any other symbol. The implementation is allowed, but not required, to put some strange object in that slot, and we cannot prevent users from getting their hands on this object if it exists. However, the nature of this object, if it exists, is completely unspecified and users cannot count on doing anything useful with it. It is an error to funcall or apply this thing, or to stick it in a symbol-function slot of some symbol and then evaluate a form with that symbol as the Car. I agree. I'd like to propose a clarification about macros. If a symbol is the name of a macro, then symbol-function returns an unspecified object that it is an error to funcall or apply, however sticking that object into the symbol-function slot of another symbol does make that other symbol name the same macro. The alternative would be to say that it's just as illegal for macros as for special forms.  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 11:14:28 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 13 Dec 85 08:03:52 PST Received: ID ; Fri 13 Dec 85 11:03:40-EST Date: Fri, 13 Dec 1985 11:03 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Cc: common-lisp@SU-AI.ARPA Subject: Special Form Question In-reply-to: Msg of 12 Dec 1985 21:36-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs) You do come up with the most imaginative questions... We clearly do not require that (setf (symbol-function 'foo) (symbol-function 'quote)) somehow makes foo act like quote. Nor do we explicitly require this to signal an error. The case that you describe is so perverse that I do not think it is worthwhile for those implementations that use something like internal FEXPRs in the interpreter to bother checking that they are being called in a legitimate way. I think the best position to take is the following: Symbols that name special forms do have symbol-function slots, just like any other symbol. The implementation is allowed, but not required, to put some strange object in that slot, and we cannot prevent users from getting their hands on this object if it exists. However, the nature of this object, if it exists, is completely unspecified and users cannot count on doing anything useful with it. It is an error to funcall or apply this thing, or to stick it in a symbol-function slot of some symbol and then evaluate a form with that symbol as the Car. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 10:54:11 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 07:43:55 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA26265; Fri, 13 Dec 85 08:44:27 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA22517; Fri, 13 Dec 85 08:44:24 MST Date: Fri, 13 Dec 85 08:44:24 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8512131544.AA22517@utah-orion.ARPA> To: NGALL@bbng.arpa, shebs%utah-orion@utah-cs.arpa Subject: Re: Special Form Question Cc: common-lisp@su-ai.arpa From NGALL@BBNG.ARPA Fri Dec 13 08:08:41 1985 (setf (symbol-function 'foo) (symbol-function 'quote)) (foo (a b c)) I vote for "is an error" for the simple reason that portable code analyzers (incl. compilers) count on the fact that they must have special-purpose code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on pg. 57). If we break this restriction, portable code ananlyzers would become much more complicated (if not impossible without further CLtL revisions). Besides, why would anyone need to do such a thing? Remember macros?... There are a lot of things that CL talks about that nobody would really do! This particular issue has a lot to do with whether an implementation needs to support fako fexprs secretly, or whether it can treat each special form case-by-case in both the compiler and interpreter. Without naming names, I can point to CL implementations which *do* have fexprs, and which *do* allow the above, but if I were to sit down and do an implementation today, I wouldn't have anything even remotely resembling fexpr functions at all. "Is an error" seems like the right answer. stan shebs  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 10:19:23 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 07:08:23 PST Date: 13 Dec 1985 10:04-EST Sender: NGALL@BBNG.ARPA Subject: Re: Special Form Question From: NGALL@BBNG.ARPA To: shebs%utah-orion@UTAH-CS.ARPA Cc: common-lisp@SU-AI.ARPA Message-ID: <[BBNG.ARPA]13-Dec-85 10:04:31.NGALL> In-Reply-To: <8512130236.AA20979@utah-orion.ARPA> Date: Thu, 12 Dec 85 19:36:38 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) To: common-lisp@su-ai.arpa Subject: Special Form Question Message-ID: <8512130236.AA20979@utah-orion.ARPA> This may seem like an exceptionally stupid question, but what should the following do? (setf (symbol-function 'foo) (symbol-function 'quote)) (foo (a b c)) While CLtL prohibits defining new special forms, it's not clear that this use is defining a "new" form. Also, symbol-function on special forms is allowed to return something (whose exact nature is carefully left vague) which presumably can be used elsewhere. The whole thing sure looks like a nod to implementations which still have nasty fexprs :-), and for which the above trick would be valid. Am I right? Or is it OK for symbol-function of a special form to signal an error? stan shebs -------------------- It is clearly NOT OK for (symbol-function 'quote) to signal an error, pg. 90. It is not clear (in CLtL) whether (setf (symbol-function 'foo) #) is an error ("The set of special forms is fixed in CL." pg. 57); must "work" (Note that there is no restriction on the "specified definition" that may be assigned to the symbol-function gen. var., pg. 90; is left undefined (Note that vagueness of what symbol-function of a special form returns and what special-form-p returns (and what can be done with them). I vote for "is an error" for the simple reason that portable code analyzers (incl. compilers) count on the fact that they must have special-purpose code only for the symbols in Table 5-1 (cf. the code-analysis "algorithm" on pg. 57). If we break this restriction, portable code ananlyzers would become much more complicated (if not impossible without further CLtL revisions). Besides, why would anyone need to do such a thing? Remember macros?... -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Dec 85 10:16:19 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Dec 85 07:04:19 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 373758; Fri 13-Dec-85 10:04:22-EST Date: Fri, 13 Dec 85 10:12 EST From: Daniel L. Weinreb Subject: Special Form Question To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8512130236.AA20979@utah-orion.ARPA> Message-ID: <851213101236.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 12 Dec 85 19:36:38 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) This may seem like an exceptionally stupid question, but what should the following do? (setf (symbol-function 'foo) (symbol-function 'quote)) (foo (a b c)) It certainly should not be required to make foo act like quote. But exactly how to rule it out is not completely clear. symbol-function is sort of useful as a tool to examine your environment, so having it signal an error might not be appropriate. Perhaps the function that the setf turns into should be responsible for not storing special forms? Or maybe this is too implementation dependant, and we should just say "it is an error" to store such a thing?  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Dec 85 22:02:55 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 12 Dec 85 18:36:14 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA19193; Thu, 12 Dec 85 19:36:42 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA20979; Thu, 12 Dec 85 19:36:38 MST Date: Thu, 12 Dec 85 19:36:38 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8512130236.AA20979@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Special Form Question This may seem like an exceptionally stupid question, but what should the following do? (setf (symbol-function 'foo) (symbol-function 'quote)) (foo (a b c)) While CLtL prohibits defining new special forms, it's not clear that this use is defining a "new" form. Also, symbol-function on special forms is allowed to return something (whose exact nature is carefully left vague) which presumably can be used elsewhere. The whole thing sure looks like a nod to implementations which still have nasty fexprs :-), and for which the above trick would be valid. Am I right? Or is it OK for symbol-function of a special form to signal an error? stan shebs  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Dec 85 21:17:06 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 10 Dec 85 13:51:51 PST Received: by hplabsd ; Tue, 10 Dec 85 13:49:37 pst Date: Tuesday, December 10, 1985 11:17:28 From: perdue@hplabsd Subject: Macrolet index bug To: common-lisp@su-ai X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 In the manual the main index for macrolet is listed at pages 93-94. The main reference should be to page 113 instead. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Dec 85 21:31:46 EST Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 8 Dec 85 18:23:10 PST Date: 8 Dec 1985 18:21-PST Sender: MATHIS@USC-ISIF.ARPA Subject: Re: ISO Standard From: MATHIS@USC-ISIF.ARPA To: jeff%aiva.edinburgh.ac.uk@UCL-CS.ARPA Cc: common-lisp@SU-AI.ARPA Message-ID: <[USC-ISIF.ARPA] 8-Dec-85 18:21:40.MATHIS> In-Reply-To: The message of Mon, 2 Dec 85 20:31:41 GMT from Jeff Dalton At the meeting in Boston, I will be talking to people about the ISO effort for a LISP standard. -- Bob Mathis  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Dec 85 21:14:58 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Dec 85 18:06:09 PST Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 369781; Sun 8-Dec-85 21:02:38-EST Date: Sun, 8 Dec 85 21:00 EST From: Robert W. Kerns Subject: The variables +, -, *, and / To: Scott E. Fahlman cc: Tim McNerney , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851208210052.9.RWK@CROW.SCRC.Symbolics.COM> Date: Sat, 7 Dec 1985 10:18 EST From: "Scott E. Fahlman" I guess I would be surprised. Most of the grad students I've known around CMU and MIT either go in and completely master their tools or else they find out what they need and master that part. But maybe these places are atypical. I grant you that some undergrads try to slide by with the minimum competence needed to pass, but are we really designing a language for those guys? Maybe the difference between grad students and us drop-outs is that us drop-outs always read the whole manual and learn our tools, instead of going to class? Anyway, for the sake of students trying to do their thesis in two weeks, I suggest we put somewhere prominent a list of facilities of interest to people imbedding languages. Anyone THEN not willing to read the little material involved doesn't deserve a degree. (I read it ALL immediately, can I get a degree?) I'm not arguing against other proposals to make it easier to use. But maybe we could make it a bit easier for the guy in a rush who only wants to learn about what he needs. Probably most people are in that situation when they start out using something new, even if they aren't by the time they're done. We just tend to forget the feeling once we become expert.  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Dec 85 09:14:50 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 8 Dec 85 06:06:43 PST Received: ID ; Sun 8 Dec 85 09:06:42-EST Date: Sun, 8 Dec 1985 09:06 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: masinter.PA@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: packages In-reply-to: Msg of 8 Dec 1985 02:25-EST from masinter.PA at Xerox.ARPA I think the history of the various subcommittees shows that they don't really begin to function until someone comes up with a concrete proposal or at least a coherent set of objectives and ideas. Whenever we have such a proposal, that would be the time to consider changes to the package system, either in a subcommittee or all together. Aside from the case-sensitivity lossage in package names, I'm not sure what people find to be so hard. If it is just that they get confused about what symbols live where, maybe all we need is a good tool (Masterscope-like?) for finding out which symbols live where, which ones shadow other sysmbols, etc., and for displaying the result in a reasonable form. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Dec 85 02:37:35 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 7 Dec 85 23:28:45 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 85 23:28:42 PST From: masinter.PA@Xerox.ARPA Date: 7 Dec 85 23:25:37 PST Subject: packages To: common-lisp@su-ai.ARPA Message-ID: <851207-232842-4561@Xerox> I think that most people recognize that the package system is seriously flawed, but that it was the best that was available by the time it was necessary to publish the book. There have not as of yet been any serious proposals for how to fix the current flaws. Perhaps this needs a separate subcommittee.  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Dec 85 20:33:02 EST X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-07 17:09:42 PST (=GMT-8hr) X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP Date: 1985 December 07 17:05:56 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132507010126.G0357 From: Robert Elton Maas To:TIM@MIT-MC.ARPA CC:COMMON-LISP@SU-AI.ARPA subject:need subset of CL! Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) | Date: Fri, 6 Dec 85 22:19:16 EST | From: Tim McNerney | Subject: The variables +, -, *, and / | I suspect that you will find that the majority of graduate students in AI | using Common Lisp for their thesis project will not learn about even a | significant fraction of Common Lisp's pitfalls before they complete their | degrees. They will have neither the time nor the inclination. I take this as evidence that CL is too big. If there are so many functions and special cases (keyword & optional args) to learn that the student doesn't have time to learn basic stuff like packages, something is wrong. I continue to say that we need some subset of CL that (1) can be taught completely to a student in one semester, (2) can be implemented on a small microcomputer by a small team of programmers in a reasonable time, (3) can be exhaustively tested for correctness (I don't mean by exhaustive trial of all combinations; I mean that each and every feature is tested without exception) by a reasonable test suite.  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Dec 85 10:27:51 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Dec 85 07:19:11 PST Received: ID ; Sat 7 Dec 85 10:19:00-EST Date: Sat, 7 Dec 1985 10:18 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Tim McNerney Cc: common-lisp@SU-AI.ARPA Subject: The variables +, -, *, and / In-reply-to: Msg of 6 Dec 1985 22:19-EST from Tim McNerney You would be surprised. I know people working on embedded languages who have either never had to use packages or have only gotten screwed by them and would prefer never to touch them again. I suspect that you will find that the majority of graduate students in AI using Common Lisp for their thesis project will not learn about even a significant fraction of Common Lisp's pitfalls before they complete their degrees. They will have neither the time nor the inclination. I guess I would be surprised. Most of the grad students I've known around CMU and MIT either go in and completely master their tools or else they find out what they need and master that part. But maybe these places are atypical. I grant you that some undergrads try to slide by with the minimum competence needed to pass, but are we really designing a language for those guys? Anyway, if packages are really proving to be that tough for people, we either need better training materials or else there are things in the package system we need to fix up to make it esier to use. Probably both. I don't think that the solution is to try to mess up the rest of the language so that people can do embedded languages without using packages -- we would basically have to take all the good names away from Common Lisp in order to leave them free for other use. The +*/- characters are just the tip of the iceberg. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 22:26:38 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 19:16:47 PST Date: Fri, 6 Dec 85 22:19:16 EST From: Tim McNerney Subject: The variables +, -, *, and / To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Fri 6 Dec 1985 10:02 EST from Scott E. Fahlman Message-ID: <[MIT-MC.ARPA].745025.851206.TIM> Date: Fri, 6 Dec 1985 10:02 EST From: Scott E. Fahlman I think that by the time a user is playing with embedded languages, he is not such a beginner and he had damned well better make friends with packages. You would be surprised. I know people working on embedded languages who have either never had to use packages or have only gotten screwed by them and would prefer never to touch them again. I suspect that you will find that the majority of graduate students in AI using Common Lisp for their thesis project will not learn about even a significant fraction of Common Lisp's pitfalls before they complete their degrees. They will have neither the time nor the inclination. Tim  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 16:32:29 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Dec 85 13:21:07 PST Received: ID ; Fri 6 Dec 85 16:05:57-EST Date: Fri, 6 Dec 1985 16:05 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jeff Dalton Cc: common-lisp@SU-AI.ARPA Subject: ISO Standard In-reply-to: Msg of 2 Dec 1985 15:31-EST from Jeff Dalton Bob Mathis will be at the Boston meeting and will fill us all in on what is happening with ISO, and also on what the possibilities are for getting Common Lisp standardized under ISO in some reasonable way. After some discussion with Mathis, I think that the idea of cooperating in a serious way with the ISO standardization effort may be a good idea after all. We'll see what develops in Boston. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 15:34:55 EST Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 6 Dec 85 12:23:21 PST Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a009085; 2 Dec 85 20:48 GMT From: Jeff Dalton Date: Mon, 2 Dec 85 20:31:41 GMT To: common-lisp@su-ai.arpa Subject: ISO Standard The 21 November issue of Computer Weekly (one of the UK "computer comics") had a short article on a recent ISO meeting in Paris, entitled "Three language standards come closer". One of the languages was C, and the ISO would use the ANSI draft standard as a basis. The other two were Prolog and Lisp: At the Paris meeting ISO also set up a study group to standardize the artificial intelligence languages, Lisp and Prolog. This group is to be chaired by Bob Mathis, who has been closely involved in the development of the Ada standard. The artificial intelligence group will report by Sept. 1986 to the ISO on the need for standards in the Lisp and prolog languages. They go on to say "the UK and France are already well advanced towards a Prolog standard" but say nothing more about Lisp. Does anyone know anything about this?  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 10:13:17 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Dec 85 07:02:23 PST Received: ID ; Fri 6 Dec 85 10:02:11-EST Date: Fri, 6 Dec 1985 10:02 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Tim McNerney Cc: common-lisp@SU-AI.ARPA Subject: The variables +, -, *, and / In-reply-to: Msg of 6 Dec 1985 03:30-EST from Tim McNerney In fact, we did not blindly follow precedent in this case. I remember asking, at the time we were doing the Eval chapter, whether we should flush these names in favor of something more mnemonic and more standard-looking. The feeling was that these things are for use by the user at the keyboard and that they want to be very short. Some users have an interaction style that depends on these things very heavily. Given that, these seemed like the one-character symbols that a user was least likely to accidentally include in a program as a symbol, precisely because they are so universally used as function names that they look ugly as variables. If we had been willing to postulate an Emacs-like top-level for every implementation, we could have come up with some different mechanism than the use of side effects on variables to save the recent results, but at the time we felt that we had to allow for simple but usable top-levels. I'm not sure I'd make the same choice today, but it's not one that look obviously crazy to me. I think that by the time a user is playing with embedded languages, he is not such a beginner and he had damned well better make friends with packages. That's what they are for, and I think they are a reasonably good solution. Note that you don't have to avoid using LISP in this case, if *+/- is your only concern. Just create a new package, use LISP, and shadow those specific symbols. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 09:54:13 EST Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 06:42:36 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 68648; Fri 6-Dec-85 09:42:02-EST Date: Fri, 6 Dec 85 09:42 EST From: Kent M Pitman Subject: The variables +, -, *, and / To: TIM@MIT-MC.ARPA, FAHLMAN@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA, greek%bach.decnet@HUDSON.DEC.COM, smh@MIT-EMS.ARPA In-Reply-To: <[MIT-MC.ARPA].743936.851206.TIM> Message-ID: <851206094203.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 6 Dec 85 03:30:43 EST From: Tim McNerney I realize that there are ways of working around the problems caused by this unfortunate choice of names, but this is not the point. I am appealing, not for seasoned Lisp hacker, but for the Lisp user experimenting with new languages who is not familiar with, for instance, the subtleties of creating packages which do not :use the LISP package. Naive users should be taught how to program using reasonable techniques. There are recently dozens of examples of people who did langauges embedded in another which were implemented as puns on primitive language semantics and then had their respective jokes spoiled by changes to the language. The case that comes immediately to mind are languages that claimed to be dynamically scopped but which were in fact depended on their underlying language to be dynamic, so when the underlying language became lexical, the embedded language became broken. There are right and wrong ways to do embedded languages. People should not continue to use broken techniques when workable ones exist. The Common Lisp language is riddled with historical relics which were preserved in the interest of making old programs like Macsyma have some hope of being ported to Common Lisp (an example of this is the separate function and value cell), but there is no reason to make the Top-Level Loop compatible with Maclisp and their descendants. Furthermore, to reserve variable names which admittedly do not follow the *...* convention, which are side-effected by the Top-Level Loop, which are globally declared special, and which naive Lisp users are likely to try use in their programs, seems inexcusable. System constants (eg, PI, MOST-POSITIVE-FIXNUM, ARRAY-RANK-LIMIT) are already in that namespace even if they are treated slightly differently. Your naive users had better know about these or they'll confuse themselves. Once they've learned about these, a few more un-starred names is not unreasonable. Besides, Lisp is a symbol-processing language. By that we mean that it's the token itself, not the character string which is its print-name, which is of interest. Allowing stars on the end of the symbol's printname to dictate the semantics of a variable is what would be inexcusable. If Common Lisp were not supposed to be an excellent language for developing new languages, I would not be nearly so disappointed. The proposed solution (using packages) mentioned by all the respondents thus far does not inhibit you from doing reasonable things. I don't know why you should be disappointed. If you dislike packages as much as I, you should be pleased that they offer a way for you to isolate yourself from the rest of the CL world and build your own personalized world out of symbols whose semantics, plist, value, etc will be untarnished by CL's hairy mechanisms. It would be far less easy to hide a CL embedded in any of the Scheme's I know of. Tim McNerney ICAD, Inc. P.S. Incidentally, please, please, let us not stumble into another discussion about the pros and cons of separate function and value cells. Date: Wed, 4 Dec 1985 11:13 EST From: Scott E. Fahlman We thought brielfly about such issues ... On the subject of amateur archiving, let me say that I find including another's message at the end of a long message like this to be silly. It gives me the impression that my Babyl file has been trashed and that somehow the boundary between two messages has disappeared. If I've gotten as far as reading to the point where this sort of included message appears, I no longer need the context.  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 09:15:39 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 06:06:22 PST Date: Fri, 6 Dec 85 09:08:54 EST From: "George J. Carrette" Subject: macsyma and common-lisp To: TIM@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, FAHLMAN@C.CS.CMU.EDU In-reply-to: Msg of Fri 6 Dec 85 03:30:43 EST from Tim McNerney Message-ID: <[MIT-MC.ARPA].744105.851206.GJC> I've heard that one too many times. Certainly it was even mentioned by people at some of the early CL meetings that "we cant do X because of programs like Macsyma," but that has certainly proved not the case. When it comes to a program the size of DOE-Macsyma at least yours truly takes the minimum work route, SHADOW EVERYTHING IN SIGHT! Keep my own private copies of the maclisp-compatible functions because you know you cant trust the quality (speed or accuracy) of things supposedly done for maclisp compatibility in some of the more popular lisp/operating-system environments. And then parts of DOE-macsyma depend heavily on the dynamic scoping in the maclisp interpreter, and I tell you that was a pain. In fact, I remember a very specific statement about (SYMBOLP ()) = T, in the early CL meetings: "we cant change that because of programs like Macsyma" Unfortunately the facts didnt seem to matter when I replied that Macsyma had already been brought up in NIL (which at the time had a more rational/orthogonal type scheme) and that the fact that (SYMBOLP ()) was now FALSE and (GET () 'ANYTHING) was now an error had uncovered some bugs that had escaped tracking down for years. The proof of actual experience of porting a large system to what at the time was the post-maclisp dialect pointing to common-lisp did not in fact matter. (Or as Hitler once said, "How many [army] divisions does the Pope have?"). So lets not entertain any further mention of things for the benefit of Macsyma.  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Dec 85 03:38:07 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Dec 85 00:28:09 PST Date: Fri, 6 Dec 85 03:30:43 EST From: Tim McNerney Subject: The variables +, -, *, and / To: FAHLMAN@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA, greek%bach.decnet@HUDSON.DEC.COM, smh@MIT-EMS.ARPA In-reply-to: Msg of Wed 4 Dec 1985 11:13 EST from Scott E. Fahlman Message-ID: <[MIT-MC.ARPA].743936.851206.TIM> I realize that there are ways of working around the problems caused by this unfortunate choice of names, but this is not the point. I am appealing, not for seasoned Lisp hacker, but for the Lisp user experimenting with new languages who is not familiar with, for instance, the subtleties of creating packages which do not :use the LISP package. The Common Lisp language is riddled with historical relics which were preserved in the interest of making old programs like Macsyma have some hope of being ported to Common Lisp (an example of this is the separate function and value cell), but there is no reason to make the Top-Level Loop compatible with Maclisp and their descendants. Furthermore, to reserve variable names which admittedly do not follow the *...* convention, which are side-effected by the Top-Level Loop, which are globally declared special, and which naive Lisp users are likely to try use in their programs, seems inexcusable. If Common Lisp were not supposed to be an excellent language for developing new languages, I would not be nearly so disappointed. Tim McNerney ICAD, Inc. P.S. Incidentally, please, please, let us not stumble into another discussion about the pros and cons of separate function and value cells. Date: Wed, 4 Dec 1985 11:13 EST From: Scott E. Fahlman We thought brielfly about such issues and decided that we would quickly go mad if we tried to avoid stepping on symbols (or ways of using them) for every other Lisp-like language. That's why there are packages. The Common Lisp top-level will not mess around with the value of SCHEME:*, etc. Customize the scheme symbols any way you want, and import from the LISP package those things that happen to be right. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 14:19:34 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Dec 85 11:01:28 PST Received: ID ; Thu 5 Dec 85 14:01:04-EST Date: Thu, 5 Dec 1985 14:00 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: Keywords with cells I thought one of the reasons for having keywords in their own package was that you can make that a stripped down package that is just a bare hashtable with no value/function/property cells? I don't think that this was aprt of the motivation for having a separate keyword package. The main reason was just so that every package could get at keywords with equal facility, and so that a keyword with the same spelling would be EQ in every context. This was thought to be desirable since keywords are used primarily as tokens and not as places to stash package-dependent data. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 14:08:55 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 10:49:30 PST Date: Thu 5 Dec 85 11:48:31-MST From: SANDRA Subject: keywords To: common-lisp@SU-AI.ARPA Message-ID: <12164735616.32.LOOSEMORE@UTAH-20.ARPA> Personally, I think that implementing keywords without value/function/property cells is a rotten idea. Essentially, this would make keywords be symbols that aren't really symbols after all. Making the behavior of symbols which just happen to be interned in the keyword package inconsistent with everything else has the potential for causing real problems for the unsuspecting user. If SYMBOLP is true of an object, then all of the functions defined on symbols should work on that object. -Sandra -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 11:54:44 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 08:40:38 PST Received: from HP-HULK by hplabsd ; Thu, 5 Dec 85 08:38:45 pst Return-Path: Received: from hplabsd by HP-HULK with TCP; Wed 4 Dec 85 23:58:18-PST Received: from SU-SCORE.ARPA by hplabsd ; Wed, 4 Dec 85 23:56:39 pst Received: from IMSSS by Score with Pup; Wed 4 Dec 85 23:55:12-PST Date: 4 Dec 1985 2356-PST From: Rem@IMSSS Subject: Keywords with cells To: snyder%HPLABS.ARPA@SCORE Resent-Date: Thu 5 Dec 85 08:40:05-PST Resent-From: Alan Snyder Resent-To: common-lisp@SU-AI.ARPA I thought one of the reasons for having keywords in their own package was that you can make that a stripped down package that is just a bare hashtable with no value/function/property cells? I agree "is an error" should be the case, so if such is the case you truly do get a crashout, and in implementations that have full package with cells it's up to the implementor to decide whether to check the "error" or not. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 09:49:27 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 06:38:27 PST Received: from SCRC-YUKON.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 06:13:54-PST Received: from CONCORD.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 176322; Thu 5-Dec-85 09:14:32-EST Date: Thu, 5 Dec 85 09:19 EST From: Bernard S. Greenberg Subject: Bad to hang properties off keywords to install their semantics To: Rem@IMSSS, COMMON-LISP%SU-AI@SU-SCORE.ARPA In-Reply-To: The message of 5 Dec 85 03:20-EST from Rem@IMSSS Message-ID: <851205091935.9.BSG@CONCORD.SCRC.Symbolics.COM> Date: 5 Dec 1985 0020-PST From: Rem@IMSSS I don't think it's a good idea to implement keyword usage (semantics) by having each function that uses that keyword to hang a property off that keyword. The reason is you can have hundreds of different uses for a single keyword. I don't see how that's different than the case with any symbol, except that there is greater likelihood that there will be more code that knows about it. What about "t"? Or "print"? Is it a good idea to put properties on them? One of the profound features of Lisp is the set of services done magically by the reader, most specifically, interning, done before the program is even run. That you do not have to look up names in symbol tables, in the course of your program, as in other languages, but can go "directly" to a referenced symbol and inspect its properties: this is a major linguistic feature. You pay for this somewhere; Property lists assume you have many more symbols than things you might want to say about any of them. When that is not so, you pay. That is the tradeoff of using property lists at all. Saying "hey, for keywords, there is some chance you'll really have to start paying", is OK, but putting the blame for the problem anywhere but with the basic idea of property lists (or, as has been noted, the requirement of cons-pair implementation) is false.  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 04:44:22 EST X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1985-Dec-05 01:33:56 PST (=GMT-8hr) X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP Date: 1985 December 05 01:33:25 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132504103204.G0353 From: Robert Elton Maas To:DOUG@SU-CSLI.ARPA CC:COMMON-LISP@SAIL.STANFORD.EDU subject:Implementation issue? (re proplist on keyword) Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) | Date: 5 Dec 1985 01:17 PST (Thu) | From: Doug Cutting | Subject: Bad to hang properties off keywords to install their semantics | Date: Thursday, 5 December 1985 00:20-PST | From: Rem at IMSSS | [...] it takes a long time each time you use that | keyword for the function to scan down the keyword's property list | looking for the one item that tells this particular function what to | do while ignoring all the other properties that are used by other | functions. [...] | This seems like an implementation issue and has little to do with | what the language standard should be. Common LISP has already gotten into the implementation mess here by insisting adamently that a property list MUST be an alternating list rather than an ASSOC list or a hashtable etc. Since we've forced the implementor to make it a linear list of a given format, we ought not to then encourage LUSER programmers to mis-use it by hanging one property per function off this one poor daisy-chain (linear-liked-list) so that the ensemble of such additions in a large system makes simple functions run very slow searching down that list.  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 04:27:12 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 01:18:01 PST Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 01:15:03-PST Date: 5 Dec 1985 01:17 PST (Thu) Message-ID: From: Doug Cutting To: Rem@IMSSS Cc: BSG%SCRC-STONY-BROOK.ARPA@SCORE, COMMON-LISP%SU-AI@SCORE, Doug@SU-CSLI.ARPA Subject: Bad to hang properties off keywords to install their semantics In-reply-to: Msg of 5 Dec 1985 00:20-PST from Rem at IMSSS Date: Thursday, 5 December 1985 00:20-PST From: Rem at IMSSS [...] it takes a long time each time you use that keyword for the function to scan down the keyword's property list looking for the one item that tells this particular function what to do while ignoring all the other properties that are used by other functions. [...] This seems like an implementation issue and has little to do with what the language standard should be.  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Dec 85 03:32:38 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Dec 85 00:23:09 PST Received: from IMSSS by Score with Pup; Thu 5 Dec 85 00:20:13-PST Date: 5 Dec 1985 0020-PST From: Rem@IMSSS Subject: Bad to hang properties off keywords to install their semantics To: COMMON-LISP%SU-AI@SCORE cc: BSG%SCRC-STONY-BROOK.ARPA@SCORE I don't think it's a good idea to implement keyword usage (semantics) by having each function that uses that keyword to hang a property off that keyword. The reason is you can have hundreds of different uses for a single keyword (for example :REVERSE to do some operation backwards from default, :IP to do something in place, :FAST to make it run fast, etc.), so then it takes a long time each time you use that keyword for the function to scan down the keyword's property list looking for the one item that tells this particular function what to do while ignoring all the other properties that are used by other functions. Better to hang the keyword as a property-tag off the property list of the function, that way the search is for the various keywords used by one function rather than the various functions that use one keyword and thus the search length is under the control of whoever wrote that function rather than being the total search length by however many packages may be loaded. As an alternative to using the property list of either the keyword or the funcion, you could use the value cell of that keyword or function pointing to a hash table, although in the case of keywod.value-->hashtable you have to a general concensus. One other problem with hanging anything at all of a shared thing such as a keyword property-list cell, is that if you have interrupts you have to carefully interlock all updates. If you hang things off the function name instead, you only have to interlock against other processes in the same package, which may be a lot more managable. In my opinion, it's totally painful to have either value or function cells hanging off a keyword, except in the case where there is some global agreement about that that cell will hold (such as a hashtable), and it's workable but rather inefficient to put properties on the keyword. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 16:56:32 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 13:44:21 PST Date: Wed, 4 Dec 85 16:46:53 EST From: Richard Mlynarik Subject: keywords To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].741648.851204.MLY> That's why you use hashtables  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 14:22:15 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:19:27 PST Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367107; Wed 4-Dec-85 13:16:30-EST Date: Wed, 4 Dec 85 13:28 EST From: Bernard S. Greenberg Subject: Re: keywords To: AS%HP-HULK@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 4 Dec 85 11:42-EST from Alan Snyder Message-ID: <851204132801.3.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed 4 Dec 85 08:42:23-PST From: Alan Snyder Symbolics Common Lisp relies heavily on the property lists of keywords. Given that a keyword is "an indicator that means X in context Y", it is right reasonable that context Y might want to hang properties off of it to implement that. An alternative is to use the keyword as the indicator on a property list attached to Y, which avoids the potential conflicts in using a global database (a propertly list attached to a keyword). When propertly implemented [sorry], you use packages to isolate these things. The issue is no different than with any other symbol. It is inevitable that keywords will be interpreted differently in different contexts. What you want to avoid is conflicts that would prevent the different contexts from coexisting. That's why you use property lists.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 13:29:15 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:19:27 PST Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367107; Wed 4-Dec-85 13:16:30-EST Date: Wed, 4 Dec 85 13:28 EST From: Bernard S. Greenberg Subject: Re: keywords To: AS%HP-HULK@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 4 Dec 85 11:42-EST from Alan Snyder Message-ID: <851204132801.3.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed 4 Dec 85 08:42:23-PST From: Alan Snyder Symbolics Common Lisp relies heavily on the property lists of keywords. Given that a keyword is "an indicator that means X in context Y", it is right reasonable that context Y might want to hang properties off of it to implement that. An alternative is to use the keyword as the indicator on a property list attached to Y, which avoids the potential conflicts in using a global database (a propertly list attached to a keyword). When propertly implemented [sorry], you use packages to isolate these things. The issue is no different than with any other symbol. It is inevitable that keywords will be interpreted differently in different contexts. What you want to avoid is conflicts that would prevent the different contexts from coexisting. That's why you use property lists.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 13:16:45 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 10:05:26 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 367089; Wed 4-Dec-85 13:02:25-EST Date: Wed, 4 Dec 85 13:05 EST From: Kent M Pitman Subject: The variables +, -, *, and / To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].740954.851204.TIM> Message-ID: <851204130539.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 4 Dec 85 04:22:30 EST From: Tim McNerney It seems unfortunate that the variables +, -, *, and / were reserved for use by the Top-Level Loop. This choice of names makes it difficult to build the run-time environment for Scheme-like language that compiles into Common Lisp and that supports the illusion that there are no separate function and value cells. If these variables had not been reserved, one could (DEFCONSTANT + #'+) (DEFCONSTANT * #'*) etc... so that ((IF SUM? + *) X Y) could be simply compiled into (FUNCALL (IF SUM? + *) X Y) Sigh... The good Scheme dialects all do modules via closure hacks, rather than via read-time hacks like packages. As such, there's no reason you can't build a Scheme package which shadows those symbols and which all Scheme users share. Talk to Jonathan Rees -- I think he's done just that with a Scheme hack he wrote to run in CL.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 11:55:11 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 08:43:13 PST Received: from HP-HULK by hplabsd ; Wed, 4 Dec 85 08:41:11 pst Date: Wed 4 Dec 85 08:42:23-PST From: Alan Snyder Subject: Re: keywords To: BSG%scrc-stony-brook.arpa@CSNET-RELAY.ARPA Cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from ""Bernard S. Greenberg" " of Wed 4 Dec 85 07:56:31-PST Symbolics Common Lisp relies heavily on the property lists of keywords. Given that a keyword is "an indicator that means X in context Y", it is right reasonable that context Y might want to hang properties off of it to implement that. An alternative is to use the keyword as the indicator on a property list attached to Y, which avoids the potential conflicts in using a global database (a propertly list attached to a keyword). It is inevitable that keywords will be interpreted differently in different contexts. What you want to avoid is conflicts that would prevent the different contexts from coexisting. P.S. Can a keyword be used as the name of a type? Can a keyword be used as the name of a block? Can a keyword be used as a tag? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 11:49:26 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 08:37:45 PST Received: from MIT-CHERRY.ARPA by MIT-MC.ARPA via Chaosnet; 4 DEC 85 11:37:15 EST Date: Wed, 4 Dec 85 11:34 EST From: Soley@MIT-MC.ARPA Subject: The variables +, -, *, and / To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].740954.851204.TIM> Message-ID: <851204113446.4.SOLEY@MIT-CHERRY.ARPA> Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 04:32:20 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 01:19:57 PST Date: Wed, 4 Dec 85 04:22:30 EST From: Tim McNerney Subject: The variables +, -, *, and / To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].740954.851204.TIM> It seems unfortunate that the variables +, -, *, and / were reserved for use by the Top-Level Loop. This choice of names makes it difficult to build the run-time environment for Scheme-like language that compiles into Common Lisp and that supports the illusion that there are no separate function and value cells. If these variables had not been reserved, one could (DEFCONSTANT + #'+) (DEFCONSTANT * #'*) etc... so that ((IF SUM? + *) X Y) could be simply compiled into (FUNCALL (IF SUM? + *) X Y) Why not create a package SCHEME that doesn't import any symbols or use any other package, and do what you like in that package, i.e., (LISP:DEFCONSTANT + #'LISP:+) and build your own world? This is not unlike the Symbolics solution to Common Lisp vs. Zetalisp on the 3600 -- two different worlds rooted at different packages ("GLOBAL" and "SYMBOLICS-COMMON-LISP"). -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 11:46:06 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 03:12:23 PST Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 366846; Wed 4-Dec-85 09:14:05-EST Date: Wed, 4 Dec 85 09:25 EST From: Bernard S. Greenberg Subject: keywords To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <851204092534.6.BSG@CONCORD.SCRC.Symbolics.COM> Date: Tue, 3 Dec 1985 22:53 EST From: "Scott E. Fahlman" It is certainly terrible style to use a keyword as the name of a function or to give it any properties. The book doesn't seem to say whether "it is an error" to do either of these things. I think it should be an error. On the other hand, I don't know of any Common Lisp that goes to the trouble of signaling such an error or that special cases keyword symbols in such a way as to eliminate the function and property-list cells. -- Scott Symbolics Common Lisp relies heavily on the property lists of keywords. Given that a keyword is "an indicator that means X in context Y", it is right reasonable that context Y might want to hang properties off of it to implement that.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 11:44:39 EST Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 03:09:24 PST Received: by mit-ems.ARPA (4.12/4.8) id AA11143; Wed, 4 Dec 85 07:43:55 est Date: Wed, 4 Dec 85 07:43:55 est From: Steven Haflich Message-Id: <8512041243.AA11143@mit-ems.ARPA> To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA Subject: Re: The variables +, -, *, and / > From: Tim McNerney > Subject: The variables +, -, *, and / > > It seems unfortunate that the variables +, -, *, and / were reserved > for use by the Top-Level Loop. This choice of names makes it difficult > to build the run-time environment for Scheme-like language that > compiles into Common Lisp and that supports the illusion that there are > no separate function and value cells. If these variables had not been > reserved, one could > > (DEFCONSTANT + #'+) > (DEFCONSTANT * #'*) > etc... > > so that > > ((IF SUM? + *) X Y) > > could be simply compiled into > > (FUNCALL (IF SUM? + *) X Y) Perhaps these symbols aren't the real problem: CL compilers tend to have built-in knowledge about certain special forms that a user can't easily modify. So if you're really scheming up a language with different semantics for the functional position of a form, you'll probably have to write new top-level loops for both compiler and interpreter which preprocess all top-level forms appropriately. Your top-level interpreter loop would probably have a reentrant top-level unwind-protect so the user doesn't ever fall out into the CL one, even during error recovery. Thus, the CLtL top-level loop won't be around to mess with +, ++, etc.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 11:23:04 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85 08:13:58 PST Received: ID ; Wed 4 Dec 85 11:13:37-EST Date: Wed, 4 Dec 1985 11:13 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Tim McNerney Cc: common-lisp@SU-AI.ARPA Subject: The variables +, -, *, and / In-reply-to: Msg of 4 Dec 1985 04:22-EST from Tim McNerney We thought brielfly about such issues and decided that we would quickly go mad if we tried to avoid stepping on symbols (or ways of using them) for every other Lisp-like language. That's why there are packages. The Common Lisp top-level will not mess around with the value of SCHEME:*, etc. Customize the scheme symbols any way you want, and import from the LISP package those things that happen to be right. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 11:16:29 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 4 Dec 85 08:03:23 PST Received: ID ; Wed 4 Dec 85 10:57:03-EST Date: Wed, 4 Dec 1985 10:56 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Bernard S. Greenberg" Cc: common-lisp@SU-AI.ARPA Subject: keywords In-reply-to: Msg of 4 Dec 1985 09:25-EST from Bernard S. Greenberg Symbolics Common Lisp relies heavily on the property lists of keywords. Given that a keyword is "an indicator that means X in context Y", it is right reasonable that context Y might want to hang properties off of it to implement that. OK, I guess I accept that this is not so terrible a thing to do. If the property names are package-specific, it shouldn't bother them that they are sharing the same package-neutral keyword, since the different uses still have a way of staying out of each other's way. It strikes me as a bit unclean, but maybe that's just that I like the abstraction of a keyword as a pure token. I would still be inclinded to holler at anyone naming a function :FOO, however. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 10:23:05 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 03:01:13 PST Received: from fang.GSD (fang.ARPA) by gswd-vms.ARPA (5.9/5.6) id AA00873; Wed, 4 Dec 85 09:15:19 CST Message-Id: <8512041515.AA00873@gswd-vms.ARPA> Date: Wed, 4 Dec 85 09:04:51 cst From: wagner%fang@gswd-vms (Fran Wagner) To: common-lisp@su-ai.arpa Subject: minor index errors Cc: wagner%fang@gswd-vms These may be known, but in CLtL index: Entry for MULTIPLE-VALUES-LIMIT is 1325, should be 135. Main entry for THE is 162-163, should be 161-162.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Dec 85 04:28:05 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Dec 85 01:19:57 PST Date: Wed, 4 Dec 85 04:22:30 EST From: Tim McNerney Subject: The variables +, -, *, and / To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].740954.851204.TIM> It seems unfortunate that the variables +, -, *, and / were reserved for use by the Top-Level Loop. This choice of names makes it difficult to build the run-time environment for Scheme-like language that compiles into Common Lisp and that supports the illusion that there are no separate function and value cells. If these variables had not been reserved, one could (DEFCONSTANT + #'+) (DEFCONSTANT * #'*) etc... so that ((IF SUM? + *) X Y) could be simply compiled into (FUNCALL (IF SUM? + *) X Y) Sigh...  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Dec 85 23:05:23 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 Dec 85 19:54:14 PST Received: ID ; Tue 3 Dec 85 22:53:58-EST Date: Tue, 3 Dec 1985 22:53 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: snyder@HPLABS.ARPA Cc: common-lisp@SU-AI.ARPA Subject: keywords In-reply-to: Msg of 3 Dec 1985 17:07-EST from snyder at hplabsd It is certainly terrible style to use a keyword as the name of a function or to give it any properties. The book doesn't seem to say whether "it is an error" to do either of these things. I think it should be an error. On the other hand, I don't know of any Common Lisp that goes to the trouble of signaling such an error or that special cases keyword symbols in such a way as to eliminate the function and property-list cells. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Dec 85 20:30:46 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 17:19:01 PST Received: by hplabsd ; Tue, 3 Dec 85 17:17:25 pst Date: Tuesday, December 3, 1985 17:07:20 From: snyder@hplabsd Subject: keywords To: common-lisp@su-ai X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Is it legal to use a keyword as the name of a function? Does a keyword have a property list? I have always assumed the answer to these questions is "no", but I cannot find any clear statement to this effect in the manual. The only related statement I could find is on page 175, and is somewhat vague: "... name conflicts are not an issue because these symbols are used only as labels and never to carry package-specific values or properties." Opinions? Alan Snyder -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Dec 85 20:15:35 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 3 Dec 85 17:06:28 PST Received: by hplabsd ; Tue, 3 Dec 85 17:04:55 pst Date: Tuesday, December 3, 1985 16:54:15 From: snyder@hplabsd Subject: manual bug (index) To: common-lisp@su-ai X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 In case it's not been noticed before, the function KEYWORDP appears in the index as KEYWORD. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Dec 85 19:53:37 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 16:44:32 PST Date: 1 Dec 1985 19:47-EST Sender: NGALL@BBNG.ARPA Subject: Re: DEFSTRUCT and predicates From: NGALL@BBNG.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[BBNG.ARPA] 1-Dec-85 19:47:09.NGALL> In-Reply-To: Date: Tue, 26 Nov 1985 18:27 EST From: Skef Wholey To: NGALL@BBNG.ARPA Subject: DEFSTRUCT and predicates In-Reply-To: Msg of 26 Nov 1985 17:20-EST from NGALL at BBNG.ARPA Message-ID: Date: Tuesday, 26 November 1985 17:20-EST From: NGALL at BBNG.ARPA The only complexity in the CL "-P" heuristic is dealing with qualified predicates such as string-(lessp). Since defstruct created predicates will ALWAYS be suffixing data-type names (NEVER existing predicate names), defstruct can safely use the simple hyphenation heuristic, i.e., if the data-type name is hyphenated, add "-P", otherwise add "P". Can anyone think of counter-examples? How about: (defstruct person mom dad kids shoe-size) (defstruct (space-person (:include person)) planet-of-birth number-of-eyes) Space-Person-P (or Space-Personp) is what you call a "qualified predicate." Hmmm. I think I disagree. I don't think Space-Person-P falls under the CL definition of "qualified predicate": 1. The rationale for for NOT hyphenating the "P" in "STRING-LESSP" is that it would "incorrectly imply that it is a predicate that tests for a kind of object called a STRING-LESS." This is exactly what we WANT to imply in the case of SPACE-PERSON; so the predicate should be SPACE-PERSON-P. 2. Your definition by example would require that SIMPLE-STRING-P become SIMPLE-STRINGP, BIT-VECTOR-P become BIT-VECTORP, etc., since STRINGP, VECTORP, etc., are already predicates. 3. In my opinion, the only predicates that retain their "P"s "as is" are predicates such as lessp, greaterp, equalp, i.e., non-type-predicates. And these are the kind of predicate that defstruct will never have to deal with. -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Dec 85 15:28:53 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Dec 85 12:19:26 PST Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 364776; Sun 1-Dec-85 15:17:00-EST Date: Sun, 1 Dec 85 15:23 EST From: Daniel L. Weinreb Subject: lexical scope and dynamic extent To: mips!escargot.earl@SU-GLACIER.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8511280231.AA15071@escargot.UUCP> Message-ID: <851201152340.2.DLW@CHICOPEE.SCRC.Symbolics.COM> In the Symbolics system, interpreted, you get >>Error: The GO tag L is no longer dynamically active Compiled, you get a less-comprehensible error message: >>Error: Attempt to %UNWIND-INTO-FRAME-AT-PC to a frame not running a compiled function In both cases, the system has detected that something's wrong. In the latter case, it goes to look for the tag, and finds an interpreted frame where it expected a compiled frame, because the outer frame is gone. To improve the error message, we'd probably have to add some more debugging-info (debugging-info is extra structure that lives with a compiled code object to help the system create error messages and to help various debugging tools figure out what's happening, among other things). It wouldn't be particularly hard.  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Nov 85 13:58:18 EST Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 Nov 85 10:51:25 PST Date: Thu 28 Nov 85 10:51:07-PST From: Richard Acuff Subject: Re: lexical scope and dynamic extent To: mips!escargot.earl@SU-GLACIER.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8511280231.AA15071@escargot.UUCP> Message-ID: <12162901082.56.ACUFF@SUMEX-AIM.ARPA> In Explorer Common Lisp you get: >>>ERROR: GO tag L is not defined or is no longer valid which seems reasonable given the statment near the top of pg. 131 of CLtL, "Once a tagbody construct has been exited, it is no longer legal to go to a tag in its body." I think you may be confusing dynamic extent and indefinite extent. An entity with dynamic extent (in this case the tag) continues to exist only as long as the form that establishes it (the tagbody), while entities with indefinite extent continue to exist as long as there is a reference to them. -- Rich -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Nov 85 23:20:17 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 20:11:13 PST Date: Wed 27 Nov 85 23:11:34-EST From: "Rodney A. Brooks" Subject: Re: lexical scope and dynamic extent To: mips!escargot.earl@SU-GLACIER.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <8511280231.AA15071@escargot.UUCP> Message-ID: <12162740965.44.BROOKS@MIT-OZ> In Lucid's SUN Common Lisp 1.0, compiled foo, you get >>Error: A go to one of (L) occured from within an out of scope closure Maybe the English needs a little work... Date: Wed, 27 Nov 85 18:31:55 pst From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8511280231.AA15071@escargot.UUCP> To: common-lisp@su-ai.ARPA Subject: lexical scope and dynamic extent Some entities in the language are described as having lexical scope and dynamic extent, which means that they can be refered to after they're gone. Do any of the implementations have good ways of detecting such things? Here's a nasty one: (defun foo () (tagbody l (return-from foo #'(lambda () (go l))))) (funcall (foo)) If you type this at various implementations, what do you get? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Nov 85 22:10:51 EST Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 27 Nov 85 19:01:49 PST Received: by glacier with Sendmail; Wed, 27 Nov 85 19:01:17 pst Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7) id AA11694; Wed, 27 Nov 85 18:32:27 pst Received: by escargot.UUCP (4.12/4.7) id AA15071; Wed, 27 Nov 85 18:31:55 pst Date: Wed, 27 Nov 85 18:31:55 pst From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8511280231.AA15071@escargot.UUCP> To: common-lisp@su-ai.ARPA Subject: lexical scope and dynamic extent Some entities in the language are described as having lexical scope and dynamic extent, which means that they can be refered to after they're gone. Do any of the implementations have good ways of detecting such things? Here's a nasty one: (defun foo () (tagbody l (return-from foo #'(lambda () (go l))))) (funcall (foo)) If you type this at various implementations, what do you get?  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Nov 85 01:44:09 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 22:33:46 PST Date: Wed, 27 Nov 85 01:36:13 EST From: Tim McNerney Subject: Amatuer Archivists (again) To: common-lisp@SU-AI.ARPA cc: schumacher!hplabs@CSNET-RELAY.ARPA, gls@THINK.COM Message-ID: <[MIT-MC.ARPA].734507.851127.TIM> I sympathize with those of you who have short terminals and have to wade through pages and pages of "context." (About 1/2 of my terminal's ram is shot, so mine is about 14 lines tall). But I also agree with Steele. Perhaps the problem lies with the conventions we use for replying to mail. If, instead of putting the reply at the end of the message (as is so easy to do when using BABYL, RMAIL and ZMAIL), we put our reply at the beginning, we could have the best of both worlds: Immediacy and Context. Tim Date: Tue, 26 Nov 85 15:04 EST From: Guy Steele On a more serious note, I receive anywhere between 20 and 100 messages a day by electronic mail. Not infrequently there are three or four distinct conversations on the common-lisp mailing list alone, and then there are other mailing lists, as well as mail related to work I actually get paid for. I often find it helpful to have some previous context for each message. Maybe I tend to overdo it because I rely on it more than others do. I'm sorry that I upset you. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 18:38:35 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Nov 85 15:28:09 PST Received: ID ; Tue 26 Nov 85 18:27:46-EST Date: Tue, 26 Nov 1985 18:27 EST Message-ID: Sender: WHOLEY@C.CS.CMU.EDU From: Skef Wholey To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: DEFSTRUCT and predicates In-reply-to: Msg of 26 Nov 1985 17:20-EST from NGALL at BBNG.ARPA Date: Tuesday, 26 November 1985 17:20-EST From: NGALL at BBNG.ARPA The only complexity in the CL "-P" heuristic is dealing with qualified predicates such as string-(lessp). Since defstruct created predicates will ALWAYS be suffixing data-type names (NEVER existing predicate names), defstruct can safely use the simple hyphenation heuristic, i.e., if the data-type name is hyphenated, add "-P", otherwise add "P". Can anyone think of counter-examples? How about: (defstruct person mom dad kids shoe-size) (defstruct (space-person (:include person)) planet-of-birth number-of-eyes) Space-Person-P (or Space-Personp) is what you call a "qualified predicate." I think defstruct SHOULD obey the CL convention. At the very least, it should be documented that it is BREAKING the convention. Yes, such a note in the manual would be worthwhile. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 17:45:12 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 14:17:52 PST Date: 26 Nov 1985 17:20-EST Sender: NGALL@BBNG.ARPA Subject: Re: DEFSTRUCT and predicates From: NGALL@BBNG.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[BBNG.ARPA]26-Nov-85 17:20:36.NGALL> In-Reply-To: From: Skef Wholey To: Kent M Pitman Subject: DEFSTRUCT and predicates Message-ID: Date: Tuesday, 26 November 1985 14:49-EST From: Kent M Pitman The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed convention for the formation of predicate names (CLtL, p71) by blindly adding -P to the end of the symbol rather than adding just "P" when there is no "-" in the base symbol. Yeah, at one point the language spec (or at least the language specifiers) said that defstrict would "do the right thing" with defstruct predicates. This decision was changed to the current one for some reason I don't recall. Note that one can get the right effect by specifying the predicate name onesself. As both an implementor and user of defstruct, I like the current situation -- I don't think the naming conventions used by the system supplied functions should be forced upon every single programmer. Of course, Common Lisp follows a somewhat more complicated hueristic with "-P"'ing things (e.g. Alpha-Charp). It's better that a program like defstruct always do the same predictable dumb thing all the time than try to be clever when it's going to be wrong occasionally. --Skef -------------------- The only complexity in the CL "-P" heuristic is dealing with qualified predicates such as string-(lessp). Since defstruct created predicates will ALWAYS be suffixing data-type names (NEVER existing predicate names), defstruct can safely use the simple hyphenation heuristic, i.e., if the data-type name is hyphenated, add "-P", otherwise add "P". Can anyone think of counter-examples? I think defstruct SHOULD obey the CL convention. At the very least, it should be documented that it is BREAKING the convention. -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 16:07:39 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Nov 85 12:21:04 PST Received: ID ; Tue 26 Nov 85 15:20:05-EST Date: Tue, 26 Nov 1985 15:20 EST Message-ID: Sender: WHOLEY@C.CS.CMU.EDU From: Skef Wholey To: Kent M Pitman Cc: ALAN@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA, GLS@AQUINAS.THINK.COM Subject: DEFSTRUCT and predicates In-reply-to: Msg of 26 Nov 1985 14:49-EST from Kent M Pitman Date: Tuesday, 26 November 1985 14:49-EST From: Kent M Pitman The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed convention for the formation of predicate names (CLtL, p71) by blindly adding -P to the end of the symbol rather than adding just "P" when there is no "-" in the base symbol. Yeah, at one point the language spec (or at least the language specifiers) said that defstrict would "do the right thing" with defstruct predicates. This decision was changed to the current one for some reason I don't recall. Note that one can get the right effect by specifying the predicate name onesself. As both an implementor and user of defstruct, I like the current situation -- I don't think the naming conventions used by the system supplied functions should be forced upon every single programmer. Of course, Common Lisp follows a somewhat more complicated hueristic with "-P"'ing things (e.g. Alpha-Charp). It's better that a program like defstruct always do the same predictable dumb thing all the time than try to be clever when it's going to be wrong occasionally. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 15:15:14 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 12:02:26 PST Received: from DUPAGE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 363211; Tue 26-Nov-85 14:48:26-EST Date: Tue, 26 Nov 85 14:49 EST From: Kent M Pitman Subject: DEFSTRUCT and predicates To: ALAN@MIT-MC.ARPA, GLS@THINK-AQUINAS.ARPA cc: Common-Lisp@SU-AI.ARPA Message-ID: <851126144928.6.KMP@DUPAGE.SCRC.Symbolics.COM> The :PREDICATE option to DEFSTRUCT (CLtL, p312) violates the supposed convention for the formation of predicate names (CLtL, p71) by blindly adding -P to the end of the symbol rather than adding just "P" when there is no "-" in the base symbol.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 15:14:52 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85 12:02:17 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 3021; Tue 26-Nov-85 15:05:22-EST Date: Tue, 26 Nov 85 15:04 EST From: Guy Steele Subject: Amatuer Archivists (again) To: schumacher!hplabs@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 25 Nov 85 15:17-EST from schumacher@hplabs.arpa Message-ID: <851126150415.1.GLS@FAUSTINUS.THINK.COM> On a more serious note, I receive anywhere between 20 and 100 messages a day by electronic mail. Not infrequently there are three or four distinct conversations on the common-lisp mailing list alone, and then there are other mailing lists, as well as mail related to work I actually get paid for. I often find it helpful to have some previous context for each message. Maybe I tend to overdo it because I rely on it more than others do. I'm sorry that I upset you. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 15:12:42 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85 11:57:33 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 3017; Tue 26-Nov-85 15:00:28-EST Date: Tue, 26 Nov 85 14:59 EST From: Guy Steele Subject: Amatuer Archivists. To: schumacher!hplabs@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 25 Nov 85 15:17-EST from schumacher@hplabs.arpa Message-ID: <851126145919.0.GLS@FAUSTINUS.THINK.COM> Da e: on ay, No mb r 5, 1 8 15:1 : 3 From s huma he @h abs.ar a Is t eally ce sa y to i lude h @ ( ntire t xt o a pr ious m g o r fe ence i ? Gu 's l s msg w s a a ticul l egr gi us xample s art ng ut wi : Date u , 26 N v 8 08:42 ST Fr m: Ber ard S. Gre nb rg BS SCRC- ONY B OOK. R A Dat Mon, 5 ov 5 4:0 PST ro : R ch d Lam n < s @RUS I N SPA. y bol s.COM Dat : Fri 22 No 85 20: 1: 1 E T Fr m: Ge rge J. arret " < J @MIT M . RPA> a d th n epeat n i SECO ime. R al folks ts ot ik we're ll re di g mail w th a lin itor. Lee ------- Well, if we're all not using line editors, then having all that text there shouldn't hurt. The redundant copy was, of course, an error on my part (sorry). There is also somewhat of a tradition of allowing large messages to build up occasionally. The likelihood of this happening is inversely correlated with the seriousness of the subject matter. Please note that, to save space, I have excerpted and condensed your original message above. --Quux  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 14:39:30 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 11:28:02 PST Received: from hplabs.arpa by CSNET-RELAY.ARPA id a012324; 26 Nov 85 14:21 EST Received: by hplabsd ; Tue, 26 Nov 85 11:21:21 pst Date: Monday, November 25, 1985 15:17:03 From: schumacher@hplabs.arpa Subject: Amatuer Archivists. To: hplabs!gls%aquinas.think.com@csnet-relay.arpa Cc: common-lisp <@csnet-relay.arpa:common-lisp@su-ai.arpa> In-Reply-To: Your message of 26-Nov-85 12:15:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Is it really necessary to include the @i(entire) text of a previous msg to reference it ? Guy's last msg was a particularly egregious example, starting out with : Date: Tue, 26 Nov 85 08:42 EST From: Bernard S. Greenberg Date: Mon, 25 Nov 85 14:08 PST From: Richard Lamson Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" and then repeating it a SECOND time. Really folks, its not like we're all reading mail with a line editor. Lee -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 13:10:04 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 26 Nov 85 09:55:41 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2970; Tue 26-Nov-85 12:17:09-EST Date: Tue, 26 Nov 85 12:15 EST From: Guy Steele Subject: LET-IF To: BSG@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <851126084235.2.BSG@CONCORD.SCRC.Symbolics.COM> Message-ID: <851126121559.6.GLS@FAUSTINUS.THINK.COM> Date: Tue, 26 Nov 85 08:42 EST From: Bernard S. Greenberg Date: Mon, 25 Nov 85 14:08 PST From: Richard Lamson Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" Funny you should mention that, I'm considering flushing quite a few special forms in the LMI system and replacing them with macros, LET-IF is one, and the following definition seems right: (defmacro let-if (pred bindings &body body) (let ((f (gentemp "f"))) `(flet ((,f () ,@body)) (if ,pred (let ,bindings (,f)) (,f))))) Unfortunately, this doesn't work if you want the bindings to be lexical instead of special bindings. Consider: (defun xor (a b) (let-if a ((b (not b))) b)) Unless B is special, this won't work using your scheme. I can't imagine what LET-IF would mean with lexical variables no matter what the implementation. Date: Tue, 26 Nov 85 08:42 EST From: Bernard S. Greenberg Date: Mon, 25 Nov 85 14:08 PST From: Richard Lamson Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" Funny you should mention that, I'm considering flushing quite a few special forms in the LMI system and replacing them with macros, LET-IF is one, and the following definition seems right: (defmacro let-if (pred bindings &body body) (let ((f (gentemp "f"))) `(flet ((,f () ,@body)) (if ,pred (let ,bindings (,f)) (,f))))) Unfortunately, this doesn't work if you want the bindings to be lexical instead of special bindings. Consider: (defun xor (a b) (let-if a ((b (not b))) b)) Unless B is special, this won't work using your scheme. I can't imagine what LET-IF would mean with lexical variables no matter what the implementation. I can imagine: (let-if a ((b (not b))) (f b)) means (if a (let ((b (not b))) (f b)) (f b)). But in most such cases I should imagine (let ((b (if a (not b) b))) (f b)) would do just as well (and result in better code), because a redundant bindings of b to iself doesn't hurt in the lexical case (whereas it is not allowed in the special case, as it would result in visibly different semantics).  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 12:50:43 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 08:03:30 PST Date: Tue, 26 Nov 85 11:06:00 EST From: "George J. Carrette" Subject: Mr Roberts vs Mr Rogers To: gls@AQUINAS.THINK.COM cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Mon 25 Nov 85 10:40 EST from Guy Steele Message-ID: <[MIT-MC.ARPA].733419.851126.GJC> Too much jungle juice I suppose.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 11:13:51 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 08:03:30 PST Date: Tue, 26 Nov 85 11:06:00 EST From: "George J. Carrette" Subject: Mr Roberts vs Mr Rogers To: gls@AQUINAS.THINK.COM cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Mon 25 Nov 85 10:40 EST from Guy Steele Message-ID: <[MIT-MC.ARPA].733419.851126.GJC> Too much jungle juice I suppose.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Nov 85 08:47:41 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 85 05:37:32 PST Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 362815; Tue 26-Nov-85 08:35:48-EST Date: Tue, 26 Nov 85 08:42 EST From: Bernard S. Greenberg Subject: LET-IF To: RSL@SCRC-STONY-BROOK.ARPA, GJC@MIT-MC.ARPA, robbins%bach.decnet@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM In-Reply-To: <851125140843.3.RSL@QUETZLCOATL.SSF.Symbolics.COM> Message-ID: <851126084235.2.BSG@CONCORD.SCRC.Symbolics.COM> Date: Mon, 25 Nov 85 14:08 PST From: Richard Lamson Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" Funny you should mention that, I'm considering flushing quite a few special forms in the LMI system and replacing them with macros, LET-IF is one, and the following definition seems right: (defmacro let-if (pred bindings &body body) (let ((f (gentemp "f"))) `(flet ((,f () ,@body)) (if ,pred (let ,bindings (,f)) (,f))))) Unfortunately, this doesn't work if you want the bindings to be lexical instead of special bindings. Consider: (defun xor (a b) (let-if a ((b (not b))) b)) Unless B is special, this won't work using your scheme. I can't imagine what LET-IF would mean with lexical variables no matter what the implementation.  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Nov 85 22:23:18 EST Date: 25 Nov 85 1715 PST From: Dick Gabriel Subject: New, Improved Agenda To: Common-lisp@SU-AI.ARPA Here is an outline of my idea of the agenda we should use for the meeting: Sunday Night: Registration and intense lobyying Monday, December 9 8:30am Welcome, registration, and coffee (Registration information will used for updating the mailing lists, possible dunning for expenses unless I can sweet talk DARPA into fronting some money for this meeting, and for making sure that the groups are represented.) 9:00am Charter Discussion Noon Lunch. You are on your own for this. 1:30pm Charter/Validation Discussion 6:00pm Dinner (Intense Lobbying and Discussions) Tuesday 8:30am Coffee 9:00am Charter/Validation/ANSI etc Discussion 12:00 Lunch. You are on your own. 1:30pm Object-oriented programming 6:00pm Dinner Wednesday 8:30am Coffee 9:00am Windows 12:00 Lunch. You are on your own. 1:30pm Windows/Errors/Varia 5:00pm Hit the Road During the Charter discussion, the following topics will be discussed: Fahlman's Proposals Inclusion of the recent minor changes and errata to the Common Lisp specification Publishing problems - Copyright, additions to the book Validation Real standardization During the object oriented programming session, Symbolics will present some the developments going on there with respect to flavors. Xerox will present their plans for CommonLoops testing using an implementation that they have been working on. I expect that the discussions will focus more closely on the methods and plans for evaluating the various proposals than on the detailed technical merits of the proposals. During the Windows discussion proposals can be presented along with implementation plans. For people who would like to make presentations, here are some guidelines: 1. Overhead or 35 millimeter slides are OK 2. Let me know that you want to make a presentation as well as why a formal presentation is necessary. 3. If you want to include a handout, make at least 50 copies (that's about 1 per group). 4. Try to limit your presentation to 30 minutes, maximum. I will have a large hook. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Nov 85 18:58:48 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 15:47:24 PST Received: from tektronix by csnet-relay.csnet id ac04345; 25 Nov 85 18:38 EST From: S Sridhar To: common-lisp@su-ai.ARPA Fcc: cl-mail Received: from tekchips by tektronix with smtp ; 25 Nov 85 09:45:08 PST Date: Monday, 25 Nov 85 09:36:19 PST Subject: Typos on p.284 and p.324 p.284: A minor grammatical typo : Near the beginning of the last quarter of the page , the sentence: "means the approximately the same as" should read "means approximately the same as" p.324: The second and third line: From the trace , it would appear that the second argument to the floor function was intended to be 3 and not 2. So the 2 in these two lines should be replaced by a 3. p.67: Another one pointed out by a colleague: At the beginning of the page it says: "The defun special form ...." and in the very next line defun is said to be a macro. [ defun does not appear in the list of special forms on p.57 ]. Light ? --sridhar  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Nov 85 17:20:08 EST Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 25 Nov 85 14:08:28 PST Received: from CERRIDWYN.SSF.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 55745; Mon 25-Nov-85 17:16:31-EST Received: from QUETZLCOATL.SSF.Symbolics.COM by CERRIDWYN.SSF.Symbolics.COM via CHAOS with CHAOS-MAIL id 55477; Mon 25-Nov-85 14:09:40-PST Date: Mon, 25 Nov 85 14:08 PST From: Richard Lamson Subject: LET-IF To: George J. Carrette , robbins%bach.decnet@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA, robbins@HUDSON.DEC.COM In-Reply-To: <[MIT-MC.ARPA].729508.851122.GJC> Message-ID: <851125140843.3.RSL@QUETZLCOATL.SSF.Symbolics.COM> Reply-To: RSL@SCRC-STONY-BROOK.ARPA Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" Funny you should mention that, I'm considering flushing quite a few special forms in the LMI system and replacing them with macros, LET-IF is one, and the following definition seems right: (defmacro let-if (pred bindings &body body) (let ((f (gentemp "f"))) `(flet ((,f () ,@body)) (if ,pred (let ,bindings (,f)) (,f))))) Unfortunately, this doesn't work if you want the bindings to be lexical instead of special bindings. Consider: (defun xor (a b) (let-if a ((b (not b))) b)) Unless B is special, this won't work using your scheme.  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Nov 85 11:01:32 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85 07:52:05 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2676; Mon 25-Nov-85 10:54:48-EST Date: Mon, 25 Nov 85 10:53 EST From: Guy Steele Subject: Minor Typo = Major Faux Pas! To: RPG@SU-AI.ARPA, common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 23 Nov 85 19:28-EST from Dick Gabriel Message-ID: <851125105359.4.GLS@FAUSTINUS.THINK.COM> Date: 23 Nov 85 1628 PST From: Dick Gabriel Dan mentioned that an existential quantifier was mistyped at some place where a 3 was meant. He meant to say the an existential quantifier was mistyped *every* place a 3 was meant. I think the spot to which he refers is a place where the TTY font for `3' belongs, and that representation of `3' looks exactly like an existential sign. This is because that is the best font Digital Press could come up with. -rpg- Similarly, on page 49, third line, you will see a terminal cursor s between "(integer " and " 2 -1)", and again on the next line. That threw me during proofreading! --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Nov 85 10:58:34 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85 07:47:32 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2674; Mon 25-Nov-85 10:50:17-EST Date: Mon, 25 Nov 85 10:49 EST From: Guy Steele Subject: Minor typo To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <851123164942.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <851125104923.3.GLS@FAUSTINUS.THINK.COM> Date: Sat, 23 Nov 85 16:49 EST From: Daniel L. Weinreb There seems to be a minor typo on page 23, second paragraph of 2.2.4, second line, in which an existential qualifier symbol appears where there ought to be a numeral "3". Aw, c'mon! I *know* the code font stinks... --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Nov 85 10:49:41 EST Received: from AQUINAS.THINK.COM by SU-AI.ARPA with TCP; 25 Nov 85 07:39:08 PST Received: from FAUSTINUS.THINK.COM by THINK-AQUINAS.ARPA via CHAOS with CHAOS-MAIL id 2671; Mon 25-Nov-85 10:41:36-EST Date: Mon, 25 Nov 85 10:40 EST From: Guy Steele Subject: LET-IF To: GJC@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, robbins%HUDSON.DEC.COM@GODOT.THINK.COM, gls@THINK-AQUINAS.ARPA In-Reply-To: <[MIT-MC.ARPA].729508.851122.GJC> Message-ID: <851125104047.2.GLS@FAUSTINUS.THINK.COM> Date: Fri, 22 Nov 85 20:41:51 EST From: "George J. Carrette" ... Or, as Mr Roberts would say, "can you say... CLOSURE," yes boys and girls... Hurrah for closures! But did you mean "Mr. Roberts" or "Mr. Rogers"? (I can't imagine Mr. Roberts talking about closures. Then again, it's just as hard to image Mr. Rogers talking about it.) --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Nov 85 18:09:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Nov 85 14:58:29 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 361709; Sun 24-Nov-85 17:56:58-EST Date: Sun, 24 Nov 85 17:55 EST From: David A. Moon Subject: Re: Misc Queries To: Stanley Shebs cc: common-lisp@SU-AI.ARPA In-Reply-To: <8511241730.AA27238@utah-orion.ARPA> Message-ID: <851124175559.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 24 Nov 85 10:30:53 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) How about (defun more-disgusting (a &optional (b (setq a nil))) (list a b)) This is almost plausible (you could save a supplied-p for b), and the CLM doesn't disallow it. I don't see anything at all problematic about this. a is just a variable like any other variable. This doesn't have the problem that the previous examples had, where the same data were being used for more than one argument: the rest argument and the keyword arguments. Perhaps the spec could be modified to say that initforms may refer to parameters on the left, but not modify them. I don't see any reason to change the language here.  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Nov 85 12:38:56 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Nov 85 09:30:46 PST Received: from utah-orion.ARPA by utah-cs.ARPA (5.5/4.40.2) id AA16140; Sun, 24 Nov 85 10:30:56 MST Received: by utah-orion.ARPA (5.5/4.40.2) id AA27238; Sun, 24 Nov 85 10:30:53 MST Date: Sun, 24 Nov 85 10:30:53 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8511241730.AA27238@utah-orion.ARPA> To: Moon@scrc-stony-brook.arpa, shebs%utah-orion@utah-cs.arpa Subject: Re: Misc Queries Cc: common-lisp@su-ai.arpa Date: Sat, 23 Nov 85 16:53 EST From: David A. Moon The second sentence of the last paragraph on page 182 is quite explicit. The Spice implementation is not the definition of the language. Well, now that I notice the sentence, it's pretty plain! One of the trouble with huge specs I suppose... The reason I brought up Spice's behavior is that a lot of people have based their implementations on it, so any wrongnesses in it will be propagated unawares. For instance, the PCLS package system is actually derived indirectly from Spice, via HP, who now presumably have something to fix in their implementation! I don't mean to criticize Spice code either; by and large, it's some of the cleanest implementation code I've seen, and we should all be thankful to Fahlman & Co. for making it available. 3) What is the general theory of destructive operations during lambda list processing (such as by initforms)? For instance, how much structure should be shared by an &rest binding and &key bindings? This would be clearer if you gave an example. If you're thinking of something like (defun disgust (&rest r &key (a (setq r nil)) b) (list a b)) (disgust :b 2) or even worse (defun disgust (&rest r &key (a (setf (second r) nil)) b) (list a b)) (disgust :b 2) I don't think we anticipated that anybody would try this when we were designing the language. I'd be happy to say that each of these is an error. I wasn't able to come up with any problematic examples that didn't involve modifying the &rest argument. Did you have others in mind? How about (defun more-disgusting (a &optional (b (setq a nil))) (list a b)) This is almost plausible (you could save a supplied-p for b), and the CLM doesn't disallow it. Perhaps the spec could be modified to say that initforms may refer to parameters on the left, but not modify them. stan shebs  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Nov 85 22:43:44 EST Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 23 Nov 85 19:33:38 PST Received: by glacier with Sendmail; Sat, 23 Nov 85 19:33:06 pst Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7) id AA28866; Sat, 23 Nov 85 15:40:25 pst Received: by escargot.UUCP (4.12/4.7) id AA13650; Sat, 23 Nov 85 15:38:07 pst Date: Sat, 23 Nov 85 15:38:07 pst From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8511232338.AA13650@escargot.UUCP> To: shebs%utah-orion@utah-cs.ARPA Cc: common-lisp@su-ai.ARPA In-Reply-To: glacier!shebs%utah-orion@utah-cs.arpa's message of Sat, 23 Nov 85 10:13:25 MST Subject: Misc Queries Date: Sat, 23 Nov 85 10:13:25 MST From: glacier!shebs%utah-orion@utah-cs.arpa (Stanley Shebs) While working on PCLS, we've encountered some situations which are probably trivial, but which I don't recall having been brought up: 1) What should (export nil) do? The CLM says that the first argument is either a symbol or list of symbols, but doesn't tell how to handle nil. Personally, I would prefer having nil mean an empty list, but Spice code assumes you want to export the symbol nil. Since (export (nil)) gets you the symbol interpretation, (export nil) should mean (export ()). This should be a general principle: things that take symbols or lists of symbols interpret nil as (). Of course, this an example of how bankrupt having () be a symbol is.  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Nov 85 19:48:02 EST Date: 23 Nov 85 1628 PST From: Dick Gabriel Subject: Minor Typo = Major Faux Pas! To: common-lisp@SU-AI.ARPA Dan mentioned that an existential quantifier was mistyped at some place where a 3 was meant. He meant to say the an existential quantifier was mistyped *every* place a 3 was meant. I think the spot to which he refers is a place where the TTY font for `3' belongs, and that representation of `3' looks exactly like an existential sign. This is because that is the best font Digital Press could come up with. -rpg-