Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 May 85 15:33:56 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 May 85 12:25:41 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244204; Mon 27-May-85 15:24:36-EDT Date: Mon, 27 May 85 15:26 EDT From: Daniel L. Weinreb Subject: Does Defmacro establish a block? To: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850527152627.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Reply-To: dlw@SCRC-STONY-BROOK.ARPA Date: Mon, 27 May 1985 04:30 EDT From: Rob MacLachlan Does defmacro establish a named block around the definition the same way that defun does? I know you're asking about the definition of CL, and I don't have anything to add about that, but I thought you might be interested to know that it does in our implementation.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 May 85 14:18:04 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 May 85 01:30:09 PDT Received: ID ; Mon 27 May 85 04:30:09-EDT Date: Mon, 27 May 1985 04:30 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Does Defmacro establish a block? Comment: Remailed after delay caused by distribution list error at SU-AI. Does defmacro establish a named block around the definition the same way that defun does? CLTL doesn't mention this issue at all, leading one to suppose that it doesn't, but this seems to create a pointless inconsistency with defun. If defmacro does, do define-setf-method, defsetf, deftype...? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 May 85 16:25:10 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85 13:00:30 PDT Received: by THINK.ARPA with CHAOS id AA17473; Fri, 24 May 85 15:55:21 edt Date: Friday, 24 May 1985, 15:55-EDT From: Guy Steele Subject: Addendum/Erratum To: common-lisp%su-ai@THINK.ARPA Cc: GRISS%hplabs.CSNET@THINK.ARPA, gls%AQUINAS@THINK.ARPA In-Reply-To: <8505241250.AA18809@HP-VENUS> Message-Id: <850524155541.1.GLS@DESIDERIUS.ARPA> I have been collecting changes that I believe to be non-controversial into one place. I also keep track of all Common Lisp mail. Now that discussions have been revving up again on this mailing list, I would like later this summer to gather up the discussions, make up another ballot, and conduct a poll on proposed changes. The results of this poll must, I suppose, be considered provisional until we come up with an organizational charter. Appended to this message is my list of non-controversial changes. ---------------------------------------------------------------- Corrections to first printing of Common Lisp: The Language 10 First two paragraphs should have monospace comma and colon, respectively, at the left margin. 18 3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted). 43 Table 43-1 should include the names "signed-byte" and "unsigned-byte". 67 The comment in (defun discriminant ...) is wrong, because the code works for complex coefficients. Change the line The quadratic equation a*x^2+b*x+c=0 has real, multiple to be the two lines If the coefficients a, b, and c are all real numbers, then the quadratic equation a*x^2+b*x+c=0 has real, multiple 69 Top line, last word but one, should be "replace", not "replaces". 99 In first line of second paragraph, delete the italicized word "newvalue". 145 Three lines from the bottom, the term "&environment" should appear at the left in monospace. 147 Last line on this page should be deleted; it duplicates first line on page 148. 157 In third line, "declaration-form" should be "decl-spec" (in italics). 200 At the end of the first paragraph "returns the result." add the sentence "It is an error if any argument other than the first is zero." After "With one argument, / reciprocates the result" add the sentence "The argument must not be zero." 204 Halfway down, the last line of a paragraph "#C(0.5 1.73205)." should say "#C(1.0 1.73205)." 216 Alter "The divisor may be any non-complex number." to read "The divisor may be any non-zero non-complex number." 216 Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to "For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...". 216 Before last paragraph, insert this new paragraph: Note that while (floor 5 2) and (floor (/ 5 2)) return the same first value, they return different remainders as the second value: (floor 5 2) => 2 1 (floor (/ 5 2)) => 2 1/2 This is why @f[values] was used above in the remark that (values (floor 5 2)) @EQ (values (floor (/ 5 2))). 276 Halfway down, in the display line before "See pushnew.", the phrase "(fn item)" should be "(funcall fn item)", with "funcall" in monospace and "fn" and "item" in italics as before. 307 In the header line for "defstruct", "{slot-description}+" should be "{slot-description}*" (star instead of plus). 309 First paragraph should end "see section 19.6)." not "see section 19.6."; there is a missing parenthesis. 325 The name of the variable "-" does not appear in the header line. 347-348 The page layout is a bit confused here; some connection should be made between the description of ";" and the example. 349 Before the first complete paragraph, there should be a heading line consisting of a single monospace backquote (accent grave). 349 In the first example of the use of backquote, the character just before " (print ,x)" is a "t". (It is badly printed in several copies.) 373 Third line from bottom: "print-array" in monospace should be "*print-array*". 454 In index entry for "defun", first page number should be 67, not 57. 458 In index entry for "macrolet", page numbers should be 113-114 instead of 93-94. 465 "zerop" is missing from the index (it is defined on page 195). 458 First reference for "macrolet" should be 113-114, not 93-94. 459 Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384, 397".  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 May 85 13:41:26 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85 10:29:57 PDT Received: by THINK.ARPA with CHAOS id AA15759; Fri, 24 May 85 13:19:06 edt Date: Friday, 24 May 1985, 13:19-EDT From: Guy Steele Subject: Rules of the game and stability To: common-lisp%sail@THINK.ARPA Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850524131942.2.GLS@ELIGIUS.ARPA> I agree with Fateman that Common Lisp should not be regarded as frozen forever and that there can be staged versions of it as for FORTRAN. I do think that two years is too short a cycle, however; given LISP's history of instability, large changes to Common Lisp over only two years will simply look like more of the same chaos. Hedrick's point is also well taken that by 1986 a lot of people will barely have finished implementing CL'84. On the other hand, FORTRAN's revisions run on an 11-year cycle, which I think is much too long. If I had to make a projection today (and I will; here it comes, ta da), I would say that the time for a major "version change" to Common Lisp will be ripe about 1988 or 1989, and there is room for a "corrected edition" of CL'84 in about 1986 (I think it will take about another year to discuss the outstanding and new issues raised since the book was published a year ago, decide what to do, change the book, and get the new edition published). I agree with DLW that my category (3) should be regarded with caution, if not suspicion; my examples were not well chosen. I am not recommending the introduction of flavors in the near future, for example. I was ordering the categories according to user disruption, not implementation disruption, and of course both are important. A small number of things like &body won't hurt, but we don't want to introduce a hundred new functions. Someone referred to my previous note with the word "policy". I would like to say that I am not attempting to establish policy unilaterally. I am trying to summarize my sense of what everyone seems to want, colored of course by my opinions as to what I think would be best for everyone concerned. (It might be useful for everyone to understand that right now I am more a user of Common Lisp than an implementor! On the other hand, part of my work here at Thinking Machines is concerned with implementing a sideset of Common Lisp for parallel processing.) --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 May 85 13:03:47 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 24 May 85 09:55:12 PDT Received: from hplabs by csnet-relay.csnet id ab11256; 24 May 85 12:32 EDT Received: by HP-VENUS id AA18809; Fri, 24 May 85 05:50:52 pdt Message-Id: <8505241250.AA18809@HP-VENUS> Date: Fri 24 May 85 05:50:26-PDT From: Martin Subject: Addendum/Erratum To: common-lisp@su-ai.ARPA Cc: GRISS@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. Are there plans to publish an Erratum or Addendum sheet to go with the current CL ref manual. Is someone gathering and editing the various comments and elucidations submitted since the book appeared. M -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 May 85 12:18:08 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 24 May 85 09:09:39 PDT Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA14729; Fri, 24 May 85 12:05:52 edt Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 243338; Fri 24-May-85 11:53:16-EDT Date: Fri, 24 May 85 11:54 EDT From: Daniel L. Weinreb Subject: Rules of the game To: gls%AQUINAS@THINK.ARPA, common-lisp%SU-AI@THINK.ARPA In-Reply-To: <850523111007.4.GLS@YON.ARPA> Message-Id: <850524115418.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Reply-To: dlw@SCRC-STONY-BROOK.ARPA I agree with all of this, except for point 3 (Compatible extensions), which I think is somewhat dubious. Accepting this point means that we can sit here and add feature after feature. Anyone comtemplating supporting Common Lisp will have to be told "Not only do you have to implement everything in this book, but there will probably be a steady stream of new features that you are REQUIRED to implement, lest some guaranteed-white-pages-compatible program not be able to run on your system." Is that really fair to the world? A great deal of discussion on this mailing list has been related to things that certainly do not fall within the domains of points 1, 2, 4, and 5. I think our time would be far better spent on those points than on designing a new version of Common Lisp. I agree with Fateman's general point about CL '84 and CL '86, and I think we should spend our time where it is most urgently needed: on CL '84.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 May 85 02:11:05 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 May 85 23:02:26 PDT Date: Fri, 24 May 85 02:01:24 EST From: Glenn S. Burke Sender: GSB0@MIT-MC Subject: Re: Adjustable and displaced arrays To: RAM@CMU-CS-C cc: common-lisp@SU-AI Message-ID: <[MIT-MC].516737.850524.GSB0> It sounds like NIL implements complex arrays in a somewhat similar manner to Spice Lisp. However, in the general case, the complex array header might have to point to another complex array header. As a result an AREF might have to iterate to find the eventual data vector. Only in the case where none of the involved arrays (other than the outermost) are adjustable can the data vector be "cached" as your implementation does. For instance. (setq c (make-array '(5 5) :adjustable t)) C is a complex array header, whose displaced-to field (like your data vector) is a simple vector 25 long, and whose displaced-index-offset field holds 0. (setq b (make-array 20 :displaced-to c :displaced-index-offset 5)) B is a complex array header, whose displaced-to field is C, because C is adjustable, and its data vector might get thrown out and replaced by a new one. (setq a (make-array '(3 3) :displaced-to b :displaced-index-offset 4)) A is a complex array header, whose displaced-to field is C. It is NOT B, because B is not adjustable, so can be optimized out. Its displaced-index-offset field is 4, which was obtained by adding its own with B's. (aref A i j) operates by computing a row-major-order index into A, using the dimensionality of A. Then (because this is a complex array) the displaced-index-offset (9) is added to this, and that is used as a row-major-order index into its displaced-to array, C. C is itself a complex array, so the process iterates once more. C's displaced-index-offset is 0 and its displaced-to happens to be just a simple vector. -------------- Moon and i discussed this specification some well over a year ago, because i was somewhat disturbed at the efficiency penalty in some of the displacement. We pretty much decided that in spite of the hair needed, this model of array displacement was reasonable, and at least simple arrays can be crunched pretty efficiently. (The point being that i was somewhat put off by the implementation necessary.) In NIL, the sequence functions operate internally by reducing a sequence to a simple sequence and an offset, and then crunch on the simple sequence. So, for instance, doing REPLACE on two strings, no matter how adjustable or displaced, will eventually use the vax MOVC3 instruction, as implemented by a primitive which moves "bytes" from one simple binary data object to another (the same thing works on bignums). The one thing i do NOT like about the specification is how elements are preserved by adjust-array. The replacement of those things with matching indices is pretty random, and pretty inefficient to boot. It should just preserve the row-major-order data insofar as that is possible (truncating, or extending with some initial-element or "undefined" value, depending on whether the total-size is being decreased or increased).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 21:27:02 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 May 85 18:19:33 PDT Date: Thu, 23 May 85 21:17:35 EST From: Glenn S. Burke Subject: Get-Setf-Method To: RAM@CMU-CS-C cc: common-lisp@SU-AI Message-ID: <[MIT-MC].516353.850523.GSB> Date: Thu, 23 May 1985 08:03 EDT From: Rob MacLachlan Get-Setf-Method should take an (optional?) environment argument so that it can expand macros correctly. I pointed this out months ago, and i thought we had established this as a given.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 19:02:42 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 15:38:51 PDT Received: from RUTGERS.ARPA (rutgers-gw.ARPA) by THINK.ARPA id AA09073; Thu, 23 May 85 18:32:45 edt Date: 23 May 85 18:32:54 EDT From: Dave Subject: Re: Does FORMAT handle multiple values To: gls%AQUINAS@THINK.ARPA, RAM@CMU-CS-C.ARPA Cc: Common-Lisp%SU-AI.ARPA@THINK.ARPA In-Reply-To: Message from "Guy Steele " of 17 Nov 1858 13:01:42 EST Date: Thu, 23 May 1985 04:57 EDT From: Rob MacLachlan Subject: Does FORMAT handle multiple values Date: Thursday, 23 May 1985 04:30-EDT From: Dave To: Common-Lisp at SU-AI.ARPA Re: Does FORMAT handle multiple values (format t "~S~%" (progn ... (values ...))) I'm not sure what you think that code is supposed to do, but there are two ways that I can think of to turn MV's into format arguments (or any other kind of arguments). You can use Multiple-Value-List (not values-list, as you said) Oops, I always mix up Values-List and Multiple-Value-List. Obviously need a TWIM (Type What I Mean :-)). to get a list, or you can use Multiple-Value-Call. What I'm doing is generating a bunch of test cases for random functions, ie (format t "~S~%" (foo ...)). I'd rather not have to do a Multiple-Value-List around everything for the few times that something returns MVs. I was hoping that format could handle multiple values in some way that I wouldn't have to know if I was dealing with MVs or not. Doesn't look like it. Oh well. In Common Lisp, there is no user-visible distinction between returning one value and returning one "multiple value", so the multiple-value-### primitives will work fine even if only one value is being returned. Rob Date: Thursday, 23 May 1985, 10:43-EDT From: Guy Steele Subject: Does FORMAT handle multiple values Date: 23 May 85 04:30:24 EDT From: Dave Does format handle multiple values at all? What I want to do is something like the following (only this throws away everything but the first value): (format t "~S~%" (progn ... (values ...))) I would write this as (multiple-value-call #'format t "~S~%" (progn ... (values ...))) In this case you either have to know how many values you are going to be returning or use the iteration directive in the format string. If you type this in as written (assuming that you get more than one value back from values), you only get one value printed. thereby causing multiple values from each argument form to be "spread out" as separate arguments to FORMAT. --Guy Oh well, looks like I'm going to have to have a separate case for MVs. thanks anyway. ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 18:59:44 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85 13:36:17 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242854; Thu 23-May-85 16:35:44-EDT Date: Thu, 23 May 85 16:37 EDT From: David C. Plummer in disguise Subject: Adjustable and displaced arrays To: Rob MacLachlan , common-lisp@SU-AI.ARPA In-Reply-To: References: , The message of 23 May 85 09:57-EDT from greek@DEC-HUDSON Message-ID: <850523163729.9.NFEP@NEPONSET.SCRC.Symbolics.COM> For references, the following describes how Lisp Machines do displacing. If array a is created displaced to array b, then there are two items of interest in this relationship. (1) Array a is holding onto array b, and array a has a number stored in it which is the offset into b. If array b is then adjusted, nothing "physically" happens to array a. Array a still is still holding onto array b and still has the same offset within b, independent of what b looked like before and after b was adjusted. I order for a to be >>meaningfully displaced<< to b, especially when b has been adjusted, the rules of row major storage must be taken into account. By the above description, people programming LispMs need to beware, not the people implementing CL for LispMs.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 16:00:54 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 10:38:37 PDT Received: from CMU-CS-C.ARPA (cmu-cs-c.arpa.ARPA) by THINK.ARPA id AA06595; Thu, 23 May 85 13:34:54 edt Received: ID ; Thu 23 May 85 13:35:06-EDT Date: Thu, 23 May 1985 13:35 EDT Message-Id: From: Rob MacLachlan To: Guy Steele Cc: common-lisp%SU-AI@THINK.ARPA Subject: Adjustable and displaced arrays In-Reply-To: Msg of 23 May 1985 10:51-EDT from Guy Steele I'm still not sure we have communicated here. My specific concern is that if I am interpreting you intent correctly, the implementation of complex arrays in Spice Lisp (and derived implementations) is seriously flawed. Spice Lisp implements complex arrays as a header which contains, among other things, a pointer to the one-dimensional simple-array which actually holds tha data, and the displaced-index-offset. When a displaced array is made, the data vector is the data vector of the original array, and the offset is set appropriately. With this representation displacement is handled with minimal additional overhead. The problem is that the header for the displaced array contains the pointer to the actual data vector for the original array. If the original array is adjusted, the aliasing will be lost. If this implementation is indeed incorrect, what is the correct implementation? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 15:38:06 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 85 11:13:13 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242733; Thu 23-May-85 14:08:26-EDT Date: Thu, 23 May 85 14:09 EDT From: Daniel L. Weinreb Subject: Re: Backquote idioms To: DCP@SCRC-QUABBIN.ARPA, smh@MIT-EDDIE.ARPA, KMP@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850522164152.8.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <850523140903.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Reply-To: dlw@SCRC-STONY-BROOK.ARPA Date: Wed, 22 May 85 16:41 EDT From: David C. Plummer in disguise I am not saying that 69 levels of backquote should not be defined. I am saying that it should not be encouraged for people writing programs. I rather doubt that any users, upon seeing the explanation in the manual, will then rush to their terminals so use triple-nested backquotes. It's not something that people will be "encouraged" to use; in fact, most people will have a very hard time figuring out why you'd ever use it. So I don't think there's much to worry about.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:51:47 EST Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 23 May 85 01:30:41 PDT Date: 23 May 85 04:30:24 EDT From: Dave Subject: Does FORMAT handle multiple values To: Common-Lisp@SU-AI.ARPA Does format handle multiple values at all? What I want to do is something like the following (only this throws away everything but the first value): (format t "~S~%" (progn ... (values ...))) Is there anyway to handle this (or should it be handling it but there is a bug in our CLisp)? BTW, I'm sure that I can do this with a values-list and the iteration directive but I wanted to know if I can do this without knowing a head of time whether I would be getting mv's back or not. thanks, ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:45:15 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 May 85 09:39:07 PDT Received: from hplabs by csnet-relay.csnet id ad04548; 23 May 85 12:28 EDT Received: by HP-VENUS id AA02099; Thu, 23 May 85 05:49:47 pdt Message-Id: <8505231249.AA02099@HP-VENUS> Date: Thu 23 May 85 05:49:20-PDT From: Martin Subject: Re: Local SPECIAL declarations To: DDYER, common-lisp@su-ai.ARPA Cc: GRISS@hplabs.CSNET In-Reply-To: Message from "Dave Dyer " of Wed 22 May 85 10:05:16-PDT Source-Info: From (or Sender) name not authenticated. I too like the notion of the local special. I once used a language (BALM) that exploited $ at the point of binding as a readmacro; (defun foo (x $y z) (setq y 3)) which effectively expanded into (defun foo (x (special y) z) (setq y 3)) Perhaps the $ should have been used on ALL references to the special y for more consistency. It was very comfortable to use. M -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:40:37 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 08:17:49 PDT Received: by THINK.ARPA with CHAOS id AA04768; Thu, 23 May 85 11:09:39 edt Date: Thursday, 23 May 1985, 11:10-EDT From: Guy Steele Subject: Rules of the game To: common-lisp%SU-AI@THINK.ARPA Cc: gls%AQUINAS@THINK.ARPA In-Reply-To: <850522212037.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <850523111007.4.GLS@YON.ARPA> Date: Wed, 22 May 85 21:20 EDT From: Daniel L. Weinreb ... I think it's important that we decide what our philosophy is about "changes to Common Lisp", particularly in light of the fact that the manual has been published and is now on the shelves of bookstores. What does it mean for us to "make a move"? ... I just think we'd spend our time better if it were somewhat more clear what game we are playing and what the rules are, and I'm worried that we're spending a great deal of time and energy designing Common Lisp after the horse has been let out of the barn. Are we really designing a new second-generation Common Lisp? Or are we proposing to tell the world shortly that the book isn't really the Real Common Lisp, please make the following forty changes to your copy? Once we have answered this question, then we can agree on a general philosophy about what degree of change is allowable. My attitude is that the horse is indeed out of the barn. I believe that changes of the following five kinds are appropriate. I list them in order of increasing seriousness and likeliness to cause disruption: (1) Typographical and editorial corrections (such as a better index!). In this category I would place changes in terminology that would leave code unaffected. For example, changing the term "special form" to "special operator" would fall into this category, but renaming SPECIAL-FORM-P to SPECIAL-OPERATOR-P would not. (2) Substantive elucidations of intent. An example of this is my reply earlier today elucidating what is supposed to happen when adjusting an array to which another array is displaced. (3) Compatible extensions to the language (such as adding a quaternion data type, or flavors, or Bessel functions, or PARSE-BODY, or the proposed three-variable &BODY feature for DEFMACRO). (4) Incompatible changes to existing features because they cannot possibly operate correctly as specified. An example is the recent report that GET-SETF-METHOD needs to take an environment argument. (5) Incompatible changes required to bring Common Lisp into conformance with an external standard. This category is fraught with danger, and the benefits must be weighed carefully. An example is the proposal to change the branch cuts of arctangent to conform to expected practice by the APL and IEEE proposed floating-point communities. I believe that it is too late for incompatible changes for the sake of clarity, consistency, or convenience. Therefore I would strongly oppose renaming or removing any existing function or feature. (This represents a reversal of my previous position on the proposal to eliminate expansion of macros into declarations.) --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:22:49 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 May 85 05:03:34 PDT Received: ID ; Thu 23 May 85 08:03:33-EDT Date: Thu, 23 May 1985 08:03 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Get-Setf-Method Get-Setf-Method should take an (optional?) environment argument so that it can expand macros correctly. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:20:59 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 May 85 01:57:27 PDT Received: ID ; Thu 23 May 85 04:57:06-EDT Date: Thu, 23 May 1985 04:57 EDT Message-ID: From: Rob MacLachlan To: Dave Cc: Common-Lisp@SU-AI.ARPA Subject: Does FORMAT handle multiple values In-reply-to: Msg of 23 May 1985 04:30-EDT from Dave Date: Thursday, 23 May 1985 04:30-EDT From: Dave To: Common-Lisp at SU-AI.ARPA Re: Does FORMAT handle multiple values (format t "~S~%" (progn ... (values ...))) I'm not sure what you think that code is supposed to do, but there are two ways that I can think of to turn MV's into format arguments (or any other kind of arguments). You can use Multiple-Value-List (not values-list, as you said) to get a list, or you can use Multiple-Value-Call. In Common Lisp, there is no user-visible distinction between returning one value and returning one "multiple value", so the multiple-value-### primitives will work fine even if only one value is being returned. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:18:50 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 23 May 85 06:57:36 PDT Date: Thu, 23 May 85 09:57:23 EDT From: greek@DEC-HUDSON Subject: Adjusting Displaced Arrays To: common-lisp@su-ai We were so confused about the problem of adjusting displaced arrays, we simply don't allow it in VAX LISP. I'd sure appreciate some thoughts on the matter myself. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:09:51 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 07:47:31 PDT Received: by THINK.ARPA with CHAOS id AA04605; Thu, 23 May 85 10:42:58 edt Date: Thursday, 23 May 1985, 10:43-EDT From: Guy Steele Subject: Does FORMAT handle multiple values To: Common-Lisp%SU-AI.ARPA@THINK.ARPA Cc: gls%AQUINAS@THINK.ARPA In-Reply-To: Your message of 23 May 85 04:30-EDT Message-Id: <850523104328.2.GLS@YON.ARPA> Date: 23 May 85 04:30:24 EDT From: Dave Does format handle multiple values at all? What I want to do is something like the following (only this throws away everything but the first value): (format t "~S~%" (progn ... (values ...))) I would write this as (multiple-value-call #'format t "~S~%" (progn ... (values ...))) thereby causing multiple values from each argument form to be "spread out" as separate arguments to FORMAT. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 12:04:17 EST Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 23 May 85 08:40:52 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46) id AA09771; Thu, 23 May 85 08:38:42 pdt Received: by ucbdali.ARPA (4.24/4.46) id AA12133; Thu, 23 May 85 08:40:55 pdt Date: Thu, 23 May 85 08:40:55 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8505231540.AA12133@ucbdali.ARPA> To: common-lisp@su-ai Subject: rules of the game It seems to me that this was brought up at the Monterey meeting (by me). That CLTL was an informal description of an approach to a Lisp dialect, leaving a considerable amount of discretion to the implementor. A language consistent with CLTL could be called compatible with CL'84 (say). When/if there is another CL, one which has an official standard-setting description, it could be called (say) CL '86. There could also be some subset CL standard. The relationship between CL'84 and CL '86 could resemble the relationships between the various Fortrans. Namely, they have similar names and intentions, but are not necessarily compatible in detail. To imply that CL is static will encourage people to design and promulgate the YADOCL family of languages (Yet Another Derivative of Common Lisp). Now if CL'84 stands in the same relation to Lisps of the next 20 years as Lisp 1.5 stood to Lisps of the previous 20 years, this may also be OK. It doesn't solve DARPA's problems of complete compatibility and portability of code, but neither, after all, did CL '84. I think it would be a mistake to be stubborn about changes. P.S. the location of the branch cut for the complex atan is not likely to affect any existing CL code, and I think that the IEEE or APL standards committee might be followed without injury.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 11:04:55 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 23 May 85 07:57:41 PDT Received: by THINK.ARPA with CHAOS id AA04649; Thu, 23 May 85 10:51:00 edt Date: Thursday, 23 May 1985, 10:51-EDT From: Guy Steele Subject: Adjustable and displaced arrays To: common-lisp%SU-AI@THINK.ARPA Cc: gls%AQUINAS@THINK.ARPA In-Reply-To: Message-Id: <850523105129.3.GLS@YON.ARPA> Date: Wed, 22 May 1985 23:56 EDT From: Rob MacLachlan I am somewhat confused about the interaction between array adjustment and displacement. In CLTL p298: Note that if the array a is created displaced to array b and subsequently array b is given to adjust-array, array a will still be displaced to array b; the effects of this displacement and the rule of row-major storage order must be taken into account. What is this trying to say? Is this a warning to the user or a threat to the implementor? The obvious interpretation of this statement seems to require that all non-simple arrays contain a list of all the other array headers that share the same data so that they can be fixed up when the array is adjusted. The answer that you stick in a forwarding pointer is not acceptable. This should be elucidated in the next edition. If you put this paragraph beside the descriptions of :DISPLACED-TO and :DISPLACED-INDEX-OFFSET on pages 288-289, and assume that array a is essentially unaffected, one concludes that array a is still displaced to array b, the mapping between elements still being determined by taking the elements in row-major order and then mapping element k of array a to element k+n of array b, where n is the :displaced-index-offset for array a. The only difference is that array b, having been adjusted, may have a different row-major ordering. (A nasty problem is that the roles of arrays A and B are reversed on pages 288 and 298! Sorry about that.) The statement in the manual also doesn't answer the question of what happens to array b if array a is adjusted. Is it legal or meaningful to have arrays which are both displaced to another array and adjustable? What are the semantics of adjusting such an array? Well, page 298 says that if A is displaced to X, then after adjustment of A, A has no relationship to X, nor does the returned result, unless X is respecified explicitly in the :displaced-to option to ADJUST-ARRAY. I admit that this fails to state explicitly that X is unaffected. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 00:20:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 21:08:22 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242358; Thu 23-May-85 00:07:47-EDT Date: Thu, 23 May 85 00:08 EDT From: Daniel L. Weinreb Subject: EQUALP hash tables (and more ...) To: Fahlman@CMU-CS-C.ARPA, hoey@NRL-AIC.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850523000805.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Reply-To: dlw@SCRC-STONY-BROOK.ARPA Date: Sun, 12 May 1985 23:30 EDT From: "Scott E. Fahlman" So I guess the point is that given magic EQ and EQL hashtables that work even when a GC moves things, you can use these to build a slower version of EQ and EQL hashtables (and related thingies) that also works, without giving the users direct access to the magic. Interesting in principle, but not the way you'd want to do anything real. Au contraire. Multics Maclisp uses this to implement the wonderful Maclisp MAKNUM and MUNKAM functions. I suppose it depends on what you mean by "real"...  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 May 85 00:08:13 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 May 85 20:56:58 PDT Received: ID ; Wed 22 May 85 23:56:52-EDT Date: Wed, 22 May 1985 23:56 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Adjustable and displaced arrays I am somewhat confused about the interaction between array adjustment and displacement. In CLTL p298: Note that if the array a is created displaced to array b and subsequently array b is given to adjust-array, array a will still be displaced to array b; the effects of this displacement and the rule of row-major storage order must be taken into account. What is this trying to say? Is this a warning to the user or a threat to the implementor? The obvious interpretation of this statement seems to require that all non-simple arrays contain a list of all the other array headers that share the same data so that they can be fixed up when the array is adjusted. The answer that you stick in a forwarding pointer is not acceptable. The statement in the manual also doesn't answer the question of what happens to array b if array a is adjusted. Is it legal or meaningful to have arrays which are both displaced to another array and adjustable? What are the semantics of adjusting such an array? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 22:38:35 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 19:27:18 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242258; Wed 22-May-85 21:20:26-EDT Date: Wed, 22 May 85 21:20 EDT From: Daniel L. Weinreb Subject: Macros -> declarations To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850522212037.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Reply-To: dlw@SCRC-STONY-BROOK.ARPA Date: Thu, 16 May 1985 22:45 EDT From: "Scott E. Fahlman" But we should only make this move so late in the game if just about everyone else feels likewise. -- Scott Taking this a few steps further, I think it's important that we decide what our philosophy is about "changes to Common Lisp", particularly in light of the fact that the manual has been published and is now on the shelves of bookstores. What does it mean for us to "make a move"? This is not intended as a criticism of Masinter's suggestion or any other particular suggestion (I actually like the suggestion, although I haven't considered it carefully). I just think we'd spend our time better if it were somewhat more clear what game we are playing and what the rules are, and I'm worried that we're spending a great deal of time and energy designing Common Lisp after the horse has been let out of the barn. Are we really designing a new second-generation Common Lisp? Or are we proposing to tell the world shortly that the book isn't really the Real Common Lisp, please make the following forty changes to your copy? Once we have answered this question, then we can agree on a general philosophy about what degree of change is allowable.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 22:37:24 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 19:27:30 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242291; Wed 22-May-85 22:19:24-EDT Date: Wed, 22 May 85 22:19 EDT From: David A. Moon Subject: Special form terminology To: Common-Lisp@SU-AI.ARPA References: <850522182532.3.ACW@ROCKY-MOUNTAINS.SCRC.Symbolics.COM> Message-ID: <850522221918.3.MOON@EUPHRATES.SCRC.Symbolics.COM> The following message may be of interest to you: Date: Wed, 22 May 85 18:25 EDT From: Allan C. Wechsler The line we have taken at Ed. Services is that macros are a subclass of special operator. The taxonomic tree we have been using looks like this: Operators __________/\_____ | | Functions Special Operators ____________/\____________ | | Macros Primitive Special Operators (PSOs) This way we have a name for each useful subdivision. Also, we need not distinguish macros from PSOs when it suits us not to. I think that whether a special operator is a PSO or a macro is often an implementation detail, which we shouldn't have to document in case we change our minds. So when I teach DEFSTRUCT, for example, I say it's a special operator. The students don't care whether it's primitive or not. They do care that it does not have function semantics.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 19:10:48 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 16:00:10 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242126; Wed 22-May-85 18:59:40-EDT Date: Wed, 22 May 85 18:59 EDT From: Robert W. Kerns Subject: Backquote idioms To: Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: <850522105634.1.GLS@MUNGO.ARPA> Message-ID: <850522185932.7.RWK@CROW.SCRC.Symbolics.COM> Date: Wednesday, 22 May 1985, 10:56-EDT From: Guy Steele By the way, ',@x is not always an error! It does make sense if x is exactly a singleton list. Sometimes this is useful in obscure cases. Similarly, ,@',,@x makes sense if x is a singleton list. See the end of this note. I think "is an error" is still the right phrase to apply. Just because there happens to be a value that does not result in an error does not make it proper. I think it is *MUCH* clearer to write ',(CAR X). You can do additional error checking on X if you like, and signal a comprehensible error, rather than depending on QUOTE to check! (I have seen implementations where QUOTE did not check).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 16:54:21 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 13:41:09 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 242016; Wed 22-May-85 16:40:27-EDT Date: Wed, 22 May 85 16:41 EDT From: David C. Plummer in disguise Subject: Re: Backquote idioms To: Steven M. Haflich , Kent M Pitman cc: common-lisp@SU-AI.ARPA In-Reply-To: <8505221833.AA16866@mit-eddie.ARPA>, <850522151235.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850522164152.8.NFEP@NEPONSET.SCRC.Symbolics.COM> I am not saying that 69 levels of backquote should not be defined. I am saying that it should not be encouraged for people writing programs. (After all, how do program writing programs bootstrap?) I have no objections to programs outputing 69 levels of backquoted structure, as long as a human never has to go near it; only some (possibly other) program should need to reinterpret it. As for what CLtL should say, I think it should say that backquote works to indefinite levels of nesting. I think it should give the common idioms. I think it should say that the deeper the nesting, the greater the loss of clarity to the human reader and the (2 for me and probably most people in this day and age) is what is considered within the normal style of programming. [I refer the audience to "The Program Feature" where it uses the word 'style' many times.] Note: I finally found where backquote is documented. it would be nice if there were a 'backquote' entry in the index.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 15:25:17 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 12:12:48 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241931; Wed 22-May-85 15:12:23-EDT Date: Wed, 22 May 85 15:12 EDT From: Kent M Pitman Subject: Re: Backquote idioms To: smh@MIT-EDDIE.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <8505221833.AA16866@mit-eddie.ARPA> Message-ID: <850522151235.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 22 May 85 14:33:01 edt From: Steven M. Haflich From @SU-AI.ARPA:DCP@SCRC-STONY-BROOK.ARPA Wed May 22 12:01:25 1985 Subject: Backquote idioms Do you all believe these? Does it matter? RWK said he has never used a triple backquote. Neither have I. There may be applications which are really good hacks, but can they be maintained? Even some double nested backquotes require enough though[t] that they should probably be avoided. Conciseness and compactness does not imply clarity and robustness. I plead that it *does* matter. It does not depend on the wisdom of anyone (other than my good friend Bernie) writing triple nested backquotes. Consider rather automatic code generators. Sometimes a code generator needs output source code to a file, instead of generating forms in memory. Backquotes exist not to provide any additional expressiveness in printed representations, but (roughly) to make clearer constructions which embed the results of form evaluation inside a template. It is conceivable that a good automatic code generator could use backquotes to aid human readablility of its output, if only to aid debugging. But an automatic code generator might, like Bernie, lack sufficient discretion not to nest backquotes in cases where readability is indeed *not* enhanced. Indeed. All too much mail on this list recently seems to address the issue of what `reasonable people' should do. As much as possible, people shouldn't be writing programs; programs should be writing programs. And as such, it matters critically that language features be clearly defined to arbitrary levels of complexity. eg, I have programs that convert backquote syntax to LIST syntax and back, and I would be -very- aggravated if I had to pass level-number parameters around to make sure I wasn't nesting excessively. Just because people get bogged down with the number 7 plus or minus 2 doesn't mean programs do... I also disagree fully with the notion that 3-level is too deep. I think ,',',',',', is quite readable. I don't think ,',,',',, is as readable. Probably most of us find CAAAAAAAAR more readable than CADAADDAAR, though. I do use triply-nested backquote, though, and believe it to be even stylistically reasonable on occassion. I apologise to BSG for pulling his leg a little, but the point is serious: CLTL must either document firmly that more than two levels of backquotes are undefined, or else the reader grammar must be clear and obeyed by all implementations. Fine for a style handbook to claim that common idioms are preferred,etc but not fine for the language spec to take any stand at all other than to say what the definition is in a way that is neatly recursively defined.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 15:15:33 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 May 85 12:06:09 PDT Received: from Semillon.ms by ArpaGateway.ms ; 22 MAY 85 12:05:25 PDT Date: 22 May 85 12:05 PDT From: Masinter.pa@Xerox.ARPA Subject: Backquote idioms To: common-lisp@su-ai.ARPA Many of these issues would be moot if the implementation of backquote were specified in terms of what the read-macro generated, and the implementation of the macros that it then expanded to. Implementations could diverge from the "specified" one only if their divergence was invisible. It might mean that some of the current implementations might have to change, but if the "specified" implementation is faithful in implementing the book, it couldn't mean too much disruption in existing code, could it?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 15:04:42 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 May 85 11:55:02 PDT Received: by THINK.ARPA with CHAOS id AA20244; Wed, 22 May 85 14:49:16 edt Date: Wed, 22 May 85 14:49 EDT From: Guy Steele Subject: Backquote idioms To: BSG@SCRC-STONY-BROOK.ARPA, DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@GODOT.ARPA Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.ARPA In-Reply-To: <850522124944.2.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <850522144942.2.GLS@UBALDO.ARPA> While I am not prepared to defend the clarity of the original ONCE-ONLIFY-INDEX-OFFSET, I can say that the proposed replacement bothers me because of the repeated SETQ-ing of the argument variable FORM. It's hard to condemn nesting per se, as LISP is perhaps the quintessence of nesting languages. I think it *is* quite clear, with an order of magnitude less than ten seconds' thought, that ONCE-ONLIFY-INDEX-OFFSET is not depending on repeated evaluation of T or NIL: the value of WAS-IXO is a gensym, which is certainly not T or NIL. (In fact, that gensym is bound by a LET generated by the first level of backquote.) I have, once or twice in my career, had a need to write a macro that generates macros that generate code--and then need to abstract that ouetr macro yet again. This leads to triply nested backquotes. Generating things incrementally this way is not difficult at all, proceeding one layer of abstraction at a time. I wanted to investigate things from the point of the (human) reader, who sees the whole thing all at once. I use `',x a LOT. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 14:52:23 EST Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 22 May 85 11:41:56 PDT Received: by mit-eddie.ARPA (4.12/4.8) id AA16866; Wed, 22 May 85 14:33:01 edt Date: Wed, 22 May 85 14:33:01 edt From: Steven M. Haflich Message-Id: <8505221833.AA16866@mit-eddie.ARPA> To: common-lisp@su-ai.ARPA Subject: Re: Backquote idioms From @SU-AI.ARPA:DCP@SCRC-STONY-BROOK.ARPA Wed May 22 12:01:25 1985 Subject: Backquote idioms Do you all believe these? Does it matter? RWK said he has never used a triple backquote. Neither have I. There may be applications which are really good hacks, but can they be maintained? Even some double nested backquotes require enough though[t] that they should probably be avoided. Conciseness and compactness does not imply clarity and robustness. I plead that it *does* matter. It does not depend on the wisdom of anyone (other than my good friend Bernie) writing triple nested backquotes. Consider rather automatic code generators. Sometimes a code generator needs output source code to a file, instead of generating forms in memory. Backquotes exist not to provide any additional expressiveness in printed representations, but (roughly) to make clearer constructions which embed the results of form evaluation inside a template. It is conceivable that a good automatic code generator could use backquotes to aid human readablility of its output, if only to aid debugging. But an automatic code generator might, like Bernie, lack sufficient discretion not to nest backquotes in cases where readability is indeed *not* enhanced. I apologise to BSG for pulling his leg a little, but the point is serious: CLTL must either document firmly that more than two levels of backquotes are undefined, or else the reader grammar must be clear and obeyed by all implementations.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 13:23:44 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 10:09:41 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241800; Wed 22-May-85 12:48:22-EDT Date: Wed, 22 May 85 12:49 EDT From: David C. Plummer in disguise Subject: Backquote idioms To: Bernard S. Greenberg , DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@THINK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850522120451.4.BSG@CONCORD.SCRC.Symbolics.COM> Message-ID: <850522124944.2.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 22 May 85 12:04 EDT From: Bernard S. Greenberg Date: Wed, 22 May 85 11:54 EDT From: David C. Plummer in disguise Date: Wednesday, 22 May 1985, 10:56-EDT From: Guy Steele ```(,@',,@q) ;Alan's example ...etc... (QUOTE (3 5) (4 6)) ;but would be sensible if Q were the singleton list (R), ; in which case third evaluation would produce (3 5). Do you all believe these? Does it matter? RWK said he has never used a triple backquote. Neither have I. There may be applications which are really good hacks, but can they be maintained? Even some double nested backquotes require enough though that they should probably be avoided. Conciseness and compactness does not imply clarity and robustness. From LMFS:DEFSTORAGE (part of PL/I record simulating substrate of File System): (defmacro once-onlify-index-offset (form) (let ((do-it-p (gensym)) (was-ixo (gensym)) (ggs (gensym))) `(let ((,do-it-p (not (atom *defstorage-index-offset*))) (,was-ixo *defstorage-index-offset*)) (let-if ,do-it-p ;Guaranteed needs wrapping now. ((*defstorage-index-offset* '',ggs)) (wrap-if (symbolp ,was-ixo) ;Needs once-onlying at macro time. `(once-only (,,was-ixo) ,:the-form) (wrap-if ,do-it-p ``(let ((,',',ggs ,,,was-ixo)) ,,:the-form) ,form)))))) Admittedly, now that there are "language tools", this can be done better. I would not want to maintain this, especially the line ``(let ((,',',ggs ,,,was-ixo)) ,,:the-form) Is that ,,, really correct, or are you using the fact that NIL and T are self evaluating? If you have to think about that for more than 10 seconds, something is wrong. If it is obvious to you, I commend you for your understanding of complex uses of backquote, and ask you to take pity on the rest of us. I'll contend it can be done better without language tools. For example, you could build the form from the inside out, instead of your outside in method. Something like (I'm not sure what the semantics of :the-form are, so I'll guess), (defmacro once-onlify-index-offset (form) (let ((do-it-p (gensym)) (was-ixo (gensym)) (ggs (gensym))) `(let ((,do-it-p (not (atom *defstorage-index-offset*))) (,was-ixo *defstorage-index-offset*)) (let-if ,do-it-p ((*defstorage-index-offset* '',ggs)) (setq form (wrap-if ,do-it-p `(let ((,',ggs ,,was-ixo)) ,:the-form) form)) (setq form (wrap-if (symbolp ,was-ixo) `(once-only (,,was-ixo) ,:the-form) form)) form)))) I also have personal problems with macros that do computation instead of translation. Also, idioms like `', and the like should be discussed. I have always been amused by the analogy to tensor subscripts and superscripts and their contraction rules.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 13:23:34 EST Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 22 May 85 10:10:59 PDT Date: 22 May 1985 10:05:16 PDT Subject: Local SPECIAL declarations From: Dave Dyer To: common-lisp@SU-AI.ARPA I want to put in a good word for the use of local rather than global "SPECIAL" declarations. Local Specials are the perfect way to implement communication among functions that aren't lexically related, and where the information being passed in the specials is only needed among a few functions. The discipline of including the SPECIAL declaractions in every function focuses attention on the fact that this particular variable is indeed "special" in the ordinary sense as well as lisp's sense of the word. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 12:20:53 EST Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 22 May 85 09:06:07 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 38658; Wed 22-May-85 12:05:20-EDT Date: Wed, 22 May 85 12:04 EDT From: Bernard S. Greenberg Subject: Backquote idioms To: DCP@SCRC-QUABBIN.ARPA, gls%AQUINAS@THINK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850522115407.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <850522120451.4.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed, 22 May 85 11:54 EDT From: David C. Plummer in disguise Date: Wednesday, 22 May 1985, 10:56-EDT From: Guy Steele ```(,@',,@q) ;Alan's example ...etc... (QUOTE (3 5) (4 6)) ;but would be sensible if Q were the singleton list (R), ; in which case third evaluation would produce (3 5). Do you all believe these? Does it matter? RWK said he has never used a triple backquote. Neither have I. There may be applications which are really good hacks, but can they be maintained? Even some double nested backquotes require enough though that they should probably be avoided. Conciseness and compactness does not imply clarity and robustness. From LMFS:DEFSTORAGE (part of PL/I record simulating substrate of File System): (defmacro once-onlify-index-offset (form) (let ((do-it-p (gensym)) (was-ixo (gensym)) (ggs (gensym))) `(let ((,do-it-p (not (atom *defstorage-index-offset*))) (,was-ixo *defstorage-index-offset*)) (let-if ,do-it-p ;Guaranteed needs wrapping now. ((*defstorage-index-offset* '',ggs)) (wrap-if (symbolp ,was-ixo) ;Needs once-onlying at macro time. `(once-only (,,was-ixo) ,:the-form) (wrap-if ,do-it-p ``(let ((,',',ggs ,,,was-ixo)) ,,:the-form) ,form)))))) Admittedly, now that there are "language tools", this can be done better. Also, idioms like `', and the like should be discussed. I have always been amused by the analogy to tensor subscripts and superscripts and their contraction rules.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 12:03:01 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 85 08:53:29 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 241751; Wed 22-May-85 11:52:45-EDT Date: Wed, 22 May 85 11:54 EDT From: David C. Plummer in disguise Subject: Backquote idioms To: Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: <850522105634.1.GLS@MUNGO.ARPA> Message-ID: <850522115407.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wednesday, 22 May 1985, 10:56-EDT From: Guy Steele ```(,@',,@q) ;Alan's example ...etc... (QUOTE (3 5) (4 6)) ;but would be sensible if Q were the singleton list (R), ; in which case third evaluation would produce (3 5). Do you all believe these? Does it matter? RWK said he has never used a triple backquote. Neither have I. There may be applications which are really good hacks, but can they be maintained? Even some double nested backquotes require enough though that they should probably be avoided. Conciseness and compactness does not imply clarity and robustness.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 11:19:31 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 22 May 85 08:04:48 PDT Received: by THINK.ARPA with CHAOS id AA16659; Wed, 22 May 85 10:55:58 edt Date: Wednesday, 22 May 1985, 10:56-EDT From: Guy Steele Subject: Backquote idioms To: ALAN@MIT-MC@THINK.ARPA, JAR@MIT-MC Cc: common-lisp@sail, gls%AQUINAS@THINK.ARPA In-Reply-To: <[MIT-MC].513387.850521.ALAN> Message-Id: <850522105634.1.GLS@MUNGO.ARPA> Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Tue 21-May-85 22:44:45-EDT Received: from MIT-MC (mit-mc.arpa.ARPA) by THINK.ARPA id AA13184; Tue, 21 May 85 22:34:23 edt Date: Tue, 21 May 85 22:34:20 EST From: Alan Bawden Subject: Backquote idioms To: JAR@MIT-MC Cc: GLS@MIT-MC In-Reply-To: Msg of Tue 21 May 85 12:39:38 EST from Jonathan A Rees Message-Id: <[MIT-MC].513387.850521.ALAN> Date: Tue, 21 May 85 12:39:38 EST From: Jonathan A Rees Date: Monday, 20 May 1985, 10:48-EDT From: Guy Steele Much to my surprise, I find that (a) ,,@ *is* supported by Common Lisp. (b) ,,@ is equivalent to ,@(list ,@ Alan told me that `(,b) was allowed to expand to (cons b nil) , which would cause ,,@ to not work: ``(,,@x) ==> `(cons ,@x nil) I don't have my CLTL handy, so I can't check this. Steele is right! I have been making fun of the crazy grammar that the CL book uses to explain backquote expansion, but no more! According to that grammar all of ",,@", ",@,", ",@,@" and ",@'," work as expected! I didn't bother to work out all of the three level comma combinations, I expect they work too, but I can't figure out at the moment if ",@',,@" makes sense... We could start sending bug reports to all of the backquote implementation that fail to meet the CL specification. I would predict that that would involve us in nit-picking discussions of the precise meaning of the list of "ligitimate" expansions given at the top of page 351. My position is that the examples on page 351 are all correct, but there should also be examples illustrating that they are not all correct if any of the items is a ,@-d form. I suspect that the problem in most implementations that fail my funny example is that there is an overzealous simplifier that is not checking for nested ,@ before simplifying. By the way, ',@x is not always an error! It does make sense if x is exactly a singleton list. Sometimes this is useful in obscure cases. Similarly, ,@',,@x makes sense if x is a singleton list. See the end of this note. I have constructed a version of backquote that rigorously follows the backquote grammar on pages 349-350, and then optionally applies a simplifier of my own random device. Here follow a bunch of examples. For each example is shown: the original backquoted form the unsimplified expansion the simplified expansion result of applying EVAL once result of applying EVAL twice ... result of applying EVAL as many times as there were backquotes ;;; First, some useful data for the examples. (defun foo (x) (list 'fooed x)) (setq q '(r s)) (defun r (x) (reduce #'* x)) (setq r '(3 5)) (setq s '(4 6)) ``(,,q) (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST Q)))) (LIST 'LIST Q) (LIST (R S)) (24) ``(,@,q) (APPEND (LIST 'APPEND) (LIST Q)) Q (R S) 24 ``(,,@q) (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) Q))) (CONS 'LIST Q) (LIST R S) ((3 5) (4 6)) ``(,@,@q) (APPEND (LIST 'APPEND) Q) (CONS 'APPEND Q) (APPEND R S) (3 5 4 6) `(foo `(bar ,,q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) (LIST (APPEND (LIST 'LIST) (LIST Q)))))) (LIST 'FOO (LIST 'LIST '(QUOTE BAR) Q)) (FOO (LIST (QUOTE BAR) (R S))) (FOOED (BAR 24)) `(foo `(bar ,@,q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) (LIST Q)))) (LIST 'FOO (LIST 'CONS '(QUOTE BAR) Q)) (FOO (CONS (QUOTE BAR) (R S))) (FOOED (BAR . 24)) `(foo `(bar ,,@q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) (LIST (APPEND (LIST 'LIST) Q))))) (LIST 'FOO (LIST* 'LIST '(QUOTE BAR) Q)) (FOO (LIST (QUOTE BAR) R S)) (FOOED (BAR (3 5) (4 6))) `(foo `(bar ,@,@q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) Q))) (LIST 'FOO (LIST 'CONS '(QUOTE BAR) (CONS 'APPEND Q))) (FOO (CONS (QUOTE BAR) (APPEND R S))) (FOOED (BAR 3 5 4 6)) ``(,',q) (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q)))))) (LIST 'QUOTE (LIST Q)) (QUOTE ((R S))) ((R S)) ``(,@',q) (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'QUOTE) (LIST Q)))) (LIST 'QUOTE Q) (QUOTE (R S)) (R S) `(foo `(bar ,',q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q)))))))) (LIST 'FOO (LIST 'QUOTE (LIST 'BAR Q))) (FOO (QUOTE (BAR (R S)))) (FOOED (BAR (R S))) `(foo `(bar ,@',q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) (LIST (APPEND (LIST 'QUOTE) (LIST Q)))))) (LIST 'FOO (LIST 'QUOTE (CONS 'BAR Q))) (FOO (QUOTE (BAR R S))) (FOOED (BAR R S)) `(foo `(bar ',',q)) (APPEND (LIST 'FOO) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'BAR))))) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'QUOTE))))) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST Q)))))))))))) (LIST 'FOO (LIST 'QUOTE (LIST 'BAR (LIST 'QUOTE Q)))) (FOO (QUOTE (BAR (QUOTE (R S))))) (FOOED (BAR (QUOTE (R S)))) ```(,@',,@q) ;Alan's example (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'APPEND))))) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'APPEND) (LIST (APPEND (LIST 'LIST) (LIST (APPEND (LIST 'QUOTE) (LIST 'QUOTE))))) (LIST (APPEND (LIST 'LIST) Q))))))) (LIST* 'LIST '(QUOTE QUOTE) Q) (LIST (QUOTE QUOTE) R S) (QUOTE (3 5) (4 6)) ;but would be sensible if Q were the singleton list (R), ; in which case third evaluation would produce (3 5). Do you all believe these? --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 May 85 01:20:37 EST Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 21 May 85 22:11:22 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 14543; Tue 21-May-85 21:21:59-EDT Date: Tue, 21 May 85 21:21 EDT From: David A. Moon Subject: terminology To: Glenn S. Burke cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC].511948.850520.GSB> Message-ID: <850521212134.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 20 May 85 21:46:08 EST From: Glenn S. Burke The use of "form" in special form leads to additional confusion -- is "(if this that something-else)" a special-form, or is "if" a special form? I would much prefer "special operator", although that leads me to say that "operator" should be used to refer to {special-operators, macros, functions}. I agree with this. I also believe (but haven't checked recently) that this is the terminology used in Symbolics documentation and training (except that not all of the documentation has yet been updated to conform to the standard terminology).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 May 85 11:57:40 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 May 85 08:48:43 PDT Date: Tue, 21 May 85 11:49:46 EST From: Jonathan A Rees Subject: "Special Operator" To: common-lisp@SU-AI In-reply-to: Msg of Sat 18 May 85 14:11 EDT from Kent M Pitman Message-ID: <[MIT-MC].512627.850521.JAR> Date: Sat, 18 May 85 14:11 EDT From: Kent M Pitman ... Also, I'd like to replace the term "special form" with "special operator" when it doesn't apply to the whole form. ie, COND is not a special form, it is a special operator. Creating a new term to permit this distinction is an excellent idea. Saying that COND is a special form is like saying that CAR is a function call. Jonathan  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 May 85 11:11:14 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 May 85 08:01:10 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 240608; Tue 21-May-85 11:00:56-EDT Date: Tue, 21 May 85 11:00 EDT From: Robert W. Kerns Subject: Backquote idioms To: Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: <850517125728.2.GLS@DESIDERIUS.ARPA> Message-ID: <850521110036.5.RWK@CROW.SCRC.Symbolics.COM> Date: Friday, 17 May 1985, 12:57-EDT From: Guy Steele Has anyone ever undertaken a study or catalog of backquote idioms? Those of you who have used backquote at all seriously have probably come to regard ', ,', ,, ,@, ,@', ,',', ---------------------------------------------------------^^^^ Shades of back-quote TECO! I discourage people from nesting things three deep, and never do in my code! It makes the list of idioms too long. Anyway, to contribute my own "idiom" and thoughts to your list: You *NEVER* see ,',@. It's useful to recognize this one as an error. (It helps to look at it as ,(QUOTE ,@X), and to remember that QUOTE does not take a variable number of arguments.) When I'm explaining backquote to people, I stick with the following list, as the "most useful" and "easiest explained". , ', ,', ,@', And, of course, the error case above, which helps them remember it's ,@', not ,',@. Personally, I feel we would do well to include a list of idioms in the next CLtL and recommend that people stick with the set of idioms. It makes it a lot easier to read code if you only have to contend with a fixed set of "tokens". I think a little taxonomy of idioms is useful: In most usage of nested back-quoting, the form produced is going to be evaluated once per level. Doing (SETQ ARGS '('A 'AA 'AAA)) (setq f '``(list ,@(list ,@ARGS))) (eval f) ==> `(LIST A AA AAA) (eval (eval f)) ==> (LIST A AA AAA) In this case, we see that A, AA, and AAA, while originally quoted, are about to be evaluated in the resulting form. This double evaluation is a charactaristic of all of these idioms which have more than one more comma than quote. I.e. ,, ,@, ,,@ and ,@(list ,@ARGS) In general, it is rarely the right thing for something to be evaluated multiple times. We rarely write A and expect the value of A's value. I find this division of these idioms into "single-evaluation", "multiple evaluation" and "complete error" to be quite helpful. I consider any use of "multiple evaluation" idioms to be suspect when I'm looking for bugs in code. Also, since I can never construct convincing examples of when they're useful when I'm showing someone backquote, I usually don't explain them at all the first time around. However, it seems to me that ,@(LIST is the same as just plain comma. I.e. the following also gives the same result. (setq f1 '``(list ,,@args)) (eval f1) ==> `(LIST A AA AAA) (eval (eval f1)) ==> (LIST A AA AAA) Is there really a reason to add ,@(LIST ,@ to our lexicon?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 May 85 02:00:39 EST Received: from IMSSS by SU-AI with PUP; 20-May-85 22:51 PDT Date: 20 May 1985 2247-PDT From: Rem@IMSSS Subject: FORM vs. FUNCTION etc. To: COMMON-LISP@SU-AI It seems to me the following is consistent usage close to LISP tradition: A 'form' is an executable s-expression, i.e. something that might reasonably be passed to EVAL or pass through the compiler. Forms are atomic or non-atomic. Non-atomic forms have two parts, the function part (the CAR, which may be a function or the name of a function or something analagous) and the argument part (the CDR, which is usually a list of arguments but may be rather strange in macros and special-forms). Perhaps anything that can fit in the function part of a form should be called a 'function', but in CL that term has been restricted to omit macros and special-forms [sic]. Alternatively it could be called an 'operator'. Thus an operator would be either a function or a macro-operator or a special-operator or the names of any of those: I.e. any of # or (LAMBDA (X) (PLUS 5 X)) or ADD5 or # or PROG1 or # or GO. (Don't take those code-pointers literally, DWIM.) So, is it likely we can agree on some consistent usage that distinguishes a function or operator (or its name) from a form containing it? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 May 85 21:55:29 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 May 85 18:44:39 PDT Date: Mon, 20 May 85 21:46:08 EST From: Glenn S. Burke Subject: terminology To: common-lisp@SU-AI Message-ID: <[MIT-MC].511948.850520.GSB> I haven't looked through the manual in a while so don't remember exactly what terminology it uses for these things. But... Two of the terms which I have been asked about many times (with reference to CLtM, but also to the NIL manual and maybe also Lisp machine lisp documentation) are "function" and "special form". Not even including referential issues ("the name of"), "function" has been taken to mean those things which you can apply, and sometimes those PLUS macros and special forms. The definition of FUNCTIONP does not help things either. The use of "form" in special form leads to additional confusion -- is "(if this that something-else)" a special-form, or is "if" a special form? I would much prefer "special operator", although that leads me to say that "operator" should be used to refer to {special-operators, macros, functions}.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 May 85 21:21:44 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 May 85 18:10:18 PDT Date: Mon, 20 May 85 21:11:13 EST From: Glenn S. Burke Subject: hash table types -- ROT To: common-lisp@SU-AI Message-ID: <[MIT-MC].511876.850520.GSB> NIL has a ROT function which rotates within a fixnum size. It was there years and years ago, and never taken out. The ONLY use within all of NIL is hidden inside a macro which combines hash codes, called SXHASH-COMBINE -- (SXHASH-COMBINE n1 n2 ...) crunches together its arguments, rotating them varying amounts first. I can't say i've ever wanted to use ROT in any other circumstance. I have on occasion, however, thought about a LDB which sign-extends.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 May 85 16:37:24 EST Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 20 May 85 13:28:17 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 14082; Mon 20-May-85 16:28:29-EDT Date: Mon, 20 May 85 16:28 EDT From: Kent M Pitman Subject: "Special Operator" vs "Special Form" To: Fahlman@CMU-CS-C.ARPA cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850520162811.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Sat, 18 May 1985 17:05 EDT From: "Scott E. Fahlman" Date: 18 May 1985 14:11-EDT From: Kent M Pitman By the way, apropos of Masinter's comments ... I assume this is what he was alluding to about it might have been more appopriate for syntax declarations, as in (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)). I guess it's a little late to try to make such a change in CL84, much less CL86. Maybe CL88... I don't understand this at all. Are you asking for a way for users to declare that some user-defined form is a special form? There aren't supposed to be any user-defined special forms. Sorry, I still get special and macro confused. In my Special Forms paper in the 1980 lisp conference, I defined macros to be a subset of special forms. Somewhere along the line, someone has taken it upon himself to change the terminology and I haven't completely debugged things. Well, (PROCLAIM '(SPECIAL ...)) could still be meaningful, just not useful. I guess I was really thinking (PROCLAIM '(MACRO ...)), though. In any case, I wasn't meaning to propose anything; was mostly just making an observation. I'm glad you agree that precise terminology on these things is important, though, because that brings me neatly into the other point... -- "Special Operator" vs "Special Form" -- Also, I'd like to replace the term "special form" with "special operator" when it doesn't apply to the whole form. ie, COND is not a special form, it is a special operator (properly, it's the name of a special operator but that's not so critical to me at this point). Well, I've already used up my quota of ridicule for the month, so I'll just say that this looks to me like nit-picking and I would oppose any change to the name of a function in order to remove the alleged inconsistency in the nomenclature. Name changes are always more hassle than they should be, so they should only be done when the old name was actually confusing people. My experience with teaching novices is that things work better when important terms like these work better when used very consistently, and I really believe people are probably being confused by this. I consider the issue of consistent naming to be extremely important during the "formative years" of programmers learning a new language. I think it sufficiently important to be worth weathering the hassle of a name-change, though as I said I'm willing to all that name change to happen in two steps over several years if necessary.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 May 85 13:23:13 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 20 May 85 10:12:15 PDT Received: by THINK.ARPA with CHAOS id AA25172; Mon, 20 May 85 13:02:45 edt Date: Monday, 20 May 1985, 13:03-EDT From: Guy Steele Subject: Backquote idioms To: Common-lisp%sail@THINK.ARPA Cc: gls%AQUINAS@THINK.ARPA In-Reply-To: The message of 20 May 85 11:42-EDT from Mail Delivery Subsystem Message-Id: <850520130325.6.GLS@DESIDERIUS.ARPA> Date: Fri, 17 May 85 20:44:49 EST From: Jonathan A Rees Subject: Backquote idioms To: gls%AQUINAS@THINK And consider the useful but not CL-supported ,,@ . Much to my surprise, I find that (a) ,,@ *is* supported by Common Lisp. (b) ,,@ is equivalent to ,@(list ,@ I obtained these results by working through the expansions of `(foo `(bar ,,@x)) and `(foo `(bar ,@(list ,@x))) using the rules on pages 349-350 of the CLM. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 May 85 10:32:49 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 85 07:21:04 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239648; Mon 20-May-85 10:11:10-EDT Date: Mon, 20 May 85 10:12 EDT From: David C. Plummer in disguise Subject: hash table types To: Jon White , dcp@TENEX cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 17 May 85 11:41-EDT from Jon White Message-ID: <850520101218.0.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: 17 May 85 0841 PDT From: Jon White Your list of "external things [I] see need changing" looks quite good to me. I might add the suggestion that we add a ROT primitive to CL which is machine independent. The following definition got added to Interlisp shortly after I went to Xerox: (ROT x n fieldsize) "performs a bitwise left-rotation of the integer x, by n places, within a field of fieldsize bits wide. Bits shifted out of the position selected by (expt 2 (sub1 fieldsize)) will flow into the 'units' position." Now, this definition has the advantage that on many machines, there will be one particular field size for which the implementation of this ROT will be very efficient (i.e., the one actually supported by a hardware ROT instruction). And since SXHASH is permitted to be implemetation dependent -- not "address dependent", but rather varying between one implementation and another -- then each implementation can use a ROT in it's sxhash with a field size that is efficient. I wouldn't object to this, but a refinement is necessary. Is ROT supposed to give the same answer in all implementations? On two's complement machines, (rot 1 (1- n) n) where N is the word width is (probably) MOST-NEGATIVE-FIXNUM. Also, (rot 1 (1- n) n) == (ash -1 (1- n)). In other words, ROT should imply sign extension (on two's complement machines).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 May 85 10:20:25 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 85 07:05:40 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239627; Mon 20-May-85 10:03:52-EDT Date: Mon, 20 May 85 10:04 EDT From: David C. Plummer in disguise Subject: Macros -> declarations To: Scott E. Fahlman , Kent M Pitman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850520100457.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Suppose: We flush Macros -> declarations. Question: Is the compiler allowed to do arbitrary and repetitive ("destructive") macro expansion at any time? By "destructive", I don't necessarily mean RPLACA, I mean that the compiler then operates on the expanded expressions? If the answer is 'No' I suggest CLtL explains WHEN the compiler IS allowed to expand macros. If the answer is 'Yes' then I don't see how it is possible to flush macro calls expanding into declarations. In this case, the implementation of the compiler, NOT THE DEFINITION OF LANGUAGE, will determine the semantics of the macro. A compiler that pre-expanded all forms and subforms before "compiling" it would get the declarations that were the result of macro expansion. (As a side effect, the compiler would be guarenteed it wouldn't have to do macro expansion during "compiling".) A compiler that expanded outermost expressions as it got to them would not see the declarations which came from macros. An alternative, which I mention just for completeness and is so vile I'm glad I'm not prone to vomiting, is to kludge the automatic macro expansion facility to know when declarations are possible and not to expand macros it sees in those places (or maybe expand the macros but wrap a PROGN around it).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 May 85 15:54:07 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 May 85 12:46:28 PDT Received: ID ; Sun 19 May 85 15:46:18-EDT Date: Sun, 19 May 1985 15:46 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Yellow pages I have copied our local Spice Lisp program library to macine CMU-CS-C.ARPA, from which it should be easily accessible by FTP. The directory is PRVA:, and the file CATALOG.TXT describes the various programs in the library in a format that should be farily easy for future "librarian" programs to use. The master copy is still on CMU-CS-SPICE, but we'll try to keep the two directories in sync. RPG may also move a copy to SU-AI. This is just a beginning, of course. Some of the programs in this library are in somewhat ragged shape, and most of them are dependent on the Spice/Accent enviornment in some way. We hope to add some additional stuff to this library as the summer progresses, including OPS5 and Flavors. We will also be putting some effort into polishing these things up and separating the truly portable things from the non-portable ones. For now at least, we reserve the right to change or improve these files in incompatible ways any time we want to. If you want a stable copy of something, grab your own copy. If anyone else has contributions for this library, please let me know. If you take one of these modules and significantly improve it, please notify both the maintainer listed in the catalog file and me, and we'll try to fold your improvements into the library version in a coherent way. For now, we will only put things into the library that are public domain or for which we have been granted permission to redistribute the work without restriction. No, we are not prepared to mail anyone a tape of this stuff. It is changing too fast for that to be a worthwhile pursuit. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 May 85 12:38:20 EST Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 19 May 85 09:29:59 PDT Date: Sun, 19 May 85 12:28 EDT From: David.Dill@CMU-CS-A.ARPA (L170DD60) To: common-lisp@SU-AI.ARPA Subject: user hash tables Message-Id: <19May85.122856.DD60@CMU-CS-A.ARPA> I have needed these badly. I have two suggestions: I frequently want to store objects that have their retrieval keys in them already; for example, a structure representing a symbol in a table often has the string for the symbol sitting in the structure already for various reasons. It is pointlessly inefficient to represent this in the hash table as a pair (key . thing) when the thing contains the key already. What you need here is a set implemented as a hash table, where the definition of equality does comparison on some piece of the structure of the object stored in the table, while hash tables as currently designed are obviously intended to be like association lists. If a hash set could be created with user-supplied :hash and :equality routines, it would be very easy to do this. I believe that a hashed set abstraction is also useful in its own right. Now, in the example of a symbol table it is often the case that you have a string in hand, and you want to find out if it is already in the symbol table. If it is, you do nothing; if not, you want to create a symbol structure with various auxilliary fields and store it in the table. Hash sets as proposed above can be extended to do this very nicely by adding a :insert routine, which is called when something is added ("adjoined", I guess) to the table. In this example, the insert routine would take the string and table as an argument and create the symbol table structure just before stuffing into the appropriate hash bucket. Given hash sets in this form, it would be very easy to implement hash tables by having the insert routine cons up a (key . object) pair. (Actually, a lookup would return the pair and I don't remember whether CL hash tables return this or the object.) I have used a hash set implementation like this at CMU on the PQCC project and at Tartan Labs (the :insert routine idea was John Nestor's). Tables of this form don't quite do everything: sometimes I have wanted the key to be a combination of several fields of the structure being stored (say "name" field and "type" or "package"). I suppose the routines could be extended to take &REST arguments or whatever. One of the properties I usually want from a hash table is speed. Pulling hash and equality routines out of a hash table object and calling them is obviously going to add a fair amount of overhead to the whole process. It would be nice if users could define a new type of hash table by some method similar to DEFSTRUCT, and have these routines defined as macros that could be expanded at compile time (but please don't suggest hairing up DEFSTRUCT even more to do this!).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 May 85 12:35:13 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 19 May 85 09:25:44 PDT Posted-Date: 19 May 85 12:03 EDT Date: Sun, 19 May 85 12:01 EDT From: Nick Gall Subject: Re: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form" To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 18 May 85 14:11 EDT from "Kent M Pitman" Message-ID: <850519160157.528715@MIT-MULTICS.ARPA> Date: 18 May 1985 14:11 edt From: Kent M Pitman Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form" Date: 18 May 85 9:30:27 PDT From: masinter.PA@Xerox.ARPA ... As long as an incompatible name is being considered, how about changing the name? While there's some amusement in having SPECIAL a special form, the novice may well wonder, "well, what's so SPECIAL about them?". Guy was careful to call them DYNAMIC in the book; it sounds like a more appropriate name for a (different syntax) declaration. -- DYNAMIC/LEXICAL -- It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush SPECIAL (or make it mean something incompatible). Yes. -- *LEXPR -- Can we get a ruling on whether (FUNCTION (FOO INTEGER &OPTIONAL INTEGER)) is a valid declaration? p159 is very vague on the subject, giving no syntax restrictions for the arglist components at all. (Only through the limited fixed-arg example can you even infer that the arglist given should contain type names and not be the actual arglist used by the function.) First, there is an error in the equivalence between the FUNCTION and FTYPE decl. specifiers. The equivalence should be: (FUNCTION name arglist result-type-1 result-type-2 ...) <=> (FTYPE (FUNCTION arglist (VALUES result-type-1 result-type-2 ...)) name) Secondly, the definition of `arglist' appears on pg. 47 in the def. of the FUNCTION type specifier. Two suggestions for the FUNCTION type-specifier definition. (1) Change the word "markers" to "lambda-list keywords". (2) Define how a keyword and its type are associated. For example, if I have a function that takes a keyword argument named FOO of type INTEGER, I assume the type specifier would look like this: (FUNCTION (&KEY (FOO INTEGER)) ...). Also, take a look at the VALUES type-specifier on the next page. I was surprised to see that it also allows lambda-list keywords (albeit for a reason that confuses me). Could someone give an example of the usefulness of this? The compiler should be encouraged to complain if it sees (PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER)) and later sees (DEFUN FOO (X) (DECLARE (SYMBOL X)) ...) but should be discouraged from complaining (or should at least be encouraged to notice the non-fatal nature of the situation) if it later sees: (DEFUN FOO (X &OPTIONAL (Y 1) (Z 2)) (DECLARE (INTEGER X Y Z)) ...) since in the latter case, the definition is upward compatible with the declaration. Again I am confused. Is the following legal? (PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER)) (DEFUN FOO (ARG1) (DECLARE (INTEGER ARG1)) ...) I.E., Is downward compatibility allowed also? If not, then perhaps the upward compatibility case should not be legal. If downwardly compatible definitions ARE allowed, then to make a proclamation that allows upwardly compat. definitions one should proclaim (PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER &REST LIST)) This would allow any number of additional optional arguments. My guess is that neither are legal and that the arglist in the FUNCTION type-specifier must exactly match its corresponding lambda-list. It occurred to me that without &OPTIONAL working in FUNCTION declarations, the functionality of Maclisp's *LEXPR declaration is conspicuously absent. By the way, apropos of Masinter's comments above, and given that it's useful to declare something like takes-variable-number-of-args in advance to thwart forward-referencing problems, it might also want to be possible to declare that some form, WITH-RANDOM-BINDINGS, is a special form so that forward-references (which will tend to be fatal errors) to it can be diagnosed immediately rather than having to wait for the definition to roll by. I assume this is what he was alluding to about it might have been more appopriate for syntax declarations, as in (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)). I guess it's a little late to try to make such a change in CL84, much less CL86. Maybe CL88... I agree with Scott's comment. In CL, there's no such thing as a special-form that the compiler and interpreter don't know about. -- "Special Operator" vs "Special Form" -- Also, I'd like to replace the term "special form" with "special operator" when it doesn't apply to the whole form. ie, COND is not a special form, it is a special operator (properly, it's the name of a special operator but that's not so critical to me at this point). Certainly, (COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the same type so needs its own name. I would like to see SPECIAL-FORM-P made obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P introduced as an alternative. In this way, SPECIAL-FORM-P could eventually be recycled (or flushed from CL proper and re-invented by private applications that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually, having the interim compatibility definition be (OR (SPECIAL-OPERATOR-P x) (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x)))) wouldn't be so bad either if we could agree to that. That way, people who order their COND clauses correctly, could start taking advantage of the recycled meaning right away. In any case, the important point here is that the "form" / "operator" distinction needs to be made more clearly than we've been making it. Yes. I think its at least worth mentioning in the section on special forms that calling the symbol COND a `special-form' is a misnomer; precisely speaking it is the name of a special form. This kind of clarification is done for other `muddy' terms in CL, e.g., DYNAMIC, UNBOUND.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 22:24:45 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 May 85 19:14:28 PDT Date: Sat, 18 May 85 22:15:14 EST From: Glenn S. Burke Subject: Re: EQUALP hash tables (and more ...) To: Common-Lisp@SU-AI Message-ID: <[MIT-MC].509855.850518.GSB> Date: Fri, 17 May 85 21:14 EDT From: David A. Moon . . . One other point: I suspect that rather than specifying the equivalence function and the hashing function as separate arguments to MAKE-HASH-TABLE, you would be better off introducing a DEFHASH special form that defines a new flavor [sic] of hash table. That way, you package up the equivalence function and the hashing function together into something that has a name, and you don't have to face the issue of inconsistent combinations. Furthermore, the DEFHASH for EQ and EQL hash tables has already been done by the Common Lisp implementation, so you don't have to publish the name of their implementation-dependent hashing function. Yes. Our CL implementation already uses the :TEST argument to MAKE-HASH-TABLE as a key looked up in a table of flavors of hash table, but we haven't told users how to add their own entries to that table. NIL does likewise. One of the "flavors" of hash table is functional-hash-table, which is additionally parameterizable by a function to do error checking on the key (so that it gets caught at gethash level rather than by the equality or hashing function). There is also some hair so that the equality function used can be different from the name used to reference; e.g., hash-tables which use :TEST #'STRING-EQUAL (one of the hash table tests predefined in NIL) actually use an internal two-argument-only form of string-equal which doesn't check its arguments, rather than applying the hairy one which takes keyworded arguments. All NIL hash tables other than EQ and EQL are implemented through this (string=, char-equal, string-equal and equal are predefined).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 17:22:57 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 14:13:36 PDT Received: ID ; Sat 18 May 85 17:13:22-EDT Date: Sat, 18 May 1985 17:13 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Macros -> declarations (oops!) In-reply-to: Msg of 18 May 1985 16:51-EDT from Scott E. Fahlman In my previous message, next to last paragrpah, I referred to providing DYNAMIC and LEXICAL "declarations" a couple of times when I meant to say "proclamations". To clarify, the proposal is that there would be no DYNAIMC and LEXICAL declarations. Sigh! -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 17:16:02 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 14:06:19 PDT Received: ID ; Sat 18 May 85 17:05:50-EDT Date: Sat, 18 May 1985 17:05 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form" In-reply-to: Msg of 18 May 1985 14:11-EDT from Kent M Pitman By the way, apropos of Masinter's comments above, and given that it's useful to declare something like takes-variable-number-of-args in advance to thwart forward-referencing problems, it might also want to be possible to declare that some form, WITH-RANDOM-BINDINGS, is a special form so that forward-references (which will tend to be fatal errors) to it can be diagnosed immediately rather than having to wait for the definition to roll by. I assume this is what he was alluding to about it might have been more appopriate for syntax declarations, as in (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)). I guess it's a little late to try to make such a change in CL84, much less CL86. Maybe CL88... I don't understand this at all. Are you asking for a way for users to declare that some user-defined form is a special form? There aren't supposed to be any user-defined special forms. -- "Special Operator" vs "Special Form" -- Also, I'd like to replace the term "special form" with "special operator" when it doesn't apply to the whole form. ie, COND is not a special form, it is a special operator (properly, it's the name of a special operator but that's not so critical to me at this point). Well, I've already used up my quota of ridicule for the month, so I'll just say that this looks to me like nit-picking and I would oppose any change to the name of a function in order to remove the alleged inconsistency in the nomenclature. Name changes are always more hassle than they should be, so they should only be done when the old name was actually confusing people. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 17:01:46 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 13:52:02 PDT Received: ID ; Sat 18 May 85 16:51:38-EDT Date: Sat, 18 May 1985 16:51 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 18 May 1985 11:14-EDT from Kent M Pitman Here's where my thinking is right now on all of this declaration stuff. 1. If it were up to me, I would still flush macro-to-definition expansion, not because it is TOTALLY worthless but because the hassle it causes far outweighs the marginal benefits. However, I am willing to concede that this battle is lost, and that this misfeature will stay in the language. 2. Given that, we definitely need PARSE-BODY as an official part of the language, and some advice on its use in the chapter on Macros (or someplace). The arguments would be (form environment &optional (doc-string-allowed t)). Query: when this form returns a body, is it desirable to allow it to return a cons of the macro-expanded first form and the rest of the body, or should we require the original body to be returned? Returning the expanded first form might sometimes save some work, but I suppose you have to worry about things where some optional-argument init code changes something that would alter the macro-expansion. 3. I also think we should add KMP's extended syntax for &body, since that makes it possible for Macro writers to pick apart these things without having to explictly handle environments or even multiple values. I prefer the simple syntax for this, as in (...&body (body decl doc)), since it is less visually confusing (fewer nested parens) than the version with defaults, and since I see no real use for these defaults. But I could live with the more complex version, I guess. 4. We should give very serious consideration to eliminating local special declarations. We would add DYNAMIC and LEXICAL proclamations, and phase out the use of the term "special variable" and the SPECIAL proclamation. (These would be changed in the 1986 manual, with a note that this change has been made and advice that implementors handle the phase-out gradually and carefully.) There would be some style advice that DYNAMIC variables should generally be dynamic thoughout a whole program and should observe the *foo* convention. The ability to switch a variable back and forth from DYNAMIC to LEXICAL is provided mostly to allow old code to be more easily ported to Common Lisp. We might possibly need something like the SPECIAL-LET that Moon suggested -- I'm not sure. In answer to KMP's comments about the usefulness of special declarations in porting old code: Yes, clean language design and compatibility are natural enemies, as most of us in this effort have seen many times. Any one of us could have designed a better Lisp if compatibility were not an issue. On the other hand, we explicitly decided that we would not shoot for full upward compatibility with Maclisp or even for fully automatic translatability. Some things were just too ugly not to change. My own view of how compatible we want to be goes more or less as follows: it should be possible to translate a program like Macsyma into Common Lisp by having some competent programmer make a careful pass through the code. If there are things that just don't translate in any reasonable way (leaving aside some of the godawful PDP-10 hacks that occur at low levels in Macsyma), then we have diverged too far. But we should not feel constrained to have macsyma run in Common Lisp without a conversion effort, and we certainly shouldn't feel constrained by a desire to have the same source code run in other dialects of Lisp. Of the specific problems that KMP raises, mostly having to do with wanting to do big conversions a little bit at a time, I think that most of these problems go away if we provide both DYNAMIC and LEXICAL declarations. I recognize that it is sometimes convenient to have such declarations lexically bundled into the function definitions they modify, but I see no reason why the proclamations and the definitions can't be moved into a patch file together, as though they were surrounded by one set of outer parens. If you really care, there's always PROGN to bundle these top-level forms together. I think that this would handle Masinter's objection, about passing a form from one environment to another, as well. Finally, on BSG's suggestion for extensions to the macro syntax, so that we can macro-expand different types of forms in different namespaces. Right now we've only got two such contexts, normal evaluated forms and type declarations. There was a proposal for a third type of context, declaration subforms, but if we retain the Macro->declaration lossage it is not necessary to add this. I see no need to go to a more general mechanism to combine the two existing uses of macro-like expansion. I also feel that if we do make this generalization, the pressure to macro-expand new and bizarre kinds of things will increase over time. SO I think we should table BSG's suggestion until such time as there is a real need for it. I've dumped all this stuff at once since I'm going to be off the net for two weeks starting Monday. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 15:04:16 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 May 85 11:56:31 PDT Received: ID ; Sat 18 May 85 14:56:12-EDT Date: Sat, 18 May 1985 14:56 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA Subject: Macros -> declarations In-reply-to: Msg of 18 May 1985 11:14-EDT from Kent M Pitman Date: Saturday, 18 May 1985 11:14-EDT From: Kent M Pitman Date: Fri, 17 May 1985 23:50 EDT From: "Scott E. Fahlman" As Moon points out, even with this change we would still need PARSE-BODY for macro writers, or my &BODY hack. No sense in not providing both, though. I think that PARSE-BODY is needed even if the &BODY hack is used. People other than DEFMACRO (the mythical code analysis tools, for example) should have some convenient way to parse bodies. Also, providing such a hook and encouraging everyone to use it could make users' lives easier when and if the language changed in any radical way. On the other hand, the fancy &BODY syntax is a great win, and should be in the language as well. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 14:20:41 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 May 85 11:11:50 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239223; Sat 18-May-85 14:11:42-EDT Date: Sat, 18 May 85 14:11 EDT From: Kent M Pitman Subject: DYNAMIC/LEXICAL, *LEXPR, "Special Operator" vs "Special Form" To: masinter.PA@XEROX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 18 May 85 12:30-EDT from masinter.PA@XEROX.ARPA Message-ID: <850518141104.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 18 May 85 9:30:27 PDT From: masinter.PA@Xerox.ARPA ... As long as an incompatible name is being considered, how about changing the name? While there's some amusement in having SPECIAL a special form, the novice may well wonder, "well, what's so SPECIAL about them?". Guy was careful to call them DYNAMIC in the book; it sounds like a more appropriate name for a (different syntax) declaration. -- DYNAMIC/LEXICAL -- It would seem reasonable that CL86 should add DYNAMIC as a synonym for SPECIAL in the declaration world, and LEXICAL for symmetry. Then in CL88 could flush SPECIAL (or make it mean something incompatible). -- *LEXPR -- Can we get a ruling on whether (FUNCTION (FOO INTEGER &OPTIONAL INTEGER)) is a valid declaration? p159 is very vague on the subject, giving no syntax restrictions for the arglist components at all. (Only through the limited fixed-arg example can you even infer that the arglist given should contain type names and not be the actual arglist used by the function.) The compiler should be encouraged to complain if it sees (PROCLAIM '(FUNCTION FOO INTEGER &OPTIONAL INTEGER)) and later sees (DEFUN FOO (X) (DECLARE (SYMBOL X)) ...) but should be discouraged from complaining (or should at least be encouraged to notice the non-fatal nature of the situation) if it later sees: (DEFUN FOO (X &OPTIONAL (Y 1) (Z 2)) (DECLARE (INTEGER X Y Z)) ...) since in the latter case, the definition is upward compatible with the declaration. It occurred to me that without &OPTIONAL working in FUNCTION declarations, the functionality of Maclisp's *LEXPR declaration is conspicuously absent. By the way, apropos of Masinter's comments above, and given that it's useful to declare something like takes-variable-number-of-args in advance to thwart forward-referencing problems, it might also want to be possible to declare that some form, WITH-RANDOM-BINDINGS, is a special form so that forward-references (which will tend to be fatal errors) to it can be diagnosed immediately rather than having to wait for the definition to roll by. I assume this is what he was alluding to about it might have been more appopriate for syntax declarations, as in (PROCLAIM '(SPECIAL WITH-RANDOM-BINDINGS)). I guess it's a little late to try to make such a change in CL84, much less CL86. Maybe CL88... -- "Special Operator" vs "Special Form" -- Also, I'd like to replace the term "special form" with "special operator" when it doesn't apply to the whole form. ie, COND is not a special form, it is a special operator (properly, it's the name of a special operator but that's not so critical to me at this point). Certainly, (COND ((NULL X) T) (T NIL)) is a "special form" and COND is not of the same type so needs its own name. I would like to see SPECIAL-FORM-P made obsolete (but retained for a while for compatibility) and SPECIAL-OPERATOR-P introduced as an alternative. In this way, SPECIAL-FORM-P could eventually be recycled (or flushed from CL proper and re-invented by private applications that care) to be (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x))). Actually, having the interim compatibility definition be (OR (SPECIAL-OPERATOR-P x) (AND (TYPEP x 'CONS) (SPECIAL-OPERATOR-P (CAR x)))) wouldn't be so bad either if we could agree to that. That way, people who order their COND clauses correctly, could start taking advantage of the recycled meaning right away. In any case, the important point here is that the "form" / "operator" distinction needs to be made more clearly than we've been making it.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 12:39:38 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 May 85 09:32:35 PDT Received: from Riesling.ms by ArpaGateway.ms ; 18 MAY 85 09:32:17 PDT From: masinter.PA@Xerox.ARPA Date: 18 May 85 9:30:27 PDT Subject: uses for specials To: common-lisp@su-ai.ARPA I've seen more than one program that constructs expressions on the fly, and then EVALs them in another context. PROGV has an implicit local special declaration. As long as an incompatible name is being considered, how about changing the name? While there's some amusement in having SPECIAL a special form, the novice may well wonder, "well, what's so SPECIAL about them?". Guy was careful to call them DYNAMIC in the book; it sounds like a more appropriate name for a (different syntax) declaration.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 May 85 11:24:35 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 May 85 08:15:34 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239203; Sat 18-May-85 11:15:26-EDT Date: Sat, 18 May 85 11:14 EDT From: Kent M Pitman Subject: Macros -> declarations To: Fahlman@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850518111450.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 17 May 1985 23:50 EDT From: "Scott E. Fahlman" Now there's an idea: flush local SPECIAL declarations altogether, keeping only global SPECIAL proclamations. I'll have to think about this awhile to see if I really believe that we can do without these declarations, but it is certainly a very attractive suggestion at first glance. Can anyone think of a really important use for such declarations? I can provide a few from recent experience with Macsyma. I'm not sure they'll convince you 100%, but hopefully they'll at least make you stop and think. It largely depends on whether you consider the goal is to produce a language that's clean and shiny or one that cares about things like compatibility with the past where possible, etc. I think these goals conflict pretty badly. With my language designer's hat on, I'd reject almost all of these arguments out of hand. But since CL was designed by people prone to wear their politician's hats a lot of the time, I'm of the impression that things like "compatibility with the past" and such are likely to carry more weight, so here goes... * Sometimes a function will need to be compiled "out of place" (eg, before the relevant DEFVAR is loaded). In such cases, the problem may go away if you move the definition containing the spurious reference to another file (which is processed after the DEFVAR), but the SPECIAL declaration may linger. * In any large system which is being converted incrementally from some other Lisp dialect (eg, old Maclisp or a relative, Interlisp, ...), it may be desirable to incrementally convert the semantics of variables used by functions. Using local SPECIAL declarations, you can gradually whittle away the region in which certain specials are used. If you force global SPECIAL declarations, you undermine the ability to make such transitions incrementally. * Although Macsyma is being converted for Common Lisp, it may continue to run in other dialects of Lisp as well. As such, FLET and friends may not be available in those dialects and a number of situations may arise where local SPECIAL declarations provide a way of achieving compatibility with those otherwise-not-cooperating dialects. * There are numerous examples of special variables being used as communication between three or four definitions. We've been working on converting: (DECLARE (SPECIAL X)) (DEFUN FOO () ... refers to special X ...) (DEFUN BAR () ... refers to special X ...) (DECLARE (UNSPECIAL X)) into (DEFUN FOO () (DECLARE (SPECIAL X)) ... refers to special X ...) (DEFUN BAR () (DECLARE (SPECIAL X)) ... refers to special X ...) This a couple of advantages worth noting. * Common Lisp has no UNSPECIAL declaration (that I could find). If the special is a common name like X, we need to not have every reference to X compiled SPECIAL. It may be very expensive and dangerous (ie, in terms of potential for typos, timing errors, etc) to change all 180 source files for Macsyma to use names that could reasonably be left SPECIAL all the time. (At some point we may consider this, but...) * It makes it explicit when you look at a particular definition just how the communication is being done (since mostly these variables don't have *...* around them. * It is a -very- common problem that we will modify a definition and just put that definition in a patch file, only to find it compiles differently out of context because the appropriate SPECIAL declarations were not present. Having the SPECIAL declarations in the definition means they will move with the definition into the patch file. (This problem would be "solved" by making SPECIAL declarations global and outlawing UNSPECIAL, but would mean I'd have to rename an awful lot of variables, which I mentioned above is a bit scary...) ----Fahlman: I don't understand Moon's comment that local SPECIAL declarations have mostly been used to simulate what FLET does better. Can you elaborate a bit? I assume he meant that variables which must be accessed in downward funargs (eg, to MAPCAR and user-defined friends) no longer have to be passed special. Likewise, what people used to write as: (DEFUN IN (OBJ TREE) (DECLARE (SPECIAL OBJ)) (IN1 TREE)) (DEFUN IN1 () (DECLARE (SPECIAL OBJ)) (COND ((ATOM TREE) (EQ OBJ TREE)) (T (OR (IN1 (CAR TREE)) (IN1 (CDR TREE)))))) can now be written: (DEFUN IN (OBJ TREE) (LABELS ((IN1 (TREE) (COND ((ATOM TREE) (EQ OBJ TREE)) (T (OR (IN1 (CAR TREE)) (IN1 (CDR TREE))))))) (IN1 TREE))) ----Fahlman: As Moon points out, even with this change we would still need PARSE-BODY for macro writers, or my &BODY hack. No sense in not providing both, though. but it would sure make life easier for the interpreter, since the other declarations can all be ignored unless you're doing tense error-checking.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 23:58:34 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 May 85 20:50:57 PDT Received: ID ; Fri 17 May 85 23:50:21-EDT Date: Fri, 17 May 1985 23:50 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 17 May 1985 21:30-EDT from David A. Moon Now there's an idea: flush local SPECIAL declarations altogether, keeping only global SPECIAL proclamations. I'll have to think about this awhile to see if I really believe that we can do without these declarations, but it is certainly a very attractive suggestion at first glance. Can anyone think of a really important use for such declarations? I don't understand Moon's comment that local SPECIAL declarations have mostly been used to simulate what FLET does better. Can you elaborate a bit? As Moon points out, even with this change we would still need PARSE-BODY for macro writers, but it would sure make life easier for the interpreter, since the other declarations can all be ignored unless you're doing tense error-checking. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 21:41:30 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 May 85 18:31:03 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239102; Fri 17-May-85 21:30:58-EDT Date: Fri, 17 May 85 21:30 EDT From: David A. Moon Subject: Macros -> declarations To: common-lisp@SU-AI.ARPA In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, , The message of 16 May 85 17:53-EDT from Masinter.pa@Xerox.ARPA, , The message of 17 May 85 10:42-EDT from Masinter.pa@Xerox.ARPA, The message of 17 May 85 14:55-EDT from Charles Hedrick Message-ID: <850517213026.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 10 May 85 01:51 EDT From: Kent M Pitman (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...)) (DECLS '((DECLARE (SPECIAL *FOO*)))) (DOC "a macro")) ...) I believe that attacking the problem of DECLARE at the level people have been attacking it gives up programmer flexibility to no good end (not to mention introducing an incompatible change to the language semantics). A change like these syntax extensions to DEFMACRO that I've been speaking about would make life easy for the macro writer without giving up the macro-writing freedoms I was originally supporting. I think this is a good suggestion. Of course we ought to think about it a bit before adopting it, but I haven't seen any problems of Common Lisp changing too fast lately! Date: 16 May 85 14:53 PDT From: Masinter.pa@Xerox.ARPA The only reason for this issue is because the interpreter has to look ahead for SPECIAL declarations. SPECIAL declarations are the only ones that have any semantic import. Furthermore, SPECIAL declarations are the only ones that are textually retroactive, in that they apply to things that appeared BEFORE the declaration rather than after. This last sentence is not true. Actually, there are almost no declarations in Common Lisp that are -not- textually retroactive, because declarations are placed in the -middle- of the form to which they apply. Rather than hacking around the deficiencies of DECLARE, why not change it? Put SPECIAL declarations where they belong, next to the variable. Leave all the other declarations where they are. Most of these issues then become moot, and we can even consider freeing up some of the restrictions on declarations; it would seem reasonable to allow declarations anywhere in an implicit PROGN to refer to the stuff that follows. I don't think it is only SPECIAL declarations that need to be attached to variable bindings. Consider the data-type declarations. One point I'd like to make in this connection is that making SPECIAL declarations locally, rather than globally with DEFVAR, is generally not something we should be encouraging. It's worth noting that the main use of local SPECIAL declarations in Maclisp-like languages in the past has been to simulate what FLET does better. Now that we have full lexical scoping, we can probably dispense with local SPECIAL declarations. Perhaps the SPECIAL declaration should be phased out, so we can say that DECLARE never has "semantic import", but is only a hint to the compiler or otherwise an "annotation." The SPECIAL proclamation would remain, of course. If people feel it is necessary, some way to change the SPECIAL status of a name locally could be retained, but it need not be DECLARE. It could be a special [multiple puns intentional] version of LET. This wouldn't change the fact that macro writers need a PARSE-BODY, since losing an annotation that makes the code run efficiently is almost as unacceptable as losing an annotation that makes the code run correctly or one that documents the code. Date: Thu, 16 May 1985 22:45 EDT From: "Scott E. Fahlman" Personally, I like the idea. I've felt for some time that we ought to separate SPECIAL declarations from all the others, even if that means that Common Lisp ends up looking a little different from Maclisp. But we should only make this move so late in the game if just about everyone else feels likewise. Agreed. Date: 17 May 85 14:55:49 EDT From: Charles Hedrick As an implementor, I would be only too happy to flush the current (incomplete) tests for SPECIAL declarations in favor of something that is in the lambda list. The idea of using the pname is obviously a bad one, but I don't see any problem with things such as (foo &special bar) We haven't bothered to remove support for &SPECIAL from our system yet, so we could hardly complain if it became a standard instead of an obsolete holdover from the past! Again, though, I think there is little real need for local SPECIAL declarations.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 21:24:24 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 May 85 18:14:46 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 239098; Fri 17-May-85 21:14:43-EDT Date: Fri, 17 May 85 21:14 EDT From: David A. Moon Subject: EQUALP hash tables (and more ...) To: Common-Lisp@SU-AI.ARPA Message-ID: <850517211410.8.MOON@EUPHRATES.SCRC.Symbolics.COM> DCP's message of 12 May said most of what I want to say on the subject of generic hash tables, Symbolics' experience with them, and what issues are involved in implementing them. One other point: I suspect that rather than specifying the equivalence function and the hashing function as separate arguments to MAKE-HASH-TABLE, you would be better off introducing a DEFHASH special form that defines a new flavor [sic] of hash table. That way, you package up the equivalence function and the hashing function together into something that has a name, and you don't have to face the issue of inconsistent combinations. Furthermore, the DEFHASH for EQ and EQL hash tables has already been done by the Common Lisp implementation, so you don't have to publish the name of their implementation-dependent hashing function. Our CL implementation already uses the :TEST argument to MAKE-HASH-TABLE as a key looked up in a table of flavors of hash table, but we haven't told users how to add their own entries to that table.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 15:07:10 EST Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 17 May 85 11:56:57 PDT Date: 17 May 85 14:55:49 EDT From: Charles Hedrick Subject: special declaration To: common-lisp@SU-AI.ARPA As an implementor, I would be only too happy to flush the current (incomplete) tests for SPECIAL declarations in favor of something that is in the lambda list. The idea of using the pname is obviously a bad one, but I don't see any problem with things such as (foo &special bar) (foo (special bar)) (foo #$bar) I would much prefer these to the current situation, and the sooner the better... At the moment there probably isn't a large body of CL code yet. It is just barely possible to make changes like this now. Shortly it will not be practical. I assert that it is possible to do a mechanical translation from the old to the new form, particularly for implementations that don't yet handle macros that expand to declarations. I have thought of one case that this can't handle, but it is probably so pathological that we can ignore it. ------------------------ Appendix. A pathlogical case. In order to assure portability, it might be helpful to make sure that code can run in implementations that use lexical binding and in implementations that use dynamic binding. For this purpose, we will declare all of our variables using the macro SOMETIMES-SPECIAL. This will declare all of its arguments special when the day of the month is odd, and otherwise expand to NIL. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 13:53:32 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:58:16 PDT Received: by THINK.ARPA with CHAOS id AA06628; Fri, 17 May 85 12:47:31 edt Date: Friday, 17 May 1985, 12:48-EDT From: Guy Steele Subject: Poor excuse for a Quux To: common-lisp@sail Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850517124814.1.GLS@DESIDERIUS.ARPA> Sigh. I figured out why the SPECIAL:FOO suggestion was totally wedged about three seconds after I had mailed off my note. My apologies for wasting everyone's time. (Apologies too to KMP for misrepresenting his intentions.) I won't insult your intelligence by suggesting such epicycles as USER:SPECIAL:PRINT-PRETTY and TV:SPECIAL:MOUSE-CURSOR-PATTERN That's what I get for shooting from the hip.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 13:51:54 EST Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 17 May 85 10:30:23 PDT Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 4996; Fri 17-May-85 13:32:09-EDT Date: Fri, 17 May 85 13:30 EDT From: Soley@MIT-MC.ARPA Subject: Macros -> declarations To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850517092025.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850517133012.1.SOLEY@CHERRY.MIT> Date: Thu, 16 May 1985 22:45 EDT From: "Scott E. Fahlman" We've kicked this idea around before in various forms, including the use of some sort of syntactic marker on special bindings -- something like turning FOO into $FOO if the variable is special, or treating the *FOO* convention as being a declaration of specialness. Other lexical Lisps have done this sort of thing with no obvious ill effects (and arguably some good effects), but it seems to have been too radical a change to have been seriously considered by most of the Common Lisp people when the language was being designed. Definitely, a great idea. But instead, why not just say that all variables whose printnames start with the characters 'I' through 'N' are special? A good extension to tried and true languages. :-) -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 13:06:13 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:58:42 PDT Received: by THINK.ARPA with CHAOS id AA06920; Fri, 17 May 85 12:56:43 edt Date: Friday, 17 May 1985, 12:57-EDT From: Guy Steele Subject: Backquote idioms To: common-lisp@sail Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850517125728.2.GLS@DESIDERIUS.ARPA> Has anyone ever undertaken a study or catalog of backquote idioms? Those of you who have used backquote at all seriously have probably come to regard ', ,', ,, ,@, ,@', ,',', as primitive idioms, almost recognizable as units, such as we take in CADDR at a glance without thinking about the three component operations. I raise this question because a few weeks ago I was confronted for the first time with a situation for which the eventual solution was ,@(LIST ,@X) and it occurred to me that ,@(LIST ,@ is another useful idiom. (It is the splicing analogue[*] of ,, .) Anyway, it would be interesting to assemble a list of such useful idioms. It might make a good paper for the 1986 LISP conference. (Alan, are you listening?) --Guy [*] I am aware that it is terribly inconsistent of me to write "catalog" but "analogue". I promise not to do it again (very much).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 13:05:13 EST Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:53:46 PDT Message-Id: <8505171652.AA09246@nrl-aic> Date: 17 May 1985 12:08:27 EDT (Fri) From: Dan Hoey Subject: SXHASH and EQ hash tables To: Jon White Cc: common-lisp@su-ai.ARPA I agree that limiting the number of substructures visited by SXHASH is a good thing to do. The next manual should promise that SXHASH will operate on any object, and mention depth- and length-limiting as an implementation note. Probably what you want is just a limit on the number of substructures visited. There's probably no good way of outlawing a constant function, but I think the desirability of having a large range for SXHASH goes without saying. Scott pointed out to me that efficiency rules out having (SETF (GETHASH KEY ...)) do an automatic (COPY-TREE KEY) for the insertion. He suggested removing the item from the hashtable, then modifying it, then reinserting; that's a solution in some cases, but what if a lot of keys share the modified structure? Well, for EQUAL hash tables, I think the manual should mention that you might want to (SETF (GETHASH (COPY-TREE Key)...)). And for EQUALP hashtables, there should be a COPY-SUBSTRUCTURE (or COPY-TREE :TEST #'EQUALP ?) function to do the analogous thing. As for using SXHASH on EQ hash tables, I think this is a really bad idea. There's just no way to get around rehashing, and I think it's conceptually wrong to have to worry about it. I can see rehashing ``whenever some object in the table is updated'' but for EQ keys you aren't modifying the object in the table. Here I think the manual should promise that EQ hashing is insensitive to changes in substructures. Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:51:34 EST Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 17 May 85 09:34:13 PDT Received: by mit-eddie.ARPA (4.12/4.8) id AA27181; Fri, 17 May 85 12:33:48 edt Date: Fri, 17 May 85 12:33:48 edt From: Steven M. Haflich Message-Id: <8505171633.AA27181@mit-eddie.ARPA> To: common-lisp@sail Subject: Re: Poor excuse for packages Cc: gls%aquinas@think > KMP hinted at a very interesting solution to the special-variables > problem: let symbols in the package SPECIAL name special variables, > and let all others name local variables. But, but, then all specials are necessarily in the same package, and we are back to the original problem that component subsystems cannot ensure that their symbols will not clash with those of other subsystems. > It's cheap to detect, too, in interpreter or compiler: just check the > package cell. This I like. Too bad it's too late. This aspect is indeed nice! I think to do it right, each package would implicitly be split into two components: one subpackage containing the specials, and one the non-specials. (This use of "subpackage" has nothing to do with the old LM notion of subpackage.) The package name of the specials subpackage would be automatically generated, perhaps by prepending `*'. By reader convention, *:foo would be the special variable foo in the current package. The implementation would be such that the subpackages necessarily share the same inheritance structure; naming either subpackage in intern, import, export, shadow, etc., would be equivalent, except for the implication of variable specialness. On the balance, I agree this idea is not worth the pain. However, its consideration leads to an interesting question: Can anyone think of a situation in which it is useful or even reasonable to refer to a non-special variable using an explicit package qualifier?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:36:57 EST Date: 17 May 85 0807 PDT From: Jon White Subject: EQUALP hash tables To: Fahlman@CMU-CS-C.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your message of 11-May-85 10:59 EDT As for names for the "equivalence" and "numericalizing" functions for hash tables, well, the :test argument is already the "equivalence" argument; how about :sxhash for the numericalizing argument? This has the mnemonic value that the default for it could simply be #'SXHASH. I see no reason to restrict the possible values that :sxhash may have -- even when the :test argment is #'EQ; as my note last week was intending to point out, EQ-type hash tables needn't be constrained to use pointer bits for the :sxhash -- it's only a vague general feeling that we don't want to have to re-hash whenever some object in th table is updated that prevents use of #'SXHASH here. But for many (maybe even most?) applications there is really no need to worry about the updating problem; after all, who really worrys about it with EQUAL type tables? and it's just as serious a problm there too, as Hoey pointed out. How would you feel about this? The default :sxhash value will be an internal version of MAKNUM *** when the :test arg is #'EQ o #'EQL *** rather than SXHASH (appropriate conversions from 'EQ and 'EQL). iven this, is there any need to have the user supply the information that the table will have to be re-hash'd after a relocating GC? This condition should only occur when the :sxhash function is somehow a function of the entry's pointer address -- and by fiat you are ruling out any user-level function that returns that address. Can anyone think of a case where this isn't true? Finally, I'd say your suggestion for a REHASH function is quite timely. Interlisp has such a function: (REHASH hash-array new-array) where both argments are hash-arrays, and the first one is merely re-hashed into the second; a NIL for the second arg means something like (I think) "cons up a fresh hash array just big enough to hold all the elements of the first argument, and it's :rehash-threshold size"; and a T for the second arg means something like (I think) "cons up a fresh hash array big enough to be the growth by the :rehash-size of the first argument". [well, if it doesn't operate exactly like that, it should]. A useful scenario is to make a huge hash table, make many entries over a period of time, and then finally decide that not may more entries will be made; thus one will want to "shrink" the table to the minimum feasible size for holding the current entries. REHASH, as defined above, with a second arg of NIL is just the right thing. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:32:29 EST Date: 17 May 85 0735 PDT From: Jon White Subject: SXHASH on circular structures? To: Hoey@NRL-AIC.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your message of 10-May-85 3:54:51 EDT Yes, one might implement SXHASH in a manner that would loop on circular structures, but there is no requirement to do so. In fact, the CLM is so vague about sxhash that (defun sxhash (x) 1) is a perfectly legitimate definition! I think there has been a common misconception about sxhash that it must descend into every node of a structure; indeed, the first implementation in pdp10 MacLisp, over a decade ago, did just that (and I'm no doubt the guilty party). But more recently, I (and others) have experimented with definitions which are depth-limited. [Similarly, during the NIL development, both NIL and pdp10 MacLisp got definitions for a number of functions which were depth-limited, solely as a (slow) way to stop depth-limiting; this was done primarily as a low-overhead, fail-safe way to detect circularities. However, a fairly large limit has to be allowed, and thus this idea has a loop hole on "blam" lists given to EQUAL; but it effectively and somewhat quickly stop circularites on LENGTH, NTH, and a few others.] But the purpose of SXHASH is to provide a user interface to the "numericalizing" function needed for hash arrays; there is no need to make it more discriminatory that would be useful in providing a moderately random distribution of collision chains in hash tables. SXHASH is a many-to-one mapping, and there is no reason to assume that, statistically speaking, the depth cutoff is more damaging than is the accidental coinciding of a particular dataset -- one might think of this "accidental coinciding" as the inherent noise in the information of the problem. Of course, too small a limit on the depth would certainly be noticeable in terms of the *average* speed of hashing functions, but just exactly where that boundary is may be difficult to determine. [I wouldn't seriously suggest using a constant function, or even one that merely discriminated on the data type -- but can anyone seriously suggest that depth 1000 will be statistically different from depth 100? I would like to know.] For some months now, Lucid Common Lisp has been running with variations on the limited-depth sxhash, and not only does it meet the CLM requirements, but it seems to meet our day-to-day needs. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:17:40 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 08:59:20 PDT Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05491; Fri, 17 May 85 11:53:37 edt Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238658; Fri 17-May-85 11:52:10-EDT Date: Fri, 17 May 85 11:52 EDT From: Robert A. Cassels Subject: Poor excuse for packages To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA> Message-Id: <850517115227.0.CASSELS@CUYAHOGA.SCRC.Symbolics.COM> Date: Friday, 17 May 1985, 10:32-EDT From: Guy Steele KMP hinted at a very interesting solution to the special-variables problem: let symbols in the package SPECIAL name special variables, and let all others name local variables. There doesn't seem to be much wrong with (LET ((SPECIAL:MY-GLOBAL-FLAG 43) (SPECIAL:PRINT-PRETTY T)) ...) or (DEFUN FOO (A B SPECIAL:C) ...) Ack! What's the point of packages then? I thought they were for avoiding name conflicts. Maybe you meant that some packages should be declared as holding only special symbols. Then we could have MY-SPECIAL:FOO and YOUR-SPECIAL:FOO. But this is getting silly. I think a more interesting interpretation of KMP's idea is to have some symbols which are always special. How they are marked internally is an implementation detail. The problem from the language designer's point of view is then to decide how the programmer specifies which of the symbols he typed are special and which are not. Other places in the language, we have used syntactic markers -- why not here? (YOW! Are we Common SCHEME yet??) The only similar thing in the present CL is the ":" vs. "::" syntax for internal and external package symbols. So we probably want some sort of prefix operator. Perhaps "*" as a leading character, since that would break the smallest number of existing programs. Maybe *:FOO and MY-PACKAGE*:FOO. Hopefully someone an come up with a better syntax. It's cheap to detect, too, in interpreter or compiler: just check the package cell. This I like. Too bad it's too late. An ugly suggestion is to ADD this mechanism to the language without removing the declaration syntax yet, and let people phase over during the next year. Ugh, bletch.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:15:59 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 08:38:55 PDT Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05313; Fri, 17 May 85 11:31:04 edt Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238641; Fri 17-May-85 11:31:09-EDT Date: Fri, 17 May 85 11:30 EDT From: Kent M Pitman Subject: Poor excuse for packages To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA> Message-Id: <850517113027.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Friday, 17 May 1985, 10:32-EDT From: Guy Steele KMP hinted at a very interesting solution to the special-variables problem: let symbols in the package SPECIAL name special variables, and let all others name local variables. There doesn't seem to be much wrong with (LET ((SPECIAL:MY-GLOBAL-FLAG 43) (SPECIAL:PRINT-PRETTY T)) ...) or (DEFUN FOO (A B SPECIAL:C) ...) It's cheap to detect, too, in interpreter or compiler: just check the package cell. This I like. Too bad it's too late. An ugly suggestion is to ADD this mechanism to the language without removing the declaration syntax yet, and let people phase over during the next year. Ugh, bletch. I certainly did not intend to hint at such a thing. While it might be appropriate for a user program to put all its specials on one package and all its non-specials on another, or even appropriate for it to be possible for a whole package to somehow be declared to have implicitly special variables (perhaps unless explicitly declared LEXICAL), it is not reasonable to make every utility's specials share the same namespace! Your suggestion is tantamount to saying that package information should be ignored for variables and used only by EQ and function lookup since the package of a lexical variable almost never matters -- ie, how many people do you expect to write: (DEFUN F (FOO:X BAR:X) (+ FOO:X BAR:X)) ? On the other hand, you might well expect someone to write: (DEFUN AVERAGE-LINEL () (// (+ FOO:*LINEL* BAR:*LINEL*) 2)) and certainly (DEFUN AVERAGE-LINEL () (// (+ SPECIAL:*FOO-LINEL* SPECIAL:*BAR-LINEL*) 2)) would be a -real- step backward. Adopting a solution like this would mean that programs written without knowledge of each other might collide very badly when loaded into the same environment for some application that wanted to compose them. Clearly unacceptable.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:15:31 EST Date: 17 May 85 0841 PDT From: Jon White Subject: hash table types To: dcp%tenex.scrc@MIT-XX.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your message of 12-May-85 10:56 EDT Your list of "external things [I] see need changing" looks quite good to me. I might add the suggestion that we add a ROT primitive to CL which is machine independent. The following definition got added to Interlisp shortly after I went to Xerox: (ROT x n fieldsize) "performs a bitwise left-rotation of the integer x, by n places, within a field of fieldsize bits wide. Bits shifted out of the position selected by (expt 2 (sub1 fieldsize)) will flow into the 'units' position." Now, this definition has the advantage that on many machines, there will be one particular field size for which the implementation of this ROT will be very efficient (i.e., the one actually supported by a hardware ROT instruction). And since SXHASH is permitted to be implemetation dependent -- not "address dependent", but rather varying between one implementation and another -- then each implementation can use a ROT in it's sxhash with a field size that is efficient. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 12:15:14 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 08:38:26 PDT Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.arpa.ARPA) by THINK.ARPA id AA05295; Fri, 17 May 85 11:27:52 edt Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 238638; Fri 17-May-85 11:28:13-EDT Date: Fri, 17 May 85 11:24 EDT From: Bernard S. Greenberg Subject: Poor excuse for packages To: gls%AQUINAS@THINK.ARPA, common-lisp%sail@THINK.ARPA In-Reply-To: <850517103227.1.GLS@DESIDERIUS.ARPA> Message-Id: <850517112438.5.BSG@CONCORD.SCRC.Symbolics.COM> Date: Friday, 17 May 1985, 10:32-EDT From: Guy Steele KMP hinted at a very interesting solution to the special-variables problem: let symbols in the package SPECIAL name special variables, and let all others name local variables. There doesn't seem to be much wrong with (LET ((SPECIAL:MY-GLOBAL-FLAG 43) (SPECIAL:PRINT-PRETTY T)) ...) or (DEFUN FOO (A B SPECIAL:C) ...) It's cheap to detect, too, in interpreter or compiler: just check the package cell. This I like. Too bad it's too late. An ugly suggestion is to ADD this mechanism to the language without removing the declaration syntax yet, and let people phase over during the next year. Ugh, bletch. There is a fairly major problem with this. "Suppose two applications that have nothing to do with each other use the symbol SPECIAL:FOO". I.e., everything that packages had bought you is now lost.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 11:12:16 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 17 May 85 07:44:25 PDT Received: from Semillon.ms by ArpaGateway.ms ; 17 MAY 85 07:42:47 PDT Date: 17 May 85 07:42 PDT From: Masinter.pa@Xerox.ARPA Subject: Re: Macros -> declarations In-reply-to: KMP, Fahlman To: common-lisp@SU-AI.ARPA There are two alternatives for dealing with specials, both of which remove SPECIAL from DECLARE. One is lexographic, relying on the characters of the symbol. (Examples include inferring specialness from *var* or $var, or, the Fortan II approach: special variables all begin with the letters P, Q or S :-). Another is syntactic; still allow arbitrary variables to be special, but denote them in a way that removes the declaration from the (optional) DECLARE syntax. For example, one might allow, at the "top level", a special form (SPECIAL var1 var2 .... varn) and also, in any place where a variable is bound (LET, DO, lambda lists, etc.), allow (SPECIAL var) wherever var is allowed. (This leads to a bit of a burden if you want a special-optional-variable, because you have to say something like (lambda (a b &optional ((special c))) --) - - - - - - - - - - - - - - I will attempt to step gently around the sticky issue of how "Common Lisp" should balance implementation inertia against technical advances, and restrict myself to comments about the form of inertia. There are two kinds of inertia: implementations of "Common Lisp" and programs implemented in it. It would seem that there is some confusion among the implementations on whether macros are or are not allowed to expand into declarations. I would claim that, at least the syntactic example above represents no more turmoil to the typical compiler and interpreter than either adding or removing the requirement that macros can or cannot expand into DECLAREs. Inertial of existing programs is a little harder to rate; it would also seem reasonable for those with large quantities of MacLisp code such as Macsyma might want to run in an (improper) superset which allows "old-style" declares. It would help,  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 11:10:30 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 17 May 85 07:38:10 PDT Received: by THINK.ARPA with CHAOS id AA04932; Fri, 17 May 85 10:31:42 edt Date: Friday, 17 May 1985, 10:32-EDT From: Guy Steele Subject: Poor excuse for packages To: common-lisp%sail@THINK.ARPA Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850517103227.1.GLS@DESIDERIUS.ARPA> KMP hinted at a very interesting solution to the special-variables problem: let symbols in the package SPECIAL name special variables, and let all others name local variables. There doesn't seem to be much wrong with (LET ((SPECIAL:MY-GLOBAL-FLAG 43) (SPECIAL:PRINT-PRETTY T)) ...) or (DEFUN FOO (A B SPECIAL:C) ...) It's cheap to detect, too, in interpreter or compiler: just check the package cell. This I like. Too bad it's too late. An ugly suggestion is to ADD this mechanism to the language without removing the declaration syntax yet, and let people phase over during the next year. Ugh, bletch.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 10:43:28 EST Date: 17 May 85 0731 PDT From: Jon White Subject: 10-May-85 0146 hoey@nrl-aic Re: EQUALP hash tables (and more ...) To: Hoey@NRL-AIC.ARPA CC: common-lisp@SU-AI.ARPA Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 10 May 85 01:46:39 PDT Date: 10 May 1985 03:54:51 EDT (Fri) From: Dan Hoey Subject: Re: EQUALP hash tables (and more ...) To: Jon White Cc: Common-Lisp@SU-AI.ARPA Message-Id: <484559691/hoey@nrl-aic> Date: 09 May 85 2356 PDT From: Jon White ... a more generalized form of hashing ... two more "properties" of hashtables -- the "equivalenceing" function, and the "numericalizing" function.... For "equivalence" function, the user may supply #'eq, #'string=, or even something random like #'=-mod-5; Bravo! If CL should have hash tables, it should have these. The existing lack of functionality is embarrassing in an otherwise orthogonal, extensible language. ... the "numericalizing" function is simply how to reduce a general s-expression into a reasonable sized fixnum.... I would leave off ``reasonable sized''; certainly gethash is capable of hashing a fixnum value to its favorite range. I [believe] hashing on EQ means using the pointer address... but nothing in the CLM would prevent an implementation from using sxhash instead. Two problems with this. First, as you note, the key could get modified. I'm not sure you noticed, but this means that in order for GETHASH to fail, it would have to examine the whole table for modified structures. Second, I think SXHASH might not terminate on circular structures, though this caveat is not in the manual (and it, or its denial, should be). Dan SXHASH on circular structures? In-reply-to: your message of 10-May-85 3:54:51 EDT Yes, one might implement SXHASH in a manner that would loop on circular structures, but there is no requirement to do so. In fact, the CLM is so vague about sxhash that (defun sxhash (x) 1) is a perfectly legitimate definition! I think there has been a common misconception about sxhash that it must descend into every node of a structure; indeed, the first implementation in pdp10 MacLisp, over a decade ago, did just that (and I'm no doubt the guilty party). But more recently, I (and others) have experimented with definitions which are depth-limited. [Similarly, during the NIL development, both NIL and pdp10 MacLisp got definitions for a number of functions which were depth-limited, solely as a (slow) way to stop depth-limiting; this was done primarily as a low-overhead, fail-safe way to detect circularities. However, a fairly large limit has to be allowed, and thus this idea has a loop hole on "blam" lists given to EQUAL; but it effectively and somewhat quickly stop circularites on LENGTH, NTH, and a few others.] But the purpose of SXHASH is to provide a user interface to the "numericalizing" function needed for hash arrays; there is no need to make it more discriminatory that would be useful in providing a moderately random distribution of collision chains in hash tables. SXHASH is a many-to-one mapping, and there is no reason to assume that, statistically speaking, the depth cutoff is more damaging than is the accidental coinciding of a particular dataset -- one might think of this "accidental coinciding" as the inherent noise in the information of the problem. Of course, too small a limit on the depth would certainly be noticeable in terms of the *average* speed of hashing functions, but just exactly where that boundary is may be difficult to determine. [I wouldn't seriously suggest using a constant function, or even one that merely discriminated on the data type -- but can anyone seriously suggest that depth 1000 will be statistically different from depth 100? I would like to know.] For some months now, Lucid Common Lisp has been running with variations on the limited-depth sxhash, and not only does it meet the CLM requirements, but it seems to meet our day-to-day needs. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 09:30:13 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 May 85 06:21:04 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 164450; Fri 17-May-85 09:15:42-EDT Date: Fri, 17 May 85 09:20 EDT From: Kent M Pitman Subject: Macros -> declarations To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850517092025.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu, 16 May 1985 22:45 EDT From: "Scott E. Fahlman" We've kicked this idea around before in various forms, including the use of some sort of syntactic marker on special bindings -- something like turning FOO into $FOO if the variable is special, or treating the *FOO* convention as being a declaration of specialness. Other lexical Lisps have done this sort of thing with no obvious ill effects (and arguably some good effects), but it seems to have been too radical a change to have been seriously considered by most of the Common Lisp people when the language was being designed. It would be even tougher now that the langauge is starting to be used and assorted companies are rushing to get implementations out. Personally, I like the idea. I've felt for some time that we ought to separate SPECIAL declarations from all the others, even if that means that Common Lisp ends up looking a little different from Maclisp. Referring specifically to your comments about a standard (enforced) naming convention for specials... * For the record, some programs like Macsyma use the printname of symbols to record other kinds of information and would have to be radically restructured to adapt to such a scheme. eg, in Macsyma any symbol with $ is accessable to the Macsyma user; ie, the macsyma expression FOO+BAR parses to something involving the Lisp symbols $FOO and $BAR. Since there need to be some special variables accessible to users and others which are not, this kind of change would cause all kinds of hassle. Admittedly, such a convention is just poor excuses for a package system, but its semantics is much different than the CL package system and it's not a trivial syntactic change to convert things. I suspect this isn't an isolated example. The Programmer's Apprentice has a ton of code (by Dick Waters) which prefixes a digit to every symbol so you can tell what module it belongs to. eg, its "database" code uses names like 8FOO and 8BAR while the display module uses 7FOO and 7BAR. I suppose a -very- careful Query Replace of "DISPLAY:" for "7" would almost "fix" things, but it'd be fairly tricky. * In general, I would want to avoid attaching language semantics to the print name of a symbol. It's bad enough that all symbols with & as their first char or that are interned on the keyword package are reserved. For example, if specials had different print names than other symbols, you'd need to add a :SPECIAL-P keyword to GENTEMP which said whether to do hair to make sure the symbol had a print name suitable to be a special variable. Various other applications that concatentated symbols to make new symbols in macros would have to use care not to produce symbols like OLD-*FOO* (preferring, I suppose *OLD-*FOO*) or OLD-$FOO (preferring $OLD-$FOO). There used to be something nice about the sanctity of a symbol ... I feel as if we're starting to walk all over that. I hope we will move -away- from having reserved symbols. eg, eventually (might take a while before we can swing it) flushing &keywords in the bvl for :keywords, and making :keywords not be SYMBOLP. ... But we should only make this move so late in the game if just about everyone else feels likewise. Wouldn't want you to think they did.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 08:49:39 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 May 85 05:44:03 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 164444; Fri 17-May-85 08:38:41-EDT Date: Fri, 17 May 85 08:43 EDT From: Kent M Pitman Subject: Property lists To: Rem@IMSSS, COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 17 May 85 04:28-EDT from Rem@IMSSS Message-ID: <850517084324.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 17 May 1985 0128-PDT From: Rem@IMSSS It seems to me that the choice of whether property lists should be kept as ASSOC lists or as alternating lists should be an implementation issue. Functions for adding, deleting, finding, modifying them should exist so that the user hardly ever needs to actually see the structure except when debugging. Yet the CL manual insists that in CL they must be implemented as alternating lists, not as ASSOC lists. Why was this decision made?? Should it be rescinded? No. For one thing, the term "property list format" provides useful terminology for contrasting "association list format". For another thing, GETF has a variety of uses in situations where lists were not actually created by (SETF (GETF ...)), etc. eg, keyword argument lists can be easily manipulated using GETF. You couldn't do that if the format wasn't defined. Instead, you'd write code identical to what's there just so that you could use it "safely". Since there are advantages to saying what the format is and no particular disadvantages (data abstractions notwithstanding; you could always write a TABLE abstraction), it has been the concensus that the format might as well be documented. -kmp  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 May 85 04:35:13 EST Received: from IMSSS by SU-AI with PUP; 17-May-85 01:29 PDT Date: 17 May 1985 0128-PDT From: Rem@IMSSS Subject: Property lists To: COMMON-LISP@SU-AI It seems to me that the choice of whether property lists should be kept as ASSOC lists or as alternating lists should be an implementation issue. Functions for adding, deleting, finding, modifying them should exist so that the user hardly ever needs to actually see the structure except when debugging. Yet the CL manual insists that in CL they must be implemented as alternating lists, not as ASSOC lists. Why was this decision made?? Should it be rescinded? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 16 May 85 23:14:05 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 May 85 20:07:23 PDT Received: from hplabs by csnet-relay.csnet id ae15232; 16 May 85 18:38 EDT Received: by HP-VENUS id AA13027; Thu, 16 May 85 05:31:14 pdt Message-Id: <8505161231.AA13027@HP-VENUS> Date: Thu 16 May 85 05:31:09-PDT From: Martin Subject: Collections of CL tests and validations To: common-lisp@su-ai.ARPA Cc: GRISS@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. Has anyone started to collect or distribute a CL validation suite or even scattered tests of CL. Are any of these publically available? Thanks Martin Griss -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 16 May 85 22:53:21 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 May 85 19:45:56 PDT Received: ID ; Thu 16 May 85 22:45:05-EDT Date: Thu, 16 May 1985 22:45 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Masinter.pa@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 16 May 1985 17:53-EDT from Masinter.pa at Xerox.ARPA We've kicked this idea around before in various forms, including the use of some sort of syntactic marker on special bindings -- something like turning FOO into $FOO if the variable is special, or treating the *FOO* convention as being a declaration of specialness. Other lexical Lisps have done this sort of thing with no obvious ill effects (and arguably some good effects), but it seems to have been too radical a change to have been seriously considered by most of the Common Lisp people when the language was being designed. It would be even tougher now that the langauge is starting to be used and assorted companies are rushing to get implementations out. Personally, I like the idea. I've felt for some time that we ought to separate SPECIAL declarations from all the others, even if that means that Common Lisp ends up looking a little different from Maclisp. But we should only make this move so late in the game if just about everyone else feels likewise. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 16 May 85 21:53:17 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 May 85 18:43:29 PDT Received: from Salvador.ms by ArpaGateway.ms ; 16 MAY 85 14:59:19 PDT Date: 16 May 85 14:53 PDT From: Masinter.pa@Xerox.ARPA Subject: Re: Macros -> declarations In-reply-to: various To: common-lisp@SU-AI.ARPA The only reason for this issue is because the interpreter has to look ahead for SPECIAL declarations. SPECIAL declarations are the only ones that have any semantic import. Furthermore, SPECIAL declarations are the only ones that are textually retroactive, in that they apply to things that appeared BEFORE the declaration rather than after. Rather than hacking around the deficiencies of DECLARE, why not change it? Put SPECIAL declarations where they belong, next to the variable. Leave all the other declarations where they are. Most of these issues then become moot, and we can even consider freeing up some of the restrictions on declarations; it would seem reasonable to allow declarations anywhere in an implicit PROGN to refer to the stuff that follows.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 May 85 19:50:59 EST Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 15 May 85 16:42:36 PDT Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a011256; 16 May 85 0:39 BST From: DALTON FHL (on ERCC DEC-10) Date: Wednesday, 15-May-85 23:06:16-GMT Message-ID: <132170-754-714@EDXA> To: Common-Lisp , J.Dalton%edxa@ucl-cs.arpa Subject: lexical closures -------- Closures ... Date: 1985 May 14 15:54:28 PST (=GMT-8hr) From: Robert Elton Maas I.e. if function A binds special X to some initial value, makes a closure of B with free variable X referring to A's fluid-binding of X, then lambda-binds X another level deep to a new value, then calls B-closure, obviously references to X within B-closure will get the first binding of X, It turns out that the B-closure will refer to the second (deeper) value of X, but not because of anything involving closures. Lexical closures in Common Lisp do not include special variables [see pp 39-40]. If X is a special variable, the free X in B will always refer to the most recent binding of X; lexical closures don't change this. One reason for the confusion may be that other dialects of Lisp, such as ZetaLisp and Franz, do provide closures over special variables that work more or less in the way you describe. Date: 15 May 1985 0213-PDT From: Rem@imsss Subject: Another question about lexical closures There's a little ambiguity about when two bindings are "the same" and when they are "different" bindings. If you bind exactly the same lexical variable (in the same function or other executable form) to exactly the same value (the values are EQ), at two different times, are the two bindings you get considered to be the same or different? If you call the same function twice, you get two different bindings (p 36: "a new binding is established on every invocation"). The text on pages 87-89 seems clear on what this means for closures, particularly the example in the middle of page 88 (think of each LET as a function call). Now if TWO-FUNS were called twice, there would be two different bindings of X, and closures involving different bindings must be different if the bound values could be changed by SETQ. Since the second of them includes a SETQ, the closures returned in the list must be different each time. Now if it weren't for the SETQ, each call to TWO-FUNS would still normally return different closures because X might have a different value each time. If two calls happened to use the same EQ value twice, I don't see anything to guarantee that the closures would be different (after all, they would be "behaviorially identical with respect to invocation"), but would any implementation notice that they could be the same? So I think the book is fairly clear, although you might have to reread it a few times if you aren't already familiar with the stuff involved. --------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 May 85 17:01:46 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 15 May 85 13:53:56 PDT Received: from ti-csl by csnet-relay.csnet id am03561; 15 May 85 2:01 EDT Date: 14 May 1985 1011-CDT From: Dan Stenger Subject: adding PARSE-BODY primitive To: common-lisp@su-ai.ARPA In-Reply-To: Your message of 6-May-85 1043-CDT Received: from csl60 by ti-csl; Tue, 14 May 85 10:09 CST I am all for adding the PARSE-BODY function. Every implementation has to have this code in it anyway and since it is generally useful why not standardize it. Dan Stenger -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 May 85 16:44:12 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 May 85 13:32:17 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 237418; Wed 15-May-85 16:26:43-EDT Date: Wed, 15 May 85 16:30 EDT From: Robert W. Kerns Subject: Another question about lexical closures To: Rem%IMSSS@SU-SCORE.ARPA cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 15 May 85 05:13-EDT from Rem@IMSSS Supersedes: <850515163014.9.RWK@CROW.SCRC.Symbolics.COM>, <850515163043.0.RWK@CROW.SCRC.Symbolics.COM> Message-ID: <850515163051.1.RWK@CROW.SCRC.Symbolics.COM> Date: 15 May 1985 0213-PDT From: Rem@IMSSS There's a little ambiguity about when two bindings are "the same" and when they are "different" bindings. If you bind exactly the same lexical variable (in the same function or other executable form) to exactly the same value (the values are EQ), at two different times, are the two bindings you get considered to be the same or different? The way I think of this is "Two calls to LET produce two different bindings". So if I read your question right, the answer is "different". I.e. if you make a lexical closure in function FOO with X bound to NIL and then make another lexical closure in function FOO with X bound to NIL, will the X-variables in those two closures be the same variable (sharing side-effects) or not? I assume here you mean two calls to FOO, not something like (LET ((X 5)) (VALUES #'(LAMBDA () X) #'(LAMBDA (Y) (SETQ X Y)))) where the answer is "save variable (sharing side effects)" My guess is they will be different, that is each time you go into a lambda-binding you get a "different" binding even if the lexical variable and its value are the same both times. Am I correct? Yes. (Note the example at the bottom of page 87 doesn't answer this question since TWO-FUNS is called only once. Indeed, I think this section could use a bit more exposition and further examples. I think the manual can't help being a bit of a language tutorial here, and should abandon the tersness of a reference manual, even if it ends up repeating the same concept in different ways. If it got called a second time, with exactly the same args, and the result SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their lexical-closure-variable, i.e. "the binding of the variable X created on entry to the function TWO-FUNS when it was called with argument 6" as described at the bottom of the page? That phrasing indicates there WOULD be sharing, but due to what it says on page 37 top "it depends on the invocaton during which the reference is made" I think it WOULD NOT be sharing, i.e. wording on page 87 should really say "... on that particular entry to the function TWO-FUNS ..." even though in that example it is moot since TWO-FUNS was called only once in the example.) ------- That's right. There would be sharing between (CAR FUNS) and (CADR FUNS), and between (CAR FUNS2) and (CADR FUNS2), but not between the elements of FUNS and FUNS2.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 May 85 16:43:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 May 85 13:31:39 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 237413; Wed 15-May-85 16:26:05-EDT Date: Wed, 15 May 85 16:30 EDT From: Robert W. Kerns Subject: Another question about lexical closures To: Rem@IMSSS cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 15 May 85 05:13-EDT from Rem@IMSSS Message-ID: <850515163014.9.RWK@CROW.SCRC.Symbolics.COM> Date: 15 May 1985 0213-PDT From: Rem@IMSSS There's a little ambiguity about when two bindings are "the same" and when they are "different" bindings. If you bind exactly the same lexical variable (in the same function or other executable form) to exactly the same value (the values are EQ), at two different times, are the two bindings you get considered to be the same or different? The way I think of this is "Two calls to LET produce two different bindings". So if I read your question right, the answer is "different". I.e. if you make a lexical closure in function FOO with X bound to NIL and then make another lexical closure in function FOO with X bound to NIL, will the X-variables in those two closures be the same variable (sharing side-effects) or not? I assume here you mean two calls to FOO, not something like (LET ((X 5)) (VALUES #'(LAMBDA () X) #'(LAMBDA (Y) (SETQ X Y)))) where the answer is "save variable (sharing side effects)" My guess is they will be different, that is each time you go into a lambda-binding you get a "different" binding even if the lexical variable and its value are the same both times. Am I correct? Yes. (Note the example at the bottom of page 87 doesn't answer this question since TWO-FUNS is called only once. Indeed, I think this section could use a bit more exposition and further examples. I think the manual can't help being a bit of a language tutorial here, and should abandon the tersness of a reference manual, even if it ends up repeating the same concept in different ways. If it got called a second time, with exactly the same args, and the result SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their lexical-closure-variable, i.e. "the binding of the variable X created on entry to the function TWO-FUNS when it was called with argument 6" as described at the bottom of the page? That phrasing indicates there WOULD be sharing, but due to what it says on page 37 top "it depends on the invocaton during which the reference is made" I think it WOULD NOT be sharing, i.e. wording on page 87 should really say "... on that particular entry to the function TWO-FUNS ..." even though in that example it is moot since TWO-FUNS was called only once in the example.) ------- That's right. There would be sharing between (CAR FUNS) and (CADR FUNS), and between (CAR FUNS2) and (CADR FUNS2), but not between the elements of FUNS and FUNS2.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 May 85 15:31:06 EST Received: from IMSSS by SU-AI with PUP; 15-May-85 12:20 PDT Date: 15 May 1985 0213-PDT From: Rem@IMSSS Subject: Another question about lexical closures To: COMMON-LISP@SU-AI There's a little ambiguity about when two bindings are "the same" and when they are "different" bindings. If you bind exactly the same lexical variable (in the same function or other executable form) to exactly the same value (the values are EQ), at two different times, are the two bindings you get considered to be the same or different? I.e. if you make a lexical closure in function FOO with X bound to NIL and then make another lexical closure in function FOO with X bound to NIL, will the X-variables in those two closures be the same variable (sharing side-effects) or not? My guess is they will be different, that is each time you go into a lambda-binding you get a "different" binding even if the lexical variable and its value are the same both times. Am I correct? (Note the example at the bottom of page 87 doesn't answer this question since TWO-FUNS is called only once. If it got called a second time, with exactly the same args, and the result SETQ'd to global FUNS2, would (CAR FUNS) and (CAR FUNS2) share their lexical-closure-variable, i.e. "the binding of the variable X created on entry to the function TWO-FUNS when it was called with argument 6" as described at the bottom of the page? That phrasing indicates there WOULD be sharing, but due to what it says on page 37 top "it depends on the invocaton during which the reference is made" I think it WOULD NOT be sharing, i.e. wording on page 87 should really say "... on that particular entry to the function TWO-FUNS ..." even though in that example it is moot since TWO-FUNS was called only once in the example.) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 May 85 00:12:31 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 May 85 21:02:53 PDT Received: ID ; Wed 15 May 85 00:03:04-EDT Date: Wed, 15 May 1985 00:02 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Common-Lisp@SU-AI.ARPA Subject: Apply-But-Last From: vanroggen@DEC-HUDSON Subject: SETF APPLY ... It seems to me that we could have both the newvalue passed as the last arg of the setting function and the ability to do SETF of APPLY if we would admit to a function, that I'll call APPLY-BUT-LAST, that's just like APPLY, except that it's the next-to-last argument that must be a list, and the last argument is just passed as the last argument to the applied function. That name is misleading (too much in common with some list manipluation functions), and the effect can be obtained portably (and reasonably efficiently (even with dumb compilers)) with Multiple-Value-Call: (multiple-value-call #'function arg1 arg2 ... (values-list rest-arg) last-arg) --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 14 May 85 22:09:30 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 May 85 18:58:32 PDT Received: ID ; Tue 14 May 85 21:58:40-EDT Date: Tue, 14 May 1985 21:58 EDT Message-ID: From: Rob MacLachlan To: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) Cc: Common-LISP@SU-AI.ARPA Subject: Semantic question about closures In-reply-to: Msg of 1985 May 14 15:54:28 PST (=GMT-8hr) from Robert Elton Maas Date: 1985 May 14 15:54:28 PST (=GMT-8hr) From: Robert Elton Maas Re: Semantic question about closures When a closure is made, with some variable encapsulated in the closure, is that variable accessible only with the exact function that was closed (...), or is that variable accessible also from any function called by the closure... The value is not visible. This is exactly what lexical scoping means. A variable DOES NOT EXIST outside of code textually enclosed by the binding form. You shouldn't worry about closures when trying to understand lexical variables--- closures are just an implementation detail. I think that you are confusing yourself by talking about "free variables"; this is not a very useful concept in Common Lisp. Instead you should think in terms of special variables and lexical variables. Special variables and lexical variables have very different semantics, and the language has possibly done a disservice by making them appear to be similar. The operation of "binding" a lexical variable is quite unlike that of binding a special. Binding a lexical variable actually creates a new "variable" which is then associated with that name within the lexical scope. By a "variable", I mean a nameless memory location which can be used for storing a value. The fact that some variables can be stack allocated is unimportant for understanding what a piece of code does. The reason that the called function in your example cannot see the original variable is that its variable is totally different from the one in the calling function, although it does happen to have the same name. The fact that it has the same name is totally irrelevant, since the association of name with variable does not exist outside of the lexical context in which the variable was created. It is important to draw the distinction between variables and names. This may be difficult for people whose primary experience is with old-fashioned shallow/special-binding lisps, since in these implementations there is a one-to-one correspondence between variables (value cells) and names (symbols). (thus somehow a copy of the gut function must be made such that it internally references that closure-cell directly rather than how the gut function in vacuuo would reference that named variable) Your parenthetical inference is incorrect, however. There is no "gut function" to copy. The compiler must determine at compile time whether it is going to close over a variable. If it decides to close over variables, it compiles code to access closure variables. Lexical variable references do not exist "in vacuo". A lexical variable is created when it is bound. I.e. if function A binds special X to some initial value, makes a closure of B with free variable X referring to A's fluid-binding of X, ... Special variables are not closed over. The meaning of a special variable reference is "give me the most recent binding in my current dynamic context." This is incompatible with the notion of closing over variables. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 14 May 85 20:04:22 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-14 15:55:04 PST (=GMT-8hr) Date: 1985 May 14 15:54:28 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132167250130.G0353 From: Robert Elton Maas To: Common-LISP@SU-AI Subject: Semantic question about closures Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) I have a question about closures in CL. When a closure is made, with some variable encapsulated in the closure, is that variable accessible only with the exact function that was closed (thus somehow a copy of the gut function must be made such that it internally references that closure-cell directly rather than how the gut function in vacuuo would reference that named variable), or is that variable accessible also from any function called by the closure (thus we can implement a closure by fluid-binding the closure-variable as we pass from the closure into the gut function and copying the final value of the fluid-binding back into the closure-cell when returning)? I.e. if function A binds special X to some initial value, makes a closure of B with free variable X referring to A's fluid-binding of X, then lambda-binds X another level deep to a new value, then calls B-closure, obviously references to X within B-closure will get the first binding of X, but if B calls C which also refers to free variable X does C get the closure-of-first-binding-of-X inherited from closure-B or does C get the second-fluid-binding-of-X inherited directly from A skipping over B?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 14 May 85 13:10:18 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 May 85 10:02:23 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 236361; Tue 14-May-85 12:57:41-EDT Date: Tue, 14 May 85 13:02 EDT From: Robert W. Kerns Subject: &optional with &key To: Robert R. Kessler cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 14 May 85 12:05-EDT from Robert R. Kessler Message-ID: <850514130227.0.RWK@CROW.SCRC.Symbolics.COM> Date: Tue 14 May 85 10:05:01-MDT From: Robert R. Kessler If you provide an &optional followed by &key's, does that mean that the &optional becomes required? The examples don't seem to address the case: ((lambda (a &optional (b 3) &key c (d a)) (list a b c d x)) 1 :c 7) Is this an error (i.e. a is bound to 1, b is bound to :c and 7 causes the error), or is a bound to 1, b bound to 3, c to 7 and d to 1. ------- It is an error (i.e. A is bound to 1, B is bound to :C and 7 causes the error). However, that is not the same as B being required! All it means is that the keyword arguments start AFTER B. This implies that you have to supply B in order to supply C or D, but that's true in (a &optional (b 3) c (d a)), too.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 14 May 85 12:40:43 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 14 May 85 09:33:08 PDT Received: by THINK.ARPA with CHAOS id AA23862; Tue, 14 May 85 12:24:51 edt Date: Tue, 14 May 85 12:25 EDT From: Guy Steele Subject: &optional with &key To: kessler%utah-20@GODOT.ARPA Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.ARPA In-Reply-To: Your message of 14 May 85 12:05-EDT Message-Id: <850514122500.1.GLS@DESIDERIUS.ARPA> It isn't quite accurate to say that the presence of &key makes an &optional parameter be required. It is true, however, that, if a function has both &optional and &key parameters, it is impossible to specify explicit arguments for any keyword parameters unless arguments are first explicitly given for all optional parameters. The book doesn't say so in one sentence, but you can deduce this from careful reading of page 61. I agree that an explicit statement of this fact would be worthwhile, and that an example would be useful. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 14 May 85 12:13:44 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 May 85 09:05:42 PDT Date: Tue 14 May 85 10:05:01-MDT From: Robert R. Kessler Subject: &optional with &key To: common-lisp@SU-AI.ARPA If you provide an &optional followed by &key's, does that mean that the &optional becomes required? The examples don't seem to address the case: ((lambda (a &optional (b 3) &key c (d a)) (list a b c d x)) 1 :c 7) Is this an error (i.e. a is bound to 1, b is bound to :c and 7 causes the error), or is a bound to 1, b bound to 3, c to 7 and d to 1. Bob. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 13 May 85 14:56:31 EST Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 13 May 85 11:44:50 PDT Received: by MIT-XX via Chaosnet; 13 May 85 14:41-EDT Date: Sunday, 12 May 1985 10:56-EDT From: David C. Plummer To: George J. Carrette Subject: hash table types cc: DCP at SCRC-QUABBIN, TIM at MIT-MC, COMMON-LISP at SU-AI In-rely-to: <[MIT-MC].499100.850512.GJC> Date: Sun, 12 May 85 08:51:09 EST From: George J. Carrette We figured that fixing the root of the problem, the lack of canonicalization in the hardware database would possibly cost enough time to break a production development window and put off the introduction of a new hardware item for a few months, with possible losses in sales of a million dollars or more for the year. Given this sort of lossage mode one cant stress enough the importance of having *some* way of getting compatibility between RELEASE N and RELEASE N+1. Remember that at some time in "zetalisp" EQUAL on type STRING meant STRING-EQUAL, which was for better or worse case insensitive. LMI release 2 and presumably also Symbolics release 6 does away with this. If there is nothing available which behaves in exactly the same way as the *old* EQUAL-HASH-TABLE then people can be screwed badly. Remember also that many ugly things that were left in Common-Lisp from maclisp days (such as the empty list being a SYMBOL, making the set of all lists and all symbols have a non-null intersection) were justified soley on the basis that there was no *automatic* way for people to detect if they were depending on such lossage and convert their programs. To quote Dave Moon: "Our customers just wont stand for it." For that exact reason, "Our customers just won't stand for it", Release 6 is compatible with Release 5 w.r.t. EQUAL-HASH-TABLEs, i.e., case is ignoreed. Release 6 provides hints on how to write code that will work in both Release 6 and Release 7, requiring recompilation and possibly minimal, if any conversion. In Release 7 there will most likely be a CASE-INSENSITIVE-HASH-TABLE that uses CASE-INSENSITIVE-EQUAL as the predicate and CASE-INSENSITIVE-EQUAL-HASH (unless EQUAL-HASH will continue to ignore case). More generally, and on the generic issue: Symbolics has had generic hash tables for quite a while. I don't know if Lisp Machine Lisp is general has. The definer of the hash table is required to write two methods, the equality predicate and the hash function. They are quite useful. All implementations must do a dispatch, since the entrypoints are the same for all types of hash tables. In a flavor-based implementation, the dispatch happens at the message send level. In other implementations, my guess is that FUNCALL is used where the function comes from some defstruct slot. In any case, generalizing does not appear to be a hard thing to implement. The external things I see needing changing are * An additional argument to make-hash-table. My vote for a name is :hash-function. * If the hash function is not provided, it defaults from the predicate. * It is an error not to supply a hash function if the predicate is not one of those builtin (currently, EQ, EQL and EQUAL). [Implementatyions may supply more builtins and opt not to signal the error.] * Requirements of the hash function: It must return an integer, possibly restricted to fixnum, possibly required to be positive. [The LispM builtin hash functions attempt to return positive fixnums that use as many bits as possible. This is so that there is more uniform distribution after it is MODed with the hash table modulus.] * Hints on how to write implementation independent, efficient hash functions. This is the hardest part. Maybe there are enough constants defined in the language to make this possible (e.g., bits-per-fixnum, etc). Hmmm... Many LispM hash functions use the functions ROT (better called ROTATE-FIXNUM) and LSH (better called LOGICAL-SHIFT-FIXNUM). They often use LOGXOR, but this is part of CLtL. I have a memory of being told that ROT and LSH were consciously not part of the CL language because they weren't mathematical. With names like ROTATE-FIXNUM and LOGICAL-SHIFT-FIXNUM maybe they should be put back? [Also see Turing's biography about the hardware designers diking out his boolean instructions for similar reasons.] * The use of MAKNUM, %POINTER or whatever it is for a particular implementation is to be forbidden for user suplied hash functions. This is because the GC can move objects and change their addresses, and there is no way in CL to communicate this between the hash table and the GC. Individual implementations may wish to implement such a communication and allow %POINTER and use it for builtin hash tables to improve efficiency. Conclusion: generic hash tables are useful and probably simple to implement. User supplied hash functions are required but difficult. Additionaly, I think there should be a CASE-INSENSITIVE-EQUAL function and a corresponding (builtin) hash table type. I have an uneasy feeling about EQUALP hash tables. I think the uneasiness comes in the traversing of arbitrary array structure that EQUALP implies and the possible inefficiency. The example needs I have so far seen for EQUALP are dealt with by CASE-INSENSITIVE-EQUAL.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 13 May 85 14:55:28 EST Received: from MIT-XX.ARPA by SU-AI.ARPA with TCP; 13 May 85 11:44:01 PDT Received: by MIT-XX via Chaosnet; 13 May 85 14:38-EDT Date: Sunday, 12 May 1985 10:56-EDT From: David C. Plummer To: George J. Carrette Subject: hash table types cc: DCP at SCRC-QUABBIN, TIM at MIT-MC, COMMON-LISP at SU-AI In-rely-to: <[MIT-MC].499100.850512.GJC> Date: Sun, 12 May 85 08:51:09 EST From: George J. Carrette We figured that fixing the root of the problem, the lack of canonicalization in the hardware database would possibly cost enough time to break a production development window and put off the introduction of a new hardware item for a few months, with possible losses in sales of a million dollars or more for the year. Given this sort of lossage mode one cant stress enough the importance of having *some* way of getting compatibility between RELEASE N and RELEASE N+1. Remember that at some time in "zetalisp" EQUAL on type STRING meant STRING-EQUAL, which was for better or worse case insensitive. LMI release 2 and presumably also Symbolics release 6 does away with this. If there is nothing available which behaves in exactly the same way as the *old* EQUAL-HASH-TABLE then people can be screwed badly. Remember also that many ugly things that were left in Common-Lisp from maclisp days (such as the empty list being a SYMBOL, making the set of all lists and all symbols have a non-null intersection) were justified soley on the basis that there was no *automatic* way for people to detect if they were depending on such lossage and convert their programs. To quote Dave Moon: "Our customers just wont stand for it." For that exact reason, "Our customers just won't stand for it", Release 6 is compatible with Release 5 w.r.t. EQUAL-HASH-TABLEs, i.e., case is ignoreed. Release 6 provides hints on how to write code that will work in both Release 6 and Release 7, requiring recompilation and possibly minimal, if any conversion. In Release 7 there will most likely be a CASE-INSENSITIVE-HASH-TABLE that uses CASE-INSENSITIVE-EQUAL as the predicate and CASE-INSENSITIVE-EQUAL-HASH (unless EQUAL-HASH will continue to ignore case). More generally, and on the generic issue: Symbolics has had generic hash tables for quite a while. I don't know if Lisp Machine Lisp is general has. The definer of the hash table is required to write two methods, the equality predicate and the hash function. They are quite useful. All implementations must do a dispatch, since the entrypoints are the same for all types of hash tables. In a flavor-based implementation, the dispatch happens at the message send level. In other implementations, my guess is that FUNCALL is used where the function comes from some defstruct slot. In any case, generalizing does not appear to be a hard thing to implement. The external things I see needing changing are * An additional argument to make-hash-table. My vote for a name is :hash-function. * If the hash function is not provided, it defaults from the predicate. * It is an error not to supply a hash function if the predicate is not one of those builtin (currently, EQ, EQL and EQUAL). [Implementatyions may supply more builtins and opt not to signal the error.] * Requirements of the hash function: It must return an integer, possibly restricted to fixnum, possibly required to be positive. [The LispM builtin hash functions attempt to return positive fixnums that use as many bits as possible. This is so that there is more uniform distribution after it is MODed with the hash table modulus.] * Hints on how to write implementation independent, efficient hash functions. This is the hardest part. Maybe there are enough constants defined in the language to make this possible (e.g., bits-per-fixnum, etc). Hmmm... Many LispM hash functions use the functions ROT (better called ROTATE-FIXNUM) and LSH (better called LOGICAL-SHIFT-FIXNUM). They often use LOGXOR, but this is part of CLtL. I have a memory of being told that ROT and LSH were consciously not part of the CL language because they weren't mathematical. With names like ROTATE-FIXNUM and LOGICAL-SHIFT-FIXNUM maybe they should be put back? [Also see Turing's biography about the hardware designers diking out his boolean instructions for similar reasons.] * The use of MAKNUM, %POINTER or  Received: from SU-AI.ARPA by MIT-MC.ARPA; 13 May 85 14:08:20 EST Date: 13 May 85 0905 PDT From: Jon White Subject: YARIM and the adbmal example To: bsg@SCRC-STONY-BROOK.ARPA CC: common-lisp@SU-AI.ARPA Re: your message of 10-May-85 14:39 EDT Not only is your adbmal example "right", but the following would have to work too (defmacro mumble (x) `(lambda (,x) (list ,x))) (defun foo () ((mumble z) (mumble z))) I just tried this out in pdp10 maclisp, and it still sort of works [I remember putting this hac in about 1979 or 1980, and it wasn`t all that well received even back then]. Incidentally, I did take your suggestion for macro-expansion contexts seriously. Not that I approve of going al the way for it, but you do bring into focus the fact that several different kinds of processing are going on during interpretations -- not just EVAL alone, but there is FUNVAL (if you will) to fetch the function part, there is DODECLS to add to a declarations database [Maclisp had a functional counterpart to DECLARE, which is why macroexpansion seemed like such a natural idea there], and there is lambda-list parsing. I'd prefer to see a uniform meta-expansion syntax -- such as defmacro -- but we may have to consider context as per your suggestion. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 13 May 85 13:55:13 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 May 85 09:21:11 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 235644; Mon 13-May-85 12:16:32-EDT Date: Mon, 13 May 85 12:22 EDT From: Bernard S. Greenberg Subject: YARIM and the adbmal example To: JLW@SU-AI.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 13 May 85 12:05-EDT from Jon White Message-ID: <850513122226.5.BSG@CONCORD.SCRC.Symbolics.COM> Date: 13 May 85 0905 PDT From: Jon White Re: your message of 10-May-85 14:39 EDT Not only is your adbmal example "right", but the following would have to work too (defmacro mumble (x) `(lambda (,x) (list ,x))) (defun foo () ((mumble z) (mumble z))) I just tried this out in pdp10 maclisp, and it still sort of works [I remember putting this hac in about 1979 or 1980, and it wasn`t all that well received even back then]. Incidentally, I did take your suggestion for macro-expansion contexts seriously. Not that I approve of going al the way for it, but you do bring into focus the fact that several different kinds of processing are going on during interpretations -- not just EVAL alone, but there is FUNVAL (if you will) to fetch the function part, there is DODECLS to add to a declarations database [Maclisp had a functional counterpart to DECLARE, which is why macroexpansion seemed like such a natural idea there], and there is lambda-list parsing. I'd prefer to see a uniform meta-expansion syntax -- such as defmacro -- but we may have to consider context as per your suggestion. You got it. That is exactly what I just said to Scott. Each of these contexts should be identified separately, via a uniform mechanism. That would fix ((mumble z) (mumble z)), i.e., make it -not- work.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 13 May 85 13:45:43 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 May 85 09:12:30 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 235635; Mon 13-May-85 12:07:49-EDT Date: Mon, 13 May 85 12:13 EDT From: Bernard S. Greenberg Subject: :-( To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850513121344.4.BSG@CONCORD.SCRC.Symbolics.COM> Date: Sat, 11 May 1985 09:35 EDT From: "Scott E. Fahlman" Upon reflection, I shouldn't have been so flippant in dismissing BSG's suggestion about macro-expansion environments, and I apologize to him. Thankyou. I thought your assessment was in fact unduly harsh. The criteria for judging this kind of suggestion should include, "Does it solve the problem?" "Does it create new problems?" "Does it bother things other than the thing it was designed to address?" "Given that it addresses some hairy need, will you have to deal with it unless you have that hairy need?" "Is it consistent in design and philosophy with the rest of the language?" "Is it straightforward to explain?" "Is efficient implementation obvious?" I think that the general idea of my suggestion meets these (admittedly self-supplied) criteria. I assume that his suggestion was serious, and poking fun at suggestions that we disagree with is obviously not the best way to promote the free flow of ideas. It has been a long week, and I was feeling irritable. Thankyou. I hope you feel better. I think that this suggestion is a step in the wrong direction. We want to make the whole issue of macros expanding in funny places less confusing, not more so, and a multiple name space mechansism so that macros in various places can have the same name doesn't look to me like a good idea. (what follows is sort of rambling...) Any better than the "declaration 'functions'" (like STRING in the preceding conversation) having the same name as a real function? Why isn't the set of those things extensible? Remember in MacLisp they actually WERE functions? I suppose macros there worked! I wonder if anyone actually ever exploited that! But now we are above that, and we have asserted that the declaration namespace is in fact divorced from the function namespace. There already -is- this multiple namespace. As there should be. Why isn't a macro paradigm within that namespace reasonable? OK, don't use defmacro, say (putprop 'my-decl #'my-decl-expander :declaration-macro) for all I care, if my syntax is too bizarre. It seems as though it's that very capability that you don't like. I would like to dredge up an elegant feature of LAP (remember those?) on Multics, which, if it encountered a symbol marked as a Lisp Macro name-symbol, as the CAR of an instruction specification, it would apply the macro-function to the instruction specification, and assemble the returned list of instructions in place. This is a typical, potent, and elegant use of "the Lisp Macro concept" to extend operator sets embedded in the Lisp Language. -Surely-, if I had thought along these lines back then, we would have some different kind or option of DEFMACRO (which didn't even exist per se) for defining LAP macros in this way. DEFMACRO provides three things for you: 1) A way to define a -LISP FUNCTION- to be called by the evaluator and compiler at certain highly specific times and contexts. 2) A way to define a Lisp function of one argument which has built-in syntactic shorthands for destructuring and structure-verifying that argument. 3) A -conceptual- ability, a paradigm, for extension of the language via transformation of code fragments. 2 & 3, esp. 3, are obviously, by the cited examples, useful in a wide, extensible variety of contexts other than "evaluation/compilation of Lisp forms". Clearly, I can put in replacements for (1) (e.g., DEFLAPMACRO) all I want, in any program I want (does this invoke your objection of "macros expanding in funny places?"). There is nothing in the language to prevent me, or even discourage me from doing this. In fact, I think it is something to encourage. Having said that, why is the notion of the Language providing hooks of -some kind- for extensibility via transformation (a euphemism, if you like), at other points where the symbol CAR of a form is significant (e.g., LAMBDA, declarations, type specs.....) not reasonable?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 May 85 23:38:33 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 May 85 20:30:38 PDT Received: ID ; Sun 12 May 85 23:30:34-EDT Date: Sun, 12 May 1985 23:30 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Dan Hoey Cc: Common-Lisp@SU-AI.ARPA Subject: EQUALP hash tables (and more ...) In-reply-to: Msg of 12 May 1985 19:12-EDT from Dan Hoey ... but then I noticed that the language already provides a mechanism for writing a perfect EQ hashing function: (DEFVAR *EQ-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQ)) (DEFVAR *EQ-HASH-COUNTER* 0) (DEFUN EQHASH (X) (OR (GETHASH X *EQ-HASH-TABLE*) (SETF (GETHASH X *EQ-HASH-TABLE*) (INCF *EQ-HASH-COUNTER*)))) So I guess the point is that given magic EQ and EQL hashtables that work even when a GC moves things, you can use these to build a slower version of EQ and EQL hashtables (and related thingies) that also works, without giving the users direct access to the magic. Interesting in principle, but not the way you'd want to do anything real. By allowing the user to specify at hashtable creation time whether his hashing function at some level makes use of something that amounts to an address pointer (and which will therefore need to be fixed after a copying GC mangles things), we allow the user to win without having to make hashtable references in the course of his comparison. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 May 85 20:54:36 EST Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 12 May 85 17:47:59 PDT Date: 12 May 1985 19:12:56 EDT (Sun) From: Dan Hoey Subject: Re: EQUALP hash tables (and more ...) To: Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA, Common-Lisp@SU-AI Message-Id: <484787577/hoey@nrl-aic> In-Reply-To: Msg of 11 May 1985 15:29 EDT from Skef Wholey and Msg of 11 May 1985 10:59-EDT from Scott E. Fahlman Skef, I was about to bring up the problem you mentioned: ``I don't think it's possible to let users write some form of hashing function that generates = numbers for EQ objects.'' but then I noticed that the language already provides a mechanism for writing a perfect EQ hashing function: (DEFVAR *EQ-HASH-TABLE* (MAKE-HASH-TABLE :TEST #'EQ)) (DEFVAR *EQ-HASH-COUNTER* 0) (DEFUN EQHASH (X) (OR (GETHASH X *EQ-HASH-TABLE*) (SETF (GETHASH X *EQ-HASH-TABLE*) (INCF *EQ-HASH-COUNTER*)))) It is a pity that there's no way to let the GC collect stuff out of the *EQ-HASH-TABLE* for fear of breaking MAPHASH. Maybe there should be some way of declaring a hash table GC-able, perhaps by declaring it un-MAPHASH-able. Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 May 85 15:33:26 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 12 May 85 12:25:23 PDT Date: Sun, 12 May 85 15:17 EDT From: Nick Gall Subject: Re: defconstant vs. lexical variables cc: common-lisp@SU-AI.ARPA In-Reply-To: Message of 6 May 85 15:40 EDT from "OLDMAN at USC-ISI" Message-ID: <850512191735.970989@MIT-MULTICS.ARPA> Date: 6 May 1985 15:40 edt From: OLDMAN at USC-ISI Subject: defconstant vs. lexical variables Page 69 of the CLM states: "Once a name has been declared by defconstant to be constant, any further assignment to or binding of that special variable is an error. ... A compiler may also choose to issue warnings about bindings of the lexical variable of the same name." Question: How can I make a lexical binding of the thing if it's implicitly proclaimed special by the defconstant? Alternate question: Why don't we have a way of declaring something locally lexical? --Dan Oldman {Data General} Answer: (defun foo (lex-x) ...) (proclaim '(special lex-x)) ; Compiler should warn me ; when it hits this statement. Alternate answer: I don't know. I think we should also. Until then, one should stick to the convention of surrounding special vars. with *'s. This should reduce the chance of unknowingly using a var. that has been proclaimed special.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 May 85 08:58:25 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 May 85 05:50:31 PDT Date: Sun, 12 May 85 08:51:09 EST From: George J. Carrette Subject: hash table types To: DCP@SCRC-QUABBIN cc: TIM@MIT-MC, COMMON-LISP@SU-AI In-reply-to: Msg of Thu 9 May 85 12:01 EDT from David C. Plummer in disguise Message-ID: <[MIT-MC].499100.850512.GJC> We figured that fixing the root of the problem, the lack of canonicalization in the hardware database would possibly cost enough time to break a production development window and put off the introduction of a new hardware item for a few months, with possible losses in sales of a million dollars or more for the year. Given this sort of lossage mode one cant stress enough the importance of having *some* way of getting compatibility between RELEASE N and RELEASE N+1. Remember that at some time in "zetalisp" EQUAL on type STRING meant STRING-EQUAL, which was for better or worse case insensitive. LMI release 2 and presumably also Symbolics release 6 does away with this. If there is nothing available which behaves in exactly the same way as the *old* EQUAL-HASH-TABLE then people can be screwed badly. Remember also that many ugly things that were left in Common-Lisp from maclisp days (such as the empty list being a SYMBOL, making the set of all lists and all symbols have a non-null intersection) were justified soley on the basis that there was no *automatic* way for people to detect if they were depending on such lossage and convert their programs. To quote Dave Moon: "Our customers just wont stand for it." -gjc  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 May 85 02:08:35 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 May 85 22:59:24 PDT Date: Sun, 12 May 85 01:58:19 EST From: Tim McNerney Subject: Macros -> declarations To: common-lisp@SU-AI Message-ID: <[MIT-MC].498921.850512.TIM> Date: Fri, 10 May 85 01:51 EDT From: Kent M Pitman Date: Wed, 8 May 85 11:53 EDT From: Robert W. Kerns Instead of DECLARE forms being allowed to be macros, why not allow the forms INSIDE declare forms be macros? Using macros rather than "declaration macros" lets you then use macrolet, and avoids the need for any new "DEFDECLARE" special forms to document or implement. No, this is too confusing. What about things like STRING which are already functions? Do we propose to have macro syntax available in a context where function syntax is not? I think that would be very confusing. IFF we have to flush macros -> declarations, I think Kerns' user-extensible DECLARE is the most palatable suggestion so far. Unfortunately, there are a number of problems with allowing macros inside of DECLARE, and indeed with nearly any user-extensible DECLARE. Perhaps the biggest problem is that the namespace available for use as declaration names has already been "given away." The sort naming conflict that KMP bought up could be solved by having a declarations package which does not use the LISP package, but CL implementations are free to use any names not explicitly mentioned in CLTL for implementation-dependent declarations. Thus, allowing macros inside of DECLARE could potentially reduce the portability of code that used this proposed feature. Whereas (declare-private-specials) -> (declare (special *foo* *bar*)) would pose no problems with portability, (declare (private-specials)) -> (declare (special *foo* *bar*)) might conflict with an existing PRIVATE-SPECIALS declaration specific to a given target implementation (unless the user is allowed to override implementation-dependent declaration names with his own, yuk!). I vote for keeping macros -> declarations and augmenting the language with a set a standard tools for keeping hairy macro writers out of trouble.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 May 85 17:12:40 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 May 85 14:03:43 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234939; Sat 11-May-85 16:59:15-EDT Date: Sat, 11 May 85 17:03 EDT From: Robert W. Kerns Subject: Macros -> declarations To: Kent M Pitman cc: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850511170339.8.RWK@CROW.SCRC.Symbolics.COM> Date: Fri, 10 May 85 01:51 EDT From: Kent M Pitman Date: Wed, 8 May 85 11:53 EDT From: Robert W. Kerns Instead of DECLARE forms being allowed to be macros, why not allow the forms INSIDE declare forms be macros? Using macros rather than "declaration macros" lets you then use macrolet, and avoids the need for any new "DEFDECLARE" special forms to document or implement. No, this is too confusing. What about things like STRING which are already functions? Do we propose to have macro syntax available in a context where function syntax is not? I think that would be very confusing. It certainly would be confusing to define a declaration named STRING, since there's already a function of that name. In our system, you'd get redefinition warnings. Why not call it STRING-DECL? How is this any more confusing than any other naming conflict? Also, what if someone did (DEFMACRO TYPE (X) `(PRINT ,X)) and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people that the possible declaration names (which are all really good names) weren't available to them for definition as names for macros (but -were- available to them as function names)... would you? No, of course not. I see no reason why DECLARE should macroexpand things it already understands. To do so would be to allow gratiutous confusion, such as this. 1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X)) 2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e. Allow DECLARE as a declaration containing declarations. Yuck. Hey, remember that this is the expanded output of a macro, not something that you write in your code. I think the macro definition ends up looking pretty obvious, and besides, the compiler is likely to give you a useful error message if you put one of these macros in an inappropriate place. (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS) `(DEFMACRO ,NAME ,BVL (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS)))) must be rewritten as (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV) (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION) (PARSE-BODY FORMS) `(DEFMACRO ,NAME ,BVL ,@DECLARATIONS ,DOCUMENTATION (MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))) I just don't see this as a big deal. I don't, either, since you need that, regardless of whether or not macros can expand into DECLARE's. However, thinking of humans, I have to say that I don't like macros expanding into entire DECLARE forms because it gets in the way of my adding my own declaration, and because *I* might not recognize something as a declaration. I'm not too worried about it being "too hard" for programs to handle. I believe that DECLARE is already structural, rather than an operator, and that allowing macros to expand into it merely confuses that issue. The other reason I proposed making them macros is so that MACROLET could be used. Most of the uses I can think of would be to allow declarations inside of calls to macros, where MACROLET would be just the right thing to define any declarations. Since it is so idiomatic, though, how about if &BODY did the declaration parsing if you gave it a list of vars instead of a symbol var. Eg, (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC)) `(DEFMACRO ,NAME ,BVL ,@DECLS ,DOC (MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))) This (and its varients I omit for brevity) is a very interesting suggestion, and is worth of discussion independently of of the declaration/macro issue.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 May 85 15:36:48 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85 12:29:13 PDT Received: ID ; Sat 11 May 85 15:29:18-EDT Date: Sat, 11 May 1985 15:29 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Common-Lisp@SU-AI.ARPA Subject: EQUALP hash tables (and more ...) In-reply-to: Msg of 11 May 1985 10:59-EDT from Scott E. Fahlman I think a user-extensible hash table mechanism would be a win, and would be easily implementable even in our non-flavorized system (surprise, surprise). I have a few comments, though: 1. I don't think it's possible to let users write some form of hashing function that generates = numbers for EQ objects. There might be an arbitrarily long time between computing the hash number and using it as an index into a vector, in which countless objects may be transported or garbage collected. This, of course, entirely ignores the ugly mechanism that necessitates rehashing the hash tables at the right time. I would suggest that any hashing facility involving EQ or EQL for some subset of Lisp objects be left to the system. I really don't think much functionality is lost this way, although I know it's very easy to dream up examples which "need" such a feature. 2. The user-supplied hashing function (why not call it :hash instead of :equivalencing?) will probably want to avoid running into bignum arithmetic and so forth. The manual should at least mention this danger when describing this feature. 3. Some implementations may have tense routines for computing a hash code for certain objects. String hashing is microcoded on the Perq, and assembly-coded on other Spice Lisp-derived systems, for example. A user can get to this particular routine via SXHASH, but that might not be the case for other hash functions. Should all specialized, system-supplied, hashing functions be implementation specific, and documented in the appropriate places? I guess that would work. 4. Regarding SXHASH on circular structures: Might there be optional arguments to SXHASH to restrict the "length" and "depth" it will descend into an object? These would default to some "reasonable" implementation-dependent values. One Spice Lisp application (a spelling checker that lives inside the editor) dives straight into the microcode to compute the hash value of a substring. This extension to SXHASH would eliminate non-portabilities like that. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 May 85 11:06:34 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85 07:59:16 PDT Received: ID ; Sat 11 May 85 10:59:21-EDT Date: Sat, 11 May 1985 10:59 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Jon White Cc: common-lisp@SU-AI.ARPA Subject: EQUALP hash tables (and more ...) In-reply-to: Msg of 10 May 1985 02:56-EDT from Jon White The Interlisp-like extension to hash tables that JONL proposes sounds like a pretty good one to me: allow users to specify their own test functions, but if they choose anything other than a small set of "built-in" tests, they have to supply the appropriate numericalizing function as well. I'm not sure what the new keyword to make-hash-table would be. :numericalize doesn't do much for me. This is a compatible extension, as long as we allow the user not to supply the numericalizer if the test is one of EQ, EQL, or EQUAL (and maybe we add EQUALP). For EQ, at least, the numericalizer has to be built in, because we really can't put anything like MAKNUM in the portable language. A few other things might be required to round this out. One is a keyword that says whether the table has to be rehashed after a GC, as most implementations now do for EQ hashtables. This switch would be ignored in implementations that do not move things during a GC. We also probably want to supply the user with a manual REHASH function that takes a whole hashtable and rehashes it. For modifying individual keys, we just have to make clear to the users that they had better remove the item, alter it, and then put it back. I'm not sure if we want to make so large an extension to hash tables, but if we do, this is a compatible way of doing it. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 May 85 09:41:54 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 May 85 06:35:36 PDT Received: ID ; Sat 11 May 85 09:35:44-EDT Date: Sat, 11 May 1985 09:35 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: :-( Upon reflection, I shouldn't have been so flippant in dismissing BSG's suggestion about macro-expansion environments, and I apologize to him. I assume that his suggestion was serious, and poking fun at suggestions that we disagree with is obviously not the best way to promote the free flow of ideas. It has been a long week, and I was feeling irritable. I think that this suggestion is a step in the wrong direction. We want to make the whole issue of macros expanding in funny places less confusing, not more so, and a multiple name space mechansism so that macros in various places can have the same name doesn't look to me like a good idea. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 May 85 23:13:21 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 May 85 20:05:34 PDT Received: ID ; Fri 10 May 85 22:35:40-EDT Date: Fri, 10 May 1985 22:04 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Bernard S. Greenberg" Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 10 May 1985 15:39-EDT from Bernard S. Greenberg You forgot to put in the :-) glyph. Without it, someone might thing you are serious. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 16:12:46 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 May 85 11:38:52 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234523; Fri 10-May-85 14:34:23-EDT Date: Fri, 10 May 85 14:39 EDT From: Bernard S. Greenberg Subject: Y.A.R.I.M.: Macros inside DECLARE? To: JLW@SU-AI.ARPA, rwk@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 10 May 85 03:17-EDT from Jon White Message-ID: <850510143907.6.BSG@CONCORD.SCRC.Symbolics.COM> Date: 10 May 85 0017 PDT From: Jon White In-reply-to: your message of 8-May-85 11:53 EDT As far as I'm concerned, your attempt to unify source-level transformations under the existing DEFMACRO is the best thing to come out of all this discussion. No more DEFMUMBLEs where DEFMUMBLE is YetAnotherRedundantImitationofMacros! I feel that this is more important than the issues of whether macros may produce declares, or whether declare macroexpands its innards. The comment above is also a vote against "lambda macros" -- they provide absolutely no functionality beyond that capable by ordinary macros, and give only marginally better error checking. -- JonL -- Do I read you right, that what you are suggesting is that I say (defmacro adbmal (x) `(lambda . (cdr ,x))) and I could then say (funcall foo #'(adbmal (y) (+ y 3)) ? That's clearly right.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 15:48:22 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 May 85 12:39:02 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234581; Fri 10-May-85 15:34:38-EDT Date: Fri, 10 May 85 15:39 EDT From: Bernard S. Greenberg Subject: Macros -> declarations To: KMP@SCRC-STONY-BROOK.ARPA, RWK@SCRC-YUKON.ARPA, Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850510153924.2.BSG@CONCORD.SCRC.Symbolics.COM> Date: Fri, 10 May 85 01:51 EDT From: Kent M Pitman No, this is too confusing. What about things like STRING which are already functions? Do we propose to have macro syntax available in a context where function syntax is not? I think that would be very confusing. Also, what if someone did (DEFMACRO TYPE (X) `(PRINT ,X)) and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people that the possible declaration names (which are all really good names) weren't available to them for definition as names for macros (but -were- available to them as function names)... would you? Damn! Just when I was beginning to like this! How about, for a really off-the-wall suggestion, a "macroification context", defined by each macro by the &EXPANDWHEN-CONTEXT notkeyword, and whose default is (:EVAL :COMPILE) (choose any names you like) (defmacro push (x y &expandwhen-context (:eval :compile)) ..etc.) means that evaluation and compilation (the only kind valid today) are the contexts in which this macro will be recognized. (I can see several implementation possibilities.) This allows extension to :declaration, :functional-form (lambda macro) :lap-code and n other non-intrusive, compatible possibilities. Thus, (defmacro register (x &EXPANDWHEN-CONTEXT :declare) `(fixnum ,(cdr x)))  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 14:07:57 EDT Received: from IMSSS by SU-AI with PUP; 10-May-85 10:57 PDT Date: 10 May 1985 1058-PDT From: Rem@IMSSS Subject: Instead of read macros, how about one reserved-word for process-time macro? To: COMMON-LISP@SU-AI Here's an idea I used here as an alternative to splicing macros and other MacLISP grunge which weren't available here, and which might in CL be a general solution to macro->declare, argument-list macros, etc. Have one reserved word, which in the CAR position of any form, even an inner form, causes the CADR to be the name of a macro and the CDDR to be a form to be passed to that macro. The result from that macro is then the effective form to be processed instead of the original form containing the reserved word. For example, if ! is the reserved word, and FOO is a macro, then (A B ! FOO X Y Z) means (A B . q) WHERE q is the result of applying FOO to the s-expression (X Y Z). For example, if FOO is a macro that expands into the arglist (VAL1 VAL2 TMP) then (DEFUN BAR (!FOO) ...) is effectively (DEFUN BAR (VAL1 VAL2 TMP) ...). If you want to patch things together, use ! before CONS or APPEND, for example if FOO2 is a macro that expands into another arglist (PTR1 PTR2) then you can get all five args by saying (DEFUN BAR (! APPEND (! FOO) (! FOO2)) ...). I'm a bit sloppy because this is just an idea. Should we use recursive evaluation when passing arguments to macros or functions named after !, or should we use EVALQUOTE conventions where args are implicitly quoted? You can of course suppress evaluation by ' or increase evaluation by doing (! EVAL
) so either way you get full flexibility. Of course the context of the macro-expansion should be whatever context would be doing the normal processing of the data. Note that even user data could use this convention if the particular program doing the processing were (advertised as) respecting this data-macro convention. Initially only a few system utilities would respect this convention, such as the compiler and interpretor when the data-macro appears in certain places in forms to be compiled or evaluated, but later additional programs could install the convention and start to advertise it. (Imagine having random data fed into some random program that happens to respect the convention, with that data having the ability to perform arbitrary processing before passing the effective data to the program! Sort of like actors/objects!) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 12:34:48 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 May 85 09:06:19 PDT Received: ID ; Fri 10 May 85 11:35:56-EDT Date: Fri, 10 May 1985 10:18 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 10 May 1985 01:51-EDT from Kent M Pitman I agree with KMP's critique of RWK's proposal to just use normal macros inside the declaration forms. Too many problems. As for KMP's comments... On the other hand, I'm really bothered by the fact that one can write: (DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X))) and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people will find this an ugly inconsistency. But you CAN'T use DECLARE-FOO at top-level, since the DECLARE form produced will not be legal there. In general, macros only work in place of forms that you are going to evaluate. In quoted contexts, or other non-evaluated places like arglists, a macro would never expand. DECLARE is one of those, since you never evaluate the DECLARE, but just look at it while deciding how to set up the arguments. The ugly inconsistency here is allowing macros in this place. I am also bothered by the idea of checking explicitly for DECLARE because it means that the thing would not really be an operator at all. It would essentially be just a part of the syntax of some other form (eg, DEFUN or LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ). That's right, DECLARE is not an opertor in Common Lisp, just a piece of syntax that happens to take the form of an operator. The form is probably a hold-over from Maclisp, where DECLARE was an operator. If we had chosen a different syntax for this, such as always having the first list of the body be a declaration without any DECLARE marker in front of it, or hiding the declarations in the arglist after an &declare marker, we would not have made the mistake of treating this as a funny kind of operator when it's really structural. (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS) `(DEFMACRO ,NAME ,BVL (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS)))) must be rewritten as (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV) (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION) (PARSE-BODY FORMS) `(DEFMACRO ,NAME ,BVL ,@DECLARATIONS ,DOCUMENTATION (MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))) I just don't see this as a big deal. It may not be a big deal, but you DID get it wrong. Parse-Body has to receive the appropriate ENV as an argument in order to do its work, unless your version of Parse-Body is somehow getting this as a special. That, basically, is the mistake that people keep making. Well, it looks like we're going to lose this battle. Too many people on this list are fascinated by the alleged flexibility that the macro -> declaration misfeature gives them, and too few are bothered by the errors, confusion, and inefficiency that this causes. Since the misfeature is already in the manual, it would require a clear consensus to remove it, and I don't see that emerging. The fallback position is to add a reasonable PARSE-BODY form to the language, with a required environment argument as well as the forms argument. We should probably do that in any event, since each and every implementation seems to have invented this and few people can write a correct macro without this. The manual will need to be extended, in the section on Macros, I guess, to explain what this is about and give an example or two. I am also very interested in KMP's suggestion for an extenstion to the &body syntax, but need to study this a bit to make sure that there are not hidden problems. The big advantage of this, of course, is that it allows the casual macro-writer to avoid dealing explicitly with environments and hairy M-V uses of Parse-body for most simple things. I grant that people who can't hack these things shouldn't be writing macros, but they will be, and life will be easier all around if we can make this process less error-prone. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 04:53:59 EDT Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 10 May 85 01:46:39 PDT Date: 10 May 1985 03:54:51 EDT (Fri) From: Dan Hoey Subject: Re: EQUALP hash tables (and more ...) To: Jon White Cc: Common-Lisp@SU-AI.ARPA Message-Id: <484559691/hoey@nrl-aic> Date: 09 May 85 2356 PDT From: Jon White ... a more generalized form of hashing ... two more "properties" of hashtables -- the "equivalenceing" function, and the "numericalizing" function.... For "equivalence" function, the user may supply #'eq, #'string=, or even something random like #'=-mod-5; Bravo! If CL should have hash tables, it should have these. The existing lack of functionality is embarrassing in an otherwise orthogonal, extensible language. ... the "numericalizing" function is simply how to reduce a general s-expression into a reasonable sized fixnum.... I would leave off ``reasonable sized''; certainly gethash is capable of hashing a fixnum value to its favorite range. I [believe] hashing on EQ means using the pointer address... but nothing in the CLM would prevent an implementation from using sxhash instead. Two problems with this. First, as you note, the key could get modified. I'm not sure you noticed, but this means that in order for GETHASH to fail, it would have to examine the whole table for modified structures. Second, I think SXHASH might not terminate on circular structures, though this caveat is not in the manual (and it, or its denial, should be). Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 03:42:36 EDT Date: 10 May 85 0017 PDT From: Jon White Subject: Y.A.R.I.M.: Macros inside DECLARE? To: rwk@SCRC-STONY-BROOK.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your message of 8-May-85 11:53 EDT As far as I'm concerned, your attempt to unify source-level transformations under the existing DEFMACRO is the best thing to come out of all this discussion. No more DEFMUMBLEs where DEFMUMBLE is YetAnotherRedundantImitationofMacros! I feel that this is more important than the issues of whether macros may produce declares, or whether declare macroexpands its innards. The comment above is also a vote against "lambda macros" -- they provide absolutely no functionality beyond that capable by ordinary macros, and give only marginally better error checking. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 03:16:48 EDT Date: 09 May 85 2356 PDT From: Jon White Subject: EQUALP hash tables (and more ...) To: tim@MIT-MC.ARPA CC: common-lisp@SU-AI.ARPA Not too long ago, some of the LOOPS people at Xerox PARC needed a more generalized form of hashing; the solution was to admit two more "properties" of hashtables -- the "equivalenceing" function, and the "numericalizing" function. Both of these are fully general arguments -- the user may supply any reasonable function there -- and I don't see why such an extended definition hasn't been accepted into CL; can anyone remember a reason for the restriction to such a limited set? [current Interlisp-D release documents changes made to hashing almost a year ago -- this loops-inspired extension was done only at the end of 1984, and wasn't even fully integrated into the system by the time I left Xerox in January 1985]. For "equivalence" function, the user may supply #'eq, #'string=, or even something random like #'=-mod-5; the "numericalizing" function is simply how to reduce a general s-expression into a reaonable sized fixnum; for EQ type tables, this is usually something like MacLisp's MAKNUM (Interlisp's LOC), and for EQUAL type tables it is usually SXHASH. One very interesting point to note is that the CLM doesn't require that EQ type tables actually use the pointer address (ie. numericalizing by MAKNUM); apparently in an effort to maintain generality and portability, the only specification for such tables is that the equivalencing test be EQ. I and several of my colleagues "believe" that everyone thinks hashing on EQ means using the pointer address, rather than the sxhash, as the numerical start -- but nothing in the CLM would prevent an implementation from using sxhash instead. And indeed, the only way one would ever notice the difference (apart from an unreasonably slow implementation of SXHASH!), is that using MAKNUM would insulate against re-orderings of the "chains" inside the table [I'm assuming everyone knows the problem with using sxhash for the numericalizing -- that updates to a hashed structure will change its sxhash value, and thereby cause it to be in a differnt chain in the hash table.] -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 02:36:49 EDT Date: 09 May 85 2319 PDT From: Jon White Subject: READ-AN-DO-FILE-ATTRIBUTES To: Fahlman@CMU-CS-C.ARPA CC: common-lisp@SU-AI.ARPA Yes, by "system-supplied", I was proposing this for white pages level on the next go-around (hopefully, for yellow pages level during the interim -- expecting that interim not to be longer than 2 years). But I didn'nt mean to imply the Lispm convention of lines with ;;; -*- when saying "attributes"; I mean the generalized notion of whatever the agreed-upon convention will be. This means that merely having the 7-extremely-randoms in a lisp-like syntax near the beginning of the file would be fine. Moon is disinclined to go for another convention (i.e. something other than the ;;; -*-), and one can sympathize with him, given the investment of time etc that Symbolics has in it. But I don't think it would be so hard to spec out a lisp-syntax proposal, especially if there were a means of doing a "limited" READ (i.e., a READ that doesn't swallow more than, say, 1024 characters.) It's not just a love of lisp syntax that brings this matter up, but rather the difficlty of extending the ;;;-*- notation to meet the increasing number of contextual needs. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 02:04:44 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85 22:54:25 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 234166; Fri 10-May-85 01:50:12-EDT Date: Fri, 10 May 85 01:51 EDT From: Kent M Pitman Subject: Macros -> declarations To: RWK@SCRC-YUKON.ARPA, Fahlman@CMU-CS-C.ARPA cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM> Message-ID: <850510015144.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 8 May 85 11:53 EDT From: Robert W. Kerns Date: Tue, 7 May 1985 22:50 EDT From: "Scott E. Fahlman" Is there any hope that we can all agree on flushing macro -> declaration expansion and replacing it with something like Skef's "declaration macro" proposal? You state that this is the minimum acceptable position (minimun acceptable amount of hair, I guess), and for me it's about the maximum acceptable position. It would seem to cover about 99% of the cases where people claim that they need the macro expansion. Might I suggest another proposal that I think adds less complexity for the same gain (for either side of the issue)? Instead of DECLARE forms being allowed to be macros, why not allow the forms INSIDE declare forms be macros? Using macros rather than "declaration macros" lets you then use macrolet, and avoids the need for any new "DEFDECLARE" special forms to document or implement. No, this is too confusing. What about things like STRING which are already functions? Do we propose to have macro syntax available in a context where function syntax is not? I think that would be very confusing. Also, what if someone did (DEFMACRO TYPE (X) `(PRINT ,X)) and then someone else did (DECLARE (TYPE LIST FOO)). You wouldn't want to tell people that the possible declaration names (which are all really good names) weren't available to them for definition as names for macros (but -were- available to them as function names)... would you? This doesn't quite cover the bases, though, unless we also deal with expanding into multiple declarations [i.e. (REGISTER X) -> (SPECIAL X) (FIXNUM X)]. I'll propose two ways to deal with that. Skef's declaration macros covered this case by making them always return a list of declarations. (This also allows one to conveniently return no declarations, which is good since if (REGISTER X) didn't want to expand into any declarations it would otherwise be stuck expanding into NIL implying (DECLARE NIL) which may be ill-formed for all I know... or (SPECIAL) implying (DECLARE (SPECIAL)) which is semantically silly.) 1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X)) 2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e. Allow DECLARE as a declaration containing declarations. Yuck. On the other hand, I'm really bothered by the fact that one can write: (DEFMACRO DECLARE-FOO (&REST X) `(DECLARE (FOO ,@X))) and use (DECLARE-FOO ...) at toplevel but not inside a DEFUN. I think people will find this an ugly inconsistency. I am also bothered by the idea of checking explicitly for DECLARE because it means that the thing would not really be an operator at all. It would essentially be just a part of the syntax of some other form (eg, DEFUN or LAMBDA) -- yet another odd kind of keyword (like OTHERWISE in SELECTQ). And when everything is said and done, the only thing we're trying to avoid is occasionally having to change: (DEFMACRO DEFFOO (NAME BVL &BODY FORMS) `(DEFUN ,(FOOIFY NAME) BVL ,@FORMS)) Oops, no that's not one of the one that has to change. Lemme see. It's gotta be more complicated than that before any of this matters. Ah yes, I wrote something like this just the other day: (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS) `(DEFMACRO ,NAME ,BVL (MAKE-MY-ENCAPSULATION (PROGN ,@FORMS)))) must be rewritten as (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY FORMS &ENVIRONMENT ENV) (MULTIPLE-VALUE-BIND (BODY DECLARATIONS DOCUMENTATION) (PARSE-BODY FORMS) `(DEFMACRO ,NAME ,BVL ,@DECLARATIONS ,DOCUMENTATION (MAKE-MY-ENCAPSULATION (PROGN ,@BODY))))) I just don't see this as a big deal. Since it is so idiomatic, though, how about if &BODY did the declaration parsing if you gave it a list of vars instead of a symbol var. Eg, (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY DECLS DOC)) `(DEFMACRO ,NAME ,BVL ,@DECLS ,DOC (MAKE-MY-ENCAPSULATION (PROGN ,@BODY)))) could be defined to mean the same as what I had just written. Or maybe (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY BODY DECLS DOC) ...) if you thionk the DECLS and DOC look too much like initializations and present-p checks the other way. This latter syntax means you could have defaults for these. Eg, (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...)) (DECLS '((DECLARE (SPECIAL *FOO*)))) (DOC "a macro")) ...) I believe that attacking the problem of DECLARE at the level people have been attacking it gives up programmer flexibility to no good end (not to mention introducing an incompatible change to the language semantics). A change like these syntax extensions to DEFMACRO that I've been speaking about would make life easy for the macro writer without giving up the macro-writing freedoms I was originally supporting. Thoughts?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 MAY 85 00:09:49 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85 21:01:48 PDT Received: ID ; Fri 10 May 85 00:01:24-EDT Date: Fri, 10 May 1985 00:01 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Martin Cc: common-lisp@SU-AI.ARPA Subject: PARSE-BODY In-reply-to: Msg of 9 May 1985 08:55-EDT from Martin We now have a small collection of public-domain programs in Common Lisp, with documentation, for our local users at CMU. Many of these things depend on features only present in the Perq and the Accent operating system, though in many of those the dependencies are minor and easily worked around. Some things are fully portable Common Lisp. A couple of biggies (OPS5, a portable Flavors implementation, a drawing program, and a Lisp-based shell for Spice) will be in there soon, but are not there now. Right now this stuff lives on CMU-CS-SPICE in /usr/spice/library/lisp. Since anonymous FTP doesn't work on this machine, I'll try to copy this stuff over to CMU-CS-C sometime soon, and will let people know when this is done. This is just a start, of course. Once we have enough things to justify the split, I'll create separate directories for truly portable things and those that depend on some aspect of Perq/Accent. If anyone has any portable code to contribute, feel free to send it to me, but only if it is public domain or if you can grant us the rights to pass this code out to anyone who wants it. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 MAY 85 12:37:09 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 May 85 09:29:06 PDT Received: from hplabs by csnet-relay.csnet id ab22357; 9 May 85 12:26 EDT Received: by HP-VENUS id AA25414; Thu, 9 May 85 05:55:47 pdt Message-Id: <8505091255.AA25414@HP-VENUS> Date: Thu 9 May 85 05:55:37-PDT From: Martin Subject: Re: PARSE-BODY To: JLW Cc: common-lisp@su-ai.ARPA, GRISS@hplabs.CSNET In-Reply-To: Message from "Jon White " of Wed 8 May 85 08:35:00-PDT Source-Info: From (or Sender) name not authenticated. Apropos Yellow PAges. Is anything happening to the Yellow pages? Is there a set of publically available and documented files, yet? Martin Griss -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 MAY 85 12:09:11 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85 09:00:17 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 233515; Thu 9-May-85 11:56:12-EDT Date: Thu, 9 May 85 12:01 EDT From: David C. Plummer in disguise Subject: hash table types To: George J. Carrette cc: TIM@MIT-MC.ARPA, COMMON-LISP@SU-AI.ARPA In-Reply-To: <[MIT-MC].493032.850509.GJC> Message-ID: <850509120102.8.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Thu, 9 May 85 08:11:50 EST From: George J. Carrette The problem was that (EQUAL "foo" "FOO") used to be T, but now is NIL, and all the hardware databases had chip and signal names in both upper and lowercase, depending on what the user first typed in. It sounds like you should fix the root problem instead of this kind of workaround. Another alternative would be to implement CASE-INSENSITIVE-EQUAL-HASH-TABLEs, where the :test is CASE-INSENSITIVE-EQUAL or somesuch. So from practical experience I can definitely put in a vote for having :TEST 'EQUALP in hash tables. That's not to say I think equalp hash tables are a bad idea. I'm not sure if they are good or bad. I fear the efficiency penalty of traversing every array it finds. Your message is clearly a request for equal-like hash table that ignore case (or maybe you should change your hardware database (or make your program always STRING-UPCASE)). Also keep in mind that it is relatively easy for flavor-based implementations to "just go off and add" more types of hash tables. The expsnse-to-implement::usefulness ratio may be too high for other architectures/systems.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 MAY 85 09:51:04 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 May 85 06:41:05 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 233367; Thu 9-May-85 09:36:59-EDT Date: Thu, 9 May 85 09:43 EDT From: Bernard S. Greenberg Subject: Macros -> declarations To: RWK@YUKON.SCRC.Symbolics.COM, Fahlman@CMU-CS-C.ARPA cc: KMP@TENEX.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA In-Reply-To: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM> Message-ID: <850509094320.7.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed, 8 May 85 11:53 EDT From: Robert W. Kerns Instead of DECLARE forms being allowed to be macros, why not allow the forms INSIDE declare forms be macros? Using macros rather than "declaration macros" lets you then use macrolet, and avoids the need for any new "DEFDECLARE" special forms to document or implement. This doesn't quite cover the bases, though, unless we also deal with expanding into multiple declarations [i.e. (REGISTER X) -> (SPECIAL X) (FIXNUM X)]. I'll propose two ways to deal with that. 1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X)) 2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e. Allow DECLARE as a declaration containing declarations. 3) Allow (DECLARE (PROGN .....)) [The onus of history.] At any rate, RWK's whole proposal seems to cover all bases.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 MAY 85 09:30:00 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 May 85 06:22:26 PDT Received: ID ; Thu 9 May 85 09:22:32-EDT Date: Thu, 9 May 1985 09:22 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Lack of EQUALP hash tables In-reply-to: Msg of 9 May 1985 02:00-EDT from Tim McNerney I think an Equalp hashtable would also be useful because it would allow you to use arrays and structures as keys. In my code I have never had any great use for the case-insensitiveness of equalp, since I use string-equal. In fact, I think it would be useful if there was a predicate which used eql for comparison and descended into arrays and structures. There have been a number of times when I could have used such a function. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 MAY 85 08:20:09 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 9 May 85 05:11:14 PDT Date: Thu, 9 May 85 08:11:50 EST From: George J. Carrette To: TIM@MIT-MC cc: COMMON-LISP@SU-AI Message-ID: <[MIT-MC].493032.850509.GJC> EQUALP hash tables were absolutely essential in keeping LMI in business, maybe thats why they were excluded. But seriously folks, the digital CAD program we use in-house, "NewDraw," broke when moving from pre-common-lisp system to post-common-lisp. Right at the time when major new hardware development was going on, and the "NewDraw" users wanted to move to post-common-lisp because of vast speed improvements such as microcoded ethernet. There clearly wasnt any time for major rewrites, so that the only thing to do was to change all functions which inductively called EQUAL in the pre-common-lisp to ones that call EQUALP in the new system. EQUAL => EQUALP, and ASSOC => ASSOC-EQUALP are the kind of obvious cases, but the program still didnt work until a clever hardware engineer realized that he was being screwed by hash table lookup, and changed MAKE-HASH-TABLE :TEST 'EQUAL => :TEST 'EQUALP. Which of course didnt work until a software person implemented it. The problem was that (EQUAL "foo" "FOO") used to be T, but now is NIL, and all the hardware databases had chip and signal names in both upper and lowercase, depending on what the user first typed in. So from practical experience I can definitely put in a vote for having :TEST 'EQUALP in hash tables. -gjc  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 MAY 85 01:07:55 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 May 85 21:59:35 PDT Date: Thu, 9 May 85 01:00:05 EST From: Tim McNerney Subject: Lack of EQUALP hash tables To: common-lisp@SU-AI Message-ID: <[MIT-MC].492730.850509.TIM> I noticed that EQUALP is no included in the set of valid :TEST's for hash tables (CLTL p. 282). What was the motivation behind this? An EQUALP hash table seems like a perfectly reasonable type of hash table to want, especially in applications where floating-point numbers and integers are intermixed. Implementing the many to one hashing function seems to be a bit tricky, but not insurmountable. Am I missing something?