Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Feb 87 00:57:43 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Feb 87 21:41:38 PST Received: by navajo.stanford.edu; Tue, 10 Feb 87 21:40:45 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA09484; Tue, 10 Feb 87 21:15:37 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA09284; Tue, 10 Feb 87 21:20:54 PST Date: Tue, 10 Feb 87 21:20:54 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8702110520.AA09284@bhopal.edsel.com> To: navajo!Cassels%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!Common-Lisp%sail@navajo.stanford.edu In-Reply-To: Robert A. Cassels's message of Tue, 10 Feb 87 10:33 EST Subject: Rational Infinity Re: . . . Since rational arithmetic doesn't overflow, associating rational infinities with IEEE infinities would confuse the distinction between the two IEEE uses of infinity. The only connection I saw for "IEEE" was that it provided both negative and positive infinities. Dan Hoey has provided the best reasoning I've seen so far for subscribing to an affine system; and Larry Masinter made a good case for wanting to separate out the infinity representation from and already-overloaded T and NIL. Re: The user [can] explicitly coerce floating-point numbers to rational, and it could just be an error to coerce an infinity to rational. [That's what we do at Symbolics.] . . . 2. You [may[ want something to do when the user attempts to coerce a floating infinity to rational, other than signal an error. That's a sticky point -- floating infinities do show up under "normal" circumstances, but Nan's don't. Providing a reasonable rational representation for the floating infinities is a necessity when converting back and forth. One can carry the similarities too far; I certainly don't want to hear about the inability to represent negative and positive fixnum zeros (even though IEEE format has them). Long Live twos's-complement arithmetic! -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Feb 87 11:19:51 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Feb 87 07:56:47 PST Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66877; Tue 10-Feb-87 10:32:28 EST Date: Tue, 10 Feb 87 10:33 EST From: Robert A. Cassels Subject: Rational Infinity To: edsel!bhopal!jonl@navajo.stanford.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <8702060633.AA03285@bhopal.edsel.com> Message-ID: <870210103346.3.CASSELS@KRYPTON.SCRC.Symbolics.COM> Date: Thu, 5 Feb 87 22:33:00 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Re: The existence of infinite rational objects and how they come about are two separate issues. . . . Very good point. Re: . . . One of the reasons that rational infinities aren't in Common Lisp yet is that there is some debate about whether rational infinity is affine (signed) or projective (unsigned). Although Common Lisp doesn't require IEEE floating-point capability, I think most people would agree that it's a reasonable goal to reach for. For compability with the infinities available there, one would like to have both +1/0 and -1/0 (I presume we can agree on a canonical form for a rational infinity, that its denominator should be 0 and its numerator's magnitude should be 1 ?) The fact that your floating-point has a representation of infinity doesn't need to imply that rational numbers do. Floating-point gets along just fine by itself. Note that the contagion rules specify that if (IEEE) floating infinity is combined arithmetically with a rational number, the result is floating-point. The user must explicitly coerce floating-point numbers to rational, and it could just be an error to coerce an infinity to rational. [That's what we do at Symbolics.] IEEE floating-point infinities serve two purposes -- to represent the results of overflow, and to represent the results of some "illegal operations" (like 1.0/0.0). That's probably the best reason for not introducing rational infinities. Since rational arithmetic doesn't overflow, associating rational infinities with IEEE infinities would confuse the distinction between the two IEEE uses of infinity. The only reasons I can see for rational infinities are: 1. Some algorithms like to have "infinities" for use in comparisons. 2. You want something to do when the user attempts to coerce a floating infinity to rational, other than signal an error. 3. You really want arithmetic in a rational domain which includes infinity. 1 is an okay reason, but NIL and T can serve almost as well. IEEE infinities can be used just as easily, if you make mixed-mode comparisons do the right thing. [If you blindly coerce to floating-point, you may overflow a large rational value to a floating infinity.] Supposing that you decide that 2 is your reason. Then you also need a way to represent NaNs. I suppose the natural representation is 0/0, but that seems to be going a little far. 3 would be a fine reason, but then you have to deal with the affine/projective question, and you've gotten far away from your original goal. [And farther out on a limb than I'm willing to go.] -- JonL -- - Bob.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Feb 87 14:20:18 EST Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Feb 87 11:04:27 PST Date: 9 Feb 1987 10:33:10 EST (Mon) From: Dan Hoey Subject: Complex infinities To: common-lisp@su-ai.ARPA Cc: edsel!bhopal!jonl@su-navajo.ARPA, Cassels@scrc-STONY-BROOK.ARPA Message-Id: <539883191/hoey@nrl-aic> Date: Fri, 6 Feb 87 19:47:04 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) ...Now, the significant question is what to do about complex infinities. I have some current needs for the two rational infinities -- one of which is to model floating-point exactly -- but I don't have any ideas at all about the complex domain. Do you? Proposal: For complex floating infinities, use z/0 such that |z| = 1. For complex rational infinities, let z have relatively prime integer parts. The format for reading and printing such infinities is #I(r) for real infinities r/0, and #I(r i) for the complex infinities #C(r i)/0. As with rationals, convert to canonical form on input. The name of the function to reconstruct z from z/0 should probably be called something like RATIONAL-SIGNUM. This function (which is useful even without infinities) coincides with SIGNUM except for rational complex arguments, where it returns a complex number with relatively prime integer parts and the same phase as its argument. I am tempted to propose #I(0) as some pseudo-arithmetical object (NAN?) that can be created but not operated on, or which becomes arithmetically contagious under user control. Maybe someone who uses NAN's can tell me whether this is the right way to do them. Date: Wed, 4 Feb 87 09:27 EST From: Robert A. Cassels ...Note that it depends on what sort of calculation you're doing whether infinity is an appropriate answer or not. One of the reasons that rational infinities aren't in Common Lisp yet is that there is some debate about whether rational infinity is affine (signed) or projective (unsigned). I hadn't heard the debate, but I know the answer: ``it depends on what sort of calculation you're doing.'' But you can do projective arithmetic on an affine system (coerce to positive infinity with ABS or some to-be-proposed automagic), whereas there's no way to do affine arithmetic on a projective system. I find this argument more compelling than IEEE compatibility for having the system support the affine case. (Cases like cot(0) where there is no unique affine answer can return the principal affine answer--which turns out to be the projective answer!) With complex numbers there are at least three possible answers (based on the compactification of the plane into a disc (affine), a projective plane (projective, but now there are many infinities), or a sphere (where there is only one infinity)). The affine model I propose above is the most general, and it can be coerced to the one-infinity model with ABS. You can coerce to the projective model with (defun PROJ(z) (if (or (minusp (imagpart z)) (and (zerop (imagpart z)) (minusp (realpart z)))) (- z) z)) for IMAGPART, REALPART, ZEROP, and MINUSP suitably extended to the infinities. Dan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Feb 87 08:02:24 EST Received: from ICST-ECF.ARPA by SAIL.STANFORD.EDU with TCP; 9 Feb 87 04:53:12 PST Date: 9 Feb 87 07:37:00 EST From: "CUGINI, JOHN" Subject: variable/binding terminology To: "common-lisp" Reply-To: "CUGINI, JOHN" > Me: no other language I know of that has > recursion speaks of "different bindings of the same variable" to > explain what's going on with the parameter list of a recursively > invoked function. > > From: Jonathan A Rees > > This usage is consistent with the usage in mathematics, and with Alonzo > Church's terminology in his paper on lambda calculus. To a > mathematician or logician, a variable is a name like "x". A variable > "varies" exactly because it DOES have different bindings at different > times, e.g. at different steps of a recursion. It is computer > scientists who have perverted the sense of the word and use it to mean > what ought to be called a location. whatever... the practical issue is whether the primary audience for a CL standard is going to be logicians or computer scientists, whether perverting or ... oh you know. It seems clear to me that for every logician who nods in approval of this theoretically correct usage, there will be 100 confused computer scientists/programmers, etc. Assuming also that logicians are smarter than computer scientists, both democracy and charity recommend using "normal" programming language lingo. John Cugini ------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 87 01:17:29 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Feb 87 22:04:53 PST Received: ID ; Sun 8 Feb 87 01:04:50-EST Date: Sun, 8 Feb 1987 01:04 EST Message-ID: From: Rob MacLachlan To: "Timothy P. Daly" Cc: common-lisp@SAIL.STANFORD.EDU Subject: defstruct (resent due to lossage) In-reply-to: Msg of 6 Feb 1987 12:08:19 EST from Timothy P. Daly Date: 6 February 1987, 12:08:19 EST From: Timothy P. Daly To: common-lisp at sail.stanford.edu Re: defstruct (resent due to lossage) How can I define data structures that are pairs using defstruct? How can I define data structures that contain pairs? What I want to say is: (defstruct (name (:type cons)) a b) Believe it or not, there are some things you just can't do in Common Lisp; this is one of them. Generally, if CLTL doesn't say that you can do a thing, then it is not possible. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Feb 87 00:30:41 EST Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 7 Feb 87 21:20:27 PST Date: 6 February 1987, 12:08:19 EST From: "Timothy P. Daly" To: common-lisp@sail.stanford.edu Message-Id: <020687.120819.daly@ibm.com> Subject: defstruct (resent due to lossage) How can I define data structures that are pairs using defstruct? How can I define data structures that contain pairs? What I want to say is: (defstruct (name (:type cons)) a b) how can I name subfields? (defstruct name (a :type cons :field-names '(kar kdr))) Tim Daly DALY@IBM.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 87 23:08:18 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Feb 87 19:52:04 PST Date: Sat, 7 Feb 87 22:51:53 EST From: Jonathan A Rees Subject: variables To: cugini@ICST-ECF.ARPA cc: common-lisp@SAIL.STANFORD.EDU In-reply-to: Msg of 4 Feb 87 07:09:00 EST from "CUGINI, JOHN" Message-ID: <150886.870207.JAR@AI.AI.MIT.EDU> Date: 4 Feb 87 07:09:00 EST From: "CUGINI, JOHN" Just frinstance, no other language I know of that has recursion speaks of "different bindings of the same variable" to explain what's going on with the parameter list of a recursively invoked function. The CL terminology conjures up the image of one object with a changeable property, rather than of different objects, each of which is referred to by the same name at different times. This usage is consistent with the usage in mathematics, and with Alonzo Church's terminology in his paper on lambda calculus. To a mathematician or logician, a variable is a name like "x". A variable "varies" exactly because it DOES have different bindings at different times, e.g. at different steps of a recursion. It is computer scientists who have perverted the sense of the word and use it to mean what ought to be called a location.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 23:21:57 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Feb 87 19:58:34 PST Received: by navajo.stanford.edu; Fri, 6 Feb 87 19:57:35 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA00531; Fri, 6 Feb 87 19:41:42 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA05272; Fri, 6 Feb 87 19:47:04 PST Date: Fri, 6 Feb 87 19:47:04 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8702070347.AA05272@bhopal.edsel.com> To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu Cc: navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 6 Feb 87 12:03 PST Subject: Rational infinities Re: b) it is reasonable to want to define an operation as working on, say, integers including +infinity and -infinity, but not arbitrary other ratios. That is, the infinities are more an extension of the integer type than the ratio type. Since we currently have (deftype rational () '(or integer ratio)) then I can't see any benefit to adding a new type that can be compared with integers, but not with ratios; nor can I see any implementational benefit to having separate "integer infinities" and "rational infinities". However, I'm not so much concerned with the implementational details as with the semantics. For example, If rational infinities answer "false" to rationalp, then for symmetry shouldn't we require that floating-point infinities answer "false" to floatp? Of course, "contagion" rules should apply so that floating-point infinities can be compared-with/combined-with rational infinities. I think it's ok if (+ 3/2 <+float-infinity>) answers "true" to floatp; but I don't want (/ 10 0) to give me a floating-point number under any circumstances; and I would prefer that (max 3 <+rational-infinity>) be "rationalp" rather than merely numberp. Now, the significant question is what to do about complex infinities. I have some current needs for the two rational infinities -- one of which is to model floating-point exactly -- but I don't have any ideas at all about the complex domain. Do you? -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 19:57:52 EST Date: 06 Feb 87 1359 PST From: System Files Subject: Re: REMF and REMPROP Received: from AEROSPACE.ARPA by SAIL.STANFORD.EDU with TCP; 6 Feb 87 13:46:58 PST Received: by aerospace.aero.org (5.51/6.0.GT) id AA05166; Fri, 6 Feb 87 12:03:54 PST Posted-Date: Fri, 06 Feb 87 12:03:50 -0800 Message-Id: <8702062003.AA05166@aerospace.aero.org> To: common-lisp@sail.stanford.edu Subject: Re: REMF and REMPROP In-Reply-To: Your message of 06 Feb 87 0659 PST. <8702061737.AA00893@aerospace.aero.org> Date: Fri, 06 Feb 87 12:03:50 -0800 From: coffee@aerospace.aero.org Excuse me, but I was just answering barmar's question -- "Doesn't GET return two values, the second indicating success or failure?" -- in the negative. The quote from Winston was somewhat tongue in cheek, illustrating (1) the extent to which this "Common Lisp" edition is really Common-compatible rather than really teaching Common _per_se_, (2) the relative rarity of the use of the optional DEFAULT argument to GET. Personally, I favor minimizing the cost of property list implementation, leaving people to construct their own A-List structures where a straightforward implementation of P-Lists doesn't leave enough flexibility. This is the only "view" of mine that need be represented, and then only if you care... ;-) Cheers - Pc^2  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 16:11:30 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Feb 87 12:37:51 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 FEB 87 12:02:18 PST Date: 6 Feb 87 12:03 PST From: Masinter.pa@Xerox.COM Subject: rational infinity To: common-lisp@sail.stanford.edu Message-ID: <870206-120218-3664@Xerox> An alternative to JonL's proposal (which encodes rational infinities as 1/0 and -1/0) would be to put the infninity(ies) in a separate class, under number, but not part of rational or ratio or integer. I think this is better than defining infinity using 1/0 or any other encoding because: a) CLtL alludes to such a possibility. b) it is reasonable to want to define an operation as working on, say, integers including +infinity and -infinity, but not arbitrary other ratios. That is, the infinities are more an extension of the integer type than the ratio type. c) it doesn't require modification of definitions which are *not* valid for infinity. For example, you might want to leave +, -, * and / undefined for infinity, but define > >= = /= < <=. d) adding signed infinity in this way doesn't preclude adding a projective unsigned infinity. I claim that the handling of IEEE floating point infinities was a good design for programming languages where variables must be type declared, and that one couldn't have a variable (binding? oops, wrong discussion) which at various times contained floating point numbers and at other times contained NANs. A Lisp embedding of IEEE floating-point which made NaNs a separate class (type) would have the advantage of being able to more simply defining (or not defining) behavior of operations on them.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 14:03:13 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 10:37:40 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47957; Fri 6-Feb-87 13:35:17 EST Date: Fri, 6 Feb 87 13:32 EST From: Daniel L. Weinreb Subject: REMF and REMPROP To: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870206133214.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Fri, 6 Feb 1987 10:36 EST From: "Scott E. Fahlman" I was attempting to give my own view on a reasonable philosophy for handling these things prior to an official clarification: Oh, I see. OK. In cases where it is obvious that most users will have a certain model of how an operation is going to be implemented, it is best not to go against that model. OK, I agree with this. I think the only question is whether it's so obvious what users are modelling or expecting. It's certainly hard to come up with a definitive way of resolving that.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 10:57:46 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Feb 87 07:39:38 PST Received: ID ; Fri 6 Feb 87 10:36:35-EST Date: Fri, 6 Feb 1987 10:36 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: REMF and REMPROP In-reply-to: Msg of 6 Feb 1987 10:01-EST from Daniel L. Weinreb In response to: Daniel L. Weinreb In other words, either we should SPECIFY the behavior of REMF and friends EXPLICITLY as part of the Common Lisp definition, or we should admit that it is UNSPECIFIED, and implementations can do what they want, and users had better be aware of it. I don't see how there can be any middle ground. In other words, we should be quite explicit about what's required and what's not required, and make sure it's stated clearly in the spec. I've got no argument with this. As these issues come up, the best thing to do is to get each one officially clarified, one way or the other. But adopting official clarifications is a slow process -- absurdly slow, unfortunately -- and there will always be some issues that we have not yet clarified. I was attempting to give my own view on a reasonable philosophy for handling these things prior to an official clarification: In cases where it is obvious that most users will have a certain model of how an operation is going to be implemented, it is best not to go against that model. If there is tremendous advantage to be gained by implementing something in an unusual way that has surprising consequences, then it may be worth doing, but in this case the documentation for that implementation should make a big point of explaining what is going on (and still some users will miss that and be screwed, because many of them tend to look only in CLtL). I really don't care what you do in this case, since so few people will be affected, nor do I care which way the issue gets decided when we get around to deciding it. The only reason I responded is that I thought I saw an explicit argument that it is OK to do this very strange thing because the manual does not explicitly forbid it, and that seemed like a dangerous precedent to me. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 10:49:46 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 07:05:53 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47843; Fri 6-Feb-87 10:04:15 EST Date: Fri, 6 Feb 87 10:01 EST From: Daniel L. Weinreb Subject: REMF and REMPROP To: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870206100113.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 5 Feb 1987 14:06 EST From: "Scott E. Fahlman" It's good design philosophy for an implementor not to exploit loopholes in the spec in ways that will screw users. As I said before, in this particular case, any user who gets in trouble was skating too close to the edge anyway, but I still don't think you should set traps for the unwary. That's a strange idea of "good design philosophy". It seems to me that we are trying to write a specification for a portable common subset here. It seems to me that the specification should say one of two things: [1] All implementations of Common Lisp are REQUIRED to obey the following contract. Any implementation that does not follow the contract is in VIOLATION of the definition. Any program written in Common Lisp is FREE to depend on and take advantage of the contract. [2] The following aspect of the operation of this function is NOT REQUIRED. Implementations might choose to have this aspect, or not have this aspect, or work a different way, because this aspect is NOT part of the contract. Any program written in Common Lisp is FORBIDDEN to depend on this aspect, or else it is not portable. You seem to feel there is a third class: [3] The following aspect of the operation of this function, while NOT REQUIRED by the Common Lisp spec, because it doesn't say anything about the aspect one way or another, is REQUIRED anyway because Fahlman deems it to be a "loophole". Any program in Common Lisp is FREE to depend on it, except that they might not run in implementations where nobody was quite sure which things were considered "loopholes" or not. In other words, either we should SPECIFY the behavior of REMF and friends EXPLICITLY as part of the Common Lisp definition, or we should admit that it is UNSPECIFIED, and implementations can do what they want, and users had better be aware of it. I don't see how there can be any middle ground. In other words, we should be quite explicit about what's required and what's not required, and make sure it's stated clearly in the spec. Here, it seems to me that we are discussing a tradeoff. We can (1) make the behavior more specifically defined in terms of the nitty-gritty that it does; Pro: users can depend on that nitty-gritty and still have their programs be portable; Con: implementations are restricted to work that way, even if it degrades performance; or (2) make the behavior be defined more abstractly; Pro: the system has more latitude to implement things more efficiently; Con: the users can only use the function for its abstract purpose, and not take advantage of the way it works inside. Either we decide that the users are too damned close to the ice, they should not be doing those things, and (2) is the way to go, or we decide that this is a trap for the unwary, users have to or want to depend on these internals, and (1) is the way to go. I don't see how we can have it both ways.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 10:20:24 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 06:58:43 PST Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53716; Fri 6-Feb-87 09:53:24 EST Date: Fri, 6 Feb 87 09:53 EST From: David L. Andre Reply-To: DLA@STONY-BROOK.SCRC.Symbolics.COM Subject: REMF and REMPROP To: Margolin@BCO-MULTICS.ARPA, coffee@aerospace.aero.org cc: common-lisp@SU-AI.ARPA, DLA@DIAMOND.S4CC.Symbolics.COM In-Reply-To: <870205203355.967711@BCO-MULTICS.ARPA>, <8702060036.AA20215@aerospace.aero.org>, <870206053142.271474@HIS-PHOENIX-MULTICS.ARPA> Message-ID: <870206095318.9.DLA@LIMPKIN.S4CC.Symbolics.COM> Sigh. Since only Fahlman and Masinter seem to have understood what I said, I'm going to explain it one more time, rather than sending individual explanations to people who didn't understand. I am not advocating changing REMPROP to be equivalent to (SETF (GET SYMBOP PROP) NIL). I am advocating changing the function as follows, in Symbolics Common Lisp: Before: (defun old-remprop (symbol indicator) (let* ((ppl (locf (symbol-plist symbol))) (pl (location-contents ppl))) (loop (when (endp pl) (return nil)) (when (eq (pop pl) indicator) (setf (location-contents ppl) (cdr pl)) (return (return t))) (psetf ppl pl pl (cdr pl))))) After: (defun new-remprop (symbol indicator) (let* ((ppl (locf (symbol-plist symbol))) (pl (location-contents ppl))) (loop (when (endp pl) (return nil)) (when (eq (pop pl) indicator) (setf (location-contents ppl) (cdr pl)) *** Change --> (setf (car pl) nil) (return (return t))) (psetf ppl pl pl (cdr pl))))) (For those of you unfamiliar with Symbolics Common Lisp, LOCF returns a "locative cell" to the place referenced, which can be then set or referenced using LOCATION-CONTENTS. LOCATION-CONTENTS = CDR.) If the symbol-plist is the only pointer to the property list, then the behavior of the new-remprop is NO DIFFERENT from old-remprop. The change merely allows the garbage collector to reclaim the removed property in the case where the plist is not immediately reclaimed. I view this as an important case because many times programmers use REMPROP to "remove pointers to structures no longer referenced". I am writing a formal proposal to CL-Cleanup, and will try to represent the views others have expressed as best I can.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 02:41:06 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 23:05:23 PST Received: by navajo.stanford.edu; Thu, 5 Feb 87 23:02:44 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA18019; Thu, 5 Feb 87 22:38:38 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA03309; Thu, 5 Feb 87 22:42:22 PST Date: Thu, 5 Feb 87 22:42:22 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8702060642.AA03309@bhopal.edsel.com> To: navajo!DLW%ALDERAAN.SCRC.Symbolics.COM@navajo.stanford.edu, navajo!hilfingr%tully.Berkeley.EDU@navajo.stanford.edu Cc: navajo!Common-Lisp%sail@navajo.stanford.edu Subject: Re: Binding terminology There is a sense in which it is easy to confuse the capabilities of the extant "shallow bound" implementations with the semantics implicit and explicit in Lisp 1.5. MIT Professor Joel Moses wrote a paper in 1970 entitled "The Function of FUNCTION in Lisp" in which he exposed some of the mis-conceptions then prevalent. The most common one was that "deep binding" was Lisp 1.5, and "shallow binding" wasn't; in fact, neither of the then-extant models was correct in the Lisp 1.5 sense. The problem lay in the ephemeral nature of the the objects used to hold bindings, rather than in the deep-versus-shallow question. One may over-generalize this criticism to say that there is no functional difference between deep and shallow binding, but only performance consequences. This generalization is incorrect, as the subsequent discussion will show. The terminology in use during the mid-1970's was that the name/value pair in the environment "alist" (Lisp 1.5 model) was a "binding" rather than the creation of a new variable such as Wilensky suggests. It's not entirely confusing to think of the entries in the alist as "value cells". So the alist model of binding permits you to think of having simultaneously many value cells, whereas the shallow-binding model clearly has only one "value cell". The difference is more apparent when you talk about constructing environment objects; in the Lisp 1.5 model, you are pointing at a (shared) alist, whereas the shallow-bound models usually didn't implement this very well, if at all. Not long after Moses' paper appeared, Dan Bobrow at BBN (and others also) developed the "spaghetti stack" model, which was supposed to have exactly the same semantics as the Lisp 1.5 model; indeed, most "spaghetti" implementations seem to weave the alist of Lisp 1.5 into subparts of the stack-frames allocated to run the program. The "deep bound" implementations which I am familiar with today are all variants of the "spaghetti stack" model; so I wouldn't be surprised to see people confusing "deep binding" questions with "environment retention" questions. It is still the case that the extant "shallow bound" models are not as rich at approximating the Lisp 1.5 model. In particlar, there is no way for them to create a "full" funarg -- that is, one that closes over the entire dynamic environment at the time of creation. When the Lisp Machine project first started, I remember Greenblatt coming up with the limited closure idea, whereby the user had to state explicitly which dynamic variables would be "closed over". (If someone else thinks they invented that idea, then maybe they did -- I just remember RG stating it). It was widely recognized then that this did not solve the so-called FUNARG problem; but it was a somewhat useful device. [Considering how well entrenched the use of dynamic variables has been, I was moderately surprised that the Common Lisp community could agree as early as 1983 to flush dynamic closuers of any kind; but Scheme's influence showed how useful lexical-only closuers could be, and they didn't require a "spaghetti stack" for implementation.] In the late 1970's or early 1980's, Henry Baker wrote a paper dealing with shallow binding in MacLisp and "re-rooting", in which he showed how you could still model Lisp variables by storing their "current" value in a "shallow" cell, but have the same semantics as the "spaghetti-stack" implementations. The important observation which he made was that there is an explicit, user-visible construct which must be invoked to change environments; at the time of switching contexts (read: environments), the processor could go around "patching up" all the relevant "shallow" value cells. However, neither the Baker idea nor stack-group switching will work for parallel processors. There is no synchronizing event occuring between two processors, running in two different "environments", which would initiate the re-rooting of the shallow cells. The obvious solution is for each environment to have it's own unique "value cell" for the dynamically-bound variables; this is what deep binding accomplishes. I have heard of an idea about pairing a "process id" cell along with a shallow value cell; the idea being that each process (presumably being run by an independent processor) would validate the "process id" before using the shallow cell; and of course there would be appropriate locks/semaphores to cover the critical periods of update. But I don't believe this works any better than the optimizations currently in use by the deep-binding implementations. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 02:04:22 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 22:40:53 PST Received: by navajo.stanford.edu; Thu, 5 Feb 87 22:38:30 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA17939; Thu, 5 Feb 87 22:29:19 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA03285; Thu, 5 Feb 87 22:33:00 PST Date: Thu, 5 Feb 87 22:33:00 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8702060633.AA03285@bhopal.edsel.com> To: navajo!Cassels%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: Robert A. Cassels's message of Wed, 4 Feb 87 09:27 EST Subject: Rational Infinity Re: The existence of infinite rational objects and how they come about are two separate issues. . . . Very good point. Re: . . . One of the reasons that rational infinities aren't in Common Lisp yet is that there is some debate about whether rational infinity is affine (signed) or projective (unsigned). Although Common Lisp doesn't require IEEE floating-point capability, I think most people would agree that it's a reasonable goal to reach for. For compability with the infinities available there, one would like to have both +1/0 and -1/0 (I presume we can agree on a canonical form for a rational infinity, that its denominator should be 0 and its numerator's magnitude should be 1 ?) -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 87 01:19:53 EST Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 21:52:05 PST Received: FROM HIS-PHOENIX-MULTICS.ARPA BY BCO-MULTICS.ARPA WITH dial; 06 FEB 1987 00:37:40 EST Sender: Barry Margolin Date: Thu, 5 Feb 87 22:31 MST From: Barry Margolin Subject: Re: REMF and REMPROP To: coffee@AEROSPACE.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message of 5 Feb 87 17:36 MST from "coffee at AEROSPACE.AERO.ORG" Message-ID: <870206053142.271474@HIS-PHOENIX-MULTICS.ARPA> Date: 5 February 1987 17:36 mst From: coffee at AEROSPACE.AERO.ORG Subject: Re: REMF and REMPROP From Steele, p.165: "Note that there is no way to distinguish an absent property from one whose value is ." The argument is optional and defaults in turn to nil, so get on an absent property is normally identical in value to get on a property with explicit value nil. Winston & Horn, p.97, shows (setf (get ) nil) as equivalent to remprop "as far as get is concerned...although it is better programming practice to use remprop." Cheers, Pc^2 Since the caller of GET can specify the default value, it would not be valid for REMPROP to set it to NIL. Consider the difference between (REMPROP 'foo :bar) (GET 'foo :bar 'my-default) => my-default and (SETF (GET 'foo :bar) NIL) (GET 'foo :bar 'my-default) => NIL So, while the caller of GET cannot distinguish a missing value from the default value, GET must be able to detect that a property is missing. By the way, here is a function that reliably provides the two-value interface I described: (defun my-get (symbol indicator &aux (default (ncons nil))) (let ((value (get symbol indicator default))) (if (eq value default) (values nil nil) (values value t)))) barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 21:36:15 EST Received: from AEROSPACE.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 18:13:00 PST Received: by aerospace.aero.org (5.51/6.0.GT) id AA20215; Thu, 5 Feb 87 16:36:57 PST Posted-Date: Thu, 05 Feb 87 16:36:51 -0800 Message-Id: <8702060036.AA20215@aerospace.aero.org> To: Barry Margolin Cc: common-lisp@sail.stanford.edu Subject: Re: REMF and REMPROP In-Reply-To: Your message of Thu, 5 Feb 87 15:33 EST. <870205203355.967711@BCO-MULTICS.ARPA> Date: Thu, 05 Feb 87 16:36:51 -0800 From: coffee@aerospace.aero.org From Steele, p.165: "Note that there is no way to distinguish an absent property from one whose value is ." The argument is optional and defaults in turn to nil, so get on an absent property is normally identical in value to get on a property with explicit value nil. Winston & Horn, p.97, shows (setf (get ) nil) as equivalent to remprop "as far as get is concerned...although it is better programming practice to use remprop." Cheers, Pc^2  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 20:22:41 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 17:00:10 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47695; Thu 5-Feb-87 19:58:13 EST Date: Thu, 5 Feb 87 19:55 EST From: Daniel L. Weinreb Subject: Re: Binding terminology To: hilfingr%tully.Berkeley.EDU@BERKELEY.EDU cc: Common-Lisp@sail.stanford.edu In-Reply-To: <8702060024.AA03116@tully> Message-ID: <870205195512.9.DLW@CHICOPEE.SCRC.Symbolics.COM> OK, I buy that. I now revise my statement as follows. Having gotten rid of the mechanism for binding variables to values, you have simply introduced a similar mechanism for binding symbols to variables. Nothing has been gained. Instead of worrying about the current value of the variable, now I must worry about the current variable of the symbol. So while there's no gain in complexity, there's no reduction in complexity either. Parallelism makes the same demand no matter which of the two models you use. Either you have to explain that the value of a variable depends on what process asks the question, or you have to explain why the variable of the symbol depends on which process asks the question. There's still a mapping going on, and it still has to be process-dependent.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 19:54:29 EST Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 16:29:20 PST Received: by ucbvax.Berkeley.EDU (5.53/1.20) id AA18428; Thu, 5 Feb 87 16:24:52 PST Received: by tully (1.1/5.17) id AA03116; Thu, 5 Feb 87 16:24:42 PST Date: Thu, 5 Feb 87 16:24:42 PST From: hilfingr%tully.Berkeley.EDU@BERKELEY.EDU (Paul Hilfinger) Message-Id: <8702060024.AA03116@tully> To: DLW@alderaan.scrc.symbolics.com, Miller.PA@xerox.com, Moon@stony-brook.scrc.symbolics.com, Pavel.pa@xerox.com Subject: Re: Binding terminology Cc: Common-Lisp@sail.stanford.edu Daniel Weinreb writes: "Now, consider the following question: `The body of x is a function-call form that adds two variables. The first variable is a lexical variable named x. Which variable is the second variable referenced by x?" I believe that this question has a single, clear answer. [*a*] always refers to one particular variable, and it's that variable. The alternative view is to say that ... it depends on who is calling foo, and what the environment is at the time.... Simply looking at foo does not tell you what variable foo is talking about. In order to explain Lisp this way, you need to introduce some kind of new concept called an "identifier" ... that is separate from the concept of a "variable", and say that the association from a given identifier to a given variable depends, in some cases, on what conditions prevail at runtime.... Such a philosophy seems pointless. Having gotten "rid" of dyanamic binding of variables to values, you have replaced it with a new concept of identifiers, and a dynamic binding of "identifiers" to "variables". No complexity has been removed, and a new fundmental concept has been added, resulting in a new gain in complexity for no benefit. ----------- This is a really good try at standing the situation on its head, but it doesn't quite make it. (1) Having been told that *a* always means the same variable (and having then discovered what that really means) the questioner's response would then be, "Oh, I meant to ask something else, then: which of the values-that-have-been-assigned-to-*a*-in-such-a-way-that-they-are- currently-available-or-might-be-restored-later does *a* have?" (The long, hyphenated construct is used to avoid introducing a new concept, which some call "binding", since this description of Lisp is not supposed to require introducing a new concept beyond "variable.") To put this all less cutely: TANSTAAFL; if there is only one variable, there have to be several of something else. The number of concepts is NOT reduced by there being just one variable. (2) The "identifier" argument is a bit weak, since Lisp already has a concept of "symbol," which will serve for all but pedants. (3) The argument concerning future extensions for parallelism is, in my mind, a good one. If the same symbol, when not lexically bound always refers to the same "variable" and if the properties of that variable (e.g., its value) do not depend on the environment (but instead are changed by certain program constructs, including setq and let), then you'll have a little difficulty explaining how the same dynamically bound variable (i.e., referenced by the same symbol) can have two different values when simultaneously read by two concurrent processes (and, yes, you certainly DO want to be able to have two concurrent processes simultaneously providing two lambda bindings for the same--in CLtL and Weinreb's terminology--variable.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 19:23:08 EST Date: 05 Feb 87 1223 PST From: System Files Subject: a historical inquiry Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 12:14:12 PST Received: ID ; Thu 5 Feb 87 15:14:10-EST Date: Thu, 5 Feb 1987 15:14 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Gregory Weeks Cc: common-lisp@SAIL.STANFORD.EDU Subject: a historical inquiry In-reply-to: Msg of 5 Feb 1987 13:30-EST from Gregory Weeks Special values (or dynamic scoping, if you prefer) are very useful in some situations. There was never any suggestion that we eliminate them completely, and I don't think there would be today. All of the discussion was about whether Lexical or dynamic scoping should be the default. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 19:15:18 EST Date: 05 Feb 87 1205 PST From: System Files Subject: a historical inquiry Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 11:59:46 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47497; Thu 5-Feb-87 14:58:04 EST Date: Thu, 5 Feb 87 14:54 EST From: Daniel L. Weinreb Subject: a historical inquiry To: hplb29a!hplbgw!weeks@hplabs.HP.COM, common-lisp@SU-AI.ARPA cc: hplbgw!weeks@hplabs.HP.COM In-Reply-To: <8702051830.AA06435@hplbgw> Message-ID: <870205145450.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 5 Feb 87 10:30:25 pst From: Gregory Weeks Could someone tell me what motivated people to include special variables in Common Lisp? (1) They're tremendously useful. Nearly every major Lisp software system I've ever used has used them to great advantage, and would suffer significantly if they were not available. Of course, the vast majority of variables are lexical, but the few dynamic variables play important roles. (2) It was considered important to allow existing software to be converted to Common Lisp in a relatively straightforward fashion. Was there any dispute at the time? No. (In fact, at the time there was some debate about full lexical scoping with upward and downward funargs; some people were dubious about implementation issues.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 19:09:06 EST Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 15:30:03 PST Date: 5 Feb 1987 17:50:05 EST (Thu) From: Dan Hoey Subject: REMF and REMPROP To: common-lisp@su-ai.ARPA Message-Id: <539560403/hoey@nrl-aic> I can't believe that shredding discarded pieces of plists to help garbage collection could serve much of a useful purpose. But it might be very useful in CDR-coded implementations to do REMF by copying the last pair of the property list into the newly-vacated position, and even to secretly remember the empty spaces this leaves after the end of the list for future use by (SETF (GETF...)). This would mean that structure once shared with the plist backbone might be changed fairly surprisingly by REMF or (SETF (GETF...)). I think users who rely on the assumption that system functions are implemented in the most obvious way are in too much trouble for a warning about REMF to help them. There has to be a distinction made between ``exploiting loopholes'' in the standard and taking advantage of the standard's deliberate flexibility. The implied contract of the property list functions has to be spelled out, something like: GETF does not structure. (REMF ...) and (SETF (GETF ...)) modify only and its top-level list structure. It's unfortunate we can't get along without the first sentence, considering what a win it can be to dynamically order property lists. Dan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 17:39:32 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Feb 87 14:15:43 PST Received: from Godot.Think.COM by zarathustra.think.com; Thu, 5 Feb 87 17:14:32 EST Received: from boethius by Godot.Think.COM via CHAOS; Thu, 5 Feb 87 17:14:17 EST Date: Thu, 5 Feb 87 17:15 EST From: Guy Steele Subject: a historical inquiry To: hplb29a!hplbgw!weeks@hplabs.hp.com, common-lisp@sail.stanford.edu Cc: hplbgw!weeks@hplabs.hp.com, gls@Think.COM In-Reply-To: <8702051830.AA06435@hplbgw> Message-Id: <870205171543.3.GLS@BOETHIUS.THINK.COM> Date: Thu, 5 Feb 87 10:30:25 pst From: Gregory Weeks Could someone tell me what motivated people to include special variables in Common Lisp? Was there any dispute at the time? I'm NOT trying to start a discussion; I'm just curious. Given the state of Lisp practice at the time, better yet you should ask "What motivated people to include any kind of variable OTHER than special variables?" (Recall that SCHEME was not nearly as popular then as now, and nearly every other Lisp used only dynamic binding in the interpreter and dynamic and local binding in compiled code.) --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 15:58:24 EST Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 12:34:43 PST Date: Thu, 5 Feb 87 15:33 EST From: Barry Margolin Subject: REMF and REMPROP To: common-lisp@SU-AI.ARPA Message-ID: <870205203355.967711@BCO-MULTICS.ARPA> I don't think it is legal for REMPROP to be equivalent to (SETF (GET SYMBOL PROP) NIL), which seemed to be one of the possibilities mentioned in the original mail. Doesn't GET return a second value indicating whether the indicator was found or not, so that a value of NIL can be distinguished from a NIL used to indicate failer? Or is it only the hashing functions that do this? barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 14:33:00 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 11:05:17 PST Received: ID ; Thu 5 Feb 87 14:06:13-EST Date: Thu, 5 Feb 1987 14:06 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: REMF and REMPROP In-reply-to: Msg of 4 Feb 1987 20:02-EST from David L. Andre In reply to: David L. Andre Destructive operations should do what they are documented to do, and no more. If this is the case, then they should be documented to do something. Consider: I can think of two plausible implementations of REMPROP which "only do their contract". The first one is the zetalisp version which requires that the top-level list be spliced in a specific fashion. The second would be a function which pulled all the elements of the plist after the removed property pair forward, and set the CDR of the tail NIL. I will argue that both of these functions "do what they are documented to do, and no more". However, programs which share property lists would behave differently in the two hypothetical implementations. So my question is, if this is allowed, why can't I wreak my own havoc with the spare conses, which has the same effect? In my view, it isn't allowed, or at least it shouldn't be done this way. If you want to think up bizarre ways of implementing things, argue that these are legal because the book doesn't explicitly forbid them, and then use these things to justify "wreaking havoc" because the book doesn't forbid that either, then I guess your position is defensible, at least. I can't point to any particular sentence in CLtL that says that what you propose to do is illegal. I just think that it violates the reasonable expectations of the users; most will assume that two backbone cells are snipped from the list without any further reordering unless the manual warns them that something more complex might be going on. It's good design philosophy for an implementor not to exploit loopholes in the spec in ways that will screw users. As I said before, in this particular case, any user who gets in trouble was skating too close to the edge anyway, but I still don't think you should set traps for the unwary. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 14:23:38 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:52:12 PST Received: by hplabs.HP.COM ; Thu, 5 Feb 87 10:30:45 pst Received: from hplbgw (hplbgw) by hplb29a ; Thu, 5 Feb 87 10:31:42 pst Received: by hplbgw ; Thu, 5 Feb 87 10:30:25 pst Date: Thu, 5 Feb 87 10:30:25 pst From: Gregory Weeks Message-Id: <8702051830.AA06435@hplbgw> To: common-lisp@su-ai.ARPA Subject: a historical inquiry Cc: hplbgw!weeks@hplabs.HP.COM Could someone tell me what motivated people to include special variables in Common Lisp? Was there any dispute at the time? I'm NOT trying to start a discussion; I'm just curious.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 14:17:46 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:05:58 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52901; Wed 4-Feb-87 12:10:27 EST Date: Wed, 4 Feb 87 12:13 EST From: David C. Plummer Subject: REMF and REMPROP To: Scott E. Fahlman , DLA@QUABBIN.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870204121313.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 4 Feb 1987 11:33 EST From: "Scott E. Fahlman" On the other hand, it seems to me that it violates the (implicit) contract of a destructive operation like REMPROP to take the excised piece of list and chop it up into little pieces or to re-use the list cells that it snipped out. The fact that some built-in operation makes a destructive change does not necessarily give this operation the right, or the necessary global perspective, to decide what is garbage and what is not. Sharing is possible in Common Lisp, and it is the garbage collector's job to decide what cons cells can safely be recycled. Destructive operations should do what they are documented to do, and no more. I can interpret parts of that paragraph two ways. One way (the way I don't want to) is that REMF can go off and bash the value. That's not what Andre was suggesting. He was suggesting only the structure that IS the property list. Here's a more explicit example: (setq *key* '(a b c) *value* '(x y z) *plist* (list :a 'a *key* *value* :c 'c) *subplist* (cddr *plist*) *subsubplist* (cdr *subplist*)) What happens by doing (remf *plist* *key*)? Because REMF is destructive on the PLIST, I think everyone will agree that *plist* => (:a a :c c) I think everyone will also agree that *key* => (a b c) *value* => (x y z) because REMF isn't allowed to bash the key or value. The question is: What are the values of *subplist* and *subsubplist*? Possible answers include: *subplist* ((a b c) (x y z) :c c) ;preserve everything (nil nil :c c) ;drop pointers to the key and value (nil nil) ;drop pointers and bash structure (nil) ;ditto, bashing harder *subsubplist* ((x y z) :c c) (nil :c c) (nil) REMF has not decided what IS garbage, but it has ALLOWED (a b c) and (x y z) to be garbage if there are no other pointers to them.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 13:39:40 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:05:59 PST Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53127; Wed 4-Feb-87 20:03:00 EST Date: Wed, 4 Feb 87 20:02 EST From: David L. Andre Subject: REMF and REMPROP To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SAIL.STANFORD.EDU, DCP@QUABBIN.SCRC.Symbolics.COM, DLA@DIAMOND.S4CC.Symbolics.COM In-Reply-To: , Message-ID: <870204200257.6.DLA@LIMPKIN.S4CC.Symbolics.COM> Date: Wed, 4 Feb 1987 11:33 EST From: "Scott E. Fahlman" I guess this is yet another thing that needs to be clarified. Here are a couple of opinions that may be of use in the meantime: First, it is in the nature of property lists that they get destructively modified, and it is a remarkably bad idea to write code of the sort you describe that shares this top-level list structure. Anyone who writes code that does this should change the code to something sensible and not quibble about what is legal. We agree here. On the other hand, it seems to me that it violates the (implicit) contract of a destructive operation like REMPROP to take the excised piece of list and chop it up into little pieces or to re-use the list cells that it snipped out. The fact that some built-in operation makes a destructive change does not necessarily give this operation the right, or the necessary global perspective, to decide what is garbage and what is not. Sharing is possible in Common Lisp, and it is the garbage collector's job to decide what cons cells can safely be recycled. Destructive operations should do what they are documented to do, and no more. If this is the case, then they should be documented to do something. Consider: I can think of two plausible implementations of REMPROP which "only do their contract". The first one is the zetalisp version which requires that the top-level list be spliced in a specific fashion. The second would be a function which pulled all the elements of the plist after the removed property pair forward, and set the CDR of the tail NIL. I will argue that both of these functions "do what they are documented to do, and no more". However, programs which share property lists would behave differently in the two hypothetical implementations. So my question is, if this is allowed, why can't I wreak my own havoc with the spare conses, which has the same effect?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 13:33:47 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:05:58 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53081; Wed 4-Feb-87 17:32:12 EST Date: Wed, 4 Feb 87 17:34 EST From: David C. Plummer Subject: Re: Rational Infinity To: Richard Fateman , DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@sail.stanford.edu, jbarnett@NRTC.ARPA In-Reply-To: <8702041935.AA28650@renoir.Berkeley.EDU> Message-ID: <870204173457.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 4 Feb 87 11:35:39 PST From: fateman@renoir.Berkeley.EDU (Richard Fateman) there are also complex numbers and complex infinities of both rational and floating-point forms in CL. These must be dealt with. The with-rational-trap-enables ... proposal suggests that trap enabling should have dynamic scope. Do you mean this? Yes, I do mean for them to have dynamic scope. I'd hate to try to write a program that has to put one of these around the lexical scope of each possible division, which may not even be division of ratios. It's like the scope of *read-base*; it affects how the program runs.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 13:19:31 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 09:53:14 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47378; Thu 5-Feb-87 11:39:35 EST Date: Thu, 5 Feb 87 11:36 EST From: Daniel L. Weinreb Subject: Re: Binding terminology To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Pavel.pa@Xerox.COM, Miller.PA@XEROX.COM cc: Common-Lisp@sail.stanford.edu In-Reply-To: <870204221242.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870205113629.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Line-fold: No Date: Wed, 4 Feb 87 22:12 EST From: David A. Moon I don't think you understood what I said. What I said has nothing to do with implementation. Right. I just went through this argument on some other mailing list. It has nothing to do with deep/shallow, which is purely an internal implementation issue. We're talking about language semantics. Consider the following program fragment: (defvar *a*) (defun foo (x) (+ x *a*)) (defun bar-1 () (let ((*a* 5)) (x 4))) (defun bar-2 () (let ((*a* 9)) (x 3))) Now, consider the following question: "The body of x is a function-call form that adds two variables. The first variable is a lexical variable named x. Which variable is the second variable referenced by x?" I believe that this question has a single, clear answer. *x* always refers to one particular variable, and it's that variable. The alternative view is to say that there isn't any answer to the question; it depends on who is calling foo, and what the environment is at the time, and stuff like that. Simply looking at foo does not tell you what variable foo is talking about. In order to explain Lisp this way, you need to introduce some kind of new concept called an "identifier" or something, that is separate from the concept of a "variable", and say that the association from a given identifier to a given variable depends, in some cases, on what conditions prevail at runtime. This mapping from identifiers to variables cannot always be determined lexically, but must be determined dynamically. Such a philosophy seems pointless. Having gotten "rid" of dyanamic binding of variables to values, you have replaced it with a new concept of identifiers, and a dynamic binding of "identifiers" to "variables". No complexity has been removed, and a new fundmental concept has been added, resulting in a new gain in complexity for no benefit.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 11:38:10 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 08:19:43 PST Date: Thu, 5 Feb 1987 11:18 EST Message-ID: From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: common-lisp@SAIL.STANFORD.EDU Subject: Common Lisp LOOP macro A few months back, someone mentioned a public domain Common Lisp version of the (Maclisp/Zetalisp) LOOP macro. Does anyone know where I can get a hold of that? - Stever  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Feb 87 04:53:20 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Feb 87 01:34:27 PST Received: from tektronix.tek.com by csnet-relay.csnet id ao00832; 5 Feb 87 0:54 EST Received: by tektronix.TEK.COM (5.31/6.19) id AA05928; Wed, 4 Feb 87 17:55:40 PST Received: by tekchips.TEK (5.31/6.16) id AA14188; Wed, 4 Feb 87 17:54:27 PST Message-Id: <8702050154.AA14188@tekchips.TEK> To: COMMON-LISP@SU-AI.ARPA Subject: Re: Binding, etc. Date: 04 Feb 87 17:54:26 PST (Wed) From: willc%tekchips.tek.com@RELAY.CS.NET In article <10248@tektronix.TEK.COM> wilensky%larch.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Robert Wilensky) writes: > >Some time ago I sent around a flame on the issue of the ``binding'' >terminology in Common LISP. My contention is that the whole notion of >binding as used in the LISP community is not particularly coherent. This is certainly true of the Common Lisp community. On the other hand, the notion of binding used in the Revised^3 Report on the Algorithmic Language Scheme (1986) is quite coherent. I would warn that the word "variable" is used in even more different senses and is even more confusing than the word "binding". For example, the 1986 Scheme report uses the word "variable" to mean an identifier that denotes a location, while Wilensky uses the word "variable" to mean a location itself. It would also be good to distinguish between identifiers (which occur in code and are typically used as variables in the Scheme sense) and symbols (which occur in data structures and are typically used as enumerated values). Many dialects of Lisp require that identifiers be represented internally as symbols, but Scheme and most other programming languages do not. Peace, William Clinger Tektronix, Inc.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 22:38:28 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 19:15:08 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 62526; Wed 4-Feb-87 22:13:03 EST Date: Wed, 4 Feb 87 22:12 EST From: David A. Moon Subject: Re: Binding terminology To: Pavel.pa@Xerox.COM, Miller.PA@XEROX.COM cc: Common-Lisp@sail.stanford.edu In-Reply-To: <870204-175046-1399@Xerox> Message-ID: <870204221242.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No I hate to bother the whole mailing list with this, but it seems necessary, since I've been mistaken as saying something biased towards shallow binding. I don't think you understood what I said. What I said has nothing to do with implementation. Dynamic variables are changeable because when a dynamic variable is referenced, that reference can refer at different times to name/value associations created at different places in the program. This is more changeable than lexical variables, where a given reference always refers to a name/value association created at the same place in the program.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 22:09:12 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Feb 87 18:43:00 PST Received: from Salvador.ms by ArpaGateway.ms ; 04 FEB 87 18:28:47 PST Date: 4 Feb 87 18:05 PST Sender: Miller.pa@Xerox.COM From: Mark S. Miller.PA Subject: Re: Binding terminology In-reply-to: David A. Moon 's message of Wed, 4 Feb 87 17:29 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: cugini@ICST-ECF.ARPA, common-lisp@sail.stanford.edu, VulcanCore^.pa@Xerox.COM Message-ID: <870204-182847-1431@Xerox> Date: Wed, 4 Feb 87 17:29 EST From: David A. Moon Dynamic variables really are one object with a changeable property. Lexical variables, on the other hand, are separate objects referred to by the same name in separate scopes. Only if your conceptual model corresponds to shallow binding. (sorry for introducing an orthogonal use of "binding" into this discussion) My conceptual model for dynamic variables corresponds to deep binding. In shallow binding, new dynamic bindings (as introducted by LET) assign to a variable and remember to undo this assignment on exit from the LET. In deep binding, LETs introduce new name-variable associations. Specifically, I think of CommonLisp as if it were compiled into a lexically-scoped-only lisp (LexicalLisp) as follows: Every CommonLisp function is compiled into a LexicalLisp function that has an additional parameter: a dynamic naming environment. This is much like compiling a call-return lisp into a call only lisp by introducing an additional continuation parameter. The dynamic naming environment is an object that associates symbols with variables ("variables" in the new suggested meaning). In the absence of any LETs, etc. of special variable names in a function body, all calls in a function would be compiled to pass on the same dynamic naming environment received by this function. What a LET form does is to create a new environment consisting of the old environment + a new contour associating names (symbols) with new variables. This environment is then used within the body of the LET as the current dynamic naming environment. References to special variable names are compiled into requests to the current dynamic naming environment to lookup the variable associated with this name. This model is conceptually simple, you don't have to worry about undoing bindings (or assignments) when you leave dynamic extents (including abnormal exits), there is no problem with introducing parallelism, and we could consistently use the new terminology without guilt. It is also a valid description of what it is that's being implemented by the typical stack lookup implementation of deep binding (such as Interlisp). I suggest that our terminology reflect this model, and that shallow binding only be considered a particular way it can be implemented. ----- MarkM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 17:58:02 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 14:31:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 62349; Wed 4-Feb-87 17:29:53 EST Date: Wed, 4 Feb 87 17:29 EST From: David A. Moon Subject: Binding terminology To: "CUGINI, JOHN" cc: common-lisp In-Reply-To: The message of 4 Feb 87 07:09 EST from "CUGINI, JOHN" Message-ID: <870204172926.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 4 Feb 87 07:09:00 EST From: "CUGINI, JOHN" ....no other language I know of that has recursion speaks of "different bindings of the same variable" to explain what's going on with the parameter list of a recursively invoked function. The CL terminology conjures up the image of one object with a changeable property, rather than of different objects, each of which is referred to by the same name at different times. Part of this is because few other languages have dynamic binding. Dynamic variables really are one object with a changeable property. Lexical variables, on the other hand, are separate objects referred to by the same name in separate scopes.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 16:23:46 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 12:48:07 PST Received: ID ; Wed 4 Feb 87 15:49:05-EST Date: Wed, 4 Feb 1987 15:48 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SAIL.STANFORD.EDU Subject: REMF and REMPROP In-reply-to: Msg of 4 Feb 1987 12:13-EST from David C. Plummer I can interpret parts of that paragraph two ways. One way (the way I don't want to) is that REMF can go off and bash the value. That's not what Andre was suggesting. I don't see how you could read this interpretation into what I said, but it doesn't matter. I think we all agree that it is not legal for REMF or REMPROP to do anything destructive to the keys and values it removes from the property list. What Andre was asking, I thought, was whether it was legal to chop up or recycle the cons cells that had been part of the backbone of the property list. My opinion was that this is not legal -- REMPROP and REMF should do only as much destructive alteration as is necessary to remove the specified key and value from the list. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 15:01:37 EST Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 11:37:06 PST Received: by renoir.Berkeley.EDU (5.57/1.16) id AA28650; Wed, 4 Feb 87 11:35:39 PST Date: Wed, 4 Feb 87 11:35:39 PST From: fateman@renoir.Berkeley.EDU (Richard Fateman) Message-Id: <8702041935.AA28650@renoir.Berkeley.EDU> To: DCP@quabbin.scrc.symbolics.com, common-lisp@sail.stanford.edu, jbarnett@nrtc.arpa Subject: Re: Rational Infinity there are also complex numbers and complex infinities of both rational and floating-point forms in CL. These must be dealt with. The with-rational-trap-enables ... proposal suggests that trap enabling should have dynamic scope. Do you mean this?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 14:34:28 EST Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 4 Feb 87 11:17:57 PST Date: 4 February 1987, 13:08:43 EST From: "Timothy P. Daly" To: common-lisp@sail.stanford.edu Message-Id: <020487.130843.daly@ibm.com> Subject: Subject: defstruct question How can I define data structures that are pairs using defstruct? How can I define data structures that contain pairs? What I want to say is: (defstruct (name (:type cons)) a b) intending to create a thing of the form (name-a . name-b) how can I name subfields? (defstruct name (a :type cons :field-names '(kar kdr))) intending to create a thing like #((name-a-kar . name-a-kdr)) Tim Daly DALY@IBM.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 11:51:01 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 08:31:30 PST Received: ID ; Wed 4 Feb 87 11:33:07-EST Date: Wed, 4 Feb 1987 11:33 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: REMF and REMPROP In-reply-to: Msg of 3 Feb 1987 20:35-EST from David L. Andre In reply to: David L. Andre Both of these are documented by CLtL to "destructively splice the property list" to remove the value. The nature of the destructive splicing is not specified. The question is, is it legal for REMF and REMPROP to remove the pointer to the value (i.e., by setting it to NIL) as part of this operation? I guess this is yet another thing that needs to be clarified. Here are a couple of opinions that may be of use in the meantime: First, it is in the nature of property lists that they get destructively modified, and it is a remarkably bad idea to write code of the sort you describe that shares this top-level list structure. Anyone who writes code that does this should change the code to something sensible and not quibble about what is legal. On the other hand, it seems to me that it violates the (implicit) contract of a destructive operation like REMPROP to take the excised piece of list and chop it up into little pieces or to re-use the list cells that it snipped out. The fact that some built-in operation makes a destructive change does not necessarily give this operation the right, or the necessary global perspective, to decide what is garbage and what is not. Sharing is possible in Common Lisp, and it is the garbage collector's job to decide what cons cells can safely be recycled. Destructive operations should do what they are documented to do, and no more. I grant that CLtL does not explicitly prohibit the kind of operation you are describing, but I submit that this is because it never occurred to us that anyone would want to do such a thing. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 10:43:38 EST Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 07:24:39 PST Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA03385; Wed, 4 Feb 87 10:07:55 EST Date: Wed, 4 Feb 87 10:07:55 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8702041507.AA03385@EMS.MEDIA.MIT.EDU> To: kempf%hplabsc@hplabs.HP.COM Subject: Re: LALR Parser Generator Available? Cc: common-lisp@sail.stanford.edu The good news: I happen to have exactly such a beast. It is essentially an analog of YACC written in portable Common Lisp. Grammar rules may be coded as Lisp sexprs, or through a front end translator providing YACC-like syntax. (The front end is written in itself, naturally.) The bad news: The software is proprietary, owned by a former employer. I'm trying to negotiate an arrangement whereby it could be released. The fact that from time to time someone expresses interest increases the chance it will happen, but I'm afraid the process will take months, not weeks.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 09:59:27 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Feb 87 06:45:40 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52788; Wed 4-Feb-87 09:44:04 EST Date: Wed, 4 Feb 87 09:46 EST From: David C. Plummer Subject: Rational Infinity To: ELIOT%cs.umass.edu@RELAY.CS.NET, Jeff Barnett , common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Feb 87 12:42 EST from ELIOT%cs.umass.edu@RELAY.CS.NET, The message of 3 Feb 87 22:08 EST from Jeff Barnett Message-ID: <870204094650.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> I assume that if this becomes a real proposal, there would be trap-enable equivalents for rational infinities and rational NaNs analogous to IEEE trap enables for overflow, underflow, etc. For example, one possible syntax might be (with-rational-trap-enables ((:divide-by-zero :infinity)) (/ a b)) might return 1/0 or -1/0 silently, while (with-rational-trap-enables ((:divide-by-zero :error)) (/ a b)) would signal an error. In systems that have condition handling and/or proceed options, the program and/or user could decide to use +-1/0 if that seemed like a good thing to do at the time. Once generated (i.e., in the dataflow of the program), rational infinities don't cause further traps unless you divide two infinities or multiply an infinity by 0. For example, (sqrt 1/0) would return 1/0, (* 1/0 positive-number) would return 1/0, etc.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 09:37:01 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 06:27:18 PST Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61678; Wed 4-Feb-87 09:26:11 EST Date: Wed, 4 Feb 87 09:27 EST From: Robert A. Cassels Subject: Rational Infinity To: ELIOT%cs.umass.edu@RELAY.CS.NET, common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Feb 87 12:42 EST from ELIOT%cs.umass.edu@RELAY.CS.NET Message-ID: <870204092720.8.CASSELS@KRYPTON.SCRC.Symbolics.COM> Date: Tue, 3 Feb 87 13:42 EDT From: ELIOT%cs.umass.edu@RELAY.CS.NET Division by zero should signal an error whenever possible. Defining it to silently return something would make debugging numerical code more difficult. I have found some very obscure bugs as a result of division by zero traps. The existence of infinite rational objects and how they come about are two separate issues. If there were a Common Lisp error system, you would want something like: - Division by zero signals an error. (Note that 0/0 is different from non-zero/0.) - The user has an option when the error is signalled (in the non-zero/0 case) to use an "infinite" result. - There is a form which turns off such error signalling within its body, so that infinities are produced for division by zero, without user intervention. - There is a way for the programmer or user to explicitly enter an infinite object into the system (by typing it). - When an infinite object appears in a computation, the "mathematically correct" thing happens. [The IEEE floating-point rules are one possible definition of "correct".] So infinities only appear under explicit programmer or user control. Thus you get the best of both trapping and non-trapping worlds. The Symbolics system handles IEEE floating-point divide-by-zero this way. [Hard-core IEEE standards fanatics will point out that the default is supposed to be that division doesn't trap, but just quietly returns an infinity. We chose to make trapping be the default for all exceptions except inexact-result.] Note that it depends on what sort of calculation you're doing whether infinity is an appropriate answer or not. One of the reasons that rational infinities aren't in Common Lisp yet is that there is some debate about whether rational infinity is affine (signed) or projective (unsigned).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Feb 87 07:37:41 EST Received: from ICST-ECF.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 04:28:58 PST Date: 4 Feb 87 07:09:00 EST From: "CUGINI, JOHN" Subject: Binding terminology To: "common-lisp" Reply-To: "CUGINI, JOHN" > From: wilensky%larch.Berkeley.EDU@BERKELEY.EDU (Robert Wilensky) > > Some time ago I sent around a flame on the issue of the ``binding'' > terminology in Common LISP. My contention is that the whole notion of > binding as used in the LISP community is not particularly coherent. The > best solution to the many problems is to eliminate this usage altogether. > While this may seem radical at first, I believe it is the only consistent > solution, and the result is actually quite simple.... I'd like to add my hearty agreement with this proposal. I distinctly remember muttering "what the hell are they talking about?" when I first tried to understand scoping, binding, variables, etc by reading CLtL (of course NOW I understand perfectly...). There's no reason why CL should adopt a peculiar terminology to explain concepts for which accepted terms already exist in other languages. Just frinstance, no other language I know of that has recursion speaks of "different bindings of the same variable" to explain what's going on with the parameter list of a recursively invoked function. The CL terminology conjures up the image of one object with a changeable property, rather than of different objects, each of which is referred to by the same name at different times. Whether this is worth the implied documentation overhaul is a matter of judgment. I would say that at least if the "fix-up CLtL" subcommittee is going to do a more or less complete re-write, then we should fold this in. John Cugini ------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 87 22:24:09 EST Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 3 Feb 87 19:08:42 PST Date: Tue, 3 Feb 87 19:08:31 PST From: Jeff Barnett To: ELIOT%cs.umass.edu@relay.cs.NET cc: common-lisp@sail.stanford.EDU Subject: Re: Rational Infinity I think it is very interesting that you find that traping division by zero helps find some very obscure bugs. It's probably also true that you think it is easier to prove and disprove various things about your programs via an appeal to formal mathematical models of numbers. Why this is interesting is that in the old days, I made the same comments when LISP systems quit traping when we took CAR and CDR of NIL! When they did, it helped me find obscure bugs and I was able to prove and disprove things about my programs via an appeal to formal mathematical models of S-EXPRESSIONS. I gave up this line of argument because nobody would listen and I got old an lazy a came out of the closet and had to admit I liked using what I still consider to be an atrocious hack. About floating point infinity and IEEE standards, I must admit that it's a great thing. I think that it would be sad to not make them part of the CL standard--if you think standards are a reasonable venture, they why not include a very good (and very well thought out) one in another. Let me change the word sad to foolish. Numerical calculations that must deal with ideal points are hard to code period. There is no similarity in code that uses IEEE standard and that which doesn't. If its available, it's too good to not use. Insisting on the standard would force some implementors to do extra work I know. But I think it would be a good idea. One of the nice things about LISP and its derivitives is that it makes it easy and possible to code our ideas and models rather than do everything by total hackery. Hell, even a poor man can pretend to be a scholar instead of a code jockey. If you don't think the IEEE standard solves an important problem, try coding some floating point computations and, before you do each operation, determine (1) if this operation will over (underflow) the size of this machines representation and (2) if any previous operation ran into trouble, what to do in lieu of this one. I think one iteration of this will make you kiss the IEEE standards with ideal points. For the record, my coding experience using hardware or software where it was available has convinced that it reduces the coding by a factor of 20 in routines where I cared about these things. Jeff  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 87 20:46:46 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 3 Feb 87 17:37:12 PST Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52704; Tue 3-Feb-87 20:35:37 EST Date: Tue, 3 Feb 87 20:35 EST From: David L. Andre Subject: REMF and REMPROP To: common-lisp@SU-AI.ARPA cc: DLA@DIAMOND.S4CC.Symbolics.COM Message-ID: <870203203541.8.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM> I would like some clarification on the definition of REMF and REMPROP. Both of these are documented by CLtL to "destructively splice the property list" to remove the value. The nature of the destructive splicing is not specified. The question is, is it legal for REMF and REMPROP to remove the pointer to the value (i.e., by setting it to NIL) as part of this operation? This is advantageous to some garbage-collection schemes, which have an easier time collecting the value pointed to if it is indeed garbage after the REMPROP. The disadvantage is that the behavior of REMPROP would be undefined when property lists are shared. For example, consider the following sequence: (SETQ *FOO* (LIST :A '(A GARBAGE) :B '(B GARBAGE))) (SETQ *ORIGINAL-FOO* *FOO*) (REMF *FOO* :A) *FOO* *ORIGINAL-FOO* One might expect the last form to return (:A (A GARBAGE) :B (B GARBAGE)), whereas if REMF is allowed to bash the pointer to assist garbage collection, the last form would return (:A NIL :B (B GARBAGE)). Alternatively, would it be legal for REMF to pull the indicators and values to the front of the list? In that case, *ORIGINAL-FOO* would end up equal to (:B (B GARBAGE)).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 87 17:07:00 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Feb 87 13:51:10 PST Received: from cs.umass.edu by csnet-relay.csnet id ax05944; 3 Feb 87 15:21 EST Date: Tue, 3 Feb 87 13:42 EDT From: ELIOT%cs.umass.edu@RELAY.CS.NET To: common-lisp@SU-AI.ARPA Subject: Rational Infinity X-VMS-To: CSNET%"common-lisp@su-ai.arpa" Division by zero should signal an error whenever possible. Defining it to silently return something would make debugging numerical code more difficult. I have found some very obscure bugs as a result of division by zero traps.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 87 16:00:54 EST Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 3 Feb 87 12:29:39 PST Received: by ucbvax.Berkeley.EDU (5.53/1.20) id AA27352; Tue, 3 Feb 87 11:04:25 PST Received: by larch (3.2/5.17) id AA16334; Tue, 3 Feb 87 11:02:35 PST Date: Tue, 3 Feb 87 11:02:35 PST From: wilensky%larch.Berkeley.EDU@BERKELEY.EDU (Robert Wilensky) Message-Id: <8702031902.AA16334@larch> To: Pavel.pa@xerox.com, Moon@stony-brook.scrc.symbolics.com Subject: Binding, etc. Cc: Common-Lisp@sail.stanford.edu (I sent this a while ago, but I believe the mail system ate it. Apologies in advance if you received it already). Some time ago I sent around a flame on the issue of the ``binding'' terminology in Common LISP. My contention is that the whole notion of binding as used in the LISP community is not particularly coherent. The best solution to the many problems is to eliminate this usage altogether. While this may seem radical at first, I believe it is the only consistent solution, and the result is actually quite simple. Basically, the gripe is that the usage of the terms ``binding'', ``bound'', ``bind'', etc. confuse implementation issues with semantic issues (more on this below). My proposal is to say that applying a lambda, etc. causes a new VARIABLE to be created corresponding to each formal parameter (as opposed to a new binding for a variable). It also happens to ASSIGN a value to that variable. In general, variables may or may not have assignments, and SETQ changes assignments. Rather than talk about bindings, etc., we now talk about how occurrences of symbols refer to variables. For example, there is no longer a notion of a ``free variable'', but merely a free occurrence of a symbol. The rules about special variables are rules about which variable a free occurrence of a symbol refers to. Similarly, using a symbol at the top level to refer to a variable refers to the global variable associated with that symbol. Note that the only change in Common LISP (other than the documentation) that needs to be changed to accommodate my proposal to rename some misnamed functions. For example, ``boundp'' (which has nothing whatsoever to do with bindings, under any interpretation) should be called ``assignp''; ``makunbound'' becomes ``makunassigned'' (or, even more daringly, ``make-unassigned''). There are a few others... I wrote Common LISPcraft using this terminology, and I believe it worked very well. Here's a copy of my old flame, fyi: ---------------------------------------- There appears to be considerable terminological confusion in Commmon LISP. Here are two examples: (1) The use of the terms ``binding'', ``bound'' and ``unbound''. On p. 55 we are told variable can be ``assigned to, as by `setq' or bound, as by `let'. '' However, a binding is defined as a particular parameter instance (p. 36). Moreover, a special variable (and only a special variable) can be ``unbound''. It is also rather hard to avoid saying that a special variable is ``bound'' when it has a value, as ``boundp'' will return true in this case. Unfortunately, these meanings are in conflict. For example, they allow for the case in which a variable is ``bound'' but has no ``binding'' (namely, when the reference is to the global value); the variable can be ``unbound'', but have a binding (as you point out, when it is ``bound'', but valueless.) If you simply refuse to say that a variable without any bindings is bound (even though ``boundp'' of it is true), you are then committed to saying that it is not `bound'', not ``unbound'', and has no ``binding'' (although, of course, it has a perfectly fine and accessible value). In addition, a ``bound variable'' appears to mean a variable that currently has a binding (as in, ``a variable bound by `let' ''), although, of course, such a bound variable may very well be ``unbound''. In addition, there appears to be confusion as to whether a variable or a binding is something that is referenced, etc. For example, p. 37 talks about the scope and extent of special bindings, whereas p. 38 talks about the scope and extent of special variables. it is unclear what a reference to a variable that happens to be a parameter might be, other than a reference to its current binding, since this is an fact the particular instance of that paramater that is in force. For example, p. 55 talks about ``the reference ... to the variable specified by the binding''. It is not clear how a particular instance of a parameter can specify a variable. Nor would this seem desirable. If two different invocations of the same function are considered to have the same variables but with different bindings, then one would not want to reference any variable, but rather, the current bindings of those variables. I could go on, but I think you get the point. Here are some suggestions: Drop the notion of binding altogether. I think this is really an old implementation artifact. Instead, say that every APPLICATION of a lambda form creates new variables for its formal parameters. Also, every symbol has a global variable associated with it. A variable may have a value, or it may be valueless. A variable has an extent and a scope. Introduce the function ``assignedp'', which meets the current description of ``boundp''. ``setq'' changes the value of a variable through ``assignment''. Lambda application creates a new variable and assigns it a value. (2) Special Form Terminology A special form is defined as a form beginning with one of the symbols appearing in Table 5-1. However, p. 57 states that ``The set of special forms is fixed in Common LISP'' and that ``The set of special forms in Common LISP is purposely kept very small''. Of course, these claims are both false. There are an infinite number of special forms in Common LISP. What is finite and small is the set of symbols that designate special forms. These are referred to in Table 5-1 as the ``names'' of special forms. Ugh. I propose the following terminology: Leave the definition of special forms alone. Call the objects referred to by the symbols that designate special forms ``special functions''. Call the objects referred to by symbols that invoke macro definitions ``macro functions''. Call everything else a ``normal'' function. These are the unmarked case, analogous to the lack of a compelling name for non-``special'' variables. This terminology appears to be consistent with ``symbol-function'', which may return something ``representing a special form (sic) or macro.''  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 87 02:14:41 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Feb 87 22:58:49 PST Received: by navajo.stanford.edu; Mon, 2 Feb 87 22:57:36 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA07923; Mon, 2 Feb 87 22:31:25 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA06863; Mon, 2 Feb 87 22:34:55 PST Date: Mon, 2 Feb 87 22:34:55 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8702030634.AA06863@bhopal.edsel.com> To: navajo!Common-Lisp%sail@navajo.stanford.edu Cc: bhopal!jonl@navajo.stanford.edu Subject: Rational Infinities Some CL implementations don't use IEEE floating point, and typically don't have any way to represent floating-point infinity. Would there be any negative consequences of allowing forms like 1/0 and -1/0 to be legitimate ratios? -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 87 21:58:52 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Feb 87 18:35:30 PST Received: ID ; Mon 2 Feb 87 21:36:27-EST Date: Mon, 2 Feb 1987 21:36 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: Just to clarify... The fact that I forwarded Scott Safier's suggestion didn't imply that I was endorsing it. In fact, I tend to agree with Skef on this: these functions already have too many arguments, and if you need temporary package rebinding, that is easily accomplished with a user-defined macro. For the record, it is legitimate to rasie new issues directly on the Common Lisp bboard. I long ago gave up the attempt to focus this forum on a small number of issues. But please bear in mind that mail sent to Common Lisp goes to a *LOT* of people, so think about your message before you send it. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 87 21:07:43 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 2 Feb 87 17:43:36 PST Received: from hplabsc by hplabs.HP.COM ; Mon, 2 Feb 87 08:13:51 pst Received: by hplabsc ; Mon, 2 Feb 87 08:10:41 pst Date: Mon, 2 Feb 87 08:10:41 pst From: Jim Kempf Message-Id: <8702021610.AA24275@hplabsc> To: common-lisp@sail.stanford.edu Subject: LALR Parser Generator Available? Is anyone aware of a LALR parser generator written in Common Lisp which is available? Public domain or university software with source is preferred, but information about products would also be appreciated. Please reply via mail (kempf@hplabs.hp.com), and apologies in advance if this mailing list is not deemed appropriate for such requests. Thanks. Jim Kempf kempf@hplabs.hp.com PS: I am aware of the SLR parser generator written in PCLS (Portable Common Lisp Subset) from Utah.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 87 15:01:06 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 2 Feb 87 11:36:20 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA27773; Mon, 2 Feb 87 12:38:02 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA13219; Mon, 2 Feb 87 12:37:58 MST Date: Mon, 2 Feb 87 12:37:58 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8702021937.AA13219@utah-orion.ARPA> To: common-lisp@sail.stanford.edu Subject: Re: Parse as General Case of Read I second the motion to have a parse function that takes a bunch of keywords... PARSE &key :stream :eof-error-p :eof-value :recursive :preserve-whitespace :delimited :float-format :base :suppress :readtable Easy to implement for existing systems, very clean for new systems, and is consistent with WRITE. If PARSE is objectionable due to excessive numbers of keywords, then so is WRITE... stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Feb 87 12:48:21 EST Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Feb 87 09:35:02 PST Received: from Godot.Think.COM by zarathustra.think.com; Mon, 2 Feb 87 12:35:00 EST Received: from blink by Godot.Think.COM via CHAOS; Mon, 2 Feb 87 12:34:53 EST Date: Mon, 2 Feb 87 12:36 EST From: Skef Wholey Subject: [SAFIER%cgi.csnet: proposed modification to common lisp] To: common-lisp@sail.stanford.edu In-Reply-To: Message-Id: <870202123603.1.SKEF@BLINK.THINK.COM> From: Scott Re: proposed modification to common lisp Proposal: the following functions be modified to include a parameter which specifies a package: read, read-delimited-list, read-preserving-white-space This additional parameter could either be a keyword argument, or an optional argument. If the package is not specified, the current package (*package*) will be used as the default. [...] Also, it is burdensome for the common lisp programmar to create a local lexical environment around input functions, simply to insure that any symbols created during input are interned in the proper package. A package argument for these input functions removes this burden. [...] Three reactions: 1. These functions already have a just-barely managable number of optional parameters, and adding another would push them over the edge. 2. Converting them to use all keyword args might have been a good idea three or four years ago, but isn't feasible now. 3. This functionality can be easily implemented at user level, with a few macros. By the way, Read-From-String probably belongs in the list above. It already takes both optional and keyword arguments, so extending it along with the others complicates (or simplifies, depending on how you look at it) the situation a bit. But how about this: introduce a new function, Parse, which is to Read as Write is to Print -- a big fancy general-purpose I/O function that takes all imaginable keyword arguments and Does The Right Thing. Whether or not it would preserve whitespace would be one argument. We could either leave Read-Delimited-List out of this, or add Parse-Delimited-List as well. --Skef  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Feb 87 19:10:00 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 1 Feb 87 15:57:29 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51692; Sun 1-Feb-87 18:55:22 EST Date: Sun, 1 Feb 87 18:54 EST From: David C. Plummer Subject: Destructuring and &whole To: Stanley T. Shebs , Hvatum@MIT-MULTICS.ARPA, common-lisp@sail.stanford.edu In-Reply-To: <8701301637.AA10271@utah-orion.ARPA>, <870130135555.226863@MIT-MULTICS.ARPA> Message-ID: <870201185415.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Sigh. My example was not an attempt to say "&whole might be used for detecting failed attempts at destructing." I don't know if that is how people read my message, or how people read a reply to that message. In any case, that's not what I meant. There are at least two uses for non-top-level &whole that I can envision: (1) To get a handle on the entire form for reporting purposes. The destructuring may have succeeded (syntax) but the form may be in error (semantics). The error reporter may want to show the entire form that failed. My example tried to show that, but I failed to articulate it. (2) To get a handle on the entire form because you want the entire form. The destructuring is an error checking mechanism (syntax), which should signal an error (the closest CLtL appears to come is top of pg151 in saying the construct is "in" error), as well as giving you a parsed form of parts of the form for (semantic) checking. "That's just an example, ..." etc. What is the cost of stipulating that &WHOLE should work at non-top level vs the cost of dearly wanting it (after all, there is no LISP:DESTRUCTURING-BIND) and not having it?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Jan 87 16:00:09 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jan 87 12:43:52 PST Received: ID ; Sat 31 Jan 87 15:44:32-EST Date: Sat, 31 Jan 1987 15:44 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: [SAFIER%cgi.csnet: proposed modification to common lisp] Date: Sat, 31 Jan 87 14:25 ??? From: Scott To: fahlman Re: proposed modification to common lisp Proposal: the following functions be modified to include a parameter which specifies a package: read, read-delimited-list, read-preserving-white-space This additional parameter could either be a keyword argument, or an optional argument. If the package is not specified, the current package (*package*) will be used as the default. Each of these three input functions can have the effect of creating symbols. All other common lisp functions which create symbols (intern, gentemp) have an optional package argument. It is inconsistent for some functions which create symbols to have a package argument, and others not. Also, it is burdensome for the common lisp programmar to create a local lexical environment around input functions, simply to insure that any symbols created during input are interned in the proper package. A package argument for these input functions removes this burden. This change is upward compatible. Current programs which rebind *package* during input will behave exactly as before. -Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jan 87 16:56:23 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jan 87 13:36:56 PST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 26957; 30 Jan 87 16:38:13-EST Received: from WHITBY.PALLADIAN.COM by JASPER.PALLADIAN.COM via INTERNET with SMTP id 26305; 30 Jan 87 16:19:51-EST Date: Fri, 30 Jan 87 16:19 EST From: Don Morrison Subject: *terminal-io* or *standard-output*? To: common-lisp@sail.arpa Message-ID: <870130161914.9.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison CLtL, page 382, refering to the output-stream argument for write and friends: "If it is t, the value of the variable *terminal-io* is used." Page 386, referring to format: "If destination is t, the output is sent to the stream that is the value of the variable *standard-output*" Is this asymmetry intentional, and if so, why? - Ben Hyde Don Morrison  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jan 87 16:22:12 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 13:02:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 58687; Fri 30-Jan-87 16:00:53 EST Date: Fri, 30 Jan 87 16:00 EST From: David A. Moon Subject: MAKUNBOUND vs. special binding To: Jonathan A Rees cc: Common-Lisp@SAIL.STANFORD.EDU, Pavel.pa@XEROX.COM In-Reply-To: <146816.870130.JAR@AI.AI.MIT.EDU> Message-ID: <870130160053.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Fri, 30 Jan 87 12:21:21 EST From: Jonathan A Rees (1) A variable is bound to a value when evaluating that variable produces that value, and is unbound when evaluating that variable is an error. (2) A special variable is bound when its value has been saved upon entry to a dynamic extent, and will be restored upon exit. Just for the record, MIT Scheme solves this terminology problem by using the terms "bound" and "unassigned". "Unbound" refers more or less to (2) and "unassigned" to (1). This sounds quite good to me. The only problem for Common Lisp is that all uses of "bind" (actually "bound") in function names (as opposed to text of the manual) are meaning (1). We just can't win.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jan 87 12:39:38 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jan 87 09:21:07 PST Date: Fri, 30 Jan 87 12:21:21 EST From: Jonathan A Rees Subject: MAKUNBOUND vs. special binding To: Moon@SCRC-STONY-BROOK.ARPA cc: Common-Lisp@SAIL.STANFORD.EDU, Pavel.pa@XEROX.COM In-reply-to: Msg of Thu 29 Jan 87 23:09 EST from David A. Moon Message-ID: <146816.870130.JAR@AI.AI.MIT.EDU> Date: Thu, 29 Jan 87 23:09 EST From: David A. Moon I believe the problem here is just the unfortunate use of the word "bind" to mean two different things. (1) A variable is bound to a value when evaluating that variable produces that value, and is unbound when evaluating that variable is an error. (2) A special variable is bound when its value has been saved upon entry to a dynamic extent, and will be restored upon exit. This poor use of English seems to date back to the earliest days of Lisp, as far as I can tell, but maybe it's time to deep-six it. Just for the record, MIT Scheme solves this terminology problem by using the terms "bound" and "unassigned". "Unbound" refers more or less to (2) and "unassigned" to (1). This works out pretty well. The equivalent of MAKUNBOUND is a primitive which makes a variable become unassigned, and it has a semantics similar to SETQ. There isn't any primitive to make a variable become unbound once it is bound, although in principle there could be. Jonathan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jan 87 11:58:51 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 08:35:59 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA25397; Fri, 30 Jan 87 09:37:36 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA10271; Fri, 30 Jan 87 09:37:33 MST Date: Fri, 30 Jan 87 09:37:33 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8701301637.AA10271@utah-orion.ARPA> To: common-lisp@sail.stanford.edu Subject: Destructuring and &whole The point has been made that &whole might be used for detecting failed attempts at destructuring, but has been countered by the observation that the CL standard doesn't say anything about what happens if destructuring doesn't work. This greatly limits the usefulness of destructuring - persons writing robust code must do all the dissection by hand. (This situation also comes up in functional languages, whose proponents frequently boast of the destructuring capability inherent in function calls, but who shrug if a program fails utterly because of an argument mismatch.) I see several choices, listed in order of difficulty: 1. Flip a coin to decide whether &whole can appear in several places or not, change nothing else. 2. Specify some sort of behavior for anomalous situations during dissection, perhaps no more than a condition to be handled by the error system. 3. Augment destructuring syntax to allow for several possibilities to be tried in order. For instance, the two forms of defsetf could be decided upon, based only on multiple patterns in the parameter list! I favor the last, but it's probably not politically feasible :-). Perhaps for EuLisp... stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jan 87 10:39:20 EST Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 07:16:27 PST Date: Fri, 30 Jan 87 08:55 EST From: Hvatum@MIT-MULTICS.ARPA Subject: &whole cum destructuring To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870130135555.226863@MIT-MULTICS.ARPA> From: Steve Bacher (C.S.Draper Lab) In-reply-to: David C. Plummer > (defmacro with-open-file ((&whole stuff var filename &rest keys) > &body body) > ... > (warn "The first form of with-open-file, ~S, is malformed." stuff) > ...) How useful is this really? It depends on how destructuring is implemented. The following cases are possible, given passing a badly formed argument (e.g. a symbol FOO) as arg 1 to with-open-file: (1) The prologue code that destructures the argument attempts to destructure FOO and blows up (or causes an error trap). (2) The prologue code that destructures the argument detects the invalid actual parameter and signals an error, something like "Error: Unable to destructure FOO into (var filename &rest keys) in macro WITH-OPEN-FILE" (3) The prologue code that destructures the argument detects the invalid actual parameter and assigns some default value to var, filename, and keys. In (1) and (2), the macro expansion function will never get control in order to tell the user anything about the value of the &whole argument. In (3), it might not be possible to tell that there is a problem (except by inspecting the &whole arg, in which case you can just follow it up with a destructuring LET). I know what you'll say: "That's just an example, there are other applications", etc. True, but it seems to me that in most cases you'll never make it that far in your code unless the value passed was successfully destructured, and in that case you can easily "de-destructure" it if you want. I think that the meaning of &whole at other than "top-level" in a DEFMACRO lambda list is questionable. I prefer to see nested destructuring lambda lists as equivalent to "normal" lambda lists (i.e. without the special DEFMACRO hair). Presumably the lambda list that DEFMACRO sees at top level gets hacked up into a "true" lambda list internally, and only the DEFMACRO expander itself knows about &whole and &env. At least that's one possible implementation/interpretation. - SEB   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 87 23:31:19 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jan 87 20:11:04 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 58020; Thu 29-Jan-87 23:09:48 EST Date: Thu, 29 Jan 87 23:09 EST From: David A. Moon Subject: MAKUNBOUND vs. special binding To: Pavel.pa@Xerox.COM cc: Common-Lisp@SAIL.Stanford.EDU In-Reply-To: <870129-194150-1540@Xerox> Message-ID: <870129230927.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No I believe the problem here is just the unfortunate use of the word "bind" to mean two different things. (1) A variable is bound to a value when evaluating that variable produces that value, and is unbound when evaluating that variable is an error. (2) A special variable is bound when its value has been saved upon entry to a dynamic extent, and will be restored upon exit. This poor use of English seems to date back to the earliest days of Lisp, as far as I can tell, but maybe it's time to deep-six it. MAKUNBOUND refers to definition 1. Thus the answer to your question is the innermost binding (definition 1) is undone, while the innermost binding (definition 2) remains unaffected.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 87 22:58:13 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Jan 87 19:41:32 PST Received: from Cabernet.ms by ArpaGateway.ms ; 29 JAN 87 19:41:50 PST Date: 29 Jan 87 19:41 PST From: Pavel.pa@Xerox.COM Subject: MAKUNBOUND vs. special binding To: Common-Lisp@SAIL.Stanford.EDU Message-ID: <870129-194150-1540@Xerox> The description of the function MAKUNBOUND is as follows: MAKUNBOUND causes the dynamic (special) variable named by "symbol" to become unbound (have no value). I'm not sure I understand what this means in certain circumstances. Consider the following program: (defvar *foo* 17) (defun foo () (test-it) ; First (let ((*foo* 18)) (bar) (test-it)) ; Fourth (test-it)) ; Fifth (defun bar () (test-it) ; Second (let ((*foo* 19)) (baz) (test-it))) ; Third (defun baz () (makunbound '*foo*)) (defun test-it () (format t "~S " (not (null (boundp '*foo*))))) (foo) What should this print? At the time the makunbound is performed, there are three bindings of *foo*. 1) Are all of them destroyed? That is, should this print out T T NIL NIL NIL? 2) Or is only the innermost binding undone (T T NIL T T)? 3) Alternatively, perhaps it should simply make the innermost binding invisible, so that this would print T T T T T... Should the function have different effects in deep-bound implementations from shallow-bound ones? I would greatly prefer that it were "an error" to MAKUNBOUND any symbol that had a binding other than the one at top level. Otherwise, you can get into this nonsensical situation where a variable is unbound in one function but somehow becomes bound again when you return from that function, as is the case in the second of my proposed answers. It should be noted that Lucid, VaxLisp, and CLisp all print T T NIL T T. Ugh. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 87 16:11:00 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 29 Jan 87 12:44:18 PST Received: from PENG.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50948; Thu 29-Jan-87 15:41:00 EST Date: Thu, 29 Jan 87 15:40 EST From: susan watkins Subject: please add me to common-lisp mailing list To: common-lisp@sail.stanford.edu Message-ID: <870129154045.4.CHAOWATKINS@PENG.S4CC.Symbolics.COM> my arpa net address is: frawley@scrc-stony-brook.arpa thanks.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jan 87 16:05:19 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87 12:44:07 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 15:41-EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 26744; 29 Jan 87 15:43:58-EST Received: from KITTYHAWK.PALLADIAN.COM by JASPER.PALLADIAN.COM via INTERNET with SMTP id 26129; 29 Jan 87 01:12:23-EST Date: Thu, 29 Jan 87 01:11 EST From: K. Shane Hartman Subject: Mentioning name twice in multiple-value-setq To: common-lisp@sail.stanford.edu Message-ID: <870129011156.4.SHANE@KITTYHAWK.PALLADIAN.COM> Reply-To: K. Shane Hartman (multiple-value-setq (x x) (values 1 2)) Is the value of x defined after executing the previous form? If so, what is the value? The same question could be asked of multiple-value-bind. -[Shane]->  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 87 21:12:08 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jan 87 17:48:16 PST Received: from Cabernet.ms by ArpaGateway.ms ; 28 JAN 87 13:06:38 PST Date: 28 Jan 87 13:06 PST From: Gregor.pa@Xerox.COM Subject: Re: survey on Lisp courses In-reply-to: Dan Aronson 's message of Wed, 28 Jan 87 13:44 EST To: Dan@think.com cc: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu Message-ID: <870128-130638-114@Xerox> Try, /pub/lisp-course-survey.txt.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 87 20:14:38 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 16:59:02 PST Received: ID ; Wed 28 Jan 87 19:59:30-EST Date: Wed 28 Jan 87 19:59:30-EST From: Dave.Touretzky@C.CS.CMU.EDU Subject: extending sequence functions to arrays To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12274641487.9.TOURETZKY@C.CS.CMU.EDU> I propose to make sequence functions more useful by extending them (very slightly) to treat arrays of rank > 1 as if they were one dimensional vectors :DISPLACED-TO the array. Presently, programmers are forced to build displaced vectors by hand in order to do simple operations on matrices. Consider the following examples: (setq a (make-array (list 5 7))) ;the matrix A (setq b (make-array (list 5 7))) ;the matrix B (setq av (make-array 35 :displaced-to a)) ;hack for accessing A (setq bv (make-array 35 :displaced-to b)) ;hack for accessing B Current Code New Code Equivalent Hack 1. zero all array elements (dotimes (i 5) (fill a 0) == (fill av 0) (dotimes (j 7) (setf (aref a i j) 0))) 2. copy array A into array B ...the obvious nested dotimes... (replace b a) == (replace bv av) 3. check if A contains a 0 anywhere (block foo (find 0 a) == (find 0 av) (dotimes (i 5) (dotimes (j 7) (if (= (aref a i j) 0) (return-from foo t))))) 4. find the minimum element of A (let ((m (aref a 0 0))) (reduce #'min a) == (reduce #'min av) (dotimes (i 5) (dotimes (j 7) (setq m (min m (aref a i j))))) m) This proposal doesn't impose any significant work on implementors since displaced arrays are already part of the language. It also does not introduce any conceptual ambiguities, e.g., in the handling of :START and :END keywords, values returned by, LENGTH, ELT, and REVERSE, etc., since the behavior of sequence functions on vectors is already well-defined. -- Dave Touretzky, CMU Computer Science Dept. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 87 15:06:42 EST Received: from BRILLIG.UMD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 11:51:44 PST Received: by brillig.umd.edu (5.9/4.7) id AA01721; Wed, 28 Jan 87 14:48:18 EST Date: Wed, 28 Jan 87 14:48:18 EST From: Bruce Israel Message-Id: <8701281948.AA01721@brillig.umd.edu> To: Dan@zarathustra.think.com Cc: Masinter.pa@xerox.com, common-lisp@sail.stanford.edu Subject: survey on Lisp courses From: Dan Aronson FTP tells me: /user/ftp/pub/lisp-course-survey.txt: No such file I got bit by this one also. It seems that ftp doesn't like absolute pathnames. Since you come in in the directory /usr/ftp, just do a 'cd pub' followed by a 'get lisp-course-survey.txt localfile' and all will work fine. Bruce  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 87 14:02:19 EST Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jan 87 10:43:39 PST Received: from Godot.Think.COM by zarathustra.think.com; Wed, 28 Jan 87 13:42:52 EST Received: from epicurus by Godot.Think.COM via CHAOS; Wed, 28 Jan 87 13:42:48 EST Date: Wed, 28 Jan 87 13:44 EST From: Dan Aronson Subject: survey on Lisp courses To: Masinter.pa@xerox.com Cc: common-lisp@sail.stanford.edu In-Reply-To: <870126-135515-4367@Xerox> Message-Id: <870128134411.8.DAN@EPICURUS.THINK.COM> Hi, FTP tells me: /user/ftp/pub/lisp-course-survey.txt: No such file or directory. If that is where it really is then our ftp is broken and could you send me a copy. If it is somewhere else could you tell me where. --Dan Aronson Thinking Machines Corporation dan@think.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 87 10:23:24 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 27 Jan 87 04:04:40 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 49828; 27 Jan 87 10:01:38 EST Date: Tue, 27 Jan 87 10:00 EST From: David C. Plummer Subject: [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of non-functions To: Masinter.pa@Xerox.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <870126-143634-4459@Xerox> Message-ID: <870127100054.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 26 Jan 87 14:42 PST From: Masinter.pa@Xerox.COM There was a misconception in David Plummer's reply that I think should be cleared up. ... Nothing in CLtL requires this to be true. Inversely, I believe nothing in CLtL requires this to be false. In private communications with Masinter I "proved" based on 5 assumptions which we can redistribute if necessary. Many Common Lisp implementations do not allow this form, although it is apparently allowed in some. Since apparently many people believe this is a property of Common Lisp, it may be grounds for a "clarification".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 23:57:00 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 20:39:58 PST Received: by hplabs.HP.COM ; Mon, 26 Jan 87 20:39:37 pst Received: from hpfcjrd.HP.COM by hpfclp; Mon, 26 Jan 87 20:41:39 mst Received: by hpfcjrd; Mon, 26 Jan 87 20:40:33 mst Date: Mon, 26 Jan 87 20:40:33 mst From: John Diamant Return-Path: Message-Id: <8701270340.AA18791@hpfcjrd.HP.COM> To: common-lisp@sail.stanford.edu Subject: Re: preprocessor-based Common Lisps Since I brought up the subject of preprocessors in Common Lisp implementations, I have been asked to describe the HP preprocessor. Here is a small paragraph written by one of the implementors of the preprocessor (Jerry Duggan): > HP chose to implement its Common Lisp system based on a preprocessor > model. The preprocessor takes "raw" Common Lisp code, expands macros, > and translates this lisp code into an internal form which is used as > input to both the interpreter and compiler. Additionally, the > preprocessor may perform optimizations on the Lisp code. There were > three reasons why the implementation was done this way. First, it was > a means to ensure consistent semantics between the interpreted and > compiled code, since both the interpreter and compiler use the same > input. Second, the preprocessor performs all the analysis required > for lexical scoping, so the implementation of lexical scoping was easy > and efficient in the interpreter, and closures could be compiled > efficiently. Third, all Common Lisp forms are translated into a basic > internal form which has about thirty different constructs. The small > number of constructs limits the allowed input to the interpreter and > compiler, making them both more manageable. The optimizations that Jerry refers to are primarily source-level translations, as opposed to machine language optimizations. Since the preprocessor is limited to source and interal representations, it cannot perform optimizations directly on machine code since that hasn't been generated yet. Preprocessed code can be traslated back into equivalent source code, but that source code may not be the same as the original source, because of the source-level optimizations (including macro-expansion) done on it. We added a declaration corresponding to the speed declaration for the interpreter (technically the preprocessor when called from the interpreter), so that a different degree of optimization can be enabled for interpreted and compiled code. John Diamant diamant%hpfclp@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 19:19:27 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 15:58:57 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 14:36:34 PST Date: 26 Jan 87 14:42 PST From: Masinter.pa@Xerox.COM Subject: [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of non-functions In-reply-to: David C. Plummer 's message of Fri, 23 Jan 87 09:21 EST To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870126-143634-4459@Xerox> [For those attempting to FTP the lisp course survey, the host name is PARCVAX.XEROX.COM, not PARC-VAX.XEROX.COM.] There was a misconception in David Plummer's reply that I think should be cleared up. The explaination given was one where the "symbol-function" implicit in obtaining the functional interpretation of car-of-form was repeated until the result was not a symbol. I.e., Dave assumed that (defun bottom () "The end!") (setf (symbol-function 'test) 'bottom) (test) would return "The end!" (This was the basis for the description that the reason why NIL fails as a value for symbol-function is because NIL has no function definition.) Nothing in CLtL requires this to be true. Many Common Lisp implementations do not allow this form, although it is apparently allowed in some. Since apparently many people believe this is a property of Common Lisp, it may be grounds for a "clarification".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 18:23:31 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:13:14 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 13:55:15 PST Date: 26 Jan 87 14:00 PST From: Masinter.pa@Xerox.COM Subject: survey on Lisp courses To: common-lisp@sail.stanford.edu Message-ID: <870126-135515-4367@Xerox> I sent out a request several weeks ago asking for information on Common Lisp courses that people had taken or taught. I collected together the responses (information about several different Lisp courses), edited out what I thought might not be for public consumption, and have stored on the file [parc-vax.xerox.com]/user/ftp/pub/lisp-course-survey.txt. The file should be available for anonymous ARPA ftp. I said I would send the results to those who contributed, but there were enough responses of the form "I don't have anything to contribute but I'd like to see the result anyway" that I thought I would broadcast the result. If you have anything to add, or don't have access and would like me to mail you a copy, please let me know. Thanks to all who responded. My observation: most of the subtleties of programming Common Lisp in a portable, efficient manner are not covered well. There may be some industrial/training sessions, but they seem to be too short to address most of the issues. A number of people that I've spoken with (whose responses are not reflected in the survey) agreed independently that the only text that covered programming style reasonably well was Abelson and Sussman's Structure and Interpretation of Computer Programs. There was more than one recommendation that a practical course was to start with that (and Scheme) and then transition to Common Lisp, explaining the compromises of Common Lisp along the way.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 18:22:15 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:06:20 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 49287; 26 Jan 87 11:21:23 EST Date: Mon, 26 Jan 87 11:20 EST From: David C. Plummer Subject: another question about defmacro lambda lists To: David A. Moon , Glenn S. Burke cc: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@sail.stanford.edu In-Reply-To: <870125200425.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870126112040.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sun, 25 Jan 87 20:04 EST From: David A. Moon Well, there's something funny here. Consider: (defmacro foo (&rest x &whole y) ...) (defmacro bar ((&rest x &whole y)) ...) In bar, x and y are bound to the same value, but in foo x is bound to (cdr y). I suppose it makes sense to allow &whole in bar anyway, but it could be confusing to some users. I agree it isn't symmetric, but there probably are cases that really are useful. Something like (defmacro with-open-file ((&whole stuff var filename &rest keys) &body body) ... (warn "The first form of with-open-file, ~S, is malformed." stuff) ...)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 17:30:50 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:13:14 PST Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 13:55:15 PST Date: 26 Jan 87 14:00 PST From: Masinter.pa@Xerox.COM Subject: survey on Lisp courses To: common-lisp@sail.stanford.edu Message-ID: <870126-135515-4367@Xerox> I sent out a request several weeks ago asking for information on Common Lisp courses that people had taken or taught. I collected together the responses (information about several different Lisp courses), edited out what I thought might not be for public consumption, and have stored on the file [parc-vax.xerox.com]/user/ftp/pub/lisp-course-survey.txt. The file should be available for anonymous ARPA ftp. I said I would send the results to those who contributed, but there were enough responses of the form "I don't have anything to contribute but I'd like to see the result anyway" that I thought I would broadcast the result. If you have anything to add, or don't have access and would like me to mail you a copy, please let me know. Thanks to all who responded. My observation: most of the subtleties of programming Common Lisp in a portable, efficient manner are not covered well. There may be some industrial/training sessions, but they seem to be too short to address most of the issues. A number of people that I've spoken with (whose responses are not reflected in the survey) agreed independently that the only text that covered programming style reasonably well was Abelson and Sussman's Structure and Interpretation of Computer Programs. There was more than one recommendation that a practical course was to start with that (and Scheme) and then transition to Common Lisp, explaining the compromises of Common Lisp along the way.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 17:24:37 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:06:20 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 49287; 26 Jan 87 11:21:23 EST Date: Mon, 26 Jan 87 11:20 EST From: David C. Plummer Subject: another question about defmacro lambda lists To: David A. Moon , Glenn S. Burke cc: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@sail.stanford.edu In-Reply-To: <870125200425.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870126112040.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sun, 25 Jan 87 20:04 EST From: David A. Moon Well, there's something funny here. Consider: (defmacro foo (&rest x &whole y) ...) (defmacro bar ((&rest x &whole y)) ...) In bar, x and y are bound to the same value, but in foo x is bound to (cdr y). I suppose it makes sense to allow &whole in bar anyway, but it could be confusing to some users. I agree it isn't symmetric, but there probably are cases that really are useful. Something like (defmacro with-open-file ((&whole stuff var filename &rest keys) &body body) ... (warn "The first form of with-open-file, ~S, is malformed." stuff) ...)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 87 11:03:48 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jan 87 07:55:10 PST Date: Mon, 26 Jan 1987 10:47 EST Message-ID: From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: common-lisp@SAIL.STANFORD.EDU Subject: Are functions defined by FLET surrounded by an implicit BLOCK? CLtL specifically states that DEFUN bodies are implicitly wrapped in a BLOCK with the same name as the function being defined. Is this true of FLET and LABELs as well? Stever  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 87 20:53:06 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jan 87 17:43:01 PST Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 95912; Sun 25-Jan-87 20:28:09 EST Date: Sun, 25 Jan 87 20:28 EST From: David A. Moon Subject: fsymeval before arg-eval? To: Jon L White cc: dlw@STONY-BROOK.SCRC.Symbolics.COM, cfry%OZ.AI.MIT.EDU@MIT-MC.ARPA, Common-Lisp@sail.stanford.edu In-Reply-To: <8701232149.AA10259@bhopal.edsel.com> Message-ID: <870125202815.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 23 Jan 87 13:49:53 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) For compiled code, the macro/functional decision has been made at compile time, and the question of order-of-evaluation is a legitimate question. In fact, most implementations I'm aware of do the "fsymeval" *after* the agruments computations in compiled code, but do it *before* them in the interpreted code. .... As far as I know, only VAX/NIL did the fsymeval in compiled code before the argument computations. Do you know of any others. Some Symbolics machines do it before, some do it after. I'm less familiar with other implementations, but I expect we could find several examples of each way of doing it. It sounds like it's going to be difficult to come to a concensus on this across a wide spectrum of implementations. Since dynamically changing the global function definition of symbols is not something that Common Lisp promotes as a standard programming technique, perhaps it's best just to leave it undefined. Normally when the function being called is not a constant, FUNCALL would be used.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 87 20:52:39 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jan 87 17:42:14 PST Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 95904; Sun 25-Jan-87 20:04:21 EST Date: Sun, 25 Jan 87 20:04 EST From: David A. Moon Subject: another question about defmacro lambda lists To: Glenn S. Burke cc: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@sail.stanford.edu In-Reply-To: <870124191250.1.GSB@DWORKIN.PALLADIAN.COM> Message-ID: <870125200425.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 24 Jan 87 19:12 EST From: Glenn S. Burke Date: Fri, 23 Jan 87 15:05 EST From: David A. Moon Date: Fri, 23 Jan 87 12:27:25 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Does it make sense for nested lambda lists in a defmacro to contain things like &environment? CLtL does not say whether the non-top-level lambda lists should be ordinary function lambda lists or whether they can use the extended syntax. They certainly need to allow destructuring; it wouldn't make sense to have only a single level of destructuring. I don't think &whole and &environment make sense any place other than at the top level, though. &whole makes sense for subforms; you need it if you want a pointer to the subform being destructured. I am assuming it applies to the subform being destructured against the lambda-list the &whole occurs in, not that it applies to the outermost form. Well, there's something funny here. Consider: (defmacro foo (&rest x &whole y) ...) (defmacro bar ((&rest x &whole y)) ...) In bar, x and y are bound to the same value, but in foo x is bound to (cdr y). I suppose it makes sense to allow &whole in bar anyway, but it could be confusing to some users.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 87 02:55:20 EST Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jan 87 23:44:06 PST Date: Sun, 25 Jan 87 02:41 EST From: Hvatum@MIT-MULTICS.ARPA Subject: quoted structure To: common-lisp@SAIL.STANFORD.EDU cc: Hvatum@MIT-MULTICS.ARPA Message-ID: <870125074145.262992@MIT-MULTICS.ARPA> From: Steve Bacher (C.S.Draper Lab) Subject: Re: is quoted structure "constant"? In-reply-to: REM%IMSSS@SU-AI.ARPA > Where quoted structure > appears as second argument to MEMQ or MEMBER or as either argument to > EQ or EQUAL et al, it is obviously not changeable hence constant. This is not necessarily true in the case of MEMQ/MEMBER. Since MEMBER (let's elide mention of MEMQ as it is not true CL) returns a sublist of its second arg by definition, it cannot be guaranteed that the second arg is unchanged. The compiler can assume constancy of the second arg to MEMBER only when the function is being used as a predicate (or for side-effect only, which is meaningless for MEMBER). - SEB   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jan 87 20:37:43 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jan 87 17:22:47 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jan 87 20:22-EST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 26179; 24 Jan 87 20:23:52-EST Received: from DWORKIN.PALLADIAN.COM by JASPER.PALLADIAN.COM via CHAOS with SMTP id 25654; 24 Jan 87 19:13:10-EST Date: Sat, 24 Jan 87 19:12 EST From: Glenn S. Burke Subject: another question about defmacro lambda lists To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%utah-orion@UTAH-CS.ARPA cc: common-lisp@sail.stanford.edu, gsb@JASPER.PALLADIAN.COM In-Reply-To: <870123150538.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870124191250.1.GSB@DWORKIN.PALLADIAN.COM> Reply-To: Glenn S. Burke Date: Fri, 23 Jan 87 15:05 EST From: David A. Moon Date: Fri, 23 Jan 87 12:27:25 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Does it make sense for nested lambda lists in a defmacro to contain things like &environment? CLtL does not say whether the non-top-level lambda lists should be ordinary function lambda lists or whether they can use the extended syntax. They certainly need to allow destructuring; it wouldn't make sense to have only a single level of destructuring. I don't think &whole and &environment make sense any place other than at the top level, though. &whole makes sense for subforms; you need it if you want a pointer to the subform being destructured. I am assuming it applies to the subform being destructured against the lambda-list the &whole occurs in, not that it applies to the outermost form.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jan 87 15:41:06 EST Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jan 87 12:27:46 PST Received: by lindy.STANFORD.EDU; Sat, 24 Jan 87 12:25:55 PST Date: Sat, 24 Jan 87 12:23:58 PST From: Reply-To: LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu To: common-lisp@sail.stanford.edu Subject: Pattern matching in CL Date: Sat, 24 Jan 87 10:32 CST From: (David Linn) Subject: Pattern matching in CL To: common-lisp@sail.stanford.edu X-Original-To: common-lisp@sail.stanford.edu, LINNDR For the last couple of years, we have been using PEARL in our (Franz)LISP applications. Now that we have CL, we are looking for a PEARL port or a comparable pattern-matching/database-handling package in CL. Can you help? Please reply by mail and I'll summarize to the list if there is sufficient interest. David Linn (The Shell Answer Man) LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU | Internet ...!psuvax1!vuengvax.bitnet!linndr | UUCP  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 19:21:05 EST Received: from IMSSS by SAIL with PUP; 23-Jan-87 16:00 PST Date: 23 Jan 1987 1557-PST From: Rem@IMSSS Subject: symeval before or after args-eval? To: COMMON-LISP@SU-AI It seems there are several possible decisions, each of which involves some change to CLtL: (1) Require symeval before args-eval in both interpretor and compiled-code. This may require overhaul of several implementations. (2) Leave it up to the implementor, but say "it is an error" to write any code that side-effects the functional binding of the CAR of a form when evaluating the args (map-eval the CDR) since its behaviour would be different on various implementations and might be different between interpreted and compiled within a single implementation. <> (3) Require lookup of type of function before evaluating args, but require actual fetching of function definition after evaluating args, and way "it is an error" to redefine a function to a macro or vice versa during evaluating args. I vote for (2) as being less drastic than either of the others. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 18:25:45 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jan 87 15:08:21 PST Received: by navajo.stanford.edu; Fri, 23 Jan 87 15:07:06 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA06525; Fri, 23 Jan 87 13:50:23 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA10259; Fri, 23 Jan 87 13:49:53 PST Date: Fri, 23 Jan 87 13:49:53 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8701232149.AA10259@bhopal.edsel.com> To: navajo!DLW%ALDERAAN.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!cfry%OZ.AI.MIT.EDU@navajo.stanford.edu, navajo!Common-Lisp%SU-AI.ARPA@navajo.stanford.edu In-Reply-To: Daniel L. Weinreb's message of Fri, 23 Jan 87 10:47 EST Subject: fsymeval before arg-eval? For compiled code, the macro/functional decision has been made at compile time, and the question of order-of-evaluation is a legitimate question. In fact, most implementations I'm aware of do the "fsymeval" *after* the agruments computations in compiled code, but do it *before* them in the interpreted code. In an implementation where the "macro-p" question is decidable without looking in the function cell (like, MacLisp and Interlisp), then the interpreter wouldn't need to do the fsymeval before doing the argument evaluations. The other issue is decidibility of "special-form-p"; in a language where the "special forms" are immutable (expect for macro-expanders for semantics clarity), there is no need to look into the funtion cell to determine whether or not the form is a "special form". Lisp/370 was implemented this way also (or was intended to have this semantics!); it is generally true for Common Lisp too. But the real issue is that evaluating the functional position last is very counterintuitive. It certainly wouldn't survive the Lisp1/Lisp2 challenge (which is a proposal to unify the function and value cells). As far as I know, only VAX/NIL did the fsymeval in compiled code before the argument computations. Do you know of any others. -- JonL -- P.S. Historical perspective: Another variant of this problem is discussed in a footnote to the paper "Lisp: Data Is Program -- A Tutorial in Lisp" found in the Proceedings of the 1977 MACSYMA Users' Conference (NASA CP 2012). See page 197. This footnote is particularly concerned with multiple "evaluations" of the function context -- such as has recently been proposed for Common Lisp as a way to accommodate the Lisp1/Lisp2 controversy -- and in particular the side-effects which may occur in the "evaluations".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 18:02:38 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 12:35:43 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50324; Fri 23-Jan-87 15:08:23 EST Date: Fri, 23 Jan 87 15:05 EST From: David A. Moon Subject: another question about defmacro lambda lists To: Sandra J Loosemore cc: common-lisp@sail.stanford.edu In-Reply-To: <8701231927.AA25049@utah-orion.ARPA> Message-ID: <870123150538.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 23 Jan 87 12:27:25 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Does it make sense for nested lambda lists in a defmacro to contain things like &environment? CLtL does not say whether the non-top-level lambda lists should be ordinary function lambda lists or whether they can use the extended syntax. They certainly need to allow destructuring; it wouldn't make sense to have only a single level of destructuring. I don't think &whole and &environment make sense any place other than at the top level, though.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 15:30:51 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Jan 87 12:13:19 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48964; Fri 23-Jan-87 15:11:19 EST Date: Fri, 23 Jan 87 15:10 EST From: David C. Plummer Subject: another question about defmacro lambda lists To: Sandra J Loosemore , common-lisp@sail.stanford.edu In-Reply-To: <8701231927.AA25049@utah-orion.ARPA> Message-ID: <870123151054.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Fri, 23 Jan 87 12:27:25 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Does it make sense for nested lambda lists in a defmacro to contain things like &environment? No, it doesn't make sense. There is only one environment (the one in which the macro is being expanded in). (Nor can it be destructured.) CLtL does not say whether the non-top-level lambda lists should be ordinary function lambda lists or whether they can use the extended syntax. I almost couldn't find &environment because of a "publishing" glitch!! The last paragraph on page 145 is supposed to have &environment next to it, but doesn't. Indeed, the spec should be explicit about what may appear in nested lambda lists.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 14:42:30 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 11:25:10 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA10694; Fri, 23 Jan 87 12:27:28 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA25049; Fri, 23 Jan 87 12:27:25 MST Date: Fri, 23 Jan 87 12:27:25 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8701231927.AA25049@utah-orion.ARPA> Subject: another question about defmacro lambda lists To: common-lisp@sail.stanford.edu Does it make sense for nested lambda lists in a defmacro to contain things like &environment? CLtL does not say whether the non-top-level lambda lists should be ordinary function lambda lists or whether they can use the extended syntax. -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 12:19:00 EST Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 09:06:22 PST Received: from mycroft.GSD (mycroft.ARPA) by gswd-vms.ARPA (5.52/) Message-Id: <8701231705.AA11090@gswd-vms.ARPA> Date: Fri, 23 Jan 87 11:03:04 CST From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@sail.stanford.edu Subject: Re: functionp/fboundp Needless to say, when I typed: Since CLtL says "FBOUNDP is always true of symbols", it's hard to see how we could do anything else... (I agree, though, that the suggested function would be useful). the "FBOUNDP" should have been "FUNCTIONP"... -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 11:30:38 EST Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 08:22:29 PST Received: from mycroft.GSD (mycroft.ARPA) by gswd-vms.ARPA (5.52/) Message-Id: <8701231621.AA11025@gswd-vms.ARPA> Date: Fri, 23 Jan 87 10:19:15 CST From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@sail.stanford.edu Subject: functionp/fboundp nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson): > ... Unfortunately, notes sent to this > mailing list have indicated that in other implementations FUNCTIONP returns > true for all symbols, regardless of the current symbol-function cell > contents. ---------- Since CLtL says "FBOUNDP is always true of symbols", it's hard to see how we could do anything else... (I agree, though, that the suggested function would be useful). -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 11:06:19 EST Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 07:50:57 PST Received: from CHICOPEE.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 95561; Fri 23-Jan-87 10:49:37 EST Date: Fri, 23 Jan 87 10:47 EST From: Daniel L. Weinreb Subject: fsymeval before arg-eval? To: cfry@OZ.AI.MIT.EDU, Common-Lisp@SU-AI.ARPA In-Reply-To: <870123010757.0.CFRY@INTERCEPTOR.AI.MIT.EDU> Message-ID: <870123104759.6.DLW@CHICOPEE.SCRC.Symbolics.COM> It has to get the definition out of the symbol first. (Otherwise, how could it tell whether the form is a funtion call, or a macro form?) You're right that the definition of the language should clearly specify that the function to be applied is the symbol-function contents before evaluation of the arguments. That is, it is not correct to re-fetch the contents of the cell after those evaluations.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 10:23:18 EST Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 23 Jan 87 07:13:00 PST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA23658; Fri, 23 Jan 87 07:13:11 PST Message-Id: <8701231513.AA23658@decwrl.dec.com> Date: Friday, 23 Jan 1987 07:09:49-PST From: nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson) To: common-lisp@sail.stanford.edu, gz%oz.ai.mit.edu@xx.lcs.mit.edu Subject: functionp/fboundp From: RHEA::DECWRL::""Gail Zacharias" GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU" 22-JAN-1987 12:37 To: common-lisp@SAIL.STANFORD.EDU Subj: symbol-function of non-functions The manual seems to imply that fboundp is required to return non-nil for macros and special forms, while symbol-function is merely allowed to do so (".. function or MAY be an object representing a special form or macro.."). Am I reading that right? In any case, it seem to me that these definitions make it impossible to tell for sure whether a symbol is a valid argument to APPLY/FUNCALL. I.e. in implementations which do not keep macros in the function cell, so that macro-function being true does not imply non-applicability of the symbol, there is no CL way to find out if there is an applicable definition regardless of whether there is or isn't a macro definition. In VAX LISP, the function FUNCTIONP returns true if the argument can be used in a call to FUNCALL or to APPLY. Unfortunately, notes sent to this mailing list have indicated that in other implementations FUNCTIONP returns true for all symbols, regardless of the current symbol-function cell contents. In those cases you could write your own version of functionp to say (defun apply-argument-p (x) (if (symbolp x) (and (fboundp x) (not (macro-function x)) (not (special-form-p x))) (functionp x))) Why not require fboundp be true if and only if there is an applicable definition. You could still say (or (macro-function x) (special-form-p x) (fboundp x)) if you really want to include all possibilities, while there is no way to implement the more restrictive fboundp in terms of what's currently documented. You can also now determine what you want by using the form written above. Beryl Nelson nelson%bach@decwrl.dec.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 09:43:23 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Jan 87 06:33:20 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48803; Fri 23-Jan-87 09:22:18 EST Date: Fri, 23 Jan 87 09:21 EST From: David C. Plummer Subject: Re: symbol-function of non-functions To: Randy@ALLEGHENY.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 22 Jan 87 15:56 EST from Randy@ALLEGHENY.SCRC.Symbolics.COM Message-ID: <870123092151.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 22 Jan 87 16:56 EDT From: Randy@a Actually, I've always wondered why SYMBOL-FUNCTION has to signal an error if the symbol does not have anything in its function cell. If it is in an attempt to be parallel to SYMBOL-VALUE, then what about SYMBOL-PLIST and SYMBOL-PACKAGE? SYMBOL-VALUE has to be special since NIL is an allowable value for a symbol to have, but NIL in a function cell would mean that there is no function. Not at all. It means that a further indirection needs to be taken since NIL is itself a symbol. The indirection looks for the functional value of NIL, which is presumably unbound, and will then generate an error. Does all of this mean that it is incorrect to (SETF (SYMBOL-FUNCTION 'FOO) NIL) and that one *has* to use FMAKUNBOUND instead? You can do (SETF (SYMBOL-FUNCTION 'FOO) NIL) and then (FOO) will try to invoke NIL as a function because of the indirection stated above, and the fboundness of NIL will determine what will happen. So... to make a symbol globally funbound, you do have to use FMAKUNOUND.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 87 01:14:45 EST Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 22:06:49 PST Received: from INTERCEPTOR.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19136; Fri 23-Jan-87 01:08:03 EST Date: Fri, 23 Jan 87 01:07 EST From: Christopher Fry Subject: fsymeval before arg-eval? To: Common-Lisp@SU-AI.ARPA Message-ID: <870123010757.0.CFRY@INTERCEPTOR.AI.MIT.EDU> When eval gets a call to a function, is the definition that is used gotten out of the symbol before the args are evaled or afterwords? Since eval has to first figure out if the car of the form is a macro, special-form or regular function before it can know what to do with the args, it makes sense that it gets the def before arg evaluation. But I haven't found a reference to this in the spec. A case where this would matter is: (defun foo (x) 1) (foo (defun foo (x) 2)) => 1 or 2 ? A particularly pathological case would be: (defun foo (x) 1) (foo (defmacro foo (x) 2))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 20:55:08 EST Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jan 87 17:41:13 PST Received: from Godot.Think.COM by zarathustra.think.com; Thu, 22 Jan 87 20:41:39 EST Received: from heidegger by Godot.Think.COM via CHAOS; Thu, 22 Jan 87 20:41:24 EST Date: Thu, 22 Jan 87 20:42 EST From: Jeff Mincy Subject: Pushing defmacro hard: destructured &KEY bindings To: DCP@quabbin.scrc.symbolics.com, Common-Lisp@sail.stanford.edu In-Reply-To: <870122174353.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Message-Id: <870122204217.3.MINCY@HEIDEGGER.THINK.COM> Date: Thu, 22 Jan 87 17:43 EST From: David C. Plummer Subject: Pushing defmacro hard: destructured &KEY bindings CLtL pages 149-151 mentions destructuring within lambda list keywords for defmacro, but don't give enough examples for users to know what is expected to work and what isn't. Specifically, it does give examples of destructuring &OPTIONAL, but doesn't say &REST may not be destructured (it doesn't at first glance make much sense, but program writing programs may generate it, and it may be a good way to do some further destructuring) and it is silent on &KEY. For example, is the following legal? p146 CLtL ... known as destructuring. "Anywhere in the lambda-list where a parameter name may appear, and where ordinary lambda-list syntax (5.2.2) does not otherwise allow a list, a lambda-list may appear in place of the parameter name." So I'd interpret that to mean any of the following "var"s in lambda-lists may be replaced with a lambda-list. ( {var}* &optional (var [initform [svar]]) &rest var &key ((key var) [initform [svar]]). ) I'd say your examples are valid. -jeff  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 18:45:43 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87 15:27:57 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49437; Thu 22-Jan-87 16:16:17 EST Date: Thu, 22 Jan 87 16:13 EST From: David A. Moon Subject: symbol-function of non-functions To: Gail Zacharias cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <12272947186.15.GZ@OZ.AI.MIT.EDU> Message-ID: <870122161341.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu 22 Jan 87 08:52:25-EST From: "Gail Zacharias" The manual seems to imply that fboundp is required to return non-nil for macros and special forms, while symbol-function is merely allowed to do so (".. function or MAY be an object representing a special form or macro.."). Am I reading that right? In any case, it seem to me that these definitions make it impossible to tell for sure whether a symbol is a valid argument to APPLY/FUNCALL. I.e. in implementations which do not keep macros in the function cell, so that macro-function being true does not imply non-applicability of the symbol, there is no CL way to find out if there is an applicable definition regardless of whether there is or isn't a macro definition. Why not require fboundp be true if and only if there is an applicable definition. You could still say (or (macro-function x) (special-form-p x) (fboundp x)) if you really want to include all possibilities, while there is no way to implement the more restrictive fboundp in terms of what's currently documented. You seem to be assuming that Common Lisp allows a symbol to be simultaneously a function and a macro. It doesn't. It only allows a symbol to be simultaneously a macro and a special form. Thus macro-function being true really does imply non-applicability. I think fboundp is supposed to mean: is this symbol globally defined as any one of a function, a macro, or a special form, i.e. does this symbol mean something in the car of a form in the global lexical environment? Note that I didn't say anything about implementation in terms of function cells, alists, or anything else.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 18:45:39 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Jan 87 15:32:11 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48658; Thu 22-Jan-87 17:44:14 EST Date: Thu, 22 Jan 87 17:43 EST From: David C. Plummer Subject: Pushing defmacro hard: destructured &KEY bindings To: Common-Lisp@SU-AI.ARPA Message-ID: <870122174353.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> CLtL pages 149-151 mentions destructuring within lambda list keywords for defmacro, but don't give enough examples for users to know what is expected to work and what isn't. Specifically, it does give examples of destructuring &OPTIONAL, but doesn't say &REST may not be destructured (it doesn't at first glance make much sense, but program writing programs may generate it, and it may be a good way to do some further destructuring) and it is silent on &KEY. For example, is the following legal? (defmacro funny (&key ((:two-elements (x1 x2)) '(two-1 two-2)) ((:three-elements (y1 y2 y3)) '(three-1 three-2 three-3)) ((:two-or-three (z1 z2 &optional (z3 'zee-three))) '(sis boom bah))) (list x1 x2 y1 y2 y3 z1 z2 z3)) (funny :three-elements (foo bar baz) :two-elements (Common Lisp) :two-or-three (tea coffee)) ==> (Common Lisp foo bar baz tea coffee zee-three) And is this legal? (defmacro bone (a b &optional c &rest (&whole d &optional e f g &rest h)) (list a b c d e f g h))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 17:26:27 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 14:15:55 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Jan 87 17:15-EST Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 25868; 22 Jan 87 17:16:37-EST Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 52241; Thu 22-Jan-87 16:58:52-EST Date: Thu, 22 Jan 87 16:56 EDT From: Randy@a To: common-lisp@SAIL.STANFORD.EDU Subject: Re: symbol-function of non-functions Actually, I've always wondered why SYMBOL-FUNCTION has to signal an error if the symbol does not have anything in its function cell. If it is in an attempt to be parallel to SYMBOL-VALUE, then what about SYMBOL-PLIST and SYMBOL-PACKAGE? SYMBOL-VALUE has to be special since NIL is an allowable value for a symbol to have, but NIL in a function cell would mean that there is no function. Does all of this mean that it is incorrect to (SETF (SYMBOL-FUNCTION 'FOO) NIL) and that one *has* to use FMAKUNBOUND instead? Random  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 16:51:29 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 22 Jan 87 13:38:24 PST Received: from cs.umass.edu by csnet-relay.csnet id ab14260; 22 Jan 87 16:20 EST Date: Thu, 22 Jan 87 15:42 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SU-AI.ARPA Subject: *print-circle* X-VMS-To: CSNET%"common-lisp@su-ai.ARPA" From: "David A. Moon" From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) .. Is there a compelling reason why *print-circle* is not required to identify shared substructures, as well as circular structures? .. .. I could imagine a user demand for separate control of circularity detecting and sharing detection; .. I agree that it should be two different switches. *Print-circle* should only endeavor to find circularity, with perhaps *print-shared* to do the full checking. I think a lot of cases of using *print-circle* are to make sure you don't get infinite printing, where you don't really care about sharing. In these cases, the #1#'s seem "spurious", and actually make the data hard to read. Kelly Murray  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 12:29:46 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87 09:16:13 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA06156; Thu, 22 Jan 87 10:18:32 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA19008; Thu, 22 Jan 87 10:18:26 MST Date: Thu, 22 Jan 87 10:18:26 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8701221718.AA19008@utah-orion.ARPA> Subject: Re: *print-circle* To: David A. Moon Cc: common-lisp@sail.stanford.edu In-Reply-To: David A. Moon , Wed, 21 Jan 87 22:12 EST Date: Wed, 21 Jan 87 22:12 EST From: David A. Moon Symbolics' implementation of *print-circle* looks for shared substructures, and it wouldn't surprise me if a lot of other implementations also do so. It seems like a good idea. This is the sort of information I was looking for. If this is indeed the common practice, and we all agree it is a good idea, then it should be standardized. So far I have had a number of requests for my code and one reply from a person who thought this behavior already was specified in the manual. I have yet to hear any negative comments. I could imagine a user demand for separate control of circularity detecting and sharing detection.... So could I, but I suspect that it would be harder to get everyone to agree on introducing a separate control mechanism than it would for us to agree to make *print-circle* do this, especially if *print-circle* already behaves this way in many implementations. I might add that an additional reason to provide a standardized way to print shared structures is that it's not possible for an ordinary user to write a general purpose routine to do this without knowing how to get at the internal representation of structures generated via defstruct. -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 10:53:08 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 07:44:23 PST Received: ID ; Thu 22 Jan 87 10:44:08-EST Date: Thu, 22 Jan 1987 10:44 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Gail Zacharias Cc: common-lisp@SAIL.STANFORD.EDU Subject: symbol-function of non-functions In-reply-to: Msg of 22 Jan 1987 08:52-EST from Gail Zacharias We definitely need to clean up the description of the function data-type and related functions so that people can tell exactly what they have, whether it is applicable, etc. I don't think that FBOUNDP is the right place to do this, however -- that wants to be fast. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 87 09:00:10 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 05:53:30 PST Date: Thu 22 Jan 87 08:52:25-EST From: "Gail Zacharias" Subject: symbol-function of non-functions To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12272947186.15.GZ@OZ.AI.MIT.EDU> The manual seems to imply that fboundp is required to return non-nil for macros and special forms, while symbol-function is merely allowed to do so (".. function or MAY be an object representing a special form or macro.."). Am I reading that right? In any case, it seem to me that these definitions make it impossible to tell for sure whether a symbol is a valid argument to APPLY/FUNCALL. I.e. in implementations which do not keep macros in the function cell, so that macro-function being true does not imply non-applicability of the symbol, there is no CL way to find out if there is an applicable definition regardless of whether there is or isn't a macro definition. Why not require fboundp be true if and only if there is an applicable definition. You could still say (or (macro-function x) (special-form-p x) (fboundp x)) if you really want to include all possibilities, while there is no way to implement the more restrictive fboundp in terms of what's currently documented. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 87 22:31:45 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Jan 87 19:15:02 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48727; Wed 21-Jan-87 22:15:25 EST Date: Wed, 21 Jan 87 22:12 EST From: David A. Moon Subject: *print-circle* To: Sandra J Loosemore cc: common-lisp@sail.stanford.edu In-Reply-To: <8701202106.AA09740@utah-orion.ARPA> Message-ID: <870121221249.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 20 Jan 87 14:06:00 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Is there a compelling reason why *print-circle* is not required to identify shared substructures, as well as circular structures? The "obvious" (to me) implementation will detect both. Circular structures can be identified with a little less overhead, since the amount of state needed at any moment is proportional to the depth of the structure rather than to the total size of the structure. Also the state has the right lifetime to be stored in a stack, so a non-consing implementation can be used easily. Neither of these strikes me as compelling! Being able to write out a complex, linked structure with the guarantee that its topology will be preserved when it is read back in again seems like a very useful thing. I'd be glad to share my code to do this if there is sufficient demand for it. Symbolics' implementation of *print-circle* looks for shared substructures, and it wouldn't surprise me if a lot of other implementations also do so. It seems like a good idea. I could imagine a user demand for separate control of circularity detecting and sharing detection; one side-effect of full shared substructure detection that surprised me when I first saw it was the result of (let ((*print-circle* t)) (print (macroexpand-all '(dolist (x y) (dolist (w x) (print w)))))) because there is some substructure shared between the two expansions of the dolist macro; in our case the list (NIL) happens to be shared and so the second occurrence turns into a #1#.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 87 17:30:11 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87 14:09:48 PST Received: ID ; Wed 21 Jan 87 17:08:57-EST Date: Wed, 21 Jan 1987 17:08 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: John Diamant Cc: common-lisp@SAIL.STANFORD.EDU Subject: preprocessor-based Common Lisps In-reply-to: Msg of 21 Jan 1987 12:18-EST from John Diamant In the majority of Common Lisp systems that I know of, DEFUN inserts the named block around the body of the lambda form before saving it away. So in this minimal sense, almost everyone does some pre-processing in the interpreter. A lot of systems save macro-expansions inline (more or less) after the first expansion occurs. This is usually a feature that you can turn on and off, and in the better systems you can undo such actions if the macro is redefined. I think that systems that expand macros or do other optimizations at DEFUN time are in the minority, however. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 87 17:10:47 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 Jan 87 13:50:31 PST Received: by hplabs.HP.COM ; Wed, 21 Jan 87 13:50:22 pst Received: by hpfclp; Wed, 21 Jan 87 10:18:27 mst Date: Wed, 21 Jan 87 10:18:27 mst From: John Diamant Return-Path: To: Moon@STONY-BROOK.SCRC.Symbolics.COM Subject: Re: preprocessor-based Common Lisps Cc: common-lisp@sail.stanford.edu > Is the fact that the DEFUN special form in Symbolics Common Lisp > fully macro-expands the body before storing the interpreted function > as the definition of its name the sort of thing you are looking for? Yes, I would be interested in that type of preprocessing. I think my second note gave a more accurate description of what I was looking for than my first one. Specifically, I would like to know how the interpreted function is stored (internal representation or simply macro-expanded source code), and if the original source code is kept around for debugging purposes). I have Symbolics manuals (Release 5.0) in case you could give me a pointer on this if it is discussed in the manual. Otherwise, I would appreciate any information you could supply about the extend to which preprocessing is used. John Diamant diamant%hpfclp@hplabs.HP.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jan 87 10:47:26 EST Received: from DOCKMASTER.ARPA by SAIL.STANFORD.EDU with TCP; 21 Jan 87 07:38:21 PST Date: Wed, 21 Jan 87 10:35 EST From: Bill Pase Subject: Mailing List To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870121153506.840831@DOCKMASTER.ARPA> Could I  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Jan 87 18:10:48 EST Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 20 Jan 87 14:48:47 PST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA09113; Tue, 20 Jan 87 14:49:06 PST Message-Id: <8701202249.AA09113@decwrl.dec.com> Date: Tuesday, 20 Jan 1987 14:48:29-PST From: vanroggen%bach.DEC@decwrl.DEC.COM To: common-lisp@sail.stanford.edu, vanroggen%bach.DEC@decwrl.DEC.COM Subject: Looking for Lisps... As part of a feature of the LISP POINTERS newsletter, we'd like to collect descriptions of all currently available Lisp implementations. Any kind of Lisp is acceptable; it doesn't have to be Common Lisp or Scheme or Interlisp or MacLisp. It doesn't have to be a commercially supported product either; it can be free with no warranties whatsoever. If you're working on an implementation, and you're willing to describe it for everyone's benefit, send us at least the following information: Implementation Name Implemented to which standard (if any) Features (if no standard; see the suggested list of issues below) Additional Features (if implemented according to a standard) Missing Features (if implemented according to a standard) Current version/availability/prices Support (if supported, by whom; sources available?) Machine(s) Operating System(s) Source or Contact Any other comments Submitter's name, address, and net-address Some features you might want to comment on include: Predefined data types Name spaces and scopes and extents Control structures (e.g., special forms, non-local goto's, multiple values, multiple stacks, tasking, multi-processor support) Typing and declarations Garbage collection I/O functions Compiler Object-oriented support Graphics and windowing support Programming tools (e.g., graphics packages, editor interaction, system maintenance) Interaction with other languages AI-oriented tools (e.g., pattern matching, rules, database support, natural language interface) Any other interesting features Send this information to: Walter van Roggen Net address: VANROGGEN%BACH.DEC@DECWRL.DEC.COM Mail address: HLO2-3/E9, 77 Reed Rd, Hudson MA, 01749, USA  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Jan 87 16:26:39 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 20 Jan 87 13:03:49 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA25591; Tue, 20 Jan 87 14:06:05 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA09740; Tue, 20 Jan 87 14:06:00 MST Date: Tue, 20 Jan 87 14:06:00 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8701202106.AA09740@utah-orion.ARPA> Subject: *print-circle* To: common-lisp@sail.stanford.edu Is there a compelling reason why *print-circle* is not required to identify shared substructures, as well as circular structures? The "obvious" (to me) implementation will detect both. Being able to write out a complex, linked structure with the guarantee that its topology will be preserved when it is read back in again seems like a very useful thing. I'd be glad to share my code to do this if there is sufficient demand for it. -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Jan 87 06:46:40 EST Received: from SAIL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jan 87 03:30:52 PST Date: 1987 January 19 21:11:50 PST (=GMT-8hr) From: Robert Elton Maas To:Common-LISP@SU-AI.ARPA CC:Fahlman@C.CS.CMU.EDU,edsel!babel!eb@navajo.stanford.edu Subject:Quoted structure not necessarily constant in my opinion, fix CLtL Date: Tue, 6 Jan 1987 19:29 EST From: "Scott E. Fahlman" Subject: Destructive operations In my view, when a constant appears in code, the compiler is free to store this in read-only space or do other strange things that depend on the constantness of the constant. This discussion isn't about constants, but about quoted structure. How does a compiler determine whether quoted structure is intended to be constant or merely initial (default) value? Where quoted structure appears as second argument to MEMQ or MEMBER or as either argument to EQ or EQUAL et al, it is obviously not changeable hence constant. But where quoted structure appears as second argument to SETQ at toplevel (not inside body of any function) it is often just an initial value. (Where it appears as second argument to SETQ within a function that might be loaded once but executed multiple times, it is probably poor programming practice and should be flagged by compiler, since on the one hand it can't be proved unchangeable, yet if it is ever destructively changed the semantics of the function are changed out from under it.) Perhaps only unambiguous cases should be accepted by the language spec, that is global SETQs are assumed to be default/initial values wile places that can't possibly be changed are assmed to be constant, and all other use should "be an error". ... I found nothing about other constants, such as '(a b c), that might appear in the body of the code. Still, I think that we must allow the compiler to assume that these things will not be altered destructively. I think assuming '(a b c) is a constant is wrong, except in special cases such as I outlined above. You can always store the list in a variable if you want it to be malleable. Variables don't "hold" lists the way they do in, say, FORTRAN. Variables hold pointers to the list, which may be shared among several pointers. In the case above of '(a b c) somewhere, copying the pointer to a variable doesn't solve the problem if the original data and hence the pointed-at data is in readonly memory. You must actually copy the whole data structure recursively by COPY or COPY-WHOLE or somesuch function, but then you end up with the original data sitting in readonly memory inaccessible yet permanently occupying memory. The compiler should arrange that the original of the data gets loaded into the heap (collectable memory) in the first place to avoid occupying readonly space with data that won't ever be referenced after loading the file. A subcommittee of X3J13 has been set up to formulate recommendations on how to fix this. This is one of the issues that they should address. I hope my points about readonly (constant) vs. initial-value will be raised by somebody attending. Date: Tue, 6 Jan 87 16:49:13 pst From: edsel!babel!eb@navajo.stanford.edu (Eric Benson) Subject: Destructive operations On p.78 of CLtL, in the description of the function EQ, is the following paragraph: ``An additional problem with EQ is that the implementation is permitted to "collapse" constants (or portions thereof) appearing in code to be compiled if they are EQUAL. An object is considered to be a constant in code to be compiled if it is a self-evaluating form or is contained in a QUOTE form. I believe strongly this is a design mistake, innerds of QUOTE form can be initial values as well as constants, depending on context, as per my remarks earlier. Is it too late to fix this in the spec? But if something is truly constant, then I agree any EQUAL parts should be foldable with each other within a single constant such as '(A (B) C (B) B) or between constants. Because the compiler is permitted to share structure with constants in compiled code, it follows that modifying such a constant is illegal. If they are modified, then perhaps they weren't supposed to be constants in the first place, the compiler jumped to a false conclusion. Date: Wed, 7 Jan 87 11:38:23 pst From: edsel!babel!eb@navajo.stanford.edu (Eric Benson) Subject: Destructive operations Right you are. I was assuming too much. Just because something may have horrible consequences doesn't necessarily make it illegal. Modifying constants in compiled code has the same legal status as modifying the SYMBOL-NAME string of a symbol. ``It is an extremely bad idea to modify'' a constant in compiled code. It's also an extremely bad idea for a compiler designer to assume anyone who quotes any structure intends it to be readonly (constant), unless the programmer also declares it to be constant somehow, or it is obvious from the code it must be constant (but then the question is moot). For similar reasons, it is a bad idea to modify any object which is used as a key in an EQUAL hash table (this problem is unfortunately not mentioned in CLtL). Putting a key in an EQUAL hash table is an obvious case where the programmer is stamping the structure readonly, and compiler is warranted in optimizing accordingly. I agree CLtL should warn about this.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 87 15:33:45 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jan 87 12:18:45 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 46409; Mon 19-Jan-87 15:11:58 EST Date: Mon, 19 Jan 87 15:09 EST From: David A. Moon Subject: Re: preprocessor-based Common Lisps To: John Diamant cc: common-lisp@sail.stanford.edu In-Reply-To: <8701182206.AA06619@hpfcjrd.HP.COM> Message-ID: <870119150910.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Is the fact that the DEFUN special form in Symbolics Common Lisp fully macro-expands the body before storing the interpreted function as the definition of its name the sort of thing you are looking for? This is not at all at the token-parsing level you seemed to be talking about at first, but seems to fit some of what you said in your latest message.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 87 03:46:54 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Jan 87 00:35:02 PST Received: by navajo.stanford.edu; Mon, 19 Jan 87 00:34:13 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA02925; Mon, 19 Jan 87 00:13:48 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA02298; Mon, 19 Jan 87 00:13:31 PST Date: Mon, 19 Jan 87 00:13:31 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8701190813.AA02298@bhopal.edsel.com> To: navajo!DALY%ibm.com@navajo.stanford.edu Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu In-Reply-To: "Timothy P. Daly"'s message of 17 January 1987, 11:34:43 EST Subject: :append keyword on compile-file PDP10 MacLisp structured its "fasl" file format so that the loader could simply read one "fasl group" in a file, and then read the next one, and so on. That way, pre-existing fasl files could be simply concatenated, and one call to the LOAD function would get them all (in sequence). Of course, this implies a certain independence among the "groups". The compiler could also produce concatenated fasl files from a multiple-source-file compilation request. Version 2 of Lucid's system has such a capabililty (in the fasl loader). We have used it internally as a means of batching together some related compiled files, and for "tacking on" patch files. However, I don't know just how or when this will be made available for customer use. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 87 19:22:26 EST Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87 16:06:25 PST Received: by mit-ems (5.54/4.8) id AA07193; Sun, 18 Jan 87 17:30:49 EST Date: Sun, 18 Jan 87 17:30:49 EST From: smh@mit-ems (Steven Haflich) Message-Id: <8701182230.AA07193@mit-ems> To: common-lisp@sail.stanford.edu Subject: Re: preprocessor-based Common Lisps Just for the record, COMPILE-FILE must read the source file with READ because otherwise EVAL-WHEN and reader macros would have a difficult time of it. See CLtL p.69 under EVAL-WHEN: "... a model of how the compiler processes forms in a file to be compiled. Successive forms are read from the file using the function READ." Even though this is only a "model", I take it to mean that the actual implementation must provide the same semantics, and thus should be indestinguishable from READ (except, perhaps, with regard to things like (TRACE READ) ).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 87 17:20:56 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Jan 87 14:08:55 PST Received: by hplabs.HP.COM ; Sun, 18 Jan 87 14:08:56 pst Received: from hpfcjrd.HP.COM by hpfclp; Sun, 18 Jan 87 15:06:47 mst Received: by hpfcjrd; Sun, 18 Jan 87 15:06:06 mst Date: Sun, 18 Jan 87 15:06:06 mst From: John Diamant Return-Path: Message-Id: <8701182206.AA06619@hpfcjrd.HP.COM> To: Masinter.pa@Xerox.COM Subject: Re: preprocessor-based Common Lisps Cc: common-lisp@sail.stanford.edu > From: Masinter.pa@Xerox.COM > > You don't say what you think a "pre-processor" is or does. Is READ a > pre-processor? (I don't think so, but...) This was sent to me as private mail, but I will respond to the entire list because I want to get as much useful information as possible, and Larry's point is valid. I would not consider READ to be a preprocessor. What I am looking for are implementations that take some of the task of the interpreter and compiler and combine them into a common pass. Graphically: interpreter / preprocessor \ compiler This could be as simple as a tokenizer, or as complex as everything but the code generator in the compiler being moved to the preprocessor (but then the interpreter would have to share the preprocessor -- otherwise, it would just be a piece of the compiler). Since READ is required by Common Lisp (though I suppose it doesn't actually say anywhere that the compiler has to READ the file, I think this is obvious that it should), this would not be anything unusual. I am looking for "alternate evaluation strategies" as referred to by CLTL. Thus, an compile-only implmentation would also be interesting to me. John Diamant Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 87 15:08:21 EST Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 18 Jan 87 11:55:23 PST Date: 18 January 1987, 11:54:13 EST From: "Timothy P. Daly" To: common-lisp@sail.stanford.edu Message-Id: <011887.115414.daly@ibm.com> Subject: append option on compile-file The ability to say (COMPILE-FILE "foo.lisp" :APPEND "foo.bin") can be generalized to allow access to the streams used by compile-file. Thus I would be able to "compile-file to a stream", then "load from the stream". Is there anything in Cltl that implies that one cannot perform incremental updates to a FASL file or manipulating FASL structures as streams? Certainly there are file structures that would allow this kind of update are well known. Most binary file libraries allow this kind of update. Tim Daly DALY@IBM.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 87 00:43:11 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Jan 87 21:31:42 PST Received: by hplabs.HP.COM ; Sat, 17 Jan 87 21:31:19 pst Received: by hpfclp; Sat, 17 Jan 87 22:28:27 mst Date: Sat, 17 Jan 87 22:28:27 mst From: John Diamant Return-Path: To: common-lisp@sail.stanford.edu Subject: preprocessor-based Common Lisps I am trying to collect a comprensive list of Common Lisp implementations that use a preprocessor, or anything remotely like one. This would mean anything from a simple tokenizer to a full preprocessor. I would appreciate any information which you could supply, including not only the implementation, but also some explanation of the extent to which a preprocessor is used. I am quite familiar with HP's implementation, as I was one of the implementors, but I would like to hear about other implementations which use varying degrees of preprocessor technology. I would also like to know about any implementations that use a compile-only strategy. Thanks in advance, John Diamant Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 87 00:29:57 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Jan 87 21:17:31 PST Received: by hplabs.HP.COM ; Sat, 17 Jan 87 21:12:01 pst Received: by hpfclp; Sat, 17 Jan 87 21:37:33 mst Date: Sat, 17 Jan 87 21:37:33 mst From: John Diamant Return-Path: To: common-lisp@sail.stanford.edu Subject: Re: :append keyword on compile-file In-Reply-To: article <280152@hpfcjrd.HP.COM> of Sat, 17 Jan 87 19:24:23 MST > Subject: :append keyword on compile-file > From: "Timothy P. Daly" > > Has anyone implemented a compile-file extension that would allow > the fast load file to be updated? > > I would like to be able to say: > > (COMPILE-FILE "foo.lisp" :APPEND "foo.bin") > > > This would enable me to supercede functions that exist in a fast load > file without recompiling the world. While this is possible to implement, I doubt it would have the effect you desire. It is quite common for a FASL (fast load) file to have information like a symbol table at the beginning of the file. Appending to a FASL file might require extending or modifying the symbol table (or other preliminary structures in the file). Efficiently implementing what you suggest implies a sequential ordering of the FASL file that may not exist. Thus, this option may be implementable by everyone, but it might be vastly more efficient in some implementations, and in fact, under certain circumstances may not gain much at all. John Diamant Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Jan 87 13:04:40 EST Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 17 Jan 87 09:54:05 PST Date: 17 January 1987, 11:34:43 EST From: "Timothy P. Daly" To: common-lisp@sail.stanford.edu Message-Id: <011787.113443.daly@ibm.com> Subject: :append keyword on compile-file Has anyone implemented a compile-file extension that would allow the fast load file to be updated? I would like to be able to say: (COMPILE-FILE "foo.lisp" :APPEND "foo.bin") with the effect that the compiler output would append its output to the existing file rather than create a new file. The ultimate effect of loading the FOO.BIN file should be that of loading the original fast load file followed by the new fast load file. This would enable me to supercede functions that exist in a fast load file without recompiling the world.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jan 87 19:21:17 EST Received: from ERNIE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 16:07:45 PST Received: by ernie.Berkeley.EDU (5.57/1.16) id AA21284; Fri, 16 Jan 87 15:53:03 PST Date: Fri, 16 Jan 87 15:53:03 PST From: wahlster@ernie.Berkeley.EDU (Prof. Wolfgang Wahlster) Message-Id: <8701162353.AA21284@ernie.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: mailing list Please put me on the mailing list for the discussions about common lisp. Thanks  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jan 87 17:56:02 EST Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 14:31:26 PST Received: by EDDIE.MIT.EDU (5.31/4.7) id AA02993; Fri, 16 Jan 87 17:33:12 EST Received: by prime.uucp (1.1/SMI-3.0DEV3) id AA04549; Fri, 16 Jan 87 14:26:32 EST Message-Id: <8701161926.AA04549@prime.uucp> Received: (from user DOUG) by ENX.Prime.PDN; 16 Jan 87 13:40:19 EDT To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 16 Jan 87 13:40:20 EDT I think that people forget the purpose of standards organizations. It is almost never the purpose of such organizations to change existing practice. The proposed charter of X3J13 (which will hopefully standardize Common LISP) by Steele says explicitly that the primary purpose is to codify existing practice. And don't forget that a major purpose of Common LISP was to provide a !!stable!! base for development for software designers. Although the issue of one namespace vs. two has gotten alot of discussion (which it deserves), it would seem impossible at this time to change the existing language. Many problems need to be solved before a one namespace LISP with macros is acceptable and a standard is the wrong place for this. The right place is in academia where such instability and experimentation is both acceptable and expected. Barry Margolin's suggestion of &functional is an attempt to extend the language to answer the people who object to the two namespaces on the grounds that it inhibits functional programming. It seems to do this fairly well. One can also do this today with explicit flet/labels. Douglas Rand PRIME Computer dougr@eddie.mit.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jan 87 10:00:16 EST Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 06:43:21 PST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA21565; Fri, 16 Jan 87 06:43:30 PST Message-Id: <8701161443.AA21565@decwrl.dec.com> Date: Friday, 16 Jan 1987 06:42:06-PST From: vanroggen%bizet.DEC@decwrl.DEC.COM To: common-lisp@sail.stanford.edu, vanroggen%bizet.DEC@decwrl.DEC.COM Subject: LISP POINTERS newsletter announcement *** ANNOUNCEMENT *** LISP POINTERS We're putting together a newsletter and we'd like you to come along. Every other month, starting in March of 1987, Lisp Pointers will be bringing you articles, implementation summaries, opinion columns, and information on the lastest action on the standardization front. And we need you -- to contribute to our departments, to read the results of our efforts, and to suggest ways we can provide more of the kinds of information you want to see. Lisp Pointers is being funded by companies who care about the future of Lisp. The editorial content of the newsletter will not be influenced by these companies nor will the companies be responsible for the material contained within Lisp Pointers. Until such time as we affiliate with a more formal organization, subscriptions to Lisp Pointers will be free. Please spread the word among your friends, both real and electronic. Our newsletter will be available through the mails. To join our mailing list, send your name and address to: Mary S. Van Deusen, Editor IBM Research PO Box 704 Yorktown Heights, New York 10598 914-789-7845 617-384-2526 MAIDA@IBM.COM Contributions should be sent directly to the appropriate department: ***LETTERS TO THE EDITOR, NEWS ITEMS*** Mary S. Van Deusen (see above) ***IMPLEMENTATIONS*** Walter van Roggen DEC 77 Reed Road HL02-3/E9 Hudson, Massachusetts 01749 617-568-5617 VANROGGEN%BACH.DEC@DECWRL.DEC.COM ***BOOK REVIEWS, BIBLIOGRAPHIES*** Daniel Weinreb Symbolics, Inc. 11 Cambridge Center Cambridge, Massachusetts 02142 617-577-7500 DLW@MC.LCS.MIT.EDU ***X3J3 LISP STANDARDIZATION*** Robert F. Mathis 9712 Ceralene Drive Fairfax, Virginia 22032 703-425-5923 mathis@b.isi.edu ***USERS*** Susan Ennis Amoco Production Co. PO Box 3385 Tulsa, Oklahoma 74102 918-660-3588 ***TECHNICAL ARTICLES*** Jonl White Lucid, Inc. 707 Laurel Street Menlo Park, California 94025 415-329-8400 edsel!bhopal!jonl@navajo.stanford.edu ***ENVIRONMENTS*** John Foderaro Franz Inc. 1141 Harbor Bay Parkway Suite 270 Alameda, California 94501 415-769-5656 jkf%franz.uucp@berkeley.edu ***SCHEME*** Will Clinger M/S 50-662 Tektronics Inc. PO Box 500 Beaverton, Oregon 97077 willc%tekchips@tek.csnet 503-627-4675 ***LISP QUESTIONS*** Patrick Dussud Texas Instruments 12501 Research Boulevard MS 2201 Austin, Texas 78759 dussud%jenner%ti-csl.csnet@csnet-relay ***INTERNATIONAL ISSUES*** Christian Quiennec LITP 4 Place Jussieu F-75252, Paris Cedex 05 FRANCE tel: +33 (1) 43 36 25 25 x 5251 UUCP: ..!mcvax!inria!queinnec ARPA: mcvax!inria!queinnec@seismo.css.GOV  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 87 11:36:42 EST Date: 15 Jan 87 0821 PST From: Dick Gabriel Subject: Issues of Function Cell To: common-lisp@SAIL.STANFORD.EDU The TEX source for the paper ``Issues of Separation in Function Cells and Value Cells'' is in the file FUNCEL.TEX[COM,LSP], which can be FTPed without login. You might have a little trouble with the Tex instructions scattered throughout, and this version of the paper is the next-to-last draft. -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 87 09:20:22 EST Received: from HI-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 06:06:11 PST Received: from HIS-PHOENIX-MULTICS.ARPA by HI-MULTICS.ARPA dial; 14-Jan-1987 19:33:48-cst Sender: Barry Margolin Date: Wed, 14 Jan 87 17:34 MST From: Barry Margolin Subject: Re: &function To: Timothy.Freeman@THEORY.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: Message of 14 Jan 87 16:45 MST from "Timothy.Freeman at THEORY.CS.CMU.EDU" Message-ID: <870115003457.658506@HIS-PHOENIX-MULTICS.ARPA> Okay, but this only eliminates the funcall's for variables which appear as arguments. What about variables that are not arguments? Is there any reason it should be easier to invoke a function object that came in as an argument than one that didn't? More irregularities in our language... If a global variable is holding a function, the right place to put it is in the function cell, not the value cell. The analogy here is that "&function symbol" is to "defun symbol" as "symbol" is to "setq symbol". What you didn't mention, but perhaps meant to imply, is that FUNCALL would still be required when the function is in a computed location, such as on a property list. Scheme would allow ((get symbol indicator) args) but Common Lisp with &function still wouldn't. I will grant you this. This keyword also serves a secondary function, that of documenting the fact that a particular parameter is expected to be a function. This is useful for programmers, and compilers can also assume a default declaration for the parameter. Is there some reason we need documentation that a variable is a function but we don't need documentation that a variable is an integer? This is an argument for going to a strongly typed language (or one that has a very irregular structure). Those of us who believe in two namespaces feel that the distinction between function names and variable names is more important than the distinction between integers and floats. Even for heavy users of functional programming, I'm sure that most of the time functions are called, not passed around as data. I think the one-namespace arrangement is easier to understand and use than what we have now. Does anyone have any explanation of why the double-namespace arrangement should be kept? Have you read KMP and RPG's paper, "Issues of Separation in Function Cells and Value Cells"? It gives the many arguments on both sides of the issue. It is document X3J13/86-010, and it was sent out to all X3J13 members before the December meeting. If you are not a member, you can probably get a copy from someone who is (Scott Fahlman is the only CMU person who comes to mind immediately). I think the burden of proof should be on the people supporting the more complex scheme. (No pun intended.) I think that the burden of proof should be on the people favoring changing the language. Common Lisp is mostly descended from a long line of two-namespace dialects, it is already building a strong following, so an incompatible change of this magnitude should only be made if the language without the change is severely deficient. People have been doing significant programming in MacLisp and Zetalisp for two decades, so I don't think the two namespaces limits the usefulness of the language greatly. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 87 04:51:39 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 01:35:59 PST Received: by navajo.stanford.edu; Thu, 15 Jan 87 01:34:54 PST Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA01027; Thu, 15 Jan 87 00:37:46 pst Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA01969; Thu, 15 Jan 87 01:17:39 PST Date: Thu, 15 Jan 87 01:17:39 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8701150917.AA01969@bhopal.edsel.uucp> To: navajo!Timothy.Freeman%theory.cs.cmu.edu@navajo.stanford.edu Cc: navajo!common-lisp%su-ai@navajo.stanford.edu, navajo!thomas.gross%sam.cs.cmu.edu@navajo.stanford.edu In-Reply-To: Timothy.Freeman@theory.cs.cmu.edu's message of Sunday, 11 January 1987 22:22:19 EST Subject: Packages & Compiling The quotation you attribute to me is a little bit out of context in that the phrase ". . . requirement that the package world be EXACTLY the same at load time that it was at compile time." wasn't meant to imply that you will be guaranteed to lose when that "requirement" is violated -- only that you can't be guaranteed to win. In particular, lots of trivial such violations occur all the time, with no lossage. The kind of lossage you and Tom Gross had experienced may have been caused by a different set of using packages between the compilation environment and the load time environment. At any rate, such a difference (in the package-use-list of your application package) may or may not cause trouble -- depends upon whether your compiled file uses any of the symbols that were accessible via inheritance from the package that was "used" at compile time but missing at load time, or has any symbols which are expected to be created in the application package but which are spuriously inherited from a used package that wasn't also used at compile time. There are other possible problems too, but they are not all related to compilation. For example, it is not at all difficult to cook up a little test file that will "act differently" when merely loaded in interpretively two times in a row. But of course, loading a compiled file compounds the number of cases in which you may lose because, typicaly, the compiled-file "reader" is not at all the same as READ. In general, however, you are touching on the issue of insulating the compilation environment from *any* side-effects occuring in the lisp before the file compilation in question, including those caused by previous compilations. You specifically bring up only the issue of compiling a file twice, and seeing a different package environment the second time. But the potential for lossage is much more complex than merely package side effects; for example, think of macro definitions -- do you want them visible or not? maybe sometimes "yes" and sometimes "no". There was a paper in the 1986 Lisp Conference on an "Un-Common Lisp" that mentioned one partial solution the the issue. There is also an ANSI sub-committee addressing the issue of compilation semantics -- perhaps they will attempt to define just how much insulation you can expect. Quite possibly, they should address the semantics of just how the compiled file reader can differ from READ. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 87 22:54:45 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Jan 87 19:36:51 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 87 17:43:06 PST Date: 14 Jan 87 17:44 PST From: Masinter.pa@Xerox.COM Subject: Re: &function In-reply-to: Timothy.Freeman@theory.cs.cmu.edu's message of Wed, 14 Jan 87 18:45:28 EST To: Timothy.Freeman@theory.cs.cmu.edu cc: common-lisp@sail.stanford.edu Message-ID: <870114-174306-1126@Xerox> It is unfortunately the case that the "burden of proof" necessarily lies on those would would modify Common Lisp. In particular, it is clearly part of the charter of the Common Lisp standards group that changes to Common Lisp only be made after explicit consideration of the costs involved. There is a very good 40-page paper by Richard Gabriel and Kent Pitman which goes into some details of all of the complex interactions that one-namespace would have with a variety of other features of Common Lisp, including macros, default dynamic binding for free references, etc. I recommend it as required background reading.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 87 19:03:38 EST Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 15:46:38 PST Date: Wednesday, 14 January 1987 18:45:28 EST From: Timothy.Freeman@theory.cs.cmu.edu To: Barry Margolin cc: common-lisp@sail.stanford.edu Subject: &function Message-ID: <1987.1.14.23.10.37.Timothy.Freeman@theory.cs.cmu.edu> I'm not sure I really agree that it is a significant deterrent, and there are reasonable arguments in favor of requiring FUNCALL, but for the purpose of this discussion let's assume that it is. Each irregularity of the language requires some effort to learn. Since normal variable evaluation is much more common than funcalls, the requirement to learn the semantics of funcall is an deterrent to using it. Unless there is some benefit gained from the irregularity, it shouldn't exist. The keyword &function in the lambda list indicates that the functional interpretation of the following parameter should be bound, rather than the value interpretation. This is analogous to the distinction between LET and FLET. Okay, but this only eliminates the funcall's for variables which appear as arguments. What about variables that are not arguments? Is there any reason it should be easier to invoke a function object that came in as an argument than one that didn't? More irregularities in our language... This keyword also serves a secondary function, that of documenting the fact that a particular parameter is expected to be a function. This is useful for programmers, and compilers can also assume a default declaration for the parameter. Is there some reason we need documentation that a variable is a function but we don't need documentation that a variable is an integer? This is an argument for going to a strongly typed language (or one that has a very irregular structure). I think the one-namespace arrangement is easier to understand and use than what we have now. Does anyone have any explanation of why the double-namespace arrangement should be kept? I think the burden of proof should be on the people supporting the more complex scheme. (No pun intended.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 87 14:55:32 EST Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 14 Jan 87 11:30:07 PST Date: Wed, 14 Jan 87 14:12 EST From: Barry Margolin Subject: &function To: common-lisp@SU-AI.ARPA Message-ID: <870114191239.078904@BCO-MULTICS.ARPA> I brought the following proposal up during the December X3J13 meeting, and it was requested that I send it to the list to allow for easier digesting and further discussion. We were discussing the pros and cons of merging the function and value namespaces. One of the issues used to support the single namespace is that functional arguments are clumsy to use when FUNCALL is required, and this may inhibit people from using high-order function composition. I'm not sure I really agree that it is a significant deterrent, and there are reasonable arguments in favor of requiring FUNCALL, but for the purpose of this discussion let's assume that it is. So, the one-namespace people argue that (defun twice (fun) #'(lambda (x) (fun (fun x)))) is clearer than (defun twice (fun) #'(lambda (x) (funcall fun (funcall fun x)))) This is then used as an argument that the value and function cells of variables should be identical. My proposal allows functional arguments to be called without using FUNCALL, but still retaining the distinct namespaces. My version of the above function would be (defun twice (&function fun) #'(lambda (x) (fun (fun x)))) The keyword &function in the lambda list indicates that the functional interpretation of the following parameter should be bound, rather than the value interpretation. This is analogous to the distinction between LET and FLET. This keyword also serves a secondary function, that of documenting the fact that a particular parameter is expected to be a function. This is useful for programmers, and compilers can also assume a default declaration for the parameter. One of the issues that was brought up when I proposed this at the meeting is that it lacks one important feature that FLET has: the lambda list of the local function. This could be solved in two ways. First, the &function syntax could be extended, so that it is &function name lambda-list I don't really care for this, because it puts a whole lot of stuff in the outer function's lambda list, and because two list elements are used for one parameter (the latter could be dealt with by making it &function (name lambda-list) ). The other solution is to use a declaration at the beginning of the function body to specify the calling sequence. This would be necessary in order to specify the types of the arguments. The two mechanisms could be combined, so that the syntax would be &function (name arg-typespecs) since there would be no use for argument names anyway (except for self-documentation purposes). &function can also be described in terms of a source transformation. The example function could be rewritten as (defun twice (g0001) (flet ((fun (&rest args) (apply g0001 args))) #'(lambda (x) (fun (fun x))))) Of course, it gets more complicated when the ideas for specifying the arguments are added, but no one ever said compiler writing was easy. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jan 87 00:20:09 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Jan 87 16:08:50 PST Received: ID ; Tue 13 Jan 87 19:08:13-EST Date: Tue, 13 Jan 1987 19:08 EST Message-ID: From: Rob MacLachlan To: "Robert W. Kerns" Cc: common-lisp@SAIL.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU Subject: Packages & Compiling In-reply-to: Msg of 13 Jan 1987 08:21-EST from Robert W. Kerns Date: Tuesday, 13 January 1987 08:21-EST From: Robert W. Kerns Re: Packages & Compiling ... Dumping should be kept strictly analogous to printing, and loading to reading, so far as package-prefix hacking is concerned. This is a reasonable way to dump symbols, but it isn't obvious to me that it is the only correct way. In fact, it would have made no difference in my example, since I was assuming that X wasn't accessible in the current package. It is a question of how far we require implementations to go in allowing changes in the package environment. I think an argument can be made for requiring a more strict equivalence, which would still allow your interpretation to be legal. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Jan 87 08:50:55 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 13 Jan 87 05:37:41 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 147826; Tue 13-Jan-87 08:20:43 EST Date: Tue, 13 Jan 87 08:21 EST From: Robert W. Kerns Subject: Packages & Compiling To: Rob MacLachlan cc: Timothy.Freeman@THEORY.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU, edsel!bhopal!jonl@NAVAJO.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU In-Reply-To: Message-ID: <870113082109.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Mon, 12 Jan 1987 20:08 EST From: Rob MacLachlan Date: Monday, 12 January 1987 19:15-EST From: Timothy.Freeman at theory.cs.cmu.edu Re: Packages & Compiling ... Allowing the compiler to depend upon the package environment when it is compiling a not-in-line function call doesn't allow it to produce better code. True; it simply allows the compiler to function. The basic problem is that if you use READ to read, there is no way to intern the symbol the same way at load time, since the reader threw away the information about how the symbol was read. For example, if the source file contains the symbol reference FOO::X, but X's home package is actually BAR, then the compiler will dump code which does the equivalent of reading BAR::X at load time. The result will be the X currently accessible in the BAR package, regardless of what symbol is currently accessible in the FOO package. In contrast, if FOO::X was read again by loading the source, then the symbol would be read as whatever X is accessible in the FOO package. Rob This has been discussed in the past. If the compiler doesn't dump BAR::X, but rather just "X" (just like the printer would), then the loader will make the same decisions the compiler did. Dumping should be kept strictly analogous to printing, and loading to reading, so far as package-prefix hacking is concerned. This certainly needs to be made a part of the standard, or implementors aren't going to realize this and their users are going to have the problems you refer to. We didn't get it right our first time around, either. This doesn't confer immunity to package-heirarchy changes, of course. Among the ways you can lose at load time include: 1) Refering to a package that is no longer there. Obviously, a source change would have been necessary. 2) Making an exported symbol be unexported. (Although a source change might have been necessary in this case, too). 3) Moving a symbol from one package to another, when you want to continue refering to the same symbol. Of course, you have to change the source anyway, so it's not suprising you have to recompile. 4) You said BAR::X, at compile time X was accessible in FOO, but at run time, it was not. No source change is necessary, because you already had it right. But in practice, these aren't very serious, while it is much more serious if you can't change which X you import into your package. In fact, I think #2 and #4 are the only cases where you really do suffer from READ not preserving information.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Jan 87 08:47:54 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 13 Jan 87 05:34:24 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 147830; Tue 13-Jan-87 08:29:34 EST Date: Tue, 13 Jan 87 08:30 EST From: Robert W. Kerns Subject: Re: Packages & Compiling To: Timothy.Freeman@theory.cs.cmu.edu cc: common-lisp@sail.stanford.edu, edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu In-Reply-To: <1987.1.12.23.41.38.Timothy.Freeman@theory.cs.cmu.edu> Message-ID: <870113083027.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Monday, 12 January 1987 19:15:36 EST From: Timothy.Freeman@theory.cs.cmu.edu Date: Mon, 12 Jan 87 15:12 EST From: Daniel L. Weinreb It's also true that if the value of *read-base* is different when you do the compilation, or if the read table has been altered in any way, all bets are off. If I start having problems with these variables having the wrong value, I can always write a little function or macro that sets or binds them to standard values. In fact, the problem is not unique to the compiler. We have a macro, WITH-STANDARD-IO-ENVIRONMENT, which does this for all the read/print controls. The idea is that you wrap this around anything which prints with an expectation that something will later read it with the same interpretation, and also around the code which reads it. Unfortunately, in a fit of blinding stupidity (and there's AT LEAST a 50% chance it was MY stupidity) we made it use ZL-USER instead of USER, thus saddling ourselves with somewhat of a compatibility problem. So I'd appreciate it if someone could come up with a better name for a CL-standard version of this.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 87 20:24:36 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 17:10:14 PST Received: ID ; Mon 12 Jan 87 20:08:11-EST Date: Mon, 12 Jan 1987 20:08 EST Message-ID: From: Rob MacLachlan To: Timothy.Freeman@THEORY.CS.CMU.EDU Cc: common-lisp@SAIL.STANFORD.EDU, edsel!bhopal!jonl@NAVAJO.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU Subject: Packages & Compiling In-reply-to: Msg of 12 Jan 1987 19:15-EST from Timothy.Freeman at theory.cs.cmu.edu Date: Monday, 12 January 1987 19:15-EST From: Timothy.Freeman at theory.cs.cmu.edu Re: Packages & Compiling ... Allowing the compiler to depend upon the package environment when it is compiling a not-in-line function call doesn't allow it to produce better code. True; it simply allows the compiler to function. The basic problem is that if you use READ to read, there is no way to intern the symbol the same way at load time, since the reader threw away the information about how the symbol was read. For example, if the source file contains the symbol reference FOO::X, but X's home package is actually BAR, then the compiler will dump code which does the equivalent of reading BAR::X at load time. The result will be the X currently accessible in the BAR package, regardless of what symbol is currently accessible in the FOO package. In contrast, if FOO::X was read again by loading the source, then the symbol would be read as whatever X is accessible in the FOO package. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 87 20:14:29 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jan 87 16:40:11 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41926; Mon 12-Jan-87 19:39:48 EST Date: Mon, 12 Jan 87 19:38 EST From: Kent M Pitman Subject: mailing list requests To: Joseph.Ginder@spice.cs.cmu.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <1987.1.7.15.59.57.Joseph.Ginder@spice.cs.cmu.edu> Message-ID: <870112193832.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wednesday, 7 January 1987 11:02:14 EST From: Joseph.Ginder@spice.cs.cmu.edu For the record, where should one send mailing list requests for the general common lisp mailing list and the various sub-lists? Please send administrative requests such as list addition/removal requests to RPG@SAIL.STANFORD.EDU (a.k.a. RPG@SU-AI.ARPA). Encourage your friends to do likewise. Please do not send such requests to Common-Lisp. Thanks.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 87 19:32:15 EST Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 16:15:05 PST Date: Monday, 12 January 1987 19:15:36 EST From: Timothy.Freeman@theory.cs.cmu.edu To: common-lisp@sail.stanford.edu cc: edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu Subject: Re: Packages & Compiling Message-ID: <1987.1.12.23.41.38.Timothy.Freeman@theory.cs.cmu.edu> In-Reply-To: <870112151228.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 12 Jan 87 15:12 EST From: Daniel L. Weinreb It's also true that if the value of *read-base* is different when you do the compilation, or if the read table has been altered in any way, all bets are off. In other words, the phenomenon is not specific to packages, but applies to any state information that affects the actions of the Lisp reader. The compiler has to be careful to do its reading with all the parameters set appropriately. I don't have any problem with the values of a couple of special variables affecting the behavior of the compiler for two reasons. (This is not a statement about whether these dependencies should exist; I'm just trying to say that they are less troublesome.) If I start having problems with these variables having the wrong value, I can always write a little function or macro that sets or binds them to standard values. I don't change the values I use for these variables often, so the problem never really arises. The dependency of the behavior of the compiler upon the package environment does give me problems for the same two reasons: It is normal for the code that is being compiled to change the package environment, so there is no standard value for the package environment. I do change the package environment often, so this is a real problem. In general, the compilation process should not depend upon aspects of the current environment which are not easy to change, unless that dependency allows better code to be produced. Allowing the compiler to depend upon the package environment when it is compiling a not-in-line function call doesn't allow it to produce better code.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 87 18:48:03 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 15:33:45 PST Received: ID ; Mon 12 Jan 87 18:34:00-EST Date: Mon, 12 Jan 1987 18:33 EST Message-ID: From: Rob MacLachlan To: Timothy.Freeman@THEORY.CS.CMU.EDU Cc: common-lisp@SAIL.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU Subject: Packages & Compiling In-reply-to: Msg of 12 Jan 1987 13:48-EST from Timothy.Freeman at theory.cs.cmu.edu Although it is not currently stated anywhere, it is definitely required that the compiler use READ to parse input files. The whole reason for having an extensible reader is that it allows people to define read macros that can be used in code. Normal macros also demand that source be represented as a s-expression, making life very difficult for any scheme that tries to pass extra information from the reader to the fasl-dumper. It may be possible to preserve package qualification information somehow, but I think any implementation would be unreasonably difficult. It isn't worth "fixing" this problem, since there are dozens of other equally intractable problems that prevent COMPILE-FILE/LOAD from being identical to LOAD of the source. The real problem is that LOAD of a source is over-specified, since "everyone knows" that it is implemented by sequentially reading and evaluating forms. What we need to do is come up with a more restrictive semantics for a "code file" such that a well-formed code file will do the same thing across the full range of legal implementations of Common Lisp evaluation. I won't discuss the non-package compiler issues that you mentioned, since they open a moby can of worms. The rules you give are certainly sufficient, but are not necessary. I said "to the extent which it matters, the package environments must be equivalent" to emphasize the unknown nature of "package equivalence". All I can really say right now is that requiring the package state to be "identical" is too restrictive. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 87 17:26:19 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 12 Jan 87 14:03:24 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 38394; Mon 12-Jan-87 15:13:15 EST Date: Mon, 12 Jan 87 15:12 EST From: Daniel L. Weinreb Subject: Packages & Compiling To: Timothy.Freeman@theory.cs.cmu.edu, common-lisp@sail.stanford.edu cc: edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu In-Reply-To: <1987.1.12.2.10.27.Timothy.Freeman@theory.cs.cmu.edu> Message-ID: <870112151228.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sunday, 11 January 1987 22:22:19 EST From: Timothy.Freeman@theory.cs.cmu.edu CLtL specifies the compiler by saying that "compiling a file of code should produce an equivalent but more efficient program". Jon is saying "compiling a file of code should produce an equivalent but more efficient program, provided that the package environment at compile time is the same as the package environment at load time; otherwise all bets are off". I can imagine ways of implementing compilers so that the qualifier about the package environment is unneccessary. It's also true that if the value of *read-base* is different when you do the compilation, or if the read table has been altered in any way, all bets are off. In other words, the phenomenon is not specific to packages, but applies to any state information that affects the actions of the Lisp reader. The compiler has to be careful to do its reading with all the parameters set appropriately. Our implementation normally accomplishes this by using "file attribute lists", property-list-like things expressed in a special text string that lives in a comment at the head of the file. However, this solution was not adopted in the Common Lisp definition. I agree that there probably is not an adequate replacement available in pure Common Lisp.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jan 87 14:14:41 EST Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 10:48:17 PST Date: Monday, 12 January 1987 13:48:30 EST From: Timothy.Freeman@theory.cs.cmu.edu To: Rob MacLachlan cc: common-lisp@sail.stanford.edu, thomas.gross@sam.cs.cmu.edu Subject: Re: Packages & Compiling Message-ID: <1987.1.12.18.9.40.Timothy.Freeman@theory.cs.cmu.edu> In-Reply-To: We could make it possible for the compiler to maintain the interpreted semantics in this case by making the read function take an optional parameter, which would be function to use to intern the symbols encountered. The default value of this parameter would be #'intern. When the compiler is running, the value of this parameter would be a function that looks at compiler data structures instead of the package world. This would have several advantages: It would allow the compiler to be reentrant. It would make it possible for the compiler to understand a "(use-package :foo)" (or any other package manipulating form) without having to modify the package world. Actually, the compiler is not required to call read, so this could have been done on the initiative of the language implementor without any change in the standard. I think that the following specification of the compiler is implementable (argue with me if you disagree): "The compiler is side-effect free and reentrant, and the semantics of loading a compiled file is the same as the semantics of loading the source, provided that all of the following are true: 1) Only the standard functions are used to manipulate the package environment, and they are top-level forms in the source. 2) Eval-when is not used. 3) All macros referenced by the source code are either defined in the source code with a toplevel defmacro form before they are used, or they are defined when the compiler is called. 4) All macros used are side-effect free and reentrant." You said: "To the extent which it matters, the package environment at the time the compiler interns a symbol must be equivalent to the package environment in which the loader interns the symbol." What exactly did you mean by the phrase "to the extent which it matters"?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 87 23:30:05 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 20:14:55 PST Received: ID ; Sun 11 Jan 87 23:15:13-EST Date: Sun, 11 Jan 1987 23:15 EST Message-ID: From: Rob MacLachlan To: Timothy.Freeman@THEORY.CS.CMU.EDU Cc: common-lisp@SAIL.STANFORD.EDU Subject: Packages & Compiling In-reply-to: Msg of 11 Jan 1987 22:22-EST from Timothy.Freeman at theory.cs.cmu.edu This is another thing that the compiler subcommittee should clear up. In this case, it is not reasonable for the compiler to be required to maintain the interpreted semantics. The problem is that the compiler presumably uses the reader to read the source code, and READ is not an information preserving operation. Since CLTL doesn't admit this problem, it also doesn't properly specify the package semantics of fasloading. There was some discussion of this a while back, and we found that different implementations were doing different things. Although this part of the language is poorly specified, any compiler which can't compile the same file twice is clearly broken. I would "clarify" the requirement for an identical compile and load environment to the following: "To the extent which it matters, the package environment at the time the compiler interns a symbol must be equivalent to the package environment in which the loader interns the symbol." This requirement isn't very useful to users, since it makes references to the times at which the interning is done by the compiler and loader. Especially in the loader, the time of interning may be non-obvious. In practice, there shouldn't be any problem as long as either: 1] The package environment used by a file is initialized using top-level package manipulation code. The compiler will guarantee that package operations done by such forms are properly sequenced with respect to INTERN operations both in the compiler and the loader. 2] Any other required aspects of the package environment are present both at the beginning of the compilation of the file and the beginning of the load of the fasl file. The most common violation of these rules that I have seen it that a user changes the package environment at load time, but doesn't use obvious top-level package manipulation forms. In this case, the compiler tends to get confused, causing the loader to attempt to find packages that don't exist yet, or other bad things. The real problem is that package manipulation forms look like ordinary Lisp code, yet must be treated in a totally magical way by the compiler. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 87 22:38:36 EST Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:22:56 PST Date: Sunday, 11 January 1987 22:22:19 EST From: Timothy.Freeman@theory.cs.cmu.edu To: common-lisp@sail.stanford.edu cc: edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu Subject: Packages & Compiling Message-ID: <1987.1.12.2.10.27.Timothy.Freeman@theory.cs.cmu.edu> Jon L. White from Lucid said in a mail message to me (among other people): Indeed, the most prevalent "obscurity" in the compilation process that snares many users is the requirement that the package world be EXACTLY the same at load time that it was at compile time. The act of compiling a file with calls to IMPORT in it changes the package world structure; and so does loading such a file (or indeed, any file with calls to IMPORT, EXPORT, IN-PACKAGE, USE-PACKAGE, INTERN, etc in it). He isn't clear about whether he is claiming this for Lucid Common Lisp only or for all common lisps anywhere. He didn't give me permission to repeat his words to a mailing list, so please don't crucify him if what he said is wrong. Since most of the lisp I write lives in its own package, most of my source files have calls to import & such. Thus, if I took his statement seriously, I would hardly ever be able to compile the same file twice in the same lisp image and expect the same results from the compilations, because the first compilation's calls to import would cause the second compilation to have a different package environment. CLtL specifies the compiler by saying that "compiling a file of code should produce an equivalent but more efficient program". Jon is saying "compiling a file of code should produce an equivalent but more efficient program, provided that the package environment at compile time is the same as the package environment at load time; otherwise all bets are off". I can imagine ways of implementing compilers so that the qualifier about the package environment is unneccessary. (I'll elaborate my imagination if it becomes apparent that people don't believe me.) Should Jon's statement be true of the common lisp standard? If so, why is doing it that way better than avoiding the repeated compilation problem that is described above?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 87 18:02:44 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 11 Jan 87 14:49:34 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146821; Sun 11-Jan-87 17:36:14 EST Date: Sun, 11 Jan 87 17:36 EST From: Robert W. Kerns Subject: Recursive COMPILE-FILE? To: Scott E. Fahlman cc: Stuart A. Malone , common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870111173656.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Fri, 9 Jan 1987 12:58 EST From: "Scott E. Fahlman" Is a Common Lisp compiler required to correctly handle forms such as: (eval-when (compile) (compile-file "utils")) I don't think that there's anything in the current spec that requires COMPILE-FILE to be re-entrant, There's nothing in the current spec that requires FUNCALL, or MAP, or MAPHASH to be re-entrant, either. I don't think the default assumption should be that things only work in specific documented cases. I think it should be assumed that they work unless there are specific documented exceptions. and at least a couple of implementations would have a hard time doing this because of the way they store the compilation environment. I can't believe it would be hard to fix any such broken implementations. In the worst case I can imagine, you'd have to do a global query-replace on GET to use a COMPILER-TABLE-GET macro that expanded into a GETHASH or GETF as appropriate. You'd probably get a big paging-performance improvment in the process.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jan 87 03:15:08 EST Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 00:04:24 PST Date: Sun 11 Jan 87 02:05:19-CST From: CMP.LADAI@R20.UTEXAS.EDU Subject: Common Classes Bboard? To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12270000413.37.CMP.LADAI@R20.UTEXAS.EDU> Is there a Bboard or Mailing List or anything else where I can listen in on discussions or progress on the proposed CL object- oriented extension, Common Classes? -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jan 87 18:33:53 EST Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 10 Jan 87 15:20:40 PST Received: from milano.sw.mcc.com by MCC.COM with TCP; Sat 10 Jan 87 17:20:54-CST Received: from tachyon (tachyon.ARPA) by milano.sw.mcc.com (4.12/STP) id AA28284; Sat, 10 Jan 87 17:20:44 cst Date: Sat, 10 Jan 87 17:20:52 CST From: Michael Sierchio Posted-Date: Sat, 10 Jan 87 17:20:52 CST Message-Id: <8701102320.AA00756@tachyon> Received: by tachyon (1.1/STP) id AA00756; Sat, 10 Jan 87 17:20:52 CST Subject: Bugs in Common LISPcraft Newsgroups: comp.lang.lisp,fa.clisp Distribution: net To: Common-Lisp@SU-AI.Arpa Keywords: Confusion and the Like I just wanted to point out some errors in the book Common LISPcraft by Robert Wilensky (Norton 1986). The book is entirely praiseworthy in its exposition of Common Lisp, both for beginners and pros in other Lisp dialects. However, there are two errors that I have spotted that might make it difficult for novices to understand a few basic points. On page 75, there is a sample function, and commentary beneath it. The 4th text paragraph refers to a conditional test "(null ll)". The expression in the function definition actually reads "(atom ll)". This is the intended statement, by the way. It's the text that's wrong. (atom ll) will, of course, return t if ll is an empty list. On page 153, there is a sample expression describing the use of "(let ..)". It reads: (let ((temp (func1 x y z)) (func2 temp) (func3 temp)) There's a paren missing, which is a normal occurance in Lisping -- however, since this means incorrect syntax, and is likely to confuse the poor reader, it is worth noting as an error. It should read: (let ((temp (func1 x y z))) (func2 temp) ^ (func3 temp)) | (the missing paren) There are other typos, but none that a reader of English should have trouble with. This is not meant to be a complete list of errors. I will post any other major ones that I find. Someone at Cal Berkeley could do me the favor of pointing this out to Wilensky. (tell Norton and anyone who's listening that I'm available for editing any or all computer books!) -- Michael Sierchio @ MCC Software Technology Program UUCP: ut-sally!im4u!milano!sierchio ARPA: sierchio@mcc.ARPA "WE REVERSE THE RIGHT TO SERVE REFUSE TO ANYONE"  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jan 87 12:27:33 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jan 87 09:14:26 PST Date: Sat, 10 Jan 87 12:17:33 EST From: Jonathan A Rees Subject: Recursive COMPILE-FILE? To: SAM@XX.LCS.MIT.EDU cc: common-lisp@SAIL.STANFORD.EDU In-reply-to: Msg of Fri 9 Jan 87 12:44:09-EST from Stuart A. Malone Message-ID: <138659.870110.JAR@AI.AI.MIT.EDU> This issue was discussed, briefly, sometime in the past year or two. As I remember, I said something similar to the following at that time, and got no response: There's nothing in CLtL that would suggest that there is any context in which it would be an error to call COMPILE-FILE. It should no more be an error to call COMPILE-FILE from a macro expander or EVAL-WHEN form than it would be an error to call CAR or OPEN. I can think of no reasonable excuse for a compiler implementor to suggest that COMPILE-FILE should not be re-entrant. So I would say that you are permitted to complain when it is not. Jonathan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jan 87 15:50:00 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jan 87 12:34:47 PST Date: Fri 9 Jan 87 15:34:22-EST From: Stuart A. Malone Subject: Recursive COMPILE-FILE? To: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <870109125312.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12269612486.14.SAM@XX.LCS.MIT.EDU> Is a Common Lisp compiler required to correctly handle forms such as: (eval-when (compile) (compile-file "utils")) I think you need to define "correctly handle" a little more explicitly. -------- I'm sorry if I wasn't clear. I usually follow such a form with a form like: (eval-when (compile) (load "utils")) This pair of forms produces a useful result in the implementations I am using, because it assures (in these implementations) that functions I have declared inline will actually be coded inline. By "correctly handle" I meant that the file "utils" should be compiled (producing a side-effect on the file system) and that the compilation of the main file should continue without error. I didn't think that whether or not I decided to load the resulting fasload file had any bearing on the question. --Stuart -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jan 87 13:15:59 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Jan 87 10:00:07 PST Received: ID ; Fri 9 Jan 87 12:59:06-EST Date: Fri, 9 Jan 1987 12:58 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Stuart A. Malone" Cc: common-lisp@SAIL.STANFORD.EDU Subject: Recursive COMPILE-FILE? Is a Common Lisp compiler required to correctly handle forms such as: (eval-when (compile) (compile-file "utils")) I don't think that there's anything in the current spec that requires COMPILE-FILE to be re-entrant, and at least a couple of implementations would have a hard time doing this because of the way they store the compilation environment. Obviously it is better for all concerned if something like this does work in your favorite implementation, but I don't think it is required. There is now a subcommittee under X3J13 that is studying the whole question of tightening up the compiler specifications. It will be up to them to weigh the costs and benefits of requiring this change and to make a recommendation to X3J13. I'm sure at some point they will be seeking the community's input on such issues. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jan 87 13:07:30 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jan 87 09:54:44 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39867; Fri 9-Jan-87 12:54:18 EST Date: Fri, 9 Jan 87 12:53 EST From: David A. Moon Subject: Recursive COMPILE-FILE? To: Stuart A. Malone cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <12269581500.45.SAM@XX.LCS.MIT.EDU> Message-ID: <870109125312.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri 9 Jan 87 12:44:09-EST From: Stuart A. Malone Is a Common Lisp compiler required to correctly handle forms such as: (eval-when (compile) (compile-file "utils")) I think you need to define "correctly handle" a little more explicitly. The form you have written says: if this form is encountered at top level by the compiler, compile another file, do nothing with the results of the compilation, and then resume the original compilation. Aside from the creation of a compiler output file in the file system, the only effect of this would be to make the compilation take longer. I assume you really intended for something else to happen?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jan 87 12:56:25 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jan 87 09:44:15 PST Date: Fri 9 Jan 87 12:44:09-EST From: Stuart A. Malone Subject: Recursive COMPILE-FILE? To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12269581500.45.SAM@XX.LCS.MIT.EDU> Is a Common Lisp compiler required to correctly handle forms such as: (eval-when (compile) (compile-file "utils")) I am working with two different implementations of Common Lisp that ignore inline declarations unless the functions being placed inline are compiled, so guaranteeing that the inline "utils" file is always compiled before the main file is useful. May I scream at the compiler implementors to make this work? --Stuart A. Malone -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 87 15:38:34 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 12:21:34 PST Received: by navajo.stanford.edu; Wed, 7 Jan 87 12:20:41 PST Received: from blacksox.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA02629; Wed, 7 Jan 87 11:38:55 pst Received: by blacksox.edsel.uucp (4.12/9.2) id AA00348; Wed, 7 Jan 87 11:38:23 pst Date: Wed, 7 Jan 87 11:38:23 pst From: edsel!babel!eb@navajo.stanford.edu (Eric Benson) Message-Id: <8701071938.AA00348@blacksox.edsel.uucp> To: navajo!Timothy.Freeman%theory.cs.cmu.edu@navajo.stanford.edu Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu, navajo!gross%sam.cs.cmu.edu@navajo.stanford.edu In-Reply-To: navajo!Timothy.Freeman@theory.cs.cmu.edu's message of Wednesday, 7 January 1987 11:37:53 EST Subject: Destructive operations Right you are. I was assuming too much. Just because something may have horrible consequences doesn't necessarily make it illegal. Modifying constants in compiled code has the same legal status as modifying the SYMBOL-NAME string of a symbol. ``It is an extremely bad idea to modify'' a constant in compiled code. ``Such a modification may tremendously confuse'' any function which contains a constant EQUAL to the one being modified. For similar reasons, it is a bad idea to modify any object which is used as a key in an EQUAL hash table (this problem is unfortunately not mentioned in CLtL).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 87 11:52:44 EST Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 08:39:56 PST Date: Wednesday, 7 January 1987 11:37:53 EST From: Timothy.Freeman@theory.cs.cmu.edu To: edsel!babel!eb@navajo.stanford.edu (Eric Benson) cc: common-lisp@sail.stanford.edu, gross@sam.cs.cmu.edu Subject: Re: Destructive operations Message-ID: <1987.1.7.16.26.12.Timothy.Freeman@theory.cs.cmu.edu> In-Reply-To: <8701070049.AA00286@blacksox.edsel.uucp> Because the compiler is permitted to share structure with constants in compiled code, it follows that modifying such a constant is illegal. Pardon me for being thick-headed, but I just don't see why this is true. I would be willing to say that "Because the compiler is permitted to share structure with constants in compiled code, modifying such a constant destructively may have the side effect of modifying any or all other constants which are equal to the given constant". This would allow one to conclude that modifying such a constant is a bad idea, but not that it is illegal. I agree that it ought to be illegal, but I don't see how CLtL implies that it is illegal.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 87 11:13:12 EST Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 08:02:22 PST Date: Wednesday, 7 January 1987 11:02:14 EST From: Joseph.Ginder@spice.cs.cmu.edu To: common-lisp@sail.stanford.edu Subject: mailin{ list requests Message-ID: <1987.1.7.15.59.57.Joseph.Ginder@spice.cs.cmu.edu> For the record, where should one send mailing list requests for the general common lisp mailing list and the various sub-lists? --Joe Ginder  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 20:57:23 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 17:38:06 PST Received: by navajo.stanford.edu; Tue, 6 Jan 87 17:37:22 PST Received: from blacksox.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA01137; Tue, 6 Jan 87 16:49:47 pst Received: by blacksox.edsel.uucp (4.12/9.2) id AA00286; Tue, 6 Jan 87 16:49:13 pst Date: Tue, 6 Jan 87 16:49:13 pst From: edsel!babel!eb@navajo.stanford.edu (Eric Benson) Message-Id: <8701070049.AA00286@blacksox.edsel.uucp> To: navajo!Timothy.Freeman%theory.cs.cmu.edu@navajo.stanford.edu Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu In-Reply-To: navajo!Timothy.Freeman@theory.cs.cmu.edu's message of Tuesday, 6 January 1987 18:55:49 EST Subject: Destructive operations On p.78 of CLtL, in the description of the function EQ, is the following paragraph: ``An additional problem with EQ is that the implementation is permitted to "collapse" constants (or portions thereof) appearing in code to be compiled if they are EQUAL. An object is considered to be a constant in code to be compiled if it is a self-evaluating form or is contained in a QUOTE form. This is why (EQ "Foo" "Foo") might be true or false; in interpreted code it would normally be false, because reading in the form (EQ "Foo" "Foo") would construct distinct strings for the two arguments to EQ, but the compiler might choose to use the same identical string or two distinct copies as the two arguments in the call to EQ. Similarly, (EQ '(A . B) '(A . B)) might be true or false, depending on whether the constant conses appearing in the QUOTE forms were collapsed by the compiler. However, (EQ (CONS 'A 'B) (CONS 'A 'B)) is always false, because every distinct call to the CONS function necessarily produces a new and distinct cons.'' Because the compiler is permitted to share structure with constants in compiled code, it follows that modifying such a constant is illegal. Some systems place such constants in a read-only region of memory.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 19:38:54 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 16:29:20 PST Received: ID ; Tue 6 Jan 87 19:29:33-EST Date: Tue, 6 Jan 1987 19:29 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Timothy.Freeman@THEORY.CS.CMU.EDU Cc: common-lisp@SAIL.STANFORD.EDU, gross@SAM.CS.CMU.EDU Subject: Destructive operations In-reply-to: Msg of 6 Jan 1987 18:55-EST from Timothy.Freeman at theory.cs.cmu.edu In my view, when a constant appears in code, the compiler is free to store this in read-only space or do other strange things that depend on the constantness of the constant. Many useful optimizaitons depend on this. I thought that I could find something in the manual that implied this clearly, but a cursory search failed. The description of DEFCONSTANT says that the compiler assume that such constants will stay put, but I found nothing about other constants, such as '(a b c), that might appear in the body of the code. Still, I think that we must allow the compiler to assume that these things will not be altered destructively. You can always store the list in a variable if you want it to be malleable. CLtL doesn't say much about what the compiler is required to do or not do. A subcommittee of X3J13 has been set up to formulate recommendations on how to fix this. This is one of the issues that they should address. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 19:06:32 EST Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 15:55:19 PST Date: Tuesday, 6 January 1987 18:55:49 EST From: Timothy.Freeman@theory.cs.cmu.edu To: common-lisp@sail.stanford.edu cc: gross@sam.cs.cmu.edu Subject: Destructive operations Message-ID: <1987.1.6.23.36.41.Timothy.Freeman@theory.cs.cmu.edu> I have been using a lisp compiler which gets an access violation at the last statement of the following scenario: (defun foo () '(1 2)) (compile 'foo) ;; Save a core image to disk ;; Run the saved core image (setf (cdr (foo)) 3) ;; The above statement bombs This behavior seems reasonable, and I understand why it is happening. My questions are: If you omit saving and restoring the core image, does this behavior fit the specification? Is the specification too vague about this? My opinion is that it should be permissable for the code to bomb in cases like this. Tim Freeman  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 15:57:17 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 12:38:27 PST Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 6148; 6 Jan 87 15:38:42 EST Date: Tue, 6 Jan 87 15:38 EST From: Brad Miller Subject: maplist and lists To: David C. Plummer cc: common-lisp@sail.stanford.edu, miller@ACORN.CS.ROCHESTER.EDU In-Reply-To: <870106130128.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Message-ID: <870106153848.2.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Date: Tue, 6 Jan 87 13:01 EST From: David C. Plummer Date: Tue, 6 Jan 87 12:57 EST From: Brad Miller That's pretty much what I expected. That still doesn't give an EXACT definition. Consider (maplist #'identity '(1 2 3)) vs (maplist #'identity '(1 2 3 . nil)) One could argue the final "dotted" NIL should be explicitly passed, and the result of both would be ((1 2 3) (2 3) (3) NIL) instead of the current ((1 2 3) (2 3) (3)) One could argue that, I suppose, but I don't. Since this is not a dotted list (even if it is input that way it is still a "true" list) the current maplist would be sufficient, and necessary to maintain compatibility. Where this is of interest, by the way, consider a pattern matcher: (A . ?x) is pretty regular input. (or ((A B . ?x) D ?y) for that matter...) the point is that right now there are no DO or MAP forms that can handle this dotted form in a trivial way. And, I don't see any particular reason why they shouldn't. (This may just be shortsightedness on my part...) Brad Miller ------ miller@cs.rochester.edu miller@acorn.cs.rochester.edu miller@rochester.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 13:22:34 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 6 Jan 87 10:05:08 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 42925; 6 Jan 87 13:03:31 EST Date: Tue, 6 Jan 87 13:01 EST From: David C. Plummer Subject: maplist and lists To: miller@cs.rochester.edu, David C. Plummer cc: common-lisp@sail.stanford.edu In-Reply-To: <870106125744.1.MILLER@CASHEW.CS.ROCHESTER.EDU> Message-ID: <870106130128.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 6 Jan 87 12:57 EST From: Brad Miller Date: Tue, 6 Jan 87 11:35 EST From: David C. Plummer Date: Tue, 6 Jan 87 11:07 EST From: Brad Miller What do you want (maplist #'list '(1 2 3 . 4) '(a b . c) '(x y z w q r s)) to return, and why? What I'm asking for is your "well defined" definition. (((1 2 3 . 4) (a b . c) (x y z w q r s)) ((2 3 . 4) (b . c) (y z w q r s)) ((3 . 4) c (z w q r s))) since there are no further cdr's of the middle form that would be it! One can argue that w/o dotted lists one can continue to take cdrs (getting nil) until all lists are ended, but using a dotted list, you "wave" that - one of the lists finished, so there are no further maps to be done. Note that this is not a problem it might be with MAPCAR, where a lot of information might be (silently) lost, though the same principle could apply... That's pretty much what I expected. That still doesn't give an EXACT definition. Consider (maplist #'identity '(1 2 3)) vs (maplist #'identity '(1 2 3 . nil)) One could argue the final "dotted" NIL should be explicitly passed, and the result of both would be ((1 2 3) (2 3) (3) NIL) instead of the current ((1 2 3) (2 3) (3))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 13:13:32 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 09:57:45 PST Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 6136; Tue 6-Jan-87 12:57:37 EST Date: Tue, 6 Jan 87 12:57 EST From: Brad Miller Subject: maplist and lists To: David C. Plummer cc: common-lisp@sail.stanford.edu, miller@ACORN.CS.ROCHESTER.EDU In-Reply-To: <870106113546.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Message-ID: <870106125744.1.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Date: Tue, 6 Jan 87 11:35 EST From: David C. Plummer Date: Tue, 6 Jan 87 11:07 EST From: Brad Miller What do you want (maplist #'list '(1 2 3 . 4) '(a b . c) '(x y z w q r s)) to return, and why? What I'm asking for is your "well defined" definition. (((1 2 3 . 4) (a b . c) (x y z w q r s)) ((2 3 . 4) (b . c) (y z w q r s)) ((3 . 4) c (z w q r s))) since there are no further cdr's of the middle form that would be it! One can argue that w/o dotted lists one can continue to take cdrs (getting nil) until all lists are ended, but using a dotted list, you "wave" that - one of the lists finished, so there are no further maps to be done. Note that this is not a problem it might be with MAPCAR, where a lot of information might be (silently) lost, though the same principle could apply... Brad Miller ------ miller@cs.rochester.edu miller@acorn.cs.rochester.edu miller@rochester.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 11:58:13 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 6 Jan 87 08:39:22 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42874; Tue 6-Jan-87 11:37:52 EST Date: Tue, 6 Jan 87 11:35 EST From: David C. Plummer Subject: maplist and lists To: miller@cs.rochester.edu, common-lisp@sail.stanford.edu In-Reply-To: <870106110759.5.MILLER@CASHEW.CS.ROCHESTER.EDU> Message-ID: <870106113546.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 6 Jan 87 11:07 EST From: Brad Miller Is there a particular motivation for not having maplist work on dotted lists? It seems to me to be well defined (and useful) to do so, but CLtL states that functions described as taking lists as arguments only really take true lists. For example (maplist #'(lambda (x) x) '(a b . c)) ((a b . c) (b . c) c) I'd like to see the definition extended to require maplist to take true and dotted lists.... This is an upward compatible extension. What do you want (maplist #'list '(1 2 3 . 4) '(a b . c) '(x y z w q r s)) to return, and why? What I'm asking for is your "well defined" definition.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jan 87 11:20:43 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 08:07:33 PST Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 6123; Tue 6-Jan-87 11:07:53 EST Date: Tue, 6 Jan 87 11:07 EST From: Brad Miller Subject: maplist and lists To: common-lisp@sail.stanford.edu cc: miller@ACORN.CS.ROCHESTER.EDU Message-ID: <870106110759.5.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Is there a particular motivation for not having maplist work on dotted lists? It seems to me to be well defined (and useful) to do so, but CLtL states that functions described as taking lists as arguments only really take true lists. For example (maplist #'(lambda (x) x) '(a b . c)) ((a b . c) (b . c) c) I'd like to see the definition extended to require maplist to take true and dotted lists.... This is an upward compatible extension. Brad Miller ------ miller@cs.rochester.edu miller@acorn.cs.rochester.edu miller@rochester.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jan 87 11:10:13 EST Received: from ARI-HQ1.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jan 87 07:59:10 PST Date: 5 Jan 87 10:52:00 EST From: "BLUE::WILLIAMS" Subject: request list To: "common-lisp" cc: williams Reply-To: "BLUE::WILLIAMS" Please include me on the list for information. williams@ari-hq1.arpa thank you. ------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jan 87 10:47:09 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Jan 87 07:36:39 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42361; Mon 5-Jan-87 10:27:28 EST Date: Mon, 5 Jan 87 10:25 EST From: David C. Plummer Subject: Implicit Blocks considered harmful To: Scott E. Fahlman , MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870105102529.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sat, 3 Jan 1987 13:51 EST From: "Scott E. Fahlman" 3) It's a bad idea to begin with, since it couples the NAME of the function with how it operates. Thus, if you ever change the name you must go through and check for any return-froms. If you ever change the name of the function, it is trivial to check for any return-froms (Automatically even). Indeed, it is harder to find and change the callers!  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jan 87 14:01:58 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 87 10:51:34 PST Received: ID ; Sat 3 Jan 87 13:51:36-EST Date: Sat, 3 Jan 1987 13:51 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: MURRAY%cs.umass.edu@RELAY.CS.NET Cc: common-lisp@SAIL.STANFORD.EDU Subject: Implicit Blocks considered harmful In-reply-to: Msg of 2 Jan 1987 14:25-EST from MURRAY%cs.umass.edu at RELAY.CS.NET I don't see any motivation for having implicit blocks around functions, and think they should be eliminated for the following reasons: 1) It is used very infrequently, so there is no reason to pay the overhead in both the interpreter and when compiling one. I've seen this used a fair amount, and people seem to find the resulting code very intuitive. As for overhead, it doesn't slow down compiled code if you don't use this mechanism. There are many things in the language that are less useful and that slow down the interpreter; in the past, we've taken the attitude that this doesn't matter too much, though I realize this is debatable. 2) It is trivial to put one in yourself if you need it, so code that uses them now can easily be updated (Automatically even). 3) It's a bad idea to begin with, since it couples the NAME of the function with how it operates. Thus, if you ever change the name you must go through and check for any return-froms. If you ever change the name of the function, it is trivial to check for any return-froms (Automatically even). 4) Most importantly, it is a problem for parallelism. A Block cannot return until all of its sub-forms have returned values, since one of them can do a Return-From. This is only a problem for the interpretor since the compiler knows if a return-from is used, but now interpreted code and compiled code will get different behavior. Common Lisp was not designed to support parallelism. Since none of us could claim that we had a good grasp of what a parallel Lisp should look like, we decided not to try to put in a lot of half-measures to make various styles of parallel processing easier. That is why, for example, we require left-to-right order of argument evaluation instead of leaving this unspecified. People who want to play with parallel Lisp systems will undoubtedly want to change Common Lisp in a variety of ways, and eliminating the implicit block may be one of them, but until one of these styles "takes hold", I don't think we should mess with the standard language to accommodate people's hunches about what might interfere with the style of parallelism they prefer. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jan 87 01:18:44 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jan 87 22:09:19 PST Received: from cs.umass.edu by csnet-relay.csnet id ag11867; 3 Jan 87 1:05 EST Date: Fri, 2 Jan 87 15:25 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SU-AI.ARPA Subject: Implicit Blocks considered harmful X-VMS-To: CSNET%"common-lisp@su-ai.ARPA" I don't see any motivation for having implicit blocks around functions, and think they should be eliminated for the following reasons: 1) It is used very infrequently, so there is no reason to pay the overhead in both the interpreter and when compiling one. 2) It is trivial to put one in yourself if you need it, so code that uses them now can easily be updated (Automatically even). 3) It's a bad idea to begin with, since it couples the NAME of the function with how it operates. Thus, if you ever change the name you must go through and check for any return-froms. 4) Most importantly, it is a problem for parallelism. A Block cannot return until all of its sub-forms have returned values, since one of them can do a Return-From. This is only a problem for the interpretor since the compiler knows if a return-from is used, but now interpreted code and compiled code will get different behavior. If people insist on having implicit blocks, I think the name of the block should be T, instead of the function name. Kelly Murray  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Dec 86 15:25:40 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Dec 86 12:15:04 PST Received: from Cabernet.ms by ArpaGateway.ms ; 30 DEC 86 11:21:37 PST Date: 30 Dec 86 11:21 PST From: Masinter.pa@Xerox.COM Subject: courses on Common Lisp To: common-lisp@sail.stanford.edu, info-1100@sumex-aim.stanford.edu reply-to: Masinter.pa@Xerox.COM Message-ID: <861230-112137-301@Xerox> I'm interested in hearing from anyone who teaches (or has taken) an "advanced" Lisp/Common Lisp programming course in a university setting. I'm preparing such a course and would be interested in hearing about the course outline, topics covered, course materials, etc. I will summarize the responses and send the summary to all who contribute. Larry  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Dec 86 15:02:44 EST Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 11:29:08 PST Date: Mon 29 Dec 86 11:28:50-PST From: Mark Richer Subject: Re: CL-WINDOWS mailing list To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU, news-makers@BRILLIG.UMD.EDU, RICHER@SUMEX-AIM.STANFORD.EDU, cl-windows@SAIL.STANFORD.EDU In-Reply-To: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU> Message-ID: <12266716971.39.RICHER@SUMEX-AIM.STANFORD.EDU> I apologize to people on cl-windows for saying that you get on the list by mailing to CL-WINDOWS@SAIL.STANFORD.EDU .... I meant to type CL-WINDOWS-REQUEST@..... As many of you know adding -REQUEST is a convention for mailing adminstrative requests such as getting added to a list (so everyone doesn't have to see those messages). Sorry. This proves I am only human afterall, Mark -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Dec 86 18:27:44 EST Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 15:21:31 PST Date: Fri 26 Dec 86 15:21:19-PST From: Mark Richer Subject: CL-WINDOWS mailing list To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU, xpert@ATHENA.MIT.EDU cc: news-makers@BRILLIG.UMD.EDU Message-ID: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU> As a follow-up to the enquiries I made in earlier messages regarding people interested in Commonlisp/Commonloops window systems interfaced to X (or News), I subsequently found out later that there is already a mailing list called CL-WINDOWS. This list had been quiet for a long time. It's original intention was to define a Commonlisp window standard. The emergence of Commonloops and language independent, network-based window systems such as X and News adds a new dimension to the discussion of a Commonlisp window system. If you are not on the list you can get on by sending a request to cl-windows@sail.stanford.edu. NOTE: I do not maintain this list. Happy New Year, Mark depending on the current state addressing schemes. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Dec 86 18:59:11 EST Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 15:52:25 PST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA01787; Mon, 22 Dec 86 15:52:26 PST Message-Id: <8612222352.AA01787@decwrl.dec.com> Date: Monday, 22 Dec 1986 15:51:00-PST From: robbins%ramona.DEC@decwrl.DEC.COM To: Common-Lisp@SAIL.Stanford.Edu Subject: Re: FOLLOW-SYNONYM-STREAM We intend to include the following functions in future versions of VAX LISP: Predicates: synonym-stream-p broadcast-stream-p concatenated-stream-p two-way-stream-p echo-stream-p string-stream-p dribble-stream-p file-stream-p terminal-stream-p open-stream-p Accessors: synonym-stream-symbol broadcast-stream-streams concatenated-stream-streams two-way-stream-input-stream two-way-stream-output-stream echo-stream-input-stream echo-stream-output-stream -- Rich  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Dec 86 09:25:03 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Dec 86 06:10:54 PST Received: from SWALLOW.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39985; Mon 22-Dec-86 09:09:17 EST Date: Mon, 22 Dec 86 09:08 EST From: Michael Greenwald Subject: sharp plus question To: DCP@QUABBIN.SCRC.Symbolics.COM, DFM%JASPER@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA cc: dfm@JASPER.Palladian.COM In-Reply-To: <861219125356.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Message-ID: <861222090840.6.GREENWALD@SWALLOW.S4CC.Symbolics.COM> Date: Fri, 19 Dec 86 12:53 EST From: David C. Plummer Date: Fri, 19 Dec 86 11:59 EST From: Don Morrison What should the second form in the following read as? (push :mumble *features*) '(#-mumble #+mumble 1 2 3) I would expect '(2 3). Both implementations I've tried read '(3), which is completely unintuitive to me. Such a thing can easily come up in real life (e.g. commenting out with #+(or) something that's already under #+mumble). Don Morrison Palladian Software, Inc. This is curious. In the Symbolics 7.0 implementation, '(#+non-existent-feature #-non-existent-feature 1 2 3) '(#-non-existent-feature #+non-existent-feature 1 2 3) '(#+LISPM #-LISPM 1 2 3) each read as '(2 3) but '(#-LISPM #+LISPM 1 2 3) does read as '(3). This does seem wrong on the following grounds: #-LISPM goes into the mode "read me a form, and ignore it." It recursively invokes the reader. The reader gets #+LISPM. #+LISPM goes into the mode "read me a form and don't ignore it." Currently, the Symbolics' reader treats both #+ and #- as "ignore next form" when *READ-SUPPRESS* is T. This is probably a misinterpretation of *READ-SUPPRESS*. It was done to solve the problem of an illegally formed expression following a #+ inside a form with *READ-SUPPRESS* 'T. For example, (PROGN #+IMPLEMENTATION-X (INCF (FROB-KNOB GROZZLE) #+SYS:GREEPS-ALLOWED 3 #-(CAR FGR:*GROZZLE-MODES*) 2) ....) Is the correct interpretation to obey #+ and #- even inside a *READ-SUPPRESS*? (while still suppressing errors inside the feature specification?) Clearly #+NON-FEATURE (A B #-NON-FEATURE C), shouldn't cause read errors while reading C. The question is whether the internal "feature specification" should be read with *READ-SUPPRESS* bound specially to NIL or not. If we keep the current binding of *READ-SUPPRESS*, then feature will always be NIL (*READ-SUPPRESS* causes all extended tokens to be NIL). If we bind *READ-SUPPRESS* to NIL to read the feature specification, then syntactic "errors" in the feature can cause errors. The problem of supporting (by ignoring) non-standard syntax in feature specifications doesn't need to be part of COMMON-LISP (I don't think CL allows extensions there), the question of nested #-'s does need to be made unambiguous. Implementations (Symbolics' for example) that want to be generous in what they accept without error, can handle that themselves. This recursively invokes the reader. The reader reads 1. #+LISPM does not ignore the 1, so it returns it as the thing read. #-LISPM is given 1 as the result of the read, and ignores it. 2 and 3 are still in the input stream, so I don't know how both of them manage to get ignored. [I'm not sure what the current state of our mailer is, but I think mail addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.] I'm not on the COMMON-LISP mailing list, but someone from Symbolics can forward to me any replies, if there is some trouble with the return paths.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Dec 86 18:30:31 EST Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 21 Dec 86 15:23:07 PST Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA21974; Sun, 21 Dec 86 15:23:14 PST Message-Id: <8612212323.AA21974@decwrl.dec.com> Date: Sunday, 21 Dec 1986 15:22:29-PST From: nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson) To: common-lisp@su-ai.ARPA, dfm%bach.DEC@decwrl.DEC.COM Subject: #+/- (This is in response to Don's message about nesting #+ and #-) VAX LISP returns a two-element list whether the #+ or #- is first. I believe that this behaviour is correct; it seems logical to consider the second # macro to apply to the first form to be read (1), and the first # macro form apply to the first remaining form to be read (1 if it hasn't been removed already, or 2 if 1 has been removed). Lisp> (push 'foo *features*) (FOO EDITOR SYSTEM-EDITOR::INTERNAL-BUILD UIS COMPILER DEBUGGER VMS DEC COMMON VAX) Lisp> '(#-foo #+foo 1 2 3) (2 3) Lisp> '(#+foo #-foo 1 2 3) (2 3) Beryl Nelson nelson%bach@decwrl.dec.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Dec 86 15:32:12 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 12:22:04 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28330; Fri 19-Dec-86 15:20:50 EST Date: Fri, 19 Dec 86 15:19 EST From: Kent M Pitman Subject: FOLLOW-SYNONYM-STREAM To: Common-Lisp@SAIL.STANFORD.EDU Message-ID: <861219151955.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> From time to time, I find myself doing: (LET ((*TERMINAL-IO* *STANDARD-OUTPUT*)) ...) in a multi-window system in order to temporarily change my interaction to the same window as output has been redirected to. On the Lisp Machine (and probably on many or most other implementations), *STANDARD-OUTPUT* can sometimes (often) contain a synonym-stream for *TERMINAL-IO* and the result of the operation above is to send output to a stream which is a (circular) synonym for itself. The kind of lossage this results in is fairly severe because *DEBUG-IO* is often a synonym for *TERMINAL-IO* and if that is in turn a synonym for *TERMINAL-IO*, then the debugger cannot run. A couple of things would make this problem more tractable: SYNONYM-STREAM-P object [Function] This accepts any kind of argument. If the argument is not a synonym stream, then NIL is returned. If the argument is a synonym stream, then the symbol for which the object is a synonym is returned. FOLLOW-SYNONYM-STREAM stream [Function] This accepts a stream and returns the result of following that stream through any number of synonym stream indirections (including zero). While I'm on page 329, I think we should also have the following functions (or functionalities) which I have needed at other times: BROADCAST-STREAM-P object [Function] CONCATENATED-STREAM-P stream [Function] TWO-WAY-STREAM-P [Function] ... This accepts any kind of argument. It returns T if the argument is a {concatenated/broadcast/two-way/...} stream and NIL if the argument is any other kind of stream. EXPAND-BROADCAST-STREAM broadcast-stream [Function] EXPAND-CONCATENATED-STREAM concatenated-stream [Function] EXPAND-TWO-WAY-STREAM two-way-stream [Function] ... This accepts a {broadcast/concatenated/two-way/...} stream and returns a list of the streams which were used to compose it (in an order compatible with the order of arguments to the creation function). Note: Implementations are allowed, but not required, to return the same list every time. The result list should not be destructively modified.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Dec 86 13:08:41 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:56:18 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39609; Fri 19-Dec-86 12:54:41 EST Date: Fri, 19 Dec 86 12:53 EST From: David C. Plummer Subject: sharp plus question To: DFM%JASPER@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA cc: dfm@JASPER.Palladian.COM In-Reply-To: <861219115917.5.DFM@WHITBY.Palladian.COM> Message-ID: <861219125356.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Fri, 19 Dec 86 11:59 EST From: Don Morrison What should the second form in the following read as? (push :mumble *features*) '(#-mumble #+mumble 1 2 3) I would expect '(2 3). Both implementations I've tried read '(3), which is completely unintuitive to me. Such a thing can easily come up in real life (e.g. commenting out with #+(or) something that's already under #+mumble). Don Morrison Palladian Software, Inc. This is curious. In the Symbolics 7.0 implementation, '(#+non-existent-feature #-non-existent-feature 1 2 3) '(#-non-existent-feature #+non-existent-feature 1 2 3) '(#+LISPM #-LISPM 1 2 3) each read as '(2 3) but '(#-LISPM #+LISPM 1 2 3) does read as '(3). This does seem wrong on the following grounds: #-LISPM goes into the mode "read me a form, and ignore it." It recursively invokes the reader. The reader gets #+LISPM. #+LISPM goes into the mode "read me a form and don't ignore it." This recursively invokes the reader. The reader reads 1. #+LISPM does not ignore the 1, so it returns it as the thing read. #-LISPM is given 1 as the result of the read, and ignores it. 2 and 3 are still in the input stream, so I don't know how both of them manage to get ignored. [I'm not sure what the current state of our mailer is, but I think mail addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.]  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Dec 86 12:35:20 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:24:23 PST Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 22488; 19 Dec 86 12:24:06-EST Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 22232; 19 Dec 86 11:59:36-EST Date: Fri, 19 Dec 86 11:59 EST From: Don Morrison Reply-To: DFM%JASPER@LIVE-OAK.LCS.MIT.EDU Subject: sharp plus question To: common-lisp@su-ai.arpa cc: dfm@JASPER.Palladian.COM Message-ID: <861219115917.5.DFM@WHITBY.Palladian.COM> What should the second form in the following read as? (push :mumble *features*) '(#-mumble #+mumble 1 2 3) I would expect '(2 3). Both implementations I've tried read '(3), which is completely unintuitive to me. Such a thing can easily come up in real life (e.g. commenting out with #+(or) something that's already under #+mumble). Don Morrison Palladian Software, Inc. [I'm not sure what the current state of our mailer is, but I think mail addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.]  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Dec 86 19:36:03 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Dec 86 16:24:53 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27691; Thu 18-Dec-86 19:22:32 EST Date: Thu, 18 Dec 86 19:22 EST From: David A. Moon Subject: File Operations To: ELIOT%cs.umass.edu@RELAY.CS.NET cc: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 18 Dec 86 11:03 EST from ELIOT%cs.umass.edu@RELAY.CS.NET Message-ID: <861218192211.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 18 Dec 86 12:03 EDT From: ELIOT%cs.umass.edu@RELAY.CS.NET .... Because of this I think that special handling of errors is called for. I would suggest that keyword arguments be added to these functions which control this behavior. .... This is obviously redundant with handling these situations in the error system. However, we won't have an error system generally implemented for quite some time. I don't understand why this change to Common Lisp would receive widespread implementation earlier than the error-handling facility change to Common Lisp. Either way it's different from what people have implemented now. At Symbolics, and earlier at MIT, we have had a lot of experience with error handling, especially in file system operations. We used to use an enable-error argument scheme similar to what you suggest, but found it to be unsatisfactory and switched to a uniformly condition-based scheme.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Dec 86 18:23:54 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Dec 86 15:13:05 PST Received: from cs.umass.edu by csnet-relay.csnet id ao02299; 18 Dec 86 17:29 EST Date: Thu, 18 Dec 86 12:03 EDT From: ELIOT%cs.umass.edu@RELAY.CS.NET To: Common-Lisp@SU-AI.ARPA Subject: File Operations X-VMS-To: CSNET%"Common-Lisp@su-ai.arpa" File Operation errors are somewhat of a special case, in that a "correct" program may attempt an uncompletable file operation. Some of the operations in question are exactly the operations which must be performed in order to determine if the operations can be done. (E.g. Probe-file.) Because of this I think that special handling of errors is called for. I would suggest that keyword arguments be added to these functions which control this behavior. I would propose two new arguments, :on-error and :on-failure. Failure is defined as a reasonable operation that couldn't be done because of some condition in the outside world, such as a network being down. Errors are operations that don't seem to make sense, such as deleting a file that does not exist, or supplying a host name that is unknown. The values to the keyword arguments would be :error arguments would be :ERROR or a value to return. (With :ERROR being the default.) A value of :ERROR would indicate that an error should be signalled. This is obviously redundant with handling these situations in the error system. However, we won't have an error system generally implemented for quite some time. Even then this crude would be useful in simpler situations, and I think it would be easier to read: (probe-file foo :on-failure nil) Than: (condition-bind (si:file-operation-failure nil) (probe-file foo)) Since file operation errors are so pervasive the redundant functionality would be worth it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 86 15:41:21 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 16 Dec 86 12:20:36 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135903; Tue 16-Dec-86 15:18:27 EST Date: Tue, 16 Dec 86 15:17 EST From: Robert W. Kerns Subject: Re: FILE-WRITE-DATE, FILE-AUTHOR To: masinter.pa@Xerox.COM cc: RWK@YUKON.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA, cal@THINK.COM In-Reply-To: <861215-135251-3226@Xerox> Message-ID: <861216151753.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM> A good summary. I'd add another option: d) Declare that they signal an error when they were actually unable to determine the existance of the file. This is not quite as satisfactory as item 'c', but is a reasonable holding action until the error system proposal is adopted and attention is given to standardizing on specific conditions and circumstances. Date: 15 Dec 86 13:45 PST From: masinter.pa@Xerox.COM The error system proposal (aka the Condition System proposal) does not at all address the issue of what functions might specify what errors, it only provides a mechanism by which the type of error might be specified, and for handling such conditions. This is my attempt to summarize the issue you brought up: "There are several operations in Common Lisp (e.g., PROBE-FILE, DIRECTORY, OPEN) for which CLtL is vague about the behavior in the face of lack of access rights, network failures, or transient conditions. The alternatives are to a) to declare that these conditions should be treated within the bounds of the specified operation, e.g., that PROBE-FILE return as if the file were not present, USER-HOMEDIR-PATHNAME, FILE-WRITE-DATE, FILE-AUTHOR return NIL b) to declare explicitly that the behavior of a Common Lisp implementation in such conditions is "unspecified" or "implementation-dependent" c) to define conditions (e.g., INTERMITTENT-FILE-ERROR, INSUFFICIENT-ACCESS-RIGHTS) which will be signalled when such conditions arise, and, perhaps, some of the actions that should happen surrounding such signals (e.g., that it should be possible to specify that FILE-WRITE-DATE should just return NIL if it is not available, ect.) - - - - - - - - - - - - Independent of the merits of one proposal over another, are there any other proposals or refinements of these? Other functions and situations (besides FILE-WRITE-DATE, FILE-AUTHOR, PROBE-FILE, DIRECTORY, OPEN, USER-HOMEDIR-PATHNAME)?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Dec 86 17:05:13 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Dec 86 13:54:12 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 DEC 86 13:52:51 PST Date: 15 Dec 86 13:45 PST From: masinter.pa@Xerox.COM Subject: Re: FILE-WRITE-DATE, FILE-AUTHOR In-reply-to: Robert W. Kerns 's message of Mon, 15 Dec 86 07:54 EST To: RWK@YUKON.SCRC.Symbolics.COM cc: common-lisp@SU-AI.ARPA, cal@THINK.COM Message-ID: <861215-135251-3226@Xerox> The error system proposal (aka the Condition System proposal) does not at all address the issue of what functions might specify what errors, it only provides a mechanism by which the type of error might be specified, and for handling such conditions. This is my attempt to summarize the issue you brought up: "There are several operations in Common Lisp (e.g., PROBE-FILE, DIRECTORY, OPEN) for which CLtL is vague about the behavior in the face of lack of access rights, network failures, or transient conditions. The alternatives are to a) to declare that these conditions should be treated within the bounds of the specified operation, e.g., that PROBE-FILE return as if the file were not present, USER-HOMEDIR-PATHNAME, FILE-WRITE-DATE, FILE-AUTHOR return NIL b) to declare explicitly that the behavior of a Common Lisp implementation in such conditions is "unspecified" or "implementation-dependent" c) to define conditions (e.g., INTERMITTENT-FILE-ERROR, INSUFFICIENT-ACCESS-RIGHTS) which will be signalled when such conditions arise, and, perhaps, some of the actions that should happen surrounding such signals (e.g., that it should be possible to specify that FILE-WRITE-DATE should just return NIL if it is not available, ect.) - - - - - - - - - - - - Independent of the merits of one proposal over another, are there any other proposals or refinements of these? Other functions and situations (besides FILE-WRITE-DATE, FILE-AUTHOR, PROBE-FILE, DIRECTORY, OPEN, USER-HOMEDIR-PATHNAME)?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Dec 86 08:06:16 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 15 Dec 86 04:56:41 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134642; Mon 15-Dec-86 07:54:51 EST Date: Mon, 15 Dec 86 07:54 EST From: Robert W. Kerns Subject: FILE-WRITE-DATE, FILE-AUTHOR To: common-lisp@SU-AI.ARPA cc: toto@YUKON.SCRC.Symbolics.COM, cal@THINK.COM Message-ID: <861215075436.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> FILE-WRITE-DATE and FILE-AUTHOR are both vague on what happens if the file does not exist. The text says: @I[file] can be a filename or a stream that is open to a file. This returns the time at which the file was created or last written as an integer in universal time format (see section 25.4.1), or NIL if this cannot be determined. (FILE-AUTHOR is similar). My reading of this is that the phrase "if this cannot be determined" means "determined by looking at the file", not "determined for any reason". I think the intent here is to cover such situations as an operating system which doesn't support creation dates, or a network link which doesn't support inquiring about dates. Situations like giving the wrong pathname, temporary network failure, or no access rights should signal an error. PROBE-FILE and DIRECTORY are also a bit vague on these matters, saying nothing about what happens when you can't inquire about files due to network failure or no access rights. I also think that if the directory doesn't exist, you should get an error, not just return NIL, but this would need to wait until we have an error system, or the incompatibility would be too large. USER-HOMEDIR-PATHNAME says "if it is impossible to determine this information, then NIL is returned instead of a pathname;". It's not clear whether this means "is impossible right now due to a system error" or "is impossible to inquire of that host". Returning NIL due to a transient condition is both uninformative to the user and may lead to suprising behaviour, like reading in the wrong files or refusing to do something. The :IF-DOES-NOT-EXIST NIL option to OPEN does not say what it does about things like network errors, etc. A lot of people seem to assume that if CLtL doesn't say anything about errors, then a function may not signal any errors, even if something goes wrong. Hopefully the new error system standard will address a lot of these issues, but some clarification (or at least agreement on the intent) would help now.