Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Sep 86 14:09:14 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86 10:37:46 PDT Date: 29 September 1986, 12:47:02 EDT From: "Timothy P. Daly" To: common-lisp@su-ai.arpa Message-Id: <092986.124703.daly@ibm.com> Subject: getting on the common lisp list Hi, How can I get on the list to receive the common lisp discussion? My address is DALY@IBM.COM.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Sep 86 09:08:15 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86 05:58:26 PDT Received: from zachary by Godot.Think.COM via CHAOS; Fri, 26 Sep 86 08:58:14 edt Date: Fri, 26 Sep 86 09:00 EDT From: Dan Aronson Subject: Jim Meehan Comments To: RPG@SAIL.STANFORD.EDU Cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8609252118.AA00590@Zarathustra.Think.COM> Message-Id: <860926090057.4.DAN@ZACHARY.THINK.COM> Date: Thu, 18 Sep 86 13:24:42 edt From: James R. Meehan CLtL doesn't say whether DOTIMES actually "uses" the loop-variable, as opposed to its value, and this ambiguity causes problems with portable code. I've seen several implementations where DOTIMES actually uses the loop-variable, thus permitting horrors like using SETQ to change the value of the loop-variable and therefore control the iterations. The implementation above would prevent that. Oh yes it does, page 128 of CLtL says: Altering the value of VAR in the body of the loop (by using SETQ, for example) will have unpredictable, possibly implementation-dependent results. A Common Lisp compiler may choose to issue a warning if such a variable appears in a SETQ. This clearly means that if you do things like SETQ then you are going to run in to portability problems. --Dan  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Sep 86 17:33:15 EDT Date: 25 Sep 86 1416 PDT From: Dick Gabriel Subject: Jim Meehan Comments To: common-lisp@SAIL.STANFORD.EDU Jim Meehan asked me to forward a remark he was unable to successfully mail to Common-Lisp. -rpg- ps. Oh yeah, by the way, here it is: Date: Thu, 18 Sep 86 13:24:42 edt From: James R. Meehan To: common-lisp@su-ai.arpa Subject: Ignoring the DOTIMES variable CLtL doesn't say whether DOTIMES actually "uses" the loop-variable, as opposed to its value, and this ambiguity causes problems with portable code. If DOTIMES does use the loop-variable, then (DOTIMES (I 10) (DECLARE (IGNORE I)) (FOO)) can cause the compiler to issue a warning, but if DOTIMES doesn't use the loop-variable, then (DOTIMES (I 10) (FOO)) can also cause the compiler to issue a warning. Personally, I think DOTIMES shouldn't use the variable, so that (DOTIMES (I 10) (DECLARE (IGNORE I)) (FOO)) would be the correct style. That is, it should behave as if it were implemented this way, more or less: (DEFMACRO DOTIMES ((VAR END &OPTIONAL FINAL) &BODY BODY) (LET ((I (GENSYM)) (STOP (GENSYM))) `(DO ((,I 0 (1+ ,I)) (,STOP ,END)) ((>= ,I ,STOP) (LET ((,VAR ,I)) ,FINAL)) (LET ((,VAR ,I)) ,@BODY)))) [This may need some additional work for copying declarations in the "final" code, via the proposed PARSE-BODY or whatever.] I've seen several implementations where DOTIMES actually uses the loop-variable, thus permitting horrors like using SETQ to change the value of the loop-variable and therefore control the iterations. The implementation above would prevent that.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Sep 86 17:16:38 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 25 Sep 86 13:58:46 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14426; Thu 25-Sep-86 16:57:22 EDT Date: Thu, 25 Sep 86 16:56 EDT From: David C. Plummer Subject: Are strings adjustable arrays? To: Stephen E. Robbins , common-lisp@SU-AI.ARPA In-Reply-To: <[MX.LCS.MIT.EDU].949090.860925.STEVER> Message-ID: <860925165650.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 25 Sep 86 09:23:17 EDT From: "Stephen E. Robbins" I have an application that does a lot of string hacking. For efficiency reasons, we'd like to mutate our strings rather than creating new ones all the time. It seems like strings which are adjustable arrays with fill pointers are what we want. I gather from page 299 that, while strings MAY have fill pointers, there is no mechanism for having them automatically created that way. Is that the intention, or is there actually some way to have strings created with fill pointers? To get either fill-pointers or adjustability, you have to use make-array. make-string is not enough. (make-array :element-type 'string-char :fill-pointer 0 :adjustable t)  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Sep 86 09:55:57 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86 06:40:10 PDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 SEP 86 09:23:00 EDT Date: Thu, 25 Sep 86 09:23:17 EDT From: "Stephen E. Robbins" Subject: Are strings adjustable arrays? To: common-lisp@SU-AI.ARPA Message-ID: <[MX.LCS.MIT.EDU].949090.860925.STEVER> I have an application that does a lot of string hacking. For efficiency reasons, we'd like to mutate our strings rather than creating new ones all the time. It seems like strings which are adjustable arrays with fill pointers are what we want. I gather from page 299 that, while strings MAY have fill pointers, there is no mechanism for having them automatically created that way. Is that the intention, or is there actually some way to have strings created with fill pointers? Stever  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Sep 86 23:14:02 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 19:41:18 PDT Received: ID ; Wed 24 Sep 86 22:34:03-EDT Date: Wed, 24 Sep 1986 22:33 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Richard Acuff Cc: common-lisp@SU-AI.ARPA Subject: Readtables and prin1 In-reply-to: Msg of 24 Sep 1986 14:56-EDT from Richard Acuff ... My inclination would be to require anyone using an extensively hacked readtable to write his own matching printer. What do you mean by "extensively"? Hacked enough that you can't do what you want to do with what is presently in Common Lisp. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Sep 86 22:47:37 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 19:32:39 PDT Received: ID ; Wed 24 Sep 86 22:31:28-EDT Date: Wed, 24 Sep 1986 22:31 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Mailing list requests Several people have recently written to me with requests to be taken off the Common Lisp mailing list. This list is maintained and altered by Dick Gabriel, RPG@SU-AI. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 24 Sep 86 15:19:26 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 11:59:35 PDT Date: Wed 24 Sep 86 11:56:35-PDT From: Richard Acuff Subject: Re: Readtables and prin1 To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <12241545278.32.ACUFF@SUMEX-AIM.ARPA> ... My inclination would be to require anyone using an extensively hacked readtable to write his own matching printer. -- Scott What do you mean by "extensively"? -- Rich -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 23 Sep 86 08:12:44 EDT Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 23 Sep 86 03:52:07 PDT Received: from ux63.bath.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a012978; 22 Sep 86 15:14 BST Date: 22 Sep 1986 11:14:06-GMT To: common-lisp <@Cs.Ucl.AC.UK:common-lisp@su-ai.arpa> Subject: OPS-5 From: ma_jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK What is all the fuss about? We ported OPS-5 to the HP Bobcat Common LISP in a very small time; even improved the thing on the way. Is there an official port to Common Lisp? Why? ==John  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 22 Sep 86 21:08:40 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 86 17:48:59 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110259; Mon 22-Sep-86 20:47:24 EDT Date: Mon, 22 Sep 86 20:46 EDT From: David A. Moon Subject: *applyhook* question (hopefully I'll get it right this time) To: SANDRA cc: common-lisp@SU-AI.ARPA In-Reply-To: <12239962857.17.LOOSEMORE@UTAH-20.ARPA> Message-ID: <860922204642.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu 18 Sep 86 12:04:06-MDT From: SANDRA I haven't seen any replies to this. I guess I can try to take a crack at it. CLtL says the apply hook function "takes three arguments, a function, a list of arguments, and an environment". Three questions: (1) Is the "function" argument already evaluated? There are no user- accessible functions for extracting its definition from the environment, so I don't see how the hook function could make much use of an unevaluated function. (2) Are the arguments in the argument list argument already evaluated, or is it the responsibility of the hook function to evaluate them before applying the function? The intent of this ("when a function is about to be applied to arguments", CLtL p.322) is that the applyhook is called after everything has been evaluated. (3) If both the "function" and "argument list" arguments are already evaluated, what does the hook function need an environment for? It's not for anything! Apparently this was discussed on the mailing list long ago, because this comment appears in our source code: ;After discussion on the Common Lisp mailing list, the ENV for the apply hook ;is the environment in which the arguments have already been evaluated, not ;the environment of the function to be called, which is of course still inside ;its closure. Its completely inutile to have the environment as an argument here, ;but it's in the book so I'll accept it and ignore it. I suspect this env is a mistake, although it's conceivable that it is a hook for some kind of future feature.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 22 Sep 86 20:46:49 EDT Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 86 17:34:18 PDT Received: from BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com (BIS-ALICE-LIDDELL.DialNet.Symbolics.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 60147; 22 Sep 86 20:26:49 EDT Date: Mon, 22 Sep 86 16:24 EDT From: Stephen Robbins Subject: " macro character To: common-lisp%su-ai.arpa@SCRC-RIVERSIDE.DialNet.Symbolics.COM Message-ID: <860922162454.3.STEVER@BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com> Hi! On page 347 of CLtL, it says that the double quote character accumulates characters until another double quote is seen. "An exception to this occurs if a \single escape/ character is seen; ..." If I want to write my function which handles " in Common-Lisp itself, how can my handler tell when a character it's read is a single escape character? It would have to be able to look into the readtable. If there are ways to look inside readtables, I've missed them... Thanks! Stever  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 20 Sep 86 21:03:12 EDT Received: from AFIT-AB.ARPA by SAIL.STANFORD.EDU with TCP; 20 Sep 86 17:51:18 PDT Date: 20 Sep 1986 20:46-EDT From: cross@wpafb-afita To: common-lisp@su-ai, ai-ed@sumex-aim Subject: xlisp query Would appreciate a pointer to where I could download the source code for xlisp 1.6 and any demonstratable programs written in xlisp. I'm aware of the stuff published in AI Expert and have downloaded it, but cannot find the source code. Thanks in advance. Steve Cross  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 19 Sep 86 22:04:56 EDT Received: from AFIT-AB.ARPA by SAIL.STANFORD.EDU with TCP; 19 Sep 86 18:53:19 PDT Date: 19 Sep 1986 21:26-EDT From: cross@wpafb-ab To: ai-ed-request@sumex-aim, soft-eng-request@mit-xx, common-lisp@su-ai, info-xlisp-request@cmu-cs-spice Subject: please add my name Please add me to the list. Thanks. Steve Cross AFIT/ENG, WPAFB OH 45433-6583 (513) 255-3576  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 18:53:27 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 15:38:42 PDT Received: by hplabs.HP.COM ; Thu, 18 Sep 86 15:37:41 pdt Date: Thu, 18 Sep 86 15:12:46 PDT From: pyramid!bein@hplabs.HP.COM (David Bein) Message-Id: <8609182212.AA14499@pyramid> Received: by pyramid (5.51/3.14) id AA14499; Thu, 18 Sep 86 15:12:46 PDT To: common-lisp@sail.stanford.edu Subject: testing addresses ... please ignore --David  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 15:50:03 EDT Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86 11:04:18 PDT Date: Thu 18 Sep 86 12:04:06-MDT From: SANDRA Subject: *applyhook* question (hopefully I'll get it right this time) To: common-lisp@SU-AI.ARPA Message-ID: <12239962857.17.LOOSEMORE@UTAH-20.ARPA> CLtL says the apply hook function "takes three arguments, a function, a list of arguments, and an environment". Three questions: (1) Is the "function" argument already evaluated? There are no user- accessible functions for extracting its definition from the environment, so I don't see how the hook function could make much use of an unevaluated function. (2) Are the arguments in the argument list argument already evaluated, or is it the responsibility of the hook function to evaluate them before applying the function? (3) If both the "function" and "argument list" arguments are already evaluated, what does the hook function need an environment for? -Sandra -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 15:49:41 EDT Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:00 PDT Date: Thu 18 Sep 86 11:58:48-MDT From: SANDRA Subject: *applyhook* question To: common-lisp@SU-AI.ARPA Message-ID: <12239961893.17.LOOSEMORE@UTAH-20.ARPA> CLtL says the apply hook function "takes three arguments, a function, a list of arguments, and an environment". Three questions: (1) Is the "function" argument already evaluated? There are no user accessible functions for extracting its definition from the environment. -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 15:49:29 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:39:43 PDT Received: from utokyo-relay by csnet-relay.csnet id ba05313; 18 Sep 86 1:40 EDT Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA09220; Sat, 13 Sep 86 14:15:23+0900 From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Sat, 13 Sep 86 13:22:58 jst Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet) id AA00467; Sat, 13 Sep 86 13:12:28+0900 Date: Sat, 13 Sep 86 13:12:28+0900 Message-Id: <8609130412.AA00467@kurims.kurims.kyoto-u.junet> To: common-lisp%su-ai.arpa%u-tokyo.junet@CSNET-RELAY.ARPA Subject: Re: OPS5 in Common Lisp We also have OPS5 running on KCL. It is VPS2, an interpreter for OPS5, copyrighted by C.Forgy in 1979, 1980, and 1981. The sources came from Edinburgh AIAI, where Jeff ported VPS2 onto Spice Lisp. Just removing the use of fexpr was enough to port it onto KCL. -- Taiichi  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 15:49:08 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:37:14 PDT Received: ID ; Thu 18 Sep 86 13:35:17-EDT Date: Thu, 18 Sep 1986 13:35 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Readtables and prin1 In-reply-to: Msg of 18 Sep 1986 10:00-EDT from Brad Miller OK, apparently lots of systems peek at the current readtable in order to see which characters need to be slashified (or vertical-barred) on output. That's probably impossible to get right, if by "right" you mean doing the minimal slashification that is necessary but no more. However, it doesn't hurt to slashify extra characters if there is some doubt. I'm not sure whether I think this is valuable or important, but I won't argue against it. I still think that requiring PRIN1 to perform correctly given any arbitrary readtable is much too hard to make this a required part of the language, and probably impossible. I'm not sure whether a half-assed attempt to adapt to the current readtable is better than explicitly not doing this at all. My inclination would be to require anyone using an extensively hacked readtable to write his own matching printer. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 15:48:54 EDT Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86 07:01:08 PDT Received: from UR-CASHEW.ARPA (UR-CASHEW.ARPA) by UR-ACORN.ARPA via INTERNET with SMTP id 34026; 18 Sep 86 10:00:17-EDT Date: Thu, 18 Sep 86 10:00 EDT From: Brad Miller Subject: Re: Readtables and prin1 To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA Fcc: ACORN:>miller>babyl.text In-Reply-To: Message-ID: <860918100035.2.MILLER@UR-CASHEW.ARPA> Sender: miller@UR-ACORN.ARPA Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Moon: 7 minutes since the full moon. Date: Wed, 17 Sep 1986 21:07 EDT From: "Scott E. Fahlman" I think that the usual practice is to print things out so that they can be read in using the standard readtable. It would be VERY difficult to write code that can print out text for any user-modified readtable, especially if the read-table contains macros. -- Scott It may be hard, but I suspect necessary. Given the user is in some context, he would expect his print function to work "so it can be read in again" which implies in his current context. Having to change contexts just to enter forms (which would then get into even more difficult problems about packaging, etc. in the new context) is not in my opinion a good user interface. Brad Miller ------ miller@rochester.arpa miller@ur-acorn.arpa  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Sep 86 01:31:03 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 17 Sep 86 22:16:31 PDT Received: from WHITE.SWW.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12684; Thu 18-Sep-86 01:15:45 EDT Received: from PURPLE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 33202; Wed 17-Sep-86 22:09:12 PDT Date: Wed, 17 Sep 86 21:54 PDT From: DDYER@RIVERSIDE.SCRC.Symbolics.COM Subject: Readtables and prin1 To: Scott E. Fahlman , Timothy.Freeman@THEORY.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Fcc: W:>ddyer>mail.sent In-Reply-To: Message-ID: <860917215432.5.DDYER@PURPLE.SWW.Symbolics.COM> Date: Wed, 17 Sep 1986 21:07 EDT From: "Scott E. Fahlman" I think that the usual practice is to print things out so that they can be read in using the standard readtable. It would be VERY difficult to write code that can print out text for any user-modified readtable, especially if the read-table contains macros. -- Scott Gee, that's the way Interlisp has always done it. In Interlisp, all print operations accept a readtable as an optional argument, which determines how things are printed. All you have to do is pre-process the readtable so you know which characters need to be slashified.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 17 Sep 86 23:25:22 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Sep 86 20:01:19 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106638; Wed 17-Sep-86 22:59:46 EDT Date: Wed, 17 Sep 86 23:00 EDT From: David A. Moon Subject: Readtables and prin1 To: Scott E. Fahlman cc: Timothy.Freeman@THEORY.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860917230007.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 17 Sep 1986 21:07 EDT From: "Scott E. Fahlman" I think that the usual practice is to print things out so that they can be read in using the standard readtable. It would be VERY difficult to write code that can print out text for any user-modified readtable, especially if the read-table contains macros. Many systems attempt to print things out so that they can be read in using the current readtable. For example, the Symbolics system uses the current readtable to determine where escape characters are required (feed the symbol's name back through the readtable and see if you get the same thing). I agree that it is very difficult to cope with arbitrary user modifications to the readtable, especially with the readtable-modifying primitives provided by Common Lisp, but on the other hand it's easy to cope with some common, simple modifications such as changing exclamation point from a constituent to a macro. Basing this on the current readtable rather than the standard readtable gives the user more flexibility, but as Common Lisp is currently defined it is up to each implementation to decide whether it wants to go to this much care. I think if we're going to be more specific than "an attempt is made to print an expression in such a way that it can be read again", then it is incumbent on us to define more specifically how to customize the printer in the same way that the reader can be customized, e.g. changing the parenthesis characters.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 17 Sep 86 22:22:05 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 18:13:24 PDT Received: ID ; Wed 17 Sep 86 21:08:13-EDT Date: Wed, 17 Sep 1986 21:07 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Timothy.Freeman@THEORY.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Subject: Readtables and prin1 In-reply-to: Msg of 17 Sep 1986 13:40-EDT from Timothy.Freeman at theory.cs.cmu.edu I think that the usual practice is to print things out so that they can be read in using the standard readtable. It would be VERY difficult to write code that can print out text for any user-modified readtable, especially if the read-table contains macros. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 17 Sep 86 21:26:47 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 18:13:24 PDT Received: ID ; Wed 17 Sep 86 21:08:13-EDT Date: Wed, 17 Sep 1986 21:07 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Timothy.Freeman@THEORY.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Subject: Readtables and prin1 In-reply-to: Msg of 17 Sep 1986 13:40-EDT from Timothy.Freeman at theory.cs.cmu.edu I think that the usual practice is to print things out so that they can be read in using the standard readtable. It would be VERY difficult to write code that can print out text for any user-modified readtable, especially if the read-table contains macros. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 17 Sep 86 14:19:49 EDT Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 10:44:08 PDT Date: Wednesday, 17 September 1986 13:40:39 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: common-lisp@su-ai.arpa Subject: Readtables and prin1 Message-ID: <1986.9.17.17.29.57.Timothy.Freeman@theory.cs.cmu.edu> When prin1 is used to print something out, should it look at the current value of *readtable* and produce text that can be read in assuming that readtable is in effect, or should it produce text that can be read in with the standard readtable? The manual says the following about the *print-escape* flag: "When this flag is not nil, then an attempt is made to print an expression in such a way that it can be read again to produce an equal structure." (page 370, near the bottom) Maybe Common Lisp needs a *print-readtable* variable that is analogous to the *print-base* variable.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 15 Sep 86 22:47:01 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 15 Sep 86 19:37:14 PDT Date: 15 Sep 1986 22:35-EDT Sender: NGALL@G.BBN.COM Subject: defstruct slots' default-inits From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]15-Sep-86 22:35:17.NGALL> Is the following legal CL: (defstruct foo (a 1) (b (+ a 2))) Specifically, is the default-init form of a slot allowed to reference the values of slots to its left (above)? In other words, is the above defined by CL to be equivalent to (defstruct (foo (:constructor make-foo (&key (a 1) (b (+ a 2))))) a b) (assuming that &key was allowed in the lambda-list for a BOA constructor) The only hint that I can find that indicates that it is legal is on page 309 (bottom): "It is as if the initialization forms were used as init forms for the keyword parameters of the constructor function." Is there a more direct statement about the interaction of default-init forms and other slots? If not, there should be. -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 15 Sep 86 19:34:48 EDT Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 15 Sep 86 14:35:57 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a006635; 13 Sep 86 19:19 BST From: Jeff Dalton Date: Sat, 13 Sep 86 19:20:10 -0100 Message-Id: <12876.8609131820@aiva.ed.ac.uk> To: fateman@renoir.berkeley.edu Subject: Re: OPS-5 in Common Lisp Cc: common-lisp@su-ai.arpa For what it's worth, I ported OPS-5 from Franz to CL a while ago but haven't been sending it around because I didn't know what restrictions applied (there is a copyright notice at the beginning). My port wasn't meant to be very efficient because I wanted to use techniques that would apply to arbitrary Franz programs without my understanding how they worked. So, for example, rather than eliminate the fexprs, I had an automatic way to define them as a combination of a macro and a function. Anyway, I would also be interested in knowing whether I can redistribute this, as there is some demand for it in the UK. I have run some benchmarks using things like the monkey and banana problem, but I would be interested in better tests if anyone has some. -- Jeff  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 15 Sep 86 19:33:52 EDT Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 13:57:22 PDT Received: by renoir.Berkeley.EDU (5.53/1.16) id AA22172; Sun, 14 Sep 86 17:08:23 PDT Date: Sun, 14 Sep 86 17:08:23 PDT From: fateman@renoir.Berkeley.EDU (Richard Fateman) Message-Id: <8609150008.AA22172@renoir.Berkeley.EDU> To: common-lisp@Sail.Stanford.EDU Subject: ops-5 There turns out to be an ops5 in CL at CMU, in addition to the one done here. A cursory inspection of the CMU one indicates that the changes made were quite similar to those in our version. Unless someone is desperate for a copy, I suggest holding off a few weeks until we get a chance to more carefully compare the two and perhaps put the best of both in one system. Distribution in either case would be public domain.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Sep 86 18:52:20 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 15:43:00 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 15:38:01 PDT Date: Sun, 14 Sep 86 15:36 PDT From: Gregor.pa@Xerox.COM Subject: Portable CommonLoops port liasons To: Common-Lisp@SU-AI.arpa Message-ID: <860914153628.2.GREGOR@AVALON.XEROX-PARC> Line-fold: no I apologize for the wide distribution of this message. For each of the Common Lisp developers, I am looking for a liason with whom I can communicate about porting Portable CommonLoops (PCL) to their Lisp. In the past I have been able to do most of the implementation-specific customizations myself. Now, in order to make PCL run faster, I expect the customizations to become more elaborate, and I would like to have someone who works on each of the Common Lisp implementations to ask questions of etc. Could a system implementor from each of the from each of the Common Lisp implementation groups please send me a message. Thanks. P.S. I already have liasons for the following implementations: Kyoto Common Lisp Lucid Symbolics Xerox Common Lisp -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Sep 86 16:46:00 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 86 13:37:11 PDT Received: ID ; Sun 14 Sep 86 16:36:00-EDT Date: Sun, 14 Sep 1986 16:35 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: ELIOT%cs.umass.edu@RELAY.CS.NET Cc: Common-Lisp@SU-AI.ARPA Subject: Locally In-reply-to: Msg of 10 Sep 1986 20:24-EDT from ELIOT%cs.umass.edu at CSNET-RELAY.ARPA (locally (declare (special foo)) (let ((foo 3)) (print foo))) In NIL, Vaxlisp and HPCommon Lisp this form executes smoothly and prints "3". Either all three implementations are wrong, or the documentation is confusing (to me.) ... I think that Locally (declae (special foo)) should affect every binding and reference to foo within the body of the locally. This would make it behave like a lexically scoped version of "proclaim". I think that all three implementations are right, but not for the reason you suspect. The binding of FOO within the LET is a lexical binding, because the external special declaration has no effect on this binding. This lexical binding is what the reference to FOO in the PRINT form sees. This new binding shadows the SPECIAL declaration for references lexically within the LET. See the example on page 158, which is almost exactly the same case. The current rules covering special declarations are strange, at best, but I think the manual is reasonably clear, under the circumstances. There is an example covering the case that confused you. I admit that the example is a bit hard to follow... -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 13 Sep 86 21:58:00 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Sep 86 18:42:46 PDT Received: from umass-cs by csnet-relay.csnet id ap00376; 11 Sep 86 17:38 EDT Date: Wed, 10 Sep 86 20:24 EDT From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Locally X-VMS-To: CSNET%"Common-Lisp@Su-Ai.arpa" What does the form: (locally (declare (special foo)) (let ((foo 3)) (print foo))) do? On P.156 it says that Locally "does not bind any variables and therefore cannot be used meaningfully for declarations of variable bindings". This would imply that the FOO bound by the LET is not affected by the LOCALLY and that this form should be an error because the SPECIAL reference to FOO in (print foo) is not bound by the lexical binding of FOO. In NIL, Vaxlisp and HPCommon Lisp this form executes smoothly and prints "3". Either all three implementations are wrong, or the documentation is confusing (to me.) Personally I think that the implementations are correct, since the other interpretation implies that the let in: (locally (declare (special foo)) ... (let ((foo ...)) ...)) Cannot ever be meaningfu, since the variable foo is REFERENCED as a special, but bound as a lexical. I think that Locally (declae (special foo)) should affect every binding and reference to foo within the body of the locally. This would make it behave like a lexically scoped version of "proclaim". In any case the documentation seems ambiguous or wrong.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Sep 86 13:42:20 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 12 Sep 86 10:29:00 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79588; Fri 12-Sep-86 13:27:28 EDT Date: Fri, 12 Sep 86 13:27 EDT From: David A. Moon Subject: An example of where setf does not do what I want. To: Bradley C. Kuszmaul cc: common-lisp@SU-AI.ARPA In-Reply-To: <8609121011.AA17090@Godot.Think.COM> Message-ID: <860912132726.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 12 Sep 86 06:11:02 EDT (Fri) From: Bradley C. Kuszmaul I want to do (setf (apply #'aref (cons my-array dims)) value) where MY-ARRAY, DIMS, and VALUE are bound to meaningful values Unfortunately, my reading of SETF says that the above won't work. If I had (ASET value array &rest dims) then I could to (apply #'aset (list* value my-array dims)) to do what I want. Recall that APPLY in Common Lisp allows more than two arguments, unlike APPLY in traditional languages such as Maclisp, Zetalisp, and Lisp 1.5. Hence the expansion is (APPLY #'aset VALUE (CONS MY-ARRAY DIMS)) where aset is not a standard Common Lisp function, but we all know what it does.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Sep 86 12:54:56 EDT Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 86 09:41:56 PDT Received: by renoir.Berkeley.EDU (5.53/1.16) id AA06052; Fri, 12 Sep 86 09:42:15 PDT Date: Fri, 12 Sep 86 09:42:15 PDT From: fateman@renoir.Berkeley.EDU (Richard Fateman) Message-Id: <8609121642.AA06052@renoir.Berkeley.EDU> To: common-lisp@Sail.Stanford.EDU Subject: OPS-5 in Common Lisp A student here has ported the OPS-5 code from Franz Lisp to Common Lisp. If there are no objections from CMU, we are willing to send this to requestors to whom we can send electronic mail. We would like recipient to tell us about bugs (and fixes, if possible) that they find. I don't know if there is any other OPS-5/CL version around, but if there is a comparably "public" version, I'd be glad to compare the two and suppress ours if ours is inferior. It might lend itself to some useful benchmarking.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Sep 86 12:15:00 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 12 Sep 86 08:43:32 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11465; Fri 12-Sep-86 11:42:35 EDT Date: Fri, 12 Sep 86 11:41 EDT From: David C. Plummer Subject: An example of where setf does not do what I want. To: Bradley C. Kuszmaul , common-lisp@SU-AI.ARPA In-Reply-To: <8609121011.AA17090@Godot.Think.COM> Message-ID: <860912114143.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 12 Sep 86 06:11:02 EDT (Fri) From: Bradley C. Kuszmaul I want to do (setf (apply #'aref (cons my-array dims)) value) where MY-ARRAY, DIMS, and VALUE are bound to meaningful values Unfortunately, my reading of SETF says that the above won't work. If I had (ASET value array &rest dims) then I could to (apply #'aset (list* value my-array dims)) to do what I want. How do I do what I want? Your code should work. First, you don't need to do that consing for apply. The old Zetalisp APPLY only took 2 arguments, but Common Lisp APPLY takes 2 or more (and is like Zetalisp lexpr-funcall). Notice (in the Symbolics [7.0] implementation) (setf (apply #'aref my-array dims) value) => (APPLY #'ZL:ASET VALUE MY-ARRAY DIMS) and also (setf (apply #'aref (cons my-array dims)) value) => (APPLY #'ZL:ASET VALUE (VALUES (CONS MY-ARRAY DIMS))) To show order of evaluation is still correct: (setf (apply #'aref (my-array) (dims)) (value)) => (LET* ((#:G8656 (MY-ARRAY)) (#:G8657 (DIMS))) NIL (APPLY #'ZL:ASET (VALUES (VALUE)) #:G8656 #:G8657)) and (setf (apply #'aref (cons (my-array) (dims))) (value)) => (LET* ((#:G8659 (CONS (MY-ARRAY) (DIMS)))) NIL (APPLY #'ZL:ASET (VALUES (VALUE)) #:G8659)) What "reading of SETF" are you using? Pages 96 and 97 explicitly describe this situation and also use AREF as the example. What implementation are you using and how does it expand (or fail to expand).  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Sep 86 11:27:30 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 86 08:14:32 PDT Received: ID ; Fri 12 Sep 86 11:13:15-EDT Date: Fri, 12 Sep 1986 11:13 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Bradley C. Kuszmaul" Cc: common-lisp@SU-AI.ARPA Subject: An example of where setf does not do what I want. In-reply-to: Msg of 12 Sep 1986 06:11-EDT from Bradley C. Kuszmaul The inclusion of APPLY as one of the cases handled by SETF (page 96) was prompted by exactly the case you describe: (setf (apply #'aref (cons my-array dims)) value) As I recall, we considered saying that (setf (apply #'aref ...) ...) was required to work one way or another, but went with this supposedly more general form instead: in a SETF the first argument to APPLY must be any function known to SETF whose internal setting function is of a certain form. Unfortunately, when all this got written into the manual, we neglected to say explicitly that AREF was required to be one of those functions that works in this context (though all the examples indicate that this is what we had in mind). So technically, given the current wording of the manual, it is legal for SETF of APPLY of AREF not to work. In my opinion, any Lisp that takes advantage of this loophole is broken, and the manual should be clarified to require that SETF of APPLY of AREF must work as you would expect. Unfortunately, the Spice Lisp code seems to be broken in exactly this way at present. I thought we had put in a special check to handle AREF years ago, but apparently the fix didn't take. Other implementations may have caught this bug from us. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Sep 86 06:21:21 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 03:11:37 PDT Received: by Godot.Think.COM; Fri, 12 Sep 86 06:11:05 edt Message-Id: <8609121011.AA17090@Godot.Think.COM> To: common-lisp@godot Subject: An example of where setf does not do what I want. Date: 12 Sep 86 06:11:02 EDT (Fri) From: Bradley C. Kuszmaul I want to do (setf (apply #'aref (cons my-array dims)) value) where MY-ARRAY, DIMS, and VALUE are bound to meaningful values Unfortunately, my reading of SETF says that the above won't work. If I had (ASET value array &rest dims) then I could to (apply #'aset (list* value my-array dims)) to do what I want. How do I do what I want? -Brad  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 11 Sep 86 11:51:00 EDT Received: from LL.ARPA by SAIL.STANFORD.EDU with TCP; 11 Sep 86 08:39:06 PDT Date: Thu 11 Sep 1986 11:36:59 EDT From: Subject: To: COMMON-LISP@SU-AI Message-ID: Hi, Please add me to your common lisp mailing list. Thanx. Matt Stillerman  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 8 Sep 86 12:22:23 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 8 Sep 86 09:09:20 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 76279; 8 Sep 86 11:58:01 EDT Date: Mon, 8 Sep 86 11:57 EDT From: David C. Plummer Subject: Programmer Notes To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 5 Sep 86 20:40 EDT from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Message-ID: <860908115735.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Re: ... try using ---, since CLtL has forbidden (unquoted) symbols consisting soley of dots. I think it is a VERY BAD idea to encourage "really nice CL envirnoment" to extend the concept of documentation strings to multiple documentation strings. That is encouraging >gratuitous< incompatibility. We should decide what we want and make the description and the prose match the decision.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 7 Sep 86 20:03:39 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 7 Sep 86 16:46:37 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75402; Sat 6-Sep-86 16:42:35 EDT Date: Sat, 6 Sep 86 16:42 EDT From: Kent M Pitman Subject: #+FOO:BAR To: Common-Lisp@SU-AI.ARPA Message-ID: <860906164226.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> We need to rule on whether people can say: #+FOO:BAR #+(AND FOO:BAR ...) if FOO is a potentially non-existent package and/or BAR is a potentially non-exported symbol. My feeling is that in both cases, these should be treated as "failing" features but should not signal read errors. There are other things that should be resolved about #+/#-, too. Such as what package it defaultly reads in, whether there are any standard features we can all agree on which should be in some known package, etc.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Sep 86 03:11:03 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Sep 86 23:58:43 PDT Received: from umass-cs by csnet-relay.csnet id bl04873; 6 Sep 86 2:27 EDT Date: Fri, 5 Sep 86 19:40 EST From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Programmer Notes X-VMS-To: CSNET%"Common-Lisp@SU-AI.arpa" When I want to leave a note to myself I include a comment with (...) in it. This can easilly be found by a program (EMACS/ZWEI) and then I am even in context where I can do something about it. Along this line, I have often wanted to make the symbol ... be a special symbol which can always be read, but whose evaluation always signals an error. In NIL the symbol ... causes the compiler to bomb, so you can't use it to indicate unimplemented functions (GJC!). I think that LISPMs can read that symbol and do reasonable things with it. (Make it a special.) I think that one documentation string is enough, the rest can be ignored by any sufficiently smart compiler given the semantics of the language, and anyone who builds a really nice Commmon Lisp environment is welcome to extend the notion of documentation strings to include multiple ones. Most people are, I think, under the impression that documentation strings can only be supplied once per function and so multiple documentatoin strings are, de facto, a change to Common Lisp. This is a very unimportant kind of thing to worry about, and I suggest it isn't worth it. I don't care one way or the other, except that I think we need to have a standard. A much more important issue is to define a syntactic standard for these kind of things. There are several places in CLtL where it is suggested that some entity fit into a sentence-schema in a certain way. I think that these guidlines should be made strict requirements, and I think that a good sentence-schema for documentation strings would be appropriate. ...Now back to important things, like message passing and declaration scoping=>  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 5 Sep 86 15:55:05 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 12:35:22 PDT Received: from katherine by Godot.Think.COM via CHAOS; Fri, 5 Sep 86 15:31:51 edt Date: Fri, 5 Sep 86 15:32 EDT From: Guy Steele Subject: Problems with Notation in CLtL To: LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU, Common-Lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <8609041739.AA09293@Zarathustra.Think.COM> Message-Id: <860905153241.6.GLS@KATHERINE.THINK.COM> Date: Thu, 4 Sep 86 12:27 CST From: (David Linn) Would it be appropriate to provide a second reference to clear up this confusion? If sufficient notation would make CLtL impenetrable for the average reader, could not a reference with sufficient notation be made availble for those with the desire to wade through it? The construction of an accurate if impenetrable reference for CLtL is merely "a small matter of writing". Sounds like a job for ANSI X3J13. Any volunteers? The first meeting, as has already been announced on this mailing list, is in Washington D.C. on September 23-24. Be there or be square. --Guy  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 21:55:37 EDT Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 18:42:26 PDT Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 1445; Thu 4-Sep-86 21:43:56 EDT Date: Thu, 4 Sep 86 21:43 EDT From: Christopher Fry Subject: Re: Documentation strings and function. To: Bobrow.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA In-Reply-To: <860904-140040-1592@Xerox> Message-ID: <860904214328.1.CFRY@JONES.AI.MIT.EDU> Expressing the current CL syntax is complicated because the syntax is unnecessarily flexible. Let's decide on whether the first doc string should be before or after the declarations and change the spec to reflect that. I think multiple document strings should be allowed. Perhaps all should precede any declarations. The argument for multiple document strings is that one can then use a simple parsing program to collect documentation from code. One could imagine a convention of the first document string describing the external interface or purpose of a document, and the second information about the implementation. Why isn't the syntax ... lambda-list {documentation}* {declarations}* ... I've yanked in Bobrow's statement since I think he has basically the right idea. Here's an example of the format that I use: (defun foo (a b) "this is THE doc string. It's used for describing the functionality of this function as seen by the outside world." (declare ...) (declare ...) (some code) "this is a programmer comment. I use it to say things like, FIX UP this code someday, or this algorhythm is too slow." (some code) "maybe another programmer comment" (final code)) The function DOCUMENTTION returns the top doc string. My own function PROGRAMMER-COMMENTS returns a list of strings. In the above example it would return the 2nd and 3rd strings in the body. The programmer-comments above don't violate existing CL semantics. And a clever compiler will just throw them out. The restriction on programmer-comments is that they do not include the first string in the body and do not include the last form in the body if that happens to be a string. The flexibility of whether doc strings or declarations go first or intermingle is unncessarily confusing for both human and machine. I find being able to imbed programer-comments in a definition and have a program that can find them helps me make notes to myself in code. Frequently you know something is not working well but can't fix it at the moment. Having a convenient way to store the information which a machine can get at and tell you about it when you ask is a great reminder.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 19:56:51 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 4 Sep 86 16:39:30 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 74534; 4 Sep 86 18:37:16 EDT Date: Thu, 4 Sep 86 18:36 EDT From: David C. Plummer Subject: Re: Documentation strings and function. To: Bobrow.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA In-Reply-To: <860904-140040-1592@Xerox> Message-ID: <860904183653.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Personally, I usually put the documentation strings after the declarations. One also has to consider macros expanding into both documentation strings (is this really allowed?) as well as declarations. The "simple parsing program" you allude to has been proposed under the name of PARSE-BODY, but partly with my flaming seems to have been stalled in committee.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 18:33:59 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 4 Sep 86 15:18:41 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 74511; 4 Sep 86 18:13:36 EDT Date: Thu, 4 Sep 86 18:13 EDT From: David C. Plummer Subject: Re: Documentation strings and function. To: Bobrow.pa@Xerox.COM, DCP@QUABBIN.SCRC.Symbolics.COM cc: Rice@SUMEX-AIM.ARPA, Fahlman@C.CS.CMU.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA In-Reply-To: <860904-140042-1593@Xerox> Message-ID: <860904181314.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 4 Sep 86 13:58 PDT From: Bobrow.pa@Xerox.COM If multiple doc strings are allowed, what does parse-body (if we ever decide on what that should be and do) return? A single string or a list of such, so that these are distinguished. I would prefer that the result would always (SATISFY LISTP). This would let macros do ,@doc-strings instead of ,@(if (stringp doc-strings) `(,doc-strings) doc-strings) as well as what DOCUMENTATION returns. I think this is the case where optimizing a singleton list to be its single component does more harm than good.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 17:38:58 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 14:20:56 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 14:00:40 PDT Date: 4 Sep 86 13:56 PDT From: Bobrow.pa@Xerox.COM Subject: Re: Documentation strings and function. In-reply-to: "Scott E. Fahlman" 's message of Thu, 4 Sep 86 12:44 EDT To: Fahlman@C.CS.CMU.EDU cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA Message-ID: <860904-140040-1592@Xerox> I think multiple document strings should be allowed. Perhaps all should precede any declarations. The argument for multiple document strings is that one can then use a simple parsing program to collect documentation from code. One could imagine a convention of the first document string describing the external interface or purpose of a document, and the second information about the implementation. Why isn't the syntax ... lambda-list {documentation}* {declarations}* ... -- danny  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 17:38:49 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 14:21:06 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 14:00:42 PDT Date: 4 Sep 86 13:58 PDT From: Bobrow.pa@Xerox.COM Subject: Re: Documentation strings and function. In-reply-to: David C. Plummer 's message of Thu, 4 Sep 86 10:37 EDT To: DCP@QUABBIN.SCRC.Symbolics.COM cc: Rice@SUMEX-AIM.ARPA, Fahlman@C.CS.CMU.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA Message-ID: <860904-140042-1593@Xerox> If multiple doc strings are allowed, what does parse-body (if we ever decide on what that should be and do) return? A single string or a list of such, so that these are distinguished. -- danny  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 15:31:21 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 12:22:43 PDT Received: ID ; Thu 4 Sep 86 15:21:09-EDT Date: Thu, 4 Sep 1986 15:20 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: allen@BFLY-VAX.BBN.COM Cc: Common-Lisp@SU-AI.ARPA Subject: Documentation strings and function. In-reply-to: Msg of 4 Sep 1986 13:55-EDT from allen at bfly-vax.bbn.com defun name lambda-list {declaration}* [doc-string] {declaration}* {form}* Yes, it looks like this is the right way to express things in this case. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 14:14:13 EDT Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 11:02:48 PDT To: "Scott E. Fahlman" cc: allen@bfly-vax.bbn.com, Common-Lisp@su-ai.ARPA Subject: Re: Documentation strings and function. In-reply-to: Your message of Thu, 4 Sep 1986 12:44 EDT. -------- Scott: Date: 04 Sep 86 13:55:50 EDT (Thu) From: allen@bfly-vax.bbn.com It may be that there are aspects of the language that are hard or impossible to express in Guy's simple notation. Since I think that simplicity is a virtue, I would advocate retaining the notation and in those cases where it is insufficient the description can be augmented with (non-well-hidden) English. For this case though, if we agree that the sentence midway thru pg 67 is The Truth, then how about defun name lambda-list {declaration}* [doc-string] {declaration}* {form}* /don  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 13:52:52 EDT Received: from WISCVM.WISC.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 10:37:50 PDT Received: from (LINNDR)VUENGVAX.BITNET by WISCVM.WISC.EDU on 09/04/86 at 12:37:07 CDT Date: Thu, 4 Sep 86 12:27 CST From: (David Linn) Subject: Problems with Notation in CLtL To: Common-Lisp@SU-AI.ARPA X-Original-To: Common-Lisp@SU-AI.ARPA, LINNDR >Well, there are things that are hard to express in the simple syntactic >notation Guy chose to use: exactly three of these things are allowed if >and only if one of those things is present, etc. I think that there are >several places in the book where the syntactic expressions provide some >necessary conditions, but where further restrictions on the format are >specified by the text. > >In order to fix all of these things, so that the syntactic expressions >provide a necessary and sufficient formal grammar for the language, we >would have to go to a much more complex notation, which would be >much tougher on the average reader. I think that the current system, >where there are syntactic expressions that are sometimes further >restricted by English statements, is the way to go. > >I agree that the statement forbidding multiple doc-strings should not be >as well-hidden as it currently is. The fact that people have missed it >is pretty good evidence that it is not visible enough. > >-- Scott > ------------------------------------------------------------------------- Would it be appropriate to provide a second reference to clear up this confusion? If sufficient notation would make CLtL impenetrable for the average reader, could not a reference with sufficient notation be made availble for those with the desire to wade through it? David Linn LINNDR@VUENGVAX.BITNET LINNDR%VUEGNVAX.BITNET@WISCVM.WISC.EDU ! Internet (I think) ...!psuvax1!vuengvax.bitnet!linndr ! uucp/USENET  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 12:59:55 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 09:45:47 PDT Received: ID ; Thu 4 Sep 86 12:44:23-EDT Date: Thu, 4 Sep 1986 12:44 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: allen@BFLY-VAX.BBN.COM Cc: Common-Lisp@SU-AI.ARPA Subject: Documentation strings and function. In-reply-to: Msg of 4 Sep 1986 11:45-EDT from allen at bfly-vax.bbn.com Well, there are things that are hard to express in the simple syntactic notation Guy chose to use: exactly three of these things are allowed if and only if one of those things is present, etc. I think that there are several places in the book where the syntactic expressions provide some necessary conditions, but where further restrictions on the format are specified by the text. In order to fix all of these things, so that the syntactic expressions provide a necessary and sufficient formal grammar for the language, we would have to go to a much more complex notation, which would be much tougher on the average reader. I think that the current system, where there are syntactic expressions that are sometimes further restricted by English statements, is the way to go. I agree that the statement forbidding multiple doc-strings should not be as well-hidden as it currently is. The fact that people have missed it is pretty good evidence that it is not visible enough. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 12:04:40 EDT Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 08:53:52 PDT To: "Scott E. Fahlman" cc: James Rice , Common-Lisp@su-ai.ARPA, allen@bfly-vax.bbn.com Subject: Re: Documentation strings and function. In-reply-to: Your message of Wed, 3 Sep 1986 21:09 EDT. Date: 04 Sep 86 11:45:55 EDT (Thu) From: allen@bfly-vax.bbn.com Scott: It would seem that "It is an error if more than one doc-string is present" is inconsistent with the syntactic description of defun at the top of page 67. I refer specifically to the {declaration | doc-string}* segment, which implies a free mix of any number of declarations and doc-strings. Rice's example is legal, if one relies on the latter. It should be decided which is correct, and the appropriate repair made to the book. /Don  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Sep 86 10:49:51 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Sep 86 07:39:21 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9425; Thu 4-Sep-86 10:37:15 EDT Date: Thu, 4 Sep 86 10:37 EDT From: David C. Plummer Subject: Documentation strings and function. To: James Rice , Scott E. Fahlman , Kent M Pitman , Common-Lisp@SU-AI.ARPA In-Reply-To: <12236040169.57.RICE@SUMEX-AIM.ARPA>, , <860903215722.4.KMP@EMU.SCRC.Symbolics.COM> Message-ID: <860904103704.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> When I brought up the multiple-doc-string issue when we were discussing parse-body, everybody seemed unanimous that the current book intended that the first string was the only doc string and that subsequent strings were part of the executable body (and therefore declarations after the second string were an error). Anyway, I was then and am willing to continue believing multiple doc strings should be OK, though I don't have strong enough opinions to take sides. If multiple doc strings are allowed, what does parse-body (if we ever decide on what that should be and do) return? Should it return a list of the doc strings (in the order encountered)? Should it return one string with newlines between the individual strings? What does (documentation 'foo 'defun) return? A list of strings? One string with newlines or some other separator?  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Sep 86 22:42:16 EDT Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 3 Sep 86 19:29:06 PDT Received: from EMU.SCRC.Symbolics.COM by WAIKATO.S4CC.SYMBOLICS.COM via CHAOS with CHAOS-MAIL id 54912; Wed 3-Sep-86 21:58:28 EDT Date: Wed, 3 Sep 86 21:57 EDT From: Kent M Pitman Subject: Documentation strings and function. To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA, Rice@SUMEX-AIM In-Reply-To: Message-ID: <860903215722.4.KMP@EMU.SCRC.Symbolics.COM> Although I would not argue in favor of such an interpretation, I think you'd have a tough time arguing that the restriction on p67 refers to anything other than functions defined by DEFUN. Both the description of DEFUN on p67 (which you cite) and the description of LAMBDA on p60 (which you don't comment on) use the same confusing syntax description: ... {declaration | documentation-string}* ... Well, ok, they don't. p60 refers to documentation-string and p67 refers to a doc-string. (-: Maybe only a doc-string is constrained the way you suggest but a documentation-string is not. :-) [On an unrelated issue that I noticed on the same page, p67 should clearly say that (DEFUN name lambda-list {declaration|doc-string}* {form}*) causes the symbol NAME to be a global name for the function specified by the lambda expression (LAMBDA lambda-list {declaration|doc-string}* (BLOCK name {form}*)) Otherwise, the ability of RETURN-FROM to work in a DEFUN seems just a little too magical, and suggests that LAMBDA or DEFUN somehow interacts with RETURN-FROM in some strange way that we don't ever explain.] Anyway, I think that multiple doc strings should not be undefined and that we should relax that restriction. They would be especially to people (like myself) who get grossed out by The Indentation Problem as illustrated in: (DEFUN FOO (X Y) "This is a very long documentation string which when printed out seems to have an obscure amount of indentation on its second and third line even though it looked nicely lined up in the source." ...) or: (DEFUN FOO (X Y) "This is a very long documentation string which when printed out has no problem about indentation for the subsequent lines, but when viewed in the source looks pretty yucky." ...) I'd prefer: (DEFUN FOO (X Y) "This is how we might allow a very long documentation string to be" "typed in in order to let it look good in the source and also to" "let it look good when obtained later, perhaps as a single string with" "newlines inserted between each of the pieces.") This would also be handy for defmacro, since you could prefix or postfix documentation strings in the expansion without worrying about whether the user was also going to supply a documentation string that elaborated on the standardly provided documentation.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Sep 86 21:23:42 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 18:10:44 PDT Received: ID ; Wed 3 Sep 86 21:09:46-EDT Date: Wed, 3 Sep 1986 21:09 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: James Rice Cc: Common-Lisp@SU-AI.ARPA Subject: Documentation strings and function. In-reply-to: Msg of 3 Sep 1986 14:56-EDT from James Rice Since one is allowed to declare the following :- (defun foo (a b) "A docstring." (declare (special a)) "Another docstring." (declare (special b)) (frob a b)) What makes you think that one is allowed to declare the preceding? I believe that this form is illegal, and that the resulting doc-string is therefore undefined. See page 67 about a third of the way down: "It is an error if more than one doc-string is present." Since that second string cannot be a doc string, the second declare form is in an illegal position. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Sep 86 19:48:04 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 16:36:49 PDT Date: 3 Sep 1986 19:14-EDT Sender: VERACSD@A.ISI.EDU Subject: Deletion from Mailing-List From: VERACSD@A.ISI.EDU To: common-lisp@SU-AI.ARPA Cc: veracsd@A.ISI.EDU Message-ID: <[A.ISI.EDU] 3-Sep-86 19:14:52.VERACSD> Please delete me from the mailing-list. (I can now get it via a bulletin board.) Thanks. -- Cris Kobryn  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Sep 86 17:23:31 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 14:07:15 PDT Date: Wed 3 Sep 86 11:56:07-PDT From: James Rice Subject: Documentation strings and function. To: Common-Lisp@SU-AI.ARPA Message-ID: <12236040169.57.RICE@SUMEX-AIM.ARPA> Since one is allowed to declare the following :- (defun foo (a b) "A docstring." (declare (special a)) "Another docstring." (declare (special b)) (frob a b)) what will the documentation be for Foo? The book seems to be quiet on this issue. I would hope that it would be either a) the two strings concatenated (i.e. when Parse-Body (what?) returns the docstring they are all stuck together, or b) it returns a list of docstrings. The implemetation I am using discards all but the first. While on the subject of documentation :- Wouldn't it be a good idea to have a Documentation function doc type called :All or some such, returning an AList of doctype and docstring. Since a number of CL supporting systems will have doc types of their own (Flavor and such like) and users might want to add their own it would be jolly good if one could guarantee getting all of the docs for a symbol. Rice. -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 2 Sep 86 15:52:31 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Sep 86 12:33:21 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 02 SEP 86 12:26:49 PDT Date: 2 Sep 86 12:26 PDT From: Masinter.pa@Xerox.COM Subject: Re: close on synonym streams, etc In-reply-to: various To: common-lisp@su-ai.ARPA Message-ID: <860902-122649-1037@Xerox> I still prefer "it is an error" to close streams not created with OPEN. However, if there is strong sentiment to allow CLOSE on pseudo-streams like broadcast, synonym and the like, it would be the most consistent to define it as a no-op. That is, closing a synonym stream should have no effect. Why? a) this is certainly the simplest to implement. There's no need to keep pseudo-state "open" or "closed" on streams that would otherwise not need them. b) this would allow the most programs to function, when handed pseudo-streams instead of file streams. In the example of "a program that, when encountering end-of-file closes the inpupt stream and returns" would work when handed a synonym stream to *standard-input*. c) it is upward compatible-- no current program would stop functioning. d) those implementations which "cache" some information into buffered streams could use "close" to mean "flush the cache", although this would have no effect on the program semantics.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 2 Sep 86 15:21:09 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86 11:48:56 PDT Received: from EMU.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72179; Tue 2-Sep-86 14:47:52 EDT Date: Tue, 2 Sep 86 14:47 EDT From: Kent M Pitman Subject: PRINT To: Common-Lisp@SU-AI.ARPA cc: KMP@SCRC-STONY-BROOK.ARPA References: <860902120550.6.MOON@EUPHRATES.SCRC.Symbolics.COM>, <12235272600.9.LOOSEMORE@UTAH-20.ARPA> Message-ID: <860902144720.7.KMP@EMU.SCRC.Symbolics.COM> If we get to a point where we're capable of contemplating incompatible changes to CL, I would strongly urge the group to consider renaming PRIN1 to PRINT (and, obviously, renaming what's currently called PRINT to something else). Sandra's query is not an isolated one. There is wide-spread confusion about what it means to "print" something because the operator named PRINT does more than just "print" a thing. eg, the :PRINT-FUNCTION specifier in DEFSTRUCT effectively defines how to PRIN1 something, not how to PRINT something, which I think most novices are apt to be confused by. I think that thoughtful renaming of a few functions to make the English and the Lisp be consistent would go a long way toward fixing this kind of confusion.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 2 Sep 86 12:30:46 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86 09:09:18 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72016; Tue 2-Sep-86 12:05:55 EDT Date: Tue, 2 Sep 86 12:05 EDT From: David A. Moon Subject: question about pprint, *print-pretty* To: common-lisp@SU-AI.ARPA In-Reply-To: <12235272600.9.LOOSEMORE@UTAH-20.ARPA> Message-ID: <860902120550.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun 31 Aug 86 14:39:44-MDT From: SANDRA In Common Lisp, both print and pprint are defined to print out a newline *before* the form rather than after. This is backwards from PSL, where the prettyprinter indents things relative to the "current" character position on the output stream, and prints a newline afterwards. Is there a portable way I can get the same kind of relative indentation in Common Lisp? Exactly what turning on *print-pretty* does is left rather vague -- the manual just says the printer should insert more whitespace. Is there some overwhelming reason why these functions were defined "backwards" in the first place that I've missed? I don't know if this is an overwhelming reason, but PRINT has always printed the newline first, all the way back to Lisp 1.5 (check the blue and white Lisp 1.5 manual). I think it's intentional that the definition of what it means to print prettily is left rather vague, since different implementations have different ideas about what looks pretty and about how effort they are willing to expend to make something look pretty. Surely binding *PRINT-PRETTY* to T is not supposed to turn PRIN1 into PPRINT. In other words, PRIN1 with *PRINT-PRETTY* = T should not print a leading newline, should indent things relative to the current character position on the output stream, and should not print a trailing newline. Next time the manual should include definitions of all of these functions in terms of WRITE, instead of only defining half of them! I think the answer to your question is to call WRITE and then TERPRI.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 2 Sep 86 12:25:34 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86 09:08:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72015; Tue 2-Sep-86 12:05:08 EDT Date: Tue, 2 Sep 86 12:05 EDT From: David A. Moon Subject: question about pprint, *print-pretty* To: common-lisp@SU-AI.ARPA In-Reply-To: <12235272600.9.LOOSEMORE@UTAH-20.ARPA> Message-ID: <860902120503.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun 31 Aug 86 14:39:44-MDT From: SANDRA In Common Lisp, both print and pprint are defined to print out a newline *before* the form rather than after. This is backwards from PSL, where the prettyprinter indents things relative to the "current" character position on the output stream, and prints a newline afterwards. Is there a portable way I can get the same kind of relative indentation in Common Lisp? Exactly what turning on *print-pretty* does is left rather vague -- the manual just says the printer should insert more whitespace. Is there some overwhelming reason why these functions were defined "backwards" in the first place that I've missed? I don't know if this is an overwhelming reason, but PRINT has always printed the newline first, all the way back to Lisp 1.5 (check the blue and white Lisp 1.5 manual). I think it's intentional that the definition of what it means to print prettily is left rather vague, since different implementations have different ideas about what looks pretty and about how effort they are willing to expend to make something look pretty. Surely binding *PRINT-PRETTY* to T is not supposed to turn PRIN1 into PPRINT. In other words, PRIN1 with *PRINT-PRETTY* = T should not print a leading newline, should indent things relative to the current character position on the output stream, and should not print a trailing newline. Next time the manual should include definitions of all of these functions in terms of WRITE, instead of only defining half of them!  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Aug 86 16:48:45 EDT Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 31 Aug 86 13:41:15 PDT Date: Sun 31 Aug 86 14:39:44-MDT From: SANDRA Subject: question about pprint, *print-pretty* To: common-lisp@SU-AI.ARPA Message-ID: <12235272600.9.LOOSEMORE@UTAH-20.ARPA> In Common Lisp, both print and pprint are defined to print out a newline *before* the form rather than after. This is backwards from PSL, where the prettyprinter indents things relative to the "current" character position on the output stream, and prints a newline afterwards. Is there a portable way I can get the same kind of relative indentation in Common Lisp? Exactly what turning on *print-pretty* does is left rather vague -- the manual just says the printer should insert more whitespace. Is there some overwhelming reason why these functions were defined "backwards" in the first place that I've missed? -Sandra -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 29 Aug 86 13:10:32 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 29 Aug 86 09:56:00 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 8447; 29 Aug 86 12:52:16 EDT Date: Fri, 29 Aug 86 12:50 EDT From: David C. Plummer Subject: Re: Fixing optional arguments? To: Gregor Kiczales , DCP@QUABBIN.SCRC.Symbolics.COM cc: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA In-Reply-To: <860828-111926-234@Xerox> Message-ID: <860829125053.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 28 Aug 86 11:18 PDT From: Gregor Kiczales From: David C. Plummer Subject: Fixing optional arguments? and somebody calls it with B or C being the value of unsupplied-... That means I would have to put a prelude function in that looks roughly like No you wouldn't have to put such a prelude. As soon as function call sees the value of unsupplied-optional-argument it drops the rest of the arguments on the floor. I guess that depends a lot on how your architecture does function calling. Many machines currently do not look at the value of the arguments, partly for historical reasons, partly for speed and perhaps partly for ease of implementation. It would also have to be very careful if some CL extension included the MultiLisp concept of futures. In that case, you DON'T want to examine the data (or you have to do so very carefully) for fear of forcing the contained computation to complete.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Aug 86 15:28:08 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86 12:14:07 PDT Received: ID ; Thu 28 Aug 86 15:14:00-EDT Date: Thu, 28 Aug 1986 15:13 EDT Message-ID: From: Rob MacLachlan To: Gregor Kiczales Cc: Common-Lisp@SU-AI.ARPA Subject: Fixing optional arguments? In-reply-to: Msg of 28 Aug 1986 14:18-EDT from Gregor Kiczales I don't think that we should significantly change the language in a way that will adversely affect the performance of many implementations to get an enhancement that is of marginal utility at best. Many implementations on stock hardware use a link-table to resolve the optional arg entry points at load time, thus eliminating any run-time arg-count dispatching. The change you propose would make this impossible since there would be no way for the compiler to tell how many "real" arguments are being supplied. Even if we disregard this efficiency issue, we would have good reason to reject the proposal as being too radical a change in language semantics. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 28 Aug 86 14:33:50 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Aug 86 11:22:04 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 AUG 86 11:19:26 PDT Date: 28 Aug 86 11:18 PDT Sender: Gregor.pa@Xerox.COM From: Gregor Kiczales Subject: Re: Fixing optional arguments? In-reply-to: David C. Plummer 's message of Wed, 27 Aug 86 21:14 EDT To: DCP@QUABBIN.SCRC.Symbolics.COM cc: Fahlman@C.CS.CMU.EDU, Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA Message-ID: <860828-111926-2340@Xerox> From: David C. Plummer Subject: Fixing optional arguments? and somebody calls it with B or C being the value of unsupplied-... That means I would have to put a prelude function in that looks roughly like No you wouldn't have to put such a prelude. As soon as function call sees the value of unsupplied-optional-argument it drops the rest of the arguments on the floor. (multiple-value-call #'bar arg-1 arg2 (if (values) (values arg-3 arg-4))) I don't see that as being much easier than saying: (if (foo arg-1 arg-2) (foo arg-1 arg-2 arg-3 arg-4))  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Aug 86 21:58:03 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 27 Aug 86 18:46:22 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7902; Wed 27-Aug-86 21:14:17 EDT Date: Wed, 27 Aug 86 21:14 EDT From: David C. Plummer Subject: Fixing optional arguments? To: Scott E. Fahlman , Gregor Kiczales cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860827211406.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 27 Aug 1986 13:51 EDT From: "Scott E. Fahlman" This could be done by convention, without any change to the language, as long as both the caller and the callee know and observe the same convention. Sure, but I think that misses the point. Suppose I have a function that looks like (defun foo (a &optional b c &rest d &key e) ...) and somebody calls it with B or C being the value of unsupplied-... That means I would have to put a prelude function in that looks roughly like (tagbody (cond ((eq b unsupplied...) (go b-is-unsupplied)) ((eq c unsupplied...) (go c-is-unsupplied))) b-is-unsupplied (setq c unsupplied...) c-is-unsupplied (setq d nil e unsupplied...)) (setq c unsupplied...) (go c-unsupplied)) in order to make all the unsupplieds consistent. It also means I can't (when (not b) (setq b (compute-b-default))) since B is not NIL. This is a rather major change to the language. There is probably some validity behind it someplace, but history probably won't allow it. Gregor, does multiple-value-call solve any of your problems? (multiple-value-call #'bar arg-1 arg2 (if (values) (values arg-3 arg-4))) ?  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Aug 86 14:09:43 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 86 10:54:26 PDT Received: ID ; Wed 27 Aug 86 13:52:08-EDT Date: Wed, 27 Aug 1986 13:51 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Gregor Kiczales Cc: Common-Lisp@SU-AI.ARPA Subject: Fixing optional arguments? In-reply-to: Msg of 27 Aug 1986 12:24-EDT from Gregor Kiczales This could be done by convention, without any change to the language, as long as both the caller and the callee know and observe the same convention. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 27 Aug 86 12:35:04 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Aug 86 09:24:48 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 27 AUG 86 09:24:26 PDT Date: 27 Aug 86 09:24 PDT Sender: Gregor.pa@Xerox.COM From: Gregor Kiczales Subject: Fixing optional arguments? To: Common-Lisp@SU-AI.arpa cc: Gregor.pa@Xerox.COM Message-ID: <860827-092426-1167@Xerox> A standard problem with optional arguments in Common Lisp is that it difficult to use the fact that a function was only called with n arguments to call some other function with only n arguments. For example: (defun foo (x &optional (y nil y-p)) ... (if y-p (bar x y) (bar x))) This is a proposed solution to that problem. - The default default value for an optional argument is the value of the constant UNSUPPLIED-OPTIONAL-ARGUMENT (instead of nil). So given the definition (defun foo (x &optional y) y). (foo 1) would return the value of the constant unsupplied-optional-argument. - When function call sees the value of unsupplied-optional-argument being used as an argument to a function, it treats it as an unsupplied value for an optional argument. As an important performance optimization, any arguments following unsupplied-optional-argument are also discarded. The example becomes: (defun foo (x &optional y) ... (bar x y) ..) In addition, it is possible to write code like: ... (when ;; We are only going to call baz with 2 arguments. (setq arg-3 unsupplied-optional-argument)) (baz arg-1 arg-2 arg-3 arg-4) In this example, the call to baz will be as if only two arguments were supplied. The supplied-p variable stuff is also no longer needed since the same thing can be determined by using (unsupplied-optional-argument-p ).  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Aug 86 12:15:06 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Aug 86 09:04:12 PDT Received: ID ; Tue 26 Aug 86 12:03:22-EDT Date: Tue, 26 Aug 1986 12:03 EDT Message-ID: From: Rob MacLachlan To: mike%acorn@LIVE-OAK.LCS.MIT.EDU Cc: Common-Lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM Subject: More words on the scoping of declarations In-reply-to: Msg of 26 Aug 1986 00:09-EDT from mike%acorn at mit-live-oak.arpa Actually I wasn't primarily worried about the meaning of repeated LET* variables, supposing they are legal. I was more concerned about the scope in LET* of declarations which don't pertain to a particular variable. In LET* there isn't a clear environment division which can contain these "pervasive" declarations. I can think of two reasonable scopes for pervasive declarations in LET*: 1] The declarations syntactically enclose all of the incremental environments in the LET*, and thus affect all init forms as well as the body. 2] The declarations affect only the innermost environment, and thus are in effect only in the body, and in none of the init forms. I favor the latter interpretation, since it more closely resembles the scoping in LET. In any case, it seems that LET* must special-case the declarations depending on whether they are "pervasive" or not. Although the concept of a pervasive declaration seems to cause Pavel to cringe, I am not yet convinced that it is a bankrupt idea. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Aug 86 10:09:56 EDT Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 26 Aug 86 06:53:37 PDT Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.51/) id AA13672; Tue, 26 Aug 86 08:52:57 CDT Message-Id: <8608261352.AA13672@gswd-vms.ARPA> Date: Tue, 26 Aug 86 08:51:24 cdt From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: More words on the scoping of dec > From: mike%acorn@mit-live-oak.arpa > The scoping of a declaration in a let* should be as close as possible > to that of a let. I think repeated names should be allowed, and the > innermost one should be the one to which the declaration applies. ---------- I agree that repeated names should be allowed, but I think the declaration should apply to the ENTIRE set of bindings, not just the innermost. If the user wants to have different declarations for the repeated instances of the name, she can break the LET* into nested LET*s. If, on the other hand, she is playing games and doing a multi-step calculation of a value in the header of the LET*, the one declaration should apply to all parts of it. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Aug 86 04:09:45 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 26 Aug 86 00:57:25 PDT Received: by hplabs.HP.COM ; Tue, 26 Aug 86 00:55:52 pdt Received: by pyramid (5.51/3.14) id AA24121; Tue, 26 Aug 86 00:50:52 PDT Date: 26 Aug 1986 00:48 PDT From: David Bein Subject: re: synonym streams.. To: common-lisp@su-ai Message-Id: <525418881/bein@pyramid> Regarding David Moon's comment about what sensible programmers should do, I agree wholeheartedly. It is somewhat clearer that streams come in more flavors than just what OPEN will return (as currently defined in both CLtL and various LispMachine manuals for existing implementations). David's suggestion seems to omit the need for making streams more usable. Closing down a stream (whether it be the product of some composite operation like make-broadcast-stream or not) is a reasonable thing to want to do. I think the issue here is deciding whether or not the programmer/user has an adequate amount of flexibility in this area. ONE QUESTION for the designers: Why was there no function like (MAKE-FILTER-STREAM ' ' ') where function gets passed both streams and does input from filtering it in some way and possibly doing some output to ? I really wish that the original specification for streams had included itself in the typing system. I feel that it would have been cleaner to define one function called: (stream-message stream :keyword <...>) much in the object-oriented spirit. I can think of some esoteric methods I would have added certainly, but the most important ones include being able to differentiate amongst streams, interrogating streams and applying a handful of options to alter how close behaves on any stream. Below the ====='ed line is my proposal. I welcome comments,modifications,critcisms, et al to the proposal presented below. --David ============================================================================= (typep stream 'stream) (stream-message stream :type) Returns stream type, e.g. synonym-stream. This should return something rather specialized. Those who feel that TYPE-OF would answer this need might consider what kinds of hair seem to be in most implementations of TYPE-OF. (stream-message stream :operations) Returns a list of operations which make sense for this stream. Defined to not recurse into streams underneath. (typep stream 'broadcast-stream) (stream-message stream :broadcasters) Returns a list of the streams to broadcast to. (typep stream 'synonym-stream) (stream-message stream :synonym) Returns the symbol which the stream is synonymous with. (stream-message stream :sanity-check) Returns T if the stream contains no loops like the kind which bite KMP and others (me too). Otherwise, returns NIL which means that this stream is inherently unsafe. NOTE: I know this is out of place and definitely smells bad. I could live with out this one I guess. (or (typep stream 'two-way-stream) (typep stream 'echo-stream)) (stream-message stream :input) Returns the input stream. (stream-message stream :output) Returns the output stream. (I think of echo streams as a specialization of two-way streams.) (typep stream 'concatenated-stream) (stream-message stream :sources) Returns a list of the input streams. (typep stream 'stream) ;; CLOSE attributes (stream-message stream :close-forever) Marks this stream as one which CLOSE should render unsuable and which should have CLOSE applied to its children. This is the DEFAULT for streams produced by OPEN or MAKE--STREAM. (stream-message stream :close-never) Marks this stream as always open. A CLOSE will not look to see if this stream has children. (stream-message stream :close-parent) Marks this stream as one which CLOSE renders unusable but does not touch any streams underneath. (stream-message stream :close-children) Marks this stream as one which never closes but a CLOSE applied to it will be applied to streams underneath. (typep stream 'stream) ;; CLOSE and ERROR (stream-message stream :close-no-error) Permit this stream to be CLOSEd. This is the DEFAULT for streams produced by OPEN,MAKE--STREAM. (stream-message stream :close-error) Marks this stream in such a way that a CLOSE of it causes an error. Handy for things like (close *terminal-io*) where it probably does not make sense to close it.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 26 Aug 86 01:06:58 EDT Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 21:53:56 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 8037; 26 Aug 86 00:57:49-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37862; Tue 26-Aug-86 00:03:47-EDT Date: Tue, 26 Aug 86 00:14 EST Sender: mike%gold-hill-acorn@mit-live-oak.arpa To: DCP@QUABBIN.SCRC.Symbolics.COM From: mike%acorn@mit-live-oak.arpa Subject: "fonted" characters in CL Cc: Common-Lisp@SU-AI.ARPA Date: Wed, 20 Aug 86 08:40 EDT From: David C. Plummer I propose we eliminate char-font-limit and the associated concepts from the language. I agree, vehemently. Either that or make the specification considerably more tight and detailed saying how >numeric< values are interpreted. Either that, or specify some >symbolic< notion of "fonts" we can live with. I don't think this is a good idea for CL, see more below. Symbolics found that the CL notion of "fonts" is not very portable, nor is it very useful. ...... What we have done instead (note I don't want to push this and I'm not sure the development staff does either since only beta-test sites have seen this so far) is to define a character to have the following attributes: A character set A code within the character set Bits Style The character set and code within character set is roughly char-code. Bits are as per CLtL. Style is a symbolic notion of what the characters LOOK like, for example, bold, italic, small, very-large, fixed width, etc, and combinations. A "font" is a set of glyphs. A font is mapped to by the triple character-set, style and output device. Let me dramatize for a second to make a point. I don't see "size", "rotation", "shading", "projection", "mask", "color",... why don't we just put TROFF in format macros and throw that in too. This would give us a full composition language.... Now don't get me wrong. I agree completely with the MOTIVATION for the new symbolics way of representing characters. It acknowledges that characters are complex objects having lots of relative attributes, etc., and that quick little hacks with font "bits" and numbers up to some limit won't work for real high-quality output. However, I see no reason for this to become part of a language standard. The users of common lisp are NOT primarily typographers. High quality screen output should be discussed w.r.t. a window system standard. (Note: there seems to be no de-facto standard here.) High quality printer output should be discussed w.r.t. an output device standard. (Note: there are two emerging standards here... Postscript and Interpress. Trademarks of somebody...) Without these notions, having "font" information is just clutter in the language. Concretely. I think char-font-limit = 1, (char-font ) = 0 should always be the case, and that ultimately we should drop the font concept from the language. (like I said, I agree vehemently...) ...mike beckerle Gold Hill Computers  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Aug 86 23:44:11 EDT Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 20:28:13 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 8026; 25 Aug 86 23:31:36-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37859; Mon 25-Aug-86 22:58:50-EDT Date: Mon, 25 Aug 86 23:09 EST Sender: mike%gold-hill-acorn@mit-live-oak.arpa To: RAM@C.CS.CMU.EDU From: mike%acorn@mit-live-oak.arpa Subject: More words on the scoping of declarations Cc: Pavel.pa@XEROX.COM, Common-Lisp@SU-AI.ARPA Date: Mon, 18 Aug 1986 13:56 EDT From: Rob MacLachlan ..... It is evident that you do have a theory of variable binding, but you don't really attempt to formalize it to the point where declartion semantics becomes obvious. You theory is based on the idea that declaration scoping should follow the same scope rules as variables. It is a property of this theory that a declaration for a specific name cannot refer to multipel variables which have the same name. So far as the application of the theory goes, the main problem that I see is with LET* and possibly other places where sequential bindings happen. It is not obvious to me what the scope of delcarations in LET* should be, even if we disallow repeated variable names. The scoping of a declaration in a let* should be as close as possible to that of a let. I think repeated names should be allowed, and the innermost one should be the one to which the declaration applies. (let* ((a (foo a)) (b a) (a 7)) (declare (type fixnum a) (type frobboz b)) ...a...b...) The only "a" which is a fixnum here is the one which gets the value 7. Semantically, the form should be equivalent to: (let ((a (foo a))) (let ((b a)) (declare (type frobboz b)) (let ((a 7)) (declare (type fixnum a)) ... a ...b..) This means that the semantics of declaration in let* is exactly as if you moved the declarations up into a nested let construct, except for the case of a repeated identifier, where the innermost name is the one the declaration applies to. There are of course ambiguous cases where expressing exactly the declarations you want requires breaking up a let* into two nested let*'s so that you can stick a declare in between. I don't see this as a tragedy. It's still better than the situation in most programming languages, where the names of identifiers are often chosen to reflect their type...... In summary, two things. (1) I think Pavel's proposal is right. (2) I think the "theory" should be extended to reflect the "innermost" principle for sequential binding constructs. ...mike beckerle Gold Hill Computers  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Aug 86 19:12:26 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86 10:59:27 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67941; Mon 25-Aug-86 13:54:56 EDT Date: Mon, 25 Aug 86 13:54 EDT From: David A. Moon Subject: Defstruct and Documentation. To: James Rice cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <12232348944.62.RICE@SUMEX-AIM.ARPA> Message-ID: <860825135423.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed 20 Aug 86 09:59:37-PDT From: James Rice I agree that doc string should be allowed in ALL defstruct generated functions. I also think that Declarations should be allowed. There may well be good reasons for wanting to (declare (optimize (safety 3) (speed 0))). Particularly whilst debugging. Shouldn't that be done as (locally (declare (optimize (safety 3) (speed 0))) (defstruct ...)) or (proclaim '(optimize (safety 3) (speed 0))) ?  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Aug 86 15:20:38 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 11:57:59 PDT Received: ID ; Mon 25 Aug 86 14:56:53-EDT Date: Mon, 25 Aug 1986 14:56 EDT Message-ID: From: Rob MacLachlan To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: question about subtypep In-reply-to: Msg of 25 Aug 1986 14:02-EDT from David A. Moon Date: Monday, 25 August 1986 14:02-EDT From: David A. Moon Date: Thu, 14 Aug 1986 06:51 EDT From: Rob MacLachlan Although (THE SHORT-FLOAT 1F0) is quite legal in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are identical, it would be reasonable for the compiler to give a warning anyway. Applications that care about this sort of thing will have to use a variant version of subtypep that is distinct from the real SUBTYPEP. They'll have to do more than that. If the user wrote (THE SHORT-FLOAT 1s0) it would read as exactly the same Lisp object as (THE SHORT-FLOAT 1f0) in an implementation where SHORT-FLOAT and SINGLE-FLOAT are identical, so I don't see how the compiler could distinguish these and give a warning for one but not for the other. I realized this was a bad example after I sent the message. Instead 1F0, substitute . For example, (THE SHORT-FLOAT (THE SINGLE-FLOAT ...)). Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Aug 86 14:33:23 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86 11:05:11 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67948; Mon 25-Aug-86 14:03:19 EDT Date: Mon, 25 Aug 86 14:02 EDT From: David A. Moon Subject: question about subtypep To: Rob MacLachlan cc: SANDRA , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860825140245.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 14 Aug 1986 06:51 EDT From: Rob MacLachlan Note there are some possible users of SUBTYPEP that would prefer answers to be based on some hypothetical maximally restrictive type system. The main example is a compiler which does compile-time type checking when possible. Although (THE SHORT-FLOAT 1F0) is quite legal in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are identical, it would be reasonable for the compiler to give a warning anyway. Applications that care about this sort of thing will have to use a variant version of subtypep that is distinct from the real SUBTYPEP. They'll have to do more than that. If the user wrote (THE SHORT-FLOAT 1s0) it would read as exactly the same Lisp object as (THE SHORT-FLOAT 1f0) in an implementation where SHORT-FLOAT and SINGLE-FLOAT are identical, so I don't see how the compiler could distinguish these and give a warning for one but not for the other. My intpretation (based on intensive meditation and reading of scripture) is that SUBTYPEP returns information about the actual subtype relations in your implementation. I agree. I think that's the only consistent interpretation.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 25 Aug 86 14:33:00 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86 11:15:55 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67962; Mon 25-Aug-86 14:13:20 EDT Date: Mon, 25 Aug 86 14:12 EDT From: David A. Moon Subject: Re: synonym streams.. To: common-lisp@SU-AI.ARPA In-Reply-To: <8608182223.AA19698@fizzy>, <12231905873.61.HEDRICK@RED.RUTGERS.EDU>, <12232095191.66.ACUFF@SUMEX-AIM.ARPA>, <860819152419.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, <524862532/bein@pyramid> Message-ID: <860825141247.8.MOON@EUPHRATES.SCRC.Symbolics.COM> I believe all of these problems would go away if programmers would follow the rule that the same module that opens (or otherwise creates) a stream is responsible for closing (or otherwise disposing of) it. This seems eminently simple and sensible, and has worked well for us for many years.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 22 Aug 86 17:37:49 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86 13:32:43 PDT Received: from Godot.Think.COM by MC.LCS.MIT.EDU 22 Aug 86 14:09:45 EDT Received: from SEBASTIAN.THINK.COM by Godot.Think.COM; Fri, 22 Aug 86 14:05:52 edt Date: Fri, 22 Aug 86 14:06 EDT From: Guy Steele Subject: 1986 Lisp conference bibliography To: common-lisp@SU-AI.ARPA, rrrs-authors@MC.LCS.MIT.EDU Cc: gls@AQUINAS Message-Id: <860822140628.4.GLS@SEBASTIAN.THINK.COM> With the help of Bill Scherlis, I have massaged the table of contents (with some corrections) for the 1986 ACM Conference on Lisp and Functional Programming into the form of a bibliography database suitable for use with LaTeX/BibTeX and (almost) SCRIBE. The database has been tested with BibTeX, and uses TeX conventions for forcing capitalization and for accenting characters (there are three accents acute, one umlaut, and one "i" with a circumflex over it). The database should require only slight modification to make it suitable for use with SCRIBE. I am mailing out the database in the interest of making it easier for everyone to refer to all these great papers from the conference. The database follows at the end of this message, followed by the BibTeX transcription of it for a bibliography format very similar to that required by CACM. (I considered just mailing out a pointer to an FTP-able file, but I find that in practice this method is rather clumsy and people don't use it.) --Guy ---------------------------------------------------------------- @InProceedings(LAWS-IN-MIRANDA ,Key = "Thompson" ,Author = "Simon Thompson" ,Title = "Laws in {M}iranda" ,Pages = "1-12" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(MINI-ML ,Key = "Clement" ,Author = "Dominique Cl\'ement and {Jo\"elle} Despeyroux and Thierry Despeyroux and Gilles Kahn" ,Title = "A Simple Applicative Language: {M}ini-{ML}" ,Pages = "13-27" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING ,Key = "Gifford" ,Author = "David K. Gifford and John M. Lucassen" ,Title = "Integrating Functional and Imperative Programming" ,Pages = "28-38" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EXPERIENCE-WITH-AN-UNCOMMON-LISP ,Key = "Alberga" ,Author = "Cyril N. Alberga and Chris Bosman-Clark and Martin Mikelsons and Mary S. Van Deusen and Julian Padget" ,Title = "Experience with an Uncommon {L}isp" ,Pages = "39-53" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP ,Key = "Padget" ,Author = "Julian Padget and others" ,Title = "Desiderata for the Standardisation of {L}isp" ,Pages = "54-66" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP ,Key = "Brooks" ,Author = "Rodney A. Brooks and David B. Posner and James L. McDonald and Jon L. White and Eric Benson and Richard P. Gabriel" ,Title = "Design of an Optimizing, Dynamically Retargetable Compiler for {C}ommon {L}isp" ,Pages = "67-85" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(IMPLEMENTATION-OF-PC-SCHEME ,Key = "Bartley" ,Author = "David H. Bartley and John C. Jensen" ,Title = "The Implementation of {PC} {S}cheme" ,Pages = "86-93" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES ,Key = "Fairbairn" ,Author = "Jon Fairbairn and Stuart C. Wray" ,Title = "Code Generation Techniques for Functional Languages" ,Pages = "94-104" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES ,Key = "Knight" ,Author = "Tom Knight" ,Title = "An Architecture for Mostly Functional Languages" ,Pages = "105-112" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION ,Key = "Lemaitre" ,Author = "M. Lema\^\itre and M. Castan and M.-H. Durand and G. Durrieu and B. Lecussan" ,Title = "Mechanisms for Efficient Multiprocessor Combinator Reduction" ,Pages = "113-121" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CURRY-CHIP ,Key = "Ramsdell" ,Author = "John D. Ramsdell" ,Title = "The {CURRY} Chip" ,Pages = "122-131" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(VARIATIONS-ON-STRICTNESS-ANALYSIS ,Key = "Bloss" ,Author = "Adrienne Bloss and Paul Hudak" ,Title = "Variations on Strictness Analysis" ,Pages = "132-142" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EXPANSION-PASSING-STYLE ,Key = "Dybvig" ,Author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes" ,Title = "Expansion-Passing Style: Beyond Conventional Macros" ,Pages = "143-150" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(HYGIENIC-MACRO-EXPANSION ,Key = "Kohlbecker" ,Author = "Eugene Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba" ,Title = "Hygienic Macro Expansion" ,Pages = "151-161" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EXACT-REAL-ARITHMETIC ,Key = "Boehm" ,Author = "Hans-J. Boehm and Robert Cartwright and Mark Riggle and Michael J. O'Donnell" ,Title = "Exact Real Arithmetic: A Case Study in Higher Order Programming" ,Pages = "162-173" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(RECONFIGURABLE-RETARGETABLE-BIGNUMS ,Key = "White" ,Author = "Jon L. White" ,Title = "Reconfigurable, Retargetable Bignums: A Case Study in Efficient, Portable {L}isp System Building" ,Pages = "174-191" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR ,Key = "Steenkiste" ,Author = "Peter Steenkiste and John Hennessy" ,Title = "{L}isp on a Reduced-Instruction-Set-Processor" ,Pages = "192-201" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW ,Key = "Sarkar" ,Author = "Vivek Sarkar and John Hennessy" ,Title = "Partitioning Parallel Programs for Macro-Dataflow" ,Pages = "202-211" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(NORMA-GRAPH-REDUCTION-PROCESSOR ,Key = "Scheevel" ,Author = "Mark Scheevel" ,Title = "{NORMA}: A Graph Reduction Processor" ,Pages = "212-219" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(FOUR-STROKE-REDUCTION-ENGINE ,Key = "Clack" ,Author = "Chris Clack and Simon L. Peyton Jones" ,Title = "The Four-Stroke Reduction Engine" ,Pages = "220-232" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS ,Key = "Lee" ,Author = "Peter Lee and Uwe Pleban" ,Title = "On the Use of {L}isp in Implementing Denotational Semantics" ,Pages = "233-248" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES ,Key = "Nielson" ,Author = "Hanne R. Nielson and Flemming Nielson" ,Title = "Semantics Directed Compiling for Functional Languages" ,Pages = "249-257" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CONNECTION-GRAPHS ,Key = "Bawden" ,Author = "Alan Bawden" ,Title = "Connection Graphs" ,Pages = "258-265" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE ,Key = "Mauny" ,Author = "Michel Mauny and Asc\'ander Su\'arez" ,Title = "Implementing Functional Languages in the Categorical Abstract Machine" ,Pages = "266-278" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(CONNECTION-MACHINE-LISP ,Key = "Steele" ,Author = "Steele, Guy L., Jr. and W. Daniel Hillis" ,Title = "Connection Machine LISP: Fine-Grained Parallel Symbolic Processing" ,Pages = "279-297" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(MYSTERY-OF-THE-TOWER-REVEALED ,Key = "Wand" ,Author = "Mitchell Wand and Daniel P. Friedman" ,Title = "The Mystery of the Tower Revealed: A Non-Reflective Description of the Reflective Tower" ,Pages = "298-307" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS ,Key = "Mitchell" ,Author = "John C. Mitchell" ,Title = "A Type-Inference Approach to Reduction Properties and Semantics of Polymorphic Expressions (summary)" ,Pages = "308-319" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(EQUATIONS-SETS-AND-REDUCTION-SEMANTICS ,Key = "Jayaraman" ,Author = "Bharat Jayaraman and Frank S. K. Silbermann" ,Title = "Equations, Sets, and Reduction Semantics for Functional and Logic Programming" ,Pages = "320-331" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES ,Key = "Thatte" ,Author = "Satish R. Thatte" ,Title = "Towards a Semantic Theory for Equational Programming Languages" ,Pages = "332-342" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING ,Key = "Lermen" ,Author = "Claus-Werner Lermen and Dieter Maurer" ,Title = "A Protocol for Distributed Reference Counting" ,Pages = "343-350" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION ,Key = "Hudak" ,Author = "Paul Hudak" ,Title = "A Semantic Model of Reference Counting and its Abstraction (detailed summary)" ,Pages = "351-363" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") @InProceedings(DISTRIBUTED-COPYING-GARBAGE-COLLECTION ,Key = "Rudalics" ,Author = "Martin Rudalics" ,Title = "Distributed Copying Garbage Collection" ,Pages = "364-372" ,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming" ,Organization = "ACM SIGPLAN/SIGACT/SIGART" ,Year = "1986" ,Month = Aug ,Address = "Cambridge, Massachusetts") ---------------------------------------------------------------- \bibitem{EXPERIENCE-WITH-AN-UNCOMMON-LISP} Alberga, Cyril N., Bosman-Clark, Chris, Mikelsons, Martin, Deusen, Mary S. Van, and Padget, Julian. Experience with an uncommon {L}isp. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 39--53. \bibitem{IMPLEMENTATION-OF-PC-SCHEME} Bartley, David H., and Jensen, John C. The implementation of {PC} {S}cheme. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 86--93. \bibitem{CONNECTION-GRAPHS} Bawden, Alan. Connection graphs. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 258--265. \bibitem{VARIATIONS-ON-STRICTNESS-ANALYSIS} Bloss, Adrienne, and Hudak, Paul. Variations on strictness analysis. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 132--142. \bibitem{EXACT-REAL-ARITHMETIC} Boehm, Hans-J., Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J. Exact real arithmetic: a case study in higher order programming. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 162--173. \bibitem{OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP} Brooks, Rodney A., Posner, David B., McDonald, James L., White, Jon L., Benson, Eric, and Gabriel, Richard P. Design of an optimizing, dynamically retargetable compiler for {C}ommon {L}isp. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 67--85. \bibitem{FOUR-STROKE-REDUCTION-ENGINE} Clack, Chris, and Jones, Simon L. Peyton. The four-stroke reduction engine. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 220--232. \bibitem{MINI-ML} Cl\'ement, Dominique, Despeyroux, {Jo\"elle}, Despeyroux, Thierry, and Kahn, Gilles. A simple applicative language: {M}ini-{ML}. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 13--27. \bibitem{EXPANSION-PASSING-STYLE} Dybvig, R. Kent, Friedman, Daniel P., and Haynes, Christopher T. Expansion-passing style: beyond conventional macros. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 143--150. \bibitem{CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES} Fairbairn, Jon, and Wray, Stuart C. Code generation techniques for functional languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 94--104. \bibitem{INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING} Gifford, David K., and Lucassen, John M. Integrating functional and imperative programming. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 28--38. \bibitem{SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION} Hudak, Paul. A semantic model of reference counting and its abstraction (detailed summary). In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 351--363. \bibitem{EQUATIONS-SETS-AND-REDUCTION-SEMANTICS} Jayaraman, Bharat, and Silbermann, Frank S. K. Equations, sets, and reduction semantics for functional and logic programming. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 320--331. \bibitem{ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES} Knight, Tom. An architecture for mostly functional languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 105--112. \bibitem{HYGIENIC-MACRO-EXPANSION} Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce. Hygienic macro expansion. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 151--161. \bibitem{USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS} Lee, Peter, and Pleban, Uwe. On the use of {L}isp in implementing denotational semantics. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 233--248. \bibitem{EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION} Lema\^\itre, M., Castan, M., Durand, M.-H., Durrieu, G., and Lecussan, B. Mechanisms for efficient multiprocessor combinator reduction. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 113--121. \bibitem{PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING} Lermen, Claus-Werner, and Maurer, Dieter. A protocol for distributed reference counting. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 343--350. \bibitem{IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE} Mauny, Michel, and Su\'arez, Asc\'ander. Implementing functional languages in the categorical abstract machine. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 266--278. \bibitem{TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS} Mitchell, John C. A type-inference approach to reduction properties and semantics of polymorphic expressions (summary). In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 308--319. \bibitem{SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES} Nielson, Hanne R., and Nielson, Flemming. Semantics directed compiling for functional languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 249--257. \bibitem{DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP} Padget, Julian, et al. Desiderata for the standardisation of {L}isp. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 54--66. \bibitem{CURRY-CHIP} Ramsdell, John D. The {CURRY} chip. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 122--131. \bibitem{DISTRIBUTED-COPYING-GARBAGE-COLLECTION} Rudalics, Martin. Distributed copying garbage collection. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 364--372. \bibitem{PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW} Sarkar, Vivek, and Hennessy, John. Partitioning parallel programs for macro-dataflow. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 202--211. \bibitem{NORMA-GRAPH-REDUCTION-PROCESSOR} Scheevel, Mark. {NORMA}: a graph reduction processor. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 212--219. \bibitem{CONNECTION-MACHINE-LISP} Steele, Jr., Guy L., and Hillis, W. Daniel. Connection machine lisp: fine-grained parallel symbolic processing. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 279--297. \bibitem{LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR} Steenkiste, Peter, and Hennessy, John. {L}isp on a reduced-instruction-set-processor. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 192--201. \bibitem{SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES} Thatte, Satish R. Towards a semantic theory for equational programming languages. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 332--342. \bibitem{LAWS-IN-MIRANDA} Thompson, Simon. Laws in {M}iranda. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 1--12. \bibitem{MYSTERY-OF-THE-TOWER-REVEALED} Wand, Mitchell, and Friedman, Daniel P. The mystery of the tower revealed: a non-reflective description of the reflective tower. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 298--307. \bibitem{RECONFIGURABLE-RETARGETABLE-BIGNUMS} White, Jon L. Reconfigurable, retargetable bignums: a case study in efficient, portable {L}isp system building. In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}. ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 174--191.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 20 Aug 86 14:10:31 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 86 10:40:33 PDT Date: Wed 20 Aug 86 09:59:37-PDT From: James Rice Subject: Defstruct and Documentation. To: Common-Lisp@SU-AI.ARPA Message-ID: <12232348944.62.RICE@SUMEX-AIM.ARPA> I agree that doc string should be allowed in ALL defstruct generated functions. I also think that Declarations should be allowed. There may well be good reasons for wanting to (declare (optimize (safety 3) (speed 0))). Particularly whilst debugging. Rice. -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 20 Aug 86 08:50:04 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 Aug 86 05:40:36 PDT Received: from FIREBIRD.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5857; Wed 20-Aug-86 08:40:10 EDT Date: Wed, 20 Aug 86 08:40 EDT From: David C. Plummer Subject: "fonted" characters in CL To: Common-Lisp@SU-AI.ARPA In-Reply-To: <860802175500.1.DCP@FIREBIRD.S4CC.Symbolics.COM> Message-ID: <860820084000.8.DCP@FIREBIRD.S4CC.Symbolics.COM> I propose we eliminate char-font-limit and the associated concepts from the language. Either that or make the specification considerably more tight and detailed saying how >numeric< values are interpreted. Either that, or specify some >symbolic< notion of "fonts" we can live with. Symbolics found that the CL notion of "fonts" is not very portable, nor is it very useful. Therefore, char-font-limit => 1 and (char-font ) =always=> 0. This is in accordance with CLtL, but it doesn't help us move code to other Common Lisp implementations, and it doesn't help others port to our system. What we have done instead (note I don't want to push this and I'm not sure the development staff does either since only beta-test sites have seen this so far) is to define a character to have the following attributes: A character set A code within the character set Bits Style The character set and code within character set is roughly char-code. Bits are as per CLtL. Style is a symbolic notion of what the characters LOOK like, for example, bold, italic, small, very-large, fixed width, etc, and combinations. A "font" is a set of glyphs. A font is mapped to by the triple character-set, style and output device. There are probably some lies in this description; our documentation is clearer and more verbose. My point is that the current numbering scheme is a holdover from 1970's text formatters (TJ6, R, etc) and the simplistic mapping of those to the MIT Lisp Machines editor buffers. The numbers in those systems are relative to something; the numbers in CLtL aren't relative to anything. Those ideas don't hold in real production systems.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 19 Aug 86 21:53:42 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 86 18:40:32 PDT Received: ID ; Tue 19 Aug 86 21:38:44-EDT Date: Tue, 19 Aug 1986 21:38 EDT Message-ID: From: Rob MacLachlan To: "S. Sridhar" Cc: common-lisp@SU-AI.ARPA Subject: documentation strings in BOA constructors ? In-reply-to: Msg of 19 Aug 1986 17:23-EDT from S. Sridhar Date: Tuesday, 19 August 1986 17:23-EDT From: S. Sridhar Re: documentation strings in BOA constructors ? Suppose you have : (defstruct (point (:constructor make-point (x y) "this makes a point")) x y) I think it clear that this is illegal and that there is no way to specify doc strings in DEFSTRUCT. Although a possible area for extensions, it not a big problem since SETF of DOCUMENTATION can be used to given function documentation to any function. If we were to extend DEFSTRUCT so that the functions could be directly documented, then the extension should apply to *all* defstruct generated functions, and not just BOA constructors. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 19 Aug 86 21:42:00 EDT Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 19 Aug 86 18:27:25 PDT Received: from tektronix by csnet-relay.csnet id ae12858; 19 Aug 86 18:43 EDT Received: by tektronix.TEK (5.31/6.16) id AA29746; Tue, 19 Aug 86 14:22:27 PDT Received: by tekecs.GWD.TEK (5.16/6.16) id AA03925; Tue, 19 Aug 86 14:23:25 PDT From: "S. Sridhar" Message-Id: <8608192123.AA03925@tekecs.GWD.TEK> Date: Tue, 19 Aug 86 14:23:23 PDT To: common-lisp@SU-AI.ARPA Subject: documentation strings in BOA constructors ? Suppose you have : (defstruct (point (:constructor make-point (x y) "this makes a point")) x y) There is no mention on page315-316 in CltL about having documentation strings for such functions. Our implementation does: (documentation 'make-point 'function) => nil. What should the "correct" behaviour be? --sridhar  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 19 Aug 86 19:22:06 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 19 Aug 86 15:55:49 PDT Received: by hplabs.HP.COM ; Tue, 19 Aug 86 15:54:54 pdt Received: by pyramid (5.51/3.14) id AA20141; Tue, 19 Aug 86 12:52:19 PDT Date: 19 Aug 1986 12:52 PDT From: David Bein Subject: streams ... To: common-lisp@su-ai Message-Id: <524862532/bein@pyramid> Sorry for all the confusion. Now for a fresh batch. My questions are motivated by what is supposed to happen when a stream which is composed of other streams runs into one of the standard streams (e.q. original *standard-input*,*standard-output*, or *terminal-io*). Note that I am assuming that it is erroneous to bash the original streams. I do not know whether it should cause an error or simply do nothing. My feeling is that either is desirable at different times. I also can imagine cases where one explicitly wants to bash one of the original streams. Any interactive error/query system ought to be able to throw its hands up when someone closes *terminal-io*. My proposal for handling this mess without forcing true believers on either side of the question is: (1) Provide a stream operation which marks a stream as "NEVER-CLOSE". When CLOSE (either directly or via a CLOSE on some composed stream) hits one of these it ignores it and returns. We could designate this as a "DINER" stream since it is always open. (2) Provide a stream operation which marks a stream as "COMPLAIN-IF-CLOSED". When CLOSE (same conditions as above) hits one of these it flames out and causes an error. Any stream which has neither of these attributes is fair game for closing either directly or via recursion. Both options may of course be turned off if a user desires it. Establish well-defined defaults for any of the standard streams so that one can write "portable" code. Perhaps neither attribute should be on when a stream is created. Of course this does not help much when *terminal-io* appears out of nowhere as far as any user is concerned. I agree with those people who believe a close on a composed-stream (echo,synonym,two-way,concatenated,broadcast) should render the top level stream unusable. While on the subject, I think that it would be reasonable to be able to query a composed stream. It would also be reasonable to make the various kinds of streams be distinct types (each a subtyp of STREAM) so the typing system could help differentiate between the streams. Of course we will have to draw some distinction between "portable" streams and all the other kinds which implementers have added. More food for thought -- what do people think is reasonable to do with *terminal-io* if the process is running without any kind of connection to an interactive device? I have seen different approaches. I personally like the idea that use of *terminal-io* when no kind of interactive device exists should cause some kind of merciless death. This has implications for error/query systems of course. --David  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 19 Aug 86 16:00:55 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Aug 86 12:40:33 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83435; Tue 19-Aug-86 15:24:50 EDT Date: Tue, 19 Aug 86 15:24 EDT From: Kent M Pitman Subject: close on synonym streams, etc To: HEDRICK@RED.RUTGERS.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <12231905873.61.HEDRICK@RED.RUTGERS.EDU> Message-ID: <860819152419.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 18 Aug 86 20:25:45 EDT From: Charles Hedrick ... I could conceive of implementations where buffering is done in each stream. In that case, it might be a good idea to close a synonym or broadcast stream, in order to make sure that any buffered characters are taken care of and any cleanup is done. It looks to me like this issue is adequately addressed by the presence of FINISH-OUTPUT and FORCE-OUTPUT. Perhaps the documentation could be clearer on that point. ... If you intend to outlaw close on one of these composite streams, then you should mention this fact clearly where synonym and broadcast streams are defined, and note that this means that they must be implemented in such a way that a close is not required when you are finished using them. Indeed, the documentation should be clear about these points. It seems to me, however, that the only point to CLOSE is that it allows the freeing of things like operating system "channels" which are often critical resources. In that respect, it's like a fast GC. If they weren't critical resources, I assume we'd just drop pointers to streams and let the GC take care of straightening out the resources in its own sweet time. Since echo and broadcast streams are presumably just lisp objects which have slots containing other streams, I see no reason to worry about fast GC of them. Statistically, I bet their components will tend to (not really coincidentally) get closed anyway by other mechanisms. eg, consider: (WITH-OPEN-FILE (FILE-STREAM ...) (LET ((ECHO-STREAM (MAKE-ECHO-STREAM STREAM *TERMINAL-IO*))) ...)) The file stream will get closed fine by the WITH-OPEN-FILE. The echo stream (holding the closed file stream) will eventually get cleaned up by the GC. That should be fine. No one's going to miss the couple of conses which is presumably the only resource being used in the meantime. It's true that there may be certain situations where you might think you want ECHO-STREAM-P, ECHO-STREAM-INPUT-STREAM, and ECHO-STREAM-OUTPUT-STREAM operations in order to clean up the loose ends. Eg, you might have done: (DEFVAR *ECHO-STREAM* (MAKE-ECHO-STREAM (OPEN ...) *TERMINAL-IO*)) and maybe you later want to close the encapsulated real stream, but my feeling is that it was so easy for you to have done: (DEFVAR *FILE-STREAM* (OPEN ...)) (DEFVAR *ECHO-STREAM* (MAKE-ECHO-STREAM *FILE-STREAM* *TERMINAL-IO*)) that there just isn't any way to claim that the language didn't let you do what you wanted to do. In fact, if someone else wrote the module that gave you the pointer to the echo stream and that person wouldn't give you the encapsulated stream, maybe it was for a reason. If so, you're asking a lot by claiming it should be ok to be closing that encapsulated stream...  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 19 Aug 86 13:53:22 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 86 10:45:33 PDT Date: Tue 19 Aug 86 10:45:43-PDT From: Richard Acuff Subject: Re: synonym streams.. To: franz!fizzy!jkf@KIM.BERKELEY.EDU, ucbkim!Xerox.COM!Masinter.pa@KIM.BERKELEY.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <8608182223.AA19698@fizzy> Message-ID: <12232095191.66.ACUFF@SUMEX-AIM.ARPA> I agree with John that making it an error to close an active stream of any sort is a mistake, since the closing code may have picked up the stream anywhere and not know its nature. What are the arguments against CLOSE closing the actual stream passed to it, leaving any underlying streams alone? The only one I can think of is the desire to close those underlying streams as well, which indicates a potential need for a mechanism to recover embedded streams. -- Rich -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Aug 86 21:32:57 EDT Received: from [128.32.130.7] by SAIL.STANFORD.EDU with TCP; 18 Aug 86 18:25:39 PDT Received: by kim.Berkeley.EDU (5.53/1.16) id AA01094; Mon, 18 Aug 86 18:26:34 PDT From: franz!fizzy!jkf@kim.Berkeley.EDU Received: from fizzy by franz (5.5/3.14) id AA11103; Mon, 18 Aug 86 15:22:33 PDT Received: by fizzy (4.12/3.14) id AA19698; Mon, 18 Aug 86 15:23:02 pdt Return-Path: Message-Id: <8608182223.AA19698@fizzy> To: ucbkim!Xerox.COM!Masinter.pa Cc: common-lisp@su-ai.arpa Subject: Re: synonym streams.. In-Reply-To: Your message of 05 Aug 86 11:09:00 PDT. <860805-111034-2460@Xerox> Date: Mon, 18 Aug 86 15:22:59 PDT >> Date: 5 Aug 86 11:09 PDT >> From: franz!ucbkim!Xerox.COM!Masinter.pa >> I propose the following rule: "It is an error to attempt to close a >> stream that wasn't created with open." >> With this rule, it would follow that, since synonym, broadcast and >> two-way streams are not created with open, it is an error to perform >> "close" on them. [sorry for the delay in the reply, this is the first chance I've had to reply] This topic was brought up in this mailing list on Aug 21, 1985 and discussed at great length on Sept 7, 1985. My feeling was then and is still now that closing a synonym stream is legal, and that the only effect is that read and writes to the closed synonym stream will cause an error to be signaled. [At the time the only other possibility discussed was that closing a synonym stream would cause the stream that it was a synonym of to be closed as well. No one has brought this option up so I assume that either it has no backers or else they are on vacation]. Suppose I have a function which takes a stream and reads and processes data from that stream and when an eof is seen, it closes the stream and returns. What is to be gained by my program having to know about synonym streams and having to check that it wasn't a synonym stream passed in before it does a close? I would like my function to be able to accept input from *standard-input* by having my program create a synonym stream (call it X) for *standard-input* and passing it to the function. When my function closes X, that should be ok, and it shouldn't affect *standard-input* (or *terminal-io*, if *standard-input* is a synonym for *terminal-io*). -john foderaro Franz Inc.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Aug 86 20:33:59 EDT Received: from RED.RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 17:25:40 PDT Date: 18 Aug 86 20:25:45 EDT From: Charles Hedrick Subject: close on synonym streams, etc To: common-lisp@SU-AI.ARPA Message-ID: <12231905873.61.HEDRICK@RED.RUTGERS.EDU> I would think that it would be legal to close a synonym stream, broadcast stream, etc., but that this close would affect only the synonym stream, as opposed to the stream it points to. I could conceive of implementations where buffering is done in each stream. In that case, it might be a good idea to close a synonym or broadcast stream, in order to make sure that any buffered characters are taken care of and any cleanup is done. It should be an error to do any I/O operation on a stream that has been closed. If you intend to outlaw close on one of these composite streams, then you should mention this fact clearly where synonym and broadcast streams are defined, and note that this means that they must be implemented in such a way that a close is not required when you are finished using them. -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Aug 86 18:13:38 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 18 Aug 86 14:58:53 PDT Date: Mon, 18 Aug 86 17:58 EDT From: DCP@QUABBIN.SCRC.Symbolics.COM Sender: File-Server@DIAMOND.S4CC.Symbolics.COM Subject: string-/=, etc. To: common-lisp@SU-AI.ARPA Supersedes: <860808175848.1.DCP@FIREBIRD.S4CC.Symbolics.COM> Comments: Retransmission of failed mail. Message-ID: <860818175815.4.FILE-SERVER@DIAMOND.S4CC.Symbolics.COM> Page 301 is slightly ambiguous. If you read it carefully, some parts imply it is a relative index ("...then the result is the index within the strings..." and "put another way, the result is the length of the logest common prefix...") but other parts imply it is absolute ("The index returned in case of a mistmatch is an index into /string1/.") The last sentence on the page is the real clincher, but is said much too late and the almost-relative wording. [In hindsight, some of us may think the answer should be relative to the beginning of the specified substrings, not absolute in string1, but that's incompatible and probably too incompatible.]  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 18 Aug 86 14:17:55 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 11:01:09 PDT Received: ID ; Mon 18 Aug 86 14:01:05-EDT Date: Mon, 18 Aug 1986 13:56 EDT Message-ID: From: Rob MacLachlan To: Pavel.pa@XEROX.COM Cc: Common-Lisp@SU-AI.ARPA Subject: More words on the scoping of declarations In-reply-to: Msg of 14 Aug 1986 17:11-EDT from Pavel.pa at Xerox.COM I think that I like the substance of your proposal for declaration scoping, but I have some misgivings about the way that you have expressed it. In your definition, you attempt to simply define all interactions between all forms where declarations can appear and all code that can appear in them. This approach attempts to deny the need for a theory of declaration scoping. Such a theory would give people a model for understanding how things work, and would also enforce some sort of consistency in the definition. It is evident that you do have a theory of variable binding, but you don't really attempt to formalize it to the point where declartion semantics becomes obvious. You theory is based on the idea that declaration scoping should follow the same scope rules as variables. It is a property of this theory that a declaration for a specific name cannot refer to multipel variables which have the same name. So far as the application of the theory goes, the main problem that I see is with LET* and possibly other places where sequential bindings happen. It is not obvious to me what the scope of delcarations in LET* should be, even if we disallow repeated variable names. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 15 Aug 86 10:43:51 EDT Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 15 Aug 86 07:34:18 PDT Full-Name: C. Vanessa Fong Message-Id: <8608151424.AA21531@mitre.ARPA> Organization: The MITRE Corp., Washington, D.C. To: common-lisp@su-ai.ARPA Subject: drop out Date: Fri, 15 Aug 86 10:24:33 -0500 From: Vanessa Fong Please delete my name from your distribution list. Thanks! C. Vanessa Fong (cvfong@mitre.arpa)  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Aug 86 19:18:50 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 15:59:44 PDT Received: ID ; Thu 14 Aug 86 18:57:21-EDT Date: Thu, 14 Aug 1986 18:57 EDT Message-ID: From: Rob MacLachlan To: Pavel.pa@XEROX.COM Cc: Common-Lisp@SU-AI.ARPA Subject: More words on the scoping of declarations (FTYPE) In-reply-to: Msg of 14 Aug 1986 17:11-EDT from Pavel.pa at Xerox.COM My reading of the manual supports the claim that FTYPE is not symmetrical with TYPE. TYPE may only be used with a binding, while FTYPE is shown in examples as being used "pervasively" on a global identifier. If FTYPE was in fact like TYPE, then you couldn't use it at all, since currently no declarations are allowed in functional binding forms. Whether this is desirable is another point altogether. We should probably clean up this gratuitous inconsistency if we are going to make sweeping changes to the declaration scoping rules. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Aug 86 18:10:03 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 86 14:43:47 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 14 AUG 86 14:11:51 PDT Date: 14 Aug 86 14:11 PDT From: Pavel.pa@Xerox.COM Subject: More words on the scoping of declarations In-reply-to: NGALL@G.BBN.COM's message of 19 Jul 86 17:17 EDT To: Common-Lisp@SU-AI.ARPA Message-ID: <860814-141151-4806@Xerox> Having been gone for three weeks, I was unable to properly defend my proposal on the scoping of declarations. Although I've been back for three days now, I have only now finished reading the incredible torrent of mail spewed out over that time. I therefore ask for your indulgence as I refer to messages now more than 25 days old. I have included contextual excerpts for those of you who haven't just read it all at once. Date: 19 Jul 86 17:17 EDT From: NGALL@G.BBN.COM Date: 11 Jul 86 18:43 PDT From: Pavel.pa@Xerox.COM In this message I will give a complete description of my proposal for declaration scoping. I won't attempt to argue for it on the basis of ``obviousness'' or clarity, though, because I think that there are people who find each of the two ways of scoping special declarations confusing. Rather, I like this way of doing things because it satisfies an important (to me) consistency criterion: the scope of \any/ declaration coincides with a particular lexical identifier scope. I don't think you mean 'any' here; I think you mean 'any declaration that concerns the bindings of variables' (cf. pg. 154). You cannot mean 'any' since in the example below (let ((x 1)) (declare (inline foo)) (foo x)) the declaration does not 'coincide with a particular lexical identifier scope.' A more extreme example is (let (...) (declare (optimize ...)) ...) in which the declaration does not refer to ANY named entity. Being a disciple of the Mad Hatter, I said what I meant and meant what I said. A declaration need not refer to a named entity in order to share that entity's scope. In the second example you gave, the OPTIMIZE declaration applies to the bindings made in the LET and to all code in the body of the LET. Thus, if we were asking to optimize speed at the expense of space, the compiler would be encouraged to bind the variables in the fastest way possible, even if it used up an extra stack cell, for example. I fully understand that most implementations, including that of Xerox, haven't the freedom to further optimize the creation of bindings (though it is a fascinating concept...). The point is that those bindings \are/ covered by the declaration and that the init-forms for the bindings are \not/ so covered, as stated in my proposal. Unfortunately, TYPE and IGNORE are the only decl specs that only concern bindings. SPECIAL concerns bindings also, but it also pervasively affects references (this is what you want changed). I am \not/ trying to change the so-called ``pervasive'' nature of special declarations, only their scope. More on this later. And FTYPE and INLINE simply confuse me. How can FTYPE be confusing when TYPE is not? They perform precisely symmetrically along the value/function axis. TYPE makes a statement about the kinds of \values/ that can be referred to by the \value/-names given, while FTPYPE makes a statement about the kinds of \functions/ that can be referred to by the \function/-names given. No difference, no confusion. First of all, FTYPE is not explicitly stated to be a pervasive decl spec, I believe this is an omission. Secondly, there is this confusing sentence at the end of their descriptions: "Note that the rules of lexical scoping are observed; if one of the functions mentioned has a lexically apparent local definition (as made by FLET or LABELS), then the declaration applies to that local definition and not to the global definition." This makes it sound like FTYPE and INLINE are like SPECIAL: they concern bindings AND affect references (but not pervasively?). For example, (FLET ((zap (...)...(zap...)...)) (declare (inline zap)) ...) Is the call to zap in the local definition of zap affected by the declaration? My reading of CLtL and commonsense make me answer no. The call to zap is not a call to the local def. of zap, and according to my reading of the sentence quoted above, the decl. only affects references within the scope of the innermost binding of the name zap. But this interpretation depends upon not interpreting 'pervasively' as stated in CLtL. Is my interpretation correct? One is strongly reminded of rabbinical study of the Talmud... This whole view of pervasive vs. non-pervasive is a red herring based upon some unclearly-written prose in CLtL. A given declaration has a certain scope and has an effect (possibly empty) on every single language construct in that scope. Thus, \every/ declaration is ``pervasive'' in the sense of CLtL. To describe the meaning of a given kind of declaration, it is necessary and sufficient to lay out its effect on every kind of language feature that can appear within its scope; clearly, most declaration-kinds will have non-empty effects on only a small set of language features. For example, a SPECIAL declaration affects variable bindings and references, but not function-calls or other declarations. The DECLARATION declaration affects only other declarations and none of variable bindings, references or function calls. I will lay out my understanding of the meanings of all of the CLtL declaration-kinds in another message (since this one is going to be too long as it is). I propose the following change to CLtL (which pretty much agrees with both CLtL and Pavel): ... I disagree with the statement that Nick's proposal agrees with mine. ... Some examples should help clarify this: (let ((y x)) (declare (type list x)) ...x...) Both references to x are affected. (let ((x x)) (declare (type list x)) ...x...) Only the second reference to x is affected (since the first reference is not within the scope of the binding named by x). This is losing. Either the init-forms of the LET should be covered by the declarations or they should not, but it shouldn't depend upon what variables are being bound. It is precisely behaviour like this against which I am raging: the scope of declarations corresponding to random, arbitrary, and hard-to-remember rules as opposed to the same, sane rules of lexical scoping around which the whole remainder of the language revolves. (FLET ((zap (...)...(zap...)...(zoop...)...)) (declare (function zap (...)...) (function zoop (...)...)) ...) The call to zap is not affected, but the call to zoop is. This is the example that really hurts. The world will be a simpler place if we can simply agree that every declaration has a certain scope, regardless of what constructs appear in that scope. Thus, the scope of these declarations either includes or does not include the body of the function ZAP. If they do (and I think that they should not), then both function calls shown should be affected. If the scope does not include that body, then neither call is affected. Clear? Note that I specified a \single/ scope for both declarations above, not a separate one for each; the only exception to this policy should be the sequential binding forms, including LAMBDA. I believe this proposal is complete, consistent, and simple to apply. I believe this proposal is incomplete (since it does not include a specific enumeration of the semantics of all declarations in all of the special forms), inconsistent (see my last set of comments above) and difficult to apply (it requires examination of the names of variables being bound, as opposed to having scope and semantics independent of specific context). ----------- The next proposal was from Bawden and was later dubbed ``Bawden's Alternate Proposal'': Date: Mon, 21 Jul 86 16:02:37 EDT From: Alan Bawden ... Actually, the more I think about this as a simplification, the more I like it. So here is a counter-proposal for rationalizing the semantics of declarations: 1. All declarations are completely pervasive. That is, if you write (locally (declare (special foo)) ...) then every occurance of FOO within the body is taken to be a special reference or a special binding. The only way to escape from the effects of a declaration within the body, is to explicitly shadow the declaration with another. This applies to -all- declarations: FTYPE, INLINE, etc. 2. Declarations that occur in the bodies of special forms (DEFUN, LET, DO, etc.), and in LAMBDA expressions, are taken to mean the same thing as if the entire form was enclosed in a LOCALLY containing the same declarations. So (let ,pairs ,@dcls ,@body) and (locally ,@dcls (let ,pairs ,@body)) are completely equivalent. (Since LAMBDA expressions aren't forms, the equivalent using LOCALLY isn't always completely straightforward to construct. For example, this case: ((lambda ,vars ,@dcls ,@body) ,@vals) is equivalent to using LOCALLY as follows: (funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals) .) One certainly can't fault this proposal on the ground of complexity. No, my major objection to Alan's plan is that it sets up an entirely separate scoping mechanism for declarations. That mechanism is entirely lexical and straightforward and all that, but it's not the same one that the binding of names uses. Why have two scopes when one will do? Also, I agree with Paul the Greek that the following is undesirable: Date: Mon, 21 Jul 86 17:55:05 EDT From: Alan Bawden From: "BACH::GREEK" Bawden's proposal would result in the following. (FLET ((FOO (X) (FOO X X))) (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO 5) ...) The declaration for FOO would pertain to both the locally-defined FOO and the outer FOO used in its body. This is correct. Since function names are lexically scoped, you can call the inner function something other than FOO with only a minor change to your program. Is this situation actually common in anyone's code? It bothers me that a single declaration can refer to two different variables that happen to share the same name. Notice that it is the creation of a separate-but-equal scoping mechanism for declarations that causes this problem; were declarations to use the same scoping mechanism as names, this problem could not arise. JonL wrote in support of Alan's proposal: Date: Wed, 23 Jul 86 03:53:30 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) ... It seems to me that Alan's proposal infuses declarations with the same kind of scoping semantics that exists for variable bindings. In the form (let ((a )) . . . (let ((a )) . . . )) the meaning of this is "a is bound to something, unless it is bound to something else"; which is parallel to Alan's notion for declarations that has (unfortunately) been called "shadowing". I find the unification of these two scoping rules to be very attractive. -- JonL -- Alan's proposal does not unify the two scoping rules, but rather grants them both first-class status, separate but equal, as I said above. I believe that my proposal, linking the scope of declarations directly to the scope of names, truly unifies the two. I've talked enough for this letter. I will send out a separate message revising and completing my proposal in as much detail I would expect (hope) the language specification to contain. Pavel  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Aug 86 09:06:58 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 14 Aug 86 05:59:37 PDT Date: Thu, 14 Aug 86 08:57 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: &rest destruction To: common-lisp@SU-AI.ARPA Message-ID: <860814125727.259238@MIT-MULTICS.ARPA> From: Steve Bacher: CSDL Subject: &rest destruction I see one more potential case where the &rest args may be indestructible - a possible compiler optimization where, given a function (defun foo (&rest x) ...) and a call like (foo 'bar 'baz 'frob) the compiler may choose to pass an inline list '(BAR BAZ FROB) to save on consing. Guaranteed destructibility would merely enjoin the compiler writer from generating this optimization, which would probably not be a problem (although I wouldn't be too happy with such a restriction). (There's one other useful case: if there's a function FROBOZZ, say, that takes one &REST arg, the compiler should be able to take (apply #'frobozz some-list) and compile it as a direct call to FROBOZZ, passing the list itself on as is. In some architectures this may be much more efficient, even apart from the elimination of APPLY from the picture; there may be an INTERNAL-FROBOZZ that takes a single list arg and does the same thing, in which case the compiler could do a source transform on the above. Again, forced consing in this (possibly more frequent) case could be detrimental.) - Steve   Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Aug 86 07:02:44 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 03:52:59 PDT Received: ID ; Thu 14 Aug 86 06:51:55-EDT Date: Thu, 14 Aug 1986 06:51 EDT Message-ID: From: Rob MacLachlan To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: question about subtypep In-reply-to: Msg of 14 Aug 1986 00:43-EDT from SANDRA CLTL is pretty vague about what subtypep does. My intpretation (based on intensive meditation and reading of scripture) is that SUBTYPEP returns information about the actual subtype relations in your implementation. Discrepencies will exist most often when an implementation decides to fold potentially distinct types together. For example, if all arrays are adjustable and have fill-pointers, then SIMPLE-ARRAY is indentical to ARRAY, and therefore (SUBTYPEP 'ARRAY 'SIMPLE-ARRAY) is true. Note there are some possible users of SUBTYPEP that would prefer answers to be based on some hypothetical maximally restrictive type system. The main example is a compiler which does compile-time type checking when possible. Although (THE SHORT-FLOAT 1F0) is quite legal in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are identical, it would be reasonable for the compiler to give a warning anyway. Applications that care about this sort of thing will have to use a variant version of subtypep that is distinct from the real SUBTYPEP. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 14 Aug 86 01:05:05 EDT Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 13 Aug 86 21:43:17 PDT Date: Wed 13 Aug 86 22:43:11-MDT From: SANDRA Subject: question about subtypep To: common-lisp@SU-AI.ARPA Message-ID: <12230642017.7.LOOSEMORE@UTAH-20.ARPA> On p. 35 of CLtL, it says that the type "array" may or may not be a subtype of "common", depending on whether your implementation allows you to make arrays that can only hold items of a type which isn't a subtype of common. Supposing the implementation has not made this extension, is it acceptable for (subtypep 'array 'common) to return T? Or is subtypep only supposed to return T if the subtype relationship definitely holds in *all* CL implementations? -Sandra -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 13 Aug 86 14:09:04 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 13 Aug 86 10:51:35 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29452; Wed 13-Aug-86 13:40:34 EDT Date: Wed, 13 Aug 86 13:41 EDT From: David A. Moon Subject: Proposal #7: TYPE-SPECIFIER-P To: Alan Snyder cc: common-lisp@SU-AI.ARPA In-Reply-To: <8608121944.AA12075@hplsny> Message-ID: <860813134107.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 12 Aug 86 12:43:53 PDT From: Alan Snyder I think the original request for this feature came from me, and the motivation was in fact to allow the portable implementation of object-oriented programming extensions. If DEFCLASS defines a TYPE, then DEFCLASS needs some way to tell if the specified class name is the name of an existing type, so that it can issue some reasonable error message. (Presumably, DEFCLASS knows if the specified name is the name of an existing CLASS, but it doesn't know about other types.) TYPE-NAME-P is adequate for this purpose, although it would look ugly to have TYPE-NAME-P in the language if we ever figured out what TYPE-SPECIFIER-P should do (perhaps Guy's definition is adequate). To the best of my knowledge, neither DEFTYPE nor DEFSTRUCT define what happens if the specified type name names an existing type. Defining their behavior in this case might also solve the problem (if an error is signalled in all cases of interest). (Only the moderator is allowed to interpret this paragraph as opening a new issue!) I see. Note that you should be allowed to re-evaluate "the same" DEFTYPE, DEFSTRUCT, or DEFCLASS, but should get an error if you evaluate one that is not "the same" but has the same name. This seems like a programming environment issue. For example, in Symbolics' system "the same" is defined by the name of the file containing the form, with all forms typed in from the terminal assumed to be "the same" and not "the same as" any form that came from a file. I can easily imagine other programming environments where "the same" would be defined in a very different way. The problem with calling this a programming environment issue rather than a language issue is that that doesn't make it go away, since the whole point was that you want a portable way to define (or extend) the programming environment. I don't have any solutions to offer, but my opinion is that one of TYPE-NAME-P or TYPE-SPECIFIER-P should exist, but DEFCLASS should not need to call it.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Aug 86 15:55:43 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Aug 86 12:46:07 PDT Received: from hplsny by hplabs.HP.COM ; Tue, 12 Aug 86 12:45:21 pdt Received: by hplsny ; Tue, 12 Aug 86 12:44:44 pdt From: Alan Snyder Message-Id: <8608121944.AA12075@hplsny> Date: Tue, 12 Aug 86 12:43:53 PDT Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P To: Masinter.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 28-Jul-86 11:52:00 X-Mailer: NMail [$Revision: 2.5 $] Date: 28 Jul 86 11:52 PDT From: Masinter.pa@Xerox.COM c) this is a request for a feature, but there's little evidence that there are significant, meaningful, portable uses for it. (Portable = a program written with one Common Lisp's version is likely to run with another Common Lisp's version.) e) there is another proposal (before the Object Oriented Programming committee in this case) which satisfies at least part of the original requirement in a different way. Date: Mon, 28 Jul 86 20:24 EDT From: David A. Moon I have no objection to either of TYPE-SPECIFIER-P or TYPE-NAME-P if someone can show why these are needed to fix something wrong with the language. Perhaps Guy can comment on why the original proposal 51 in his clarifications list was tagged with an asterisk indicating that it corrects an important flaw or resolves an ambiguity in the specification. I think the original request for this feature came from me, and the motivation was in fact to allow the portable implementation of object-oriented programming extensions. If DEFCLASS defines a TYPE, then DEFCLASS needs some way to tell if the specified class name is the name of an existing type, so that it can issue some reasonable error message. (Presumably, DEFCLASS knows if the specified name is the name of an existing CLASS, but it doesn't know about other types.) TYPE-NAME-P is adequate for this purpose, although it would look ugly to have TYPE-NAME-P in the language if we ever figured out what TYPE-SPECIFIER-P should do (perhaps Guy's definition is adequate). To the best of my knowledge, neither DEFTYPE nor DEFSTRUCT define what happens if the specified type name names an existing type. Defining their behavior in this case might also solve the problem (if an error is signalled in all cases of interest). (Only the moderator is allowed to interpret this paragraph as opening a new issue!) Alan -------  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Aug 86 02:20:02 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 11 Aug 86 23:07:00 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61108; Tue 12-Aug-86 02:05:59 EDT Date: Tue, 12 Aug 86 02:06 EDT From: David A. Moon Subject: :allow-other-keys query To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860812020607.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 10 Aug 1986 00:04 EDT From: "Scott E. Fahlman" From: earl Given (defun bah (&key humbug) ...) which of the following are legal? 1 (bah :allow-other-keys nil :other 'blah) 2 (bah :allow-other-keys t :other 'blah) 3 (bah :allow-other-keys nil) Certainly 1 is in error and 2 is legal. What about 3? The way I read the manual this is an error, which I don't think is the intent of this feature. Opinions? I agree with your analysis: a strict reading of the current wording of the manual would suggest that case 3 is an error, but it would make more sense if this were not treated as an error. Our implementation treated 3 as an error for a while, due to being misled by the manual, and we decided that that was a bug. I agree with Earl; all &key functions accept :allow-other-keys, and the manual (pp.62-3) should be clarified accordingly.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 12 Aug 86 02:11:33 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 11 Aug 86 22:57:50 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61106; Tue 12-Aug-86 01:56:40 EDT Date: Tue, 12 Aug 86 01:56 EDT From: David A. Moon Subject: TAGBODY vs LABELS To: Stanley Shebs cc: common-lisp@SU-AI.ARPA In-Reply-To: <8608102050.AA00254@utah-orion.ARPA> Message-ID: <860812015648.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 10 Aug 86 14:50:39 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) I was in the process of implementing TAGBODY in terms of LABELS (each piece of straightline code turns into a function, and GO turns into function calls), but upon perusing CLtl more closely, I found that the GO is apparently supposed to undo catchers, which wouldn't happen if it becomes a function call... Is this analysis correct? If so, then perhaps the standard deserves something a little stronger than the phrase "can break up catchers if necessary to get to the target" (middle of p. 131), which leaves me wondering what else GOs are supposed to do to get to those elusive targets... Most people implement non-local GO in terms of THROW and local GO. (tagbody (foo #'(lambda () (go a))) (baz) a (bar)) ==> (tagbody (case (catch g0001 (foo #'(lambda () (throw g0001 1))) 2) (1 (go a)) (2 (baz))) a (bar)) or (tagbody (catch g0001 (foo #'(lambda () (throw g0001 nil))) (go g0002)) (go a) g0002 (baz) a (bar)) where g0001 is bound to something dynamically unique (using a gensym constant here won't work, you should easily be able to construct a counterexample using recursive functions). Regardless of your exact implementation, I think you'll find that cases exist in which only an implementation of GO that uses THROW will work.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 11 Aug 86 14:32:47 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 86 11:19:35 PDT Received: from nymphodora by Godot.Think.COM via CHAOS; Mon, 11 Aug 86 14:19:34 edt Date: Mon, 11 Aug 86 14:20 EDT From: Guy Steele Subject: tagbody using labels To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <860810-232733-1239@Xerox> Message-Id: <860811142008.3.GLS@NYMPHODORA.THINK.COM> Utterly astonishing! --Guy  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 11 Aug 86 12:23:17 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 86 09:16:06 PDT Received: from nymphodora by Godot.Think.COM via CHAOS; Mon, 11 Aug 86 12:15:53 edt Date: Mon, 11 Aug 86 12:16 EDT From: Guy Steele Subject: ,',@ To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <860801153243.3.ALAN@PIGPEN.AI.MIT.EDU> Message-Id: <860811121629.4.GLS@NYMPHODORA.THINK.COM> For the record, I was somewhat wedged in my last reply to Alan about ,',@ and I am now in full agreement with him on the technical issues. --Guy  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 11 Aug 86 02:33:16 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Aug 86 23:27:10 PDT Received: from Salvador.ms by ArpaGateway.ms ; 10 AUG 86 23:27:33 PDT From: masinter.PA@Xerox.COM Date: 10 Aug 86 23:26:24 PDT Subject: tagbody using labels To: ram@c.cs.cmu.edu cc: common-lisp@su-ai.ARPA Message-ID: <860810-232733-1239@Xerox> GO requires no more magic than return-from. This was an interesting puzzle. This definition doesn't handle go's from inside an inner tagbody to an outer one, but I couldn't figure out how to do that without introducing a compiler-let. (defmacro tagbody (&rest rest) (labels ((parse (tail &aux (rest (member-if #'atom (cdr tail)))) (if tail (cons (cons (gensym) (ldiff tail rest)) (parse rest))))) (let ((name (gensym)) (bodies (parse (cons (gensym) rest)))) `(block ,name (macrolet ((go (tag) `(return-from ,(car (find tag ',bodies :key 'cadr)) nil))) (labels ,(maplist #'(lambda (tail) `(,(caar tail) () ,@(reduce #'(lambda (body tag) `((block ,(car tag) ,@body) (return-from ,name (,(car tag))))) bodies :initial-value `(,@(cddar tail) ,(if (cdr tail) `(return-from ,(caadr tail) nil)))))) bodies) (,(caar bodies)))))))) Larry <:-)  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 11 Aug 86 00:38:07 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 86 21:32:09 PDT Received: ID ; Mon 11 Aug 86 00:32:27-EDT Date: Mon, 11 Aug 1986 00:32 EDT Message-ID: From: Rob MacLachlan To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Cc: common-lisp@SU-AI.ARPA Subject: TAGBODY vs LABELS In-reply-to: Msg of 10 Aug 1986 16:50-EDT from shebs%utah-orion at utah-cs.arpa (Stanley Shebs) GO has to do whatever is necessary in your implementation to get out of whatever possible stuff that you wrap around the GO. There are no restrictions on where a GO may appear other than that it must be lexically within the body of the TAGBODY and that it must be evaluated within the dynamic context of the TAGBODY. It may be partly due to a lack of complete understanding of how the LABELS hack works, but I believe that there isn't a straightforward general conversion in Common Lisp. In general, any kind of dynamic state may have to be magically undone. Consider the example in p131 where the call to MAPCAR is aborted by a GO. Special bindings seem to cause similar problems. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 10 Aug 86 16:56:29 EDT Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 10 Aug 86 13:50:10 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA23843; Sun, 10 Aug 86 14:50:42 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA00254; Sun, 10 Aug 86 14:50:39 MDT Date: Sun, 10 Aug 86 14:50:39 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8608102050.AA00254@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: TAGBODY vs LABELS I was in the process of implementing TAGBODY in terms of LABELS (each piece of straightline code turns into a function, and GO turns into function calls), but upon perusing CLtl more closely, I found that the GO is apparently supposed to undo catchers, which wouldn't happen if it becomes a function call... Is this analysis correct? If so, then perhaps the standard deserves something a little stronger than the phrase "can break up catchers if necessary to get to the target" (middle of p. 131), which leaves me wondering what else GOs are supposed to do to get to those elusive targets... stan  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 10 Aug 86 15:12:14 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 86 12:05:22 PDT Received: ID ; Sun 10 Aug 86 15:05:34-EDT Date: Sun, 10 Aug 1986 15:05 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: &rest destruction In-reply-to: Msg of 10 Aug 1986 02:11-EDT from Hvatum at MIT-MULTICS.ARPA From: Steve Bacher (CSDL) Subject: What's all this fuss about &rest destruction? ... Conversely, I find it hard to accept the notion that Common LISP may specify that some particular kind of argument to a function is GUARANTEED to be freshly consed and therefore destructible. Suppose you have a function like (defun foo (a b &rest c) ...) Why should I be guaranteed that the value bound to c will be clobberable, when I am not given such a guarantee for a and b? The situation for A and B is not the same as for C. The values for A and B come direct from the caller. In the case of a normal call to FOO, the value passed in for C will be a list that is freshly consed at runtime. The only case in which C might not be freshly consed is if FOO is called via APPLY. Since calls via APPLY are relatively rare, the question is whether we should require copying in this rare case (which would allow users to assume that a rest arg is ALWAYS freshly-consed), or whether we should warn the users that the &rest arg may have shared top-level strucutre in some rare cases. The issue of whether &rest args have indefinite extent is a separate one, dragged in by some random comments by DCP. It seems that everyone agrees that Common Lisp currently requires &rest args to have indefinite extent, and that this should not be changed. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 10 Aug 86 02:36:34 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 9 Aug 86 23:20:36 PDT Date: Sun, 10 Aug 86 02:11 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: &rest destruction To: common-lisp@SU-AI.ARPA Message-ID: <860810061145.560694@MIT-MULTICS.ARPA> From: Steve Bacher (CSDL) Subject: What's all this fuss about &rest destruction? Having been watching while just about everyone on the CL mailing list has argued about the &REST proposal, I have to jump in and make a point. Many of you are now contending that there is no difference between restricting the user from destroying a list passed as an argument to a function and restricting the user from passing same list back as a return value or storing it in "stable" storage (e.g. SETQ'ing some global variable thereto). I find it incredible that this idea should be suddenly gaining concurrency. Ever since LISP began (I realize this is a meaningless argument to most Common LISPers)... or maybe I should say that scattered throughout every LISP manual and certainly CLtL (though I can't quote any exact references), it has been emphasized that the destructive operations are DANGEROUS and should be used WITH CAUTION only by EXPERIENCED LISP PROGRAMMERS. It follows that if you are about to do something that will destructively update a list, you'd better be damned sure that nobody else is pointing to that list. The only way to be certain of this is (usually) if you create the list yourself out of fresh conses (or if you get the list back from a function which you know has created a list safe for destruction). Conversely, I find it hard to accept the notion that Common LISP may specify that some particular kind of argument to a function is GUARANTEED to be freshly consed and therefore destructible. Suppose you have a function like (defun foo (a b &rest c) ...) Why should I be guaranteed that the value bound to c will be clobberable, when I am not given such a guarantee for a and b? Perhaps your answer will be that functions should always do COPY-LIST on any list arguments they pass to other functions, since those other functions might wish to do NCONC or RPLACA on their args? :-) On the other hand, NEVER in the history of any LISP that I know has there been a rule that for some situation or other, the user may not pass a given object back as a return value or store it somewhere permanent. Such a restriction is truly abhorrent and contrary to the spirit of the language. But it sure might make some compiler implementors happy. Imagine: the whole problem of upward funargs could have been avoided so easily - just tell users that functions may be passed as arguments, but they may not be returned as values or assigned to global variables! We might never had had to design all those hairy mechanisms for saving environments in heap storage. If the rationale behind this is that certain implementations put their &REST args on the stack to save some conses, that's just too bad. (Should we support implementations that keep lexical closure environments on the stack because it's just too hard to let users pass lexical closures around as arguments?) I agree with Scott Fahlman's suggestion for an additional mechanism in the language to provide for LEXPR'ish passing of varying numbers of args on the stack as an alternative to consing &REST lists. In short, there most definitely IS a qualitative distinction between proscribing wanton clobbering of lists regardless of their origin and limiting users' right to do with arguments what they please in nondestructive ways. - Steve Bacher C.S.Draper Laboratory   Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 10 Aug 86 00:11:12 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86 21:04:42 PDT Received: ID ; Sun 10 Aug 86 00:04:09-EDT Date: Sun, 10 Aug 1986 00:04 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: mips!earl@glacier.stanford.edu (Earl Killian) Cc: common-lisp@SU-AI.ARPA Subject: :allow-other-keys query In-reply-to: Msg of 9 Aug 1986 22:30-EDT from mips!earl at glacier.stanford.edu (Earl Killian) Given (defun bah (&key humbug) ...) which of the following are legal? 1 (bah :allow-other-keys nil :other 'blah) 2 (bah :allow-other-keys t :other 'blah) 3 (bah :allow-other-keys nil) Certainly 1 is in error and 2 is legal. What about 3? The way I read the manual this is an error, which I don't think is the intent of this feature. Opinions? I agree with your analysis: a strict reading of the current wording of the manual would suggest that case 3 is an error, but it would make more sense if this were not treated as an error.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 9 Aug 86 23:46:29 EDT Received: from GLACIER.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86 20:41:09 PDT Received: by glacier.stanford.edu with Sendmail; Sat, 9 Aug 86 20:42:42 pdt Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7) id AA12969; Sat, 9 Aug 86 19:30:22 pdt Received: by pachyderm.UUCP (4.12/4.7) id AA13610; Sat, 9 Aug 86 19:30:20 pdt Date: Sat, 9 Aug 86 19:30:20 pdt From: mips!earl@glacier.stanford.edu (Earl Killian) Message-Id: <8608100230.AA13610@pachyderm.UUCP> To: common-lisp@su-ai.ARPA Subject: :allow-other-keys query Given (defun bah (&key humbug) ...) which of the following are legal? 1 (bah :allow-other-keys nil :other 'blah) 2 (bah :allow-other-keys t :other 'blah) 3 (bah :allow-other-keys nil) Certainly 1 is in error and 2 is legal. What about 3? The way I read the manual this is an error, which I don't think is the intent of this feature. Opinions?  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Aug 86 22:14:56 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 86 19:04:28 PDT Date: Wed, 6 Aug 1986 22:09 EDT Message-ID: From: SOLEY@XX.LCS.MIT.EDU To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: DPB, DPBS, something like that In-reply-to: Msg of 6 Aug 1986 10:31-EDT from David C. Plummer Date: Wednesday, 6 August 1986 10:31-EDT From: David C. Plummer To: common-lisp at SU-AI.ARPA Re: DPB, DPBS, something like that (dpb val1 spec1 (dpb val2 spec2 (dpb val3 spec3 ... int))) ==> (dpb val1 spec1 val2 spec2 val3 spec3 ... int) Have others had a need for this and would find this generally useful? I too have written this a million times. It's an obvious upward-compatible extension.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Aug 86 20:36:18 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 86 17:24:05 PDT Received: from EUPHRATES.SCRC.Symbolics.COM (EUPHRATES.SCRC.Symbolics.COM) by QUABBIN.SCRC.Symbolics.COM via INTERNET with SMTP id 28297; 6 Aug 86 20:22:51 EDT Date: Wed, 6 Aug 86 20:23 EDT From: David A. Moon Subject: Re: synonym streams.. To: common-lisp@SU-AI.ARPA In-Reply-To: <860805-111034-2460@Xerox> Message-ID: <860806202341.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 5 Aug 86 11:09 PDT From: Masinter.pa@Xerox.COM I propose the following rule: "It is an error to attempt to close a stream that wasn't created with open." With this rule, it would follow that, since synonym, broadcast and two-way streams are not created with open, it is an error to perform "close" on them. I think this is a fine suggestion.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Aug 86 14:14:27 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 86 11:00:05 PDT Received: from DIAMOND.S4CC.Symbolics.COM (DIAMOND.S4CC.Symbolics.COM) by QUABBIN.SCRC.Symbolics.COM via INTERNET with SMTP id 28119; 6 Aug 86 13:56:55 EDT Received: from FIREBIRD.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2592; Wed 6-Aug-86 10:32:11 EDT Date: Wed, 6 Aug 86 10:31 EDT From: David C. Plummer Subject: DPB, DPBS, something like that To: common-lisp@SU-AI.ARPA Message-ID: <860806103157.4.DCP@FIREBIRD.S4CC.Symbolics.COM> When writing system code especially, but sometimes when writing normal code, I have often had to write long chains of DPBs, such as (dpb val1 spec1 (dpb val2 spec2 (dpb val3 spec3 ...))) This (a) gets tedious and (b) looks bad. I would either like to extend DPB to take an odd number of arguments, or have a new function which does. (It probably wants to be a function rather than a macro.) Thus, (dpb val1 spec1 val2 spec2 val3 spec3 ... background-integer) Have others had a need for this and would find this generally useful?  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 5 Aug 86 14:26:39 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Aug 86 11:11:28 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 05 AUG 86 11:10:34 PDT Date: 5 Aug 86 11:09 PDT From: Masinter.pa@Xerox.COM Subject: Re: synonym streams.. In-reply-to: David Bein 's message of 5 Aug 86 09:05 PDT To: common-lisp@su-ai.ARPA Message-ID: <860805-111034-2460@Xerox> I propose the following rule: "It is an error to attempt to close a stream that wasn't created with open." With this rule, it would follow that, since synonym, broadcast and two-way streams are not created with open, it is an error to perform "close" on them.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 5 Aug 86 12:19:05 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Aug 86 09:08:39 PDT Received: by hplabs.HP.COM ; Tue, 5 Aug 86 09:07:35 pdt Received: by pyramid (5.51/3.14) id AA16356; Tue, 5 Aug 86 09:06:34 PDT Date: 5 Aug 1986 09:05-PDT From: David Bein Subject: synonym streams.. To: common-lisp@su-ai Message-Id: <523641937/bein@pyramid> Should a close on a synonym-stream merely close what it is synonymous with or should it too be rendered useless after the close (regardless of what happens to the underlying stream -- see my last note re: standard streams) ?? --David  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Aug 86 16:09:49 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 4 Aug 86 12:59:56 PDT Received: from epicurus by Godot.Think.COM via CHAOS; Mon, 4 Aug 86 16:00:15 edt Date: Mon, 4 Aug 86 16:00 EDT From: Dan Aronson Subject: ignore this message To: common-lisp@SU-AI.ARPA Message-Id: <860804160059.2.DAN@EPICURUS.THINK.COM> Please ignore this test of our local mailing list. --dan  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 18:47:58 EDT Received: from HI-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86 15:32:44 PDT Acknowledge-To: Hadden@HI-MULTICS.ARPA Date: Fri, 1 Aug 86 09:46 CDT From: Hadden@HI-MULTICS.ARPA Subject: Re: Proposal #9 Status: Variable Name Conflicts To: Jeff Barnett cc: common-lisp@SU-AI.ARPA In-Reply-To: Message of 30 Jul 86 15:55 CDT from "Jeff Barnett" Message-ID: <860801144651.291022@HI-MULTICS.ARPA> actually, i think it can be done in order N. the idea is to scan down the list checking each symbol's property list for a flag. if it's not there, put it there; if it is, you've already seen it. the following (untested) code may give you the idea: (defun dup-p (arg-list) (do ((l arg-list (cdr l)) (foo (gensym))) ((null l) (mapc #'(lambda (x) (remprop x foo)) arg-list) nil) (if (get (car l) foo) (progn (mapc #'(lambda (x) (remprop x foo)) arg-list) (return t)) (setf (get (car l) foo) t)))) -geo  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 13:10:03 EDT Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 1 Aug 86 09:55:41 PDT Received: from thorlac by Godot.Think.COM via CHAOS; Fri, 1 Aug 86 12:55:36 edt Date: Fri, 1 Aug 86 12:56 EDT From: Guy Steele Subject: Proposal #9: Fast testing in PROGV To: DCP@QUABBIN.SCRC.Symbolics.COM, hoey@NRL-AIC.ARPA, jbarnett@NRTC.ARPA, common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <860801083615.2.DCP@CREEPER.SCRC.Symbolics.COM> Message-Id: <860801125635.6.GLS@THORLAC.THINK.COM> Moon: 3 days, 19 hours, 20 minutes since the last quarter of the moon. Date: Fri, 1 Aug 86 08:36 EDT From: David C. Plummer Putting a mark on a property list takes linear time (length of the property list to see if it is already there), and you have to do this for N variables. So you are back to N^2 again, and you are likely consing, and misusing property lists, and... Barf! Who says you have to search the entire property list? One of the reasons we are having such an explosion of mail is that many people are failing to think for more than three seconds before shooting from the hip. (defun does-a-list-of-symbols-contain-duplicates-p (symbols) (let ((unique (list 'foo))) (unwind-protect (dolist (s symbols) (when (eq (car (symbol-plist s)) unique) (return-from does-a-list-of-symbols-contain-duplicates-p t)) (setf (symbol-plist s) (list* unique t (symbol-plist s)))) (dolist (s symbols) (if (eq (car (symbol-plist s)) unique) (setf (symbol-plist s) (cddr (symbol-plist s))) (return)))) nil)) Looks like linear time to me. (Historical note: the implementation of SUBLIS in MacLisp used to pull a similar trick.) --Guy  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 13:09:51 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86 09:55:22 PDT Date: 1 Aug 1986 12:31:26 EDT (Fri) From: Dan Hoey Subject: Proposal #9: Fast testing in PROGV To: David C. Plummer Cc: jbarnett@NRTC.ARPA, common-lisp@SU-AI.ARPA Message-Id: <523297888/hoey@nrl-aic> Date: Fri, 1 Aug 86 08:36 EDT From: David C. Plummer From: Dan Hoey From: Jeff Barnett ...looking for duplicate names in the variable-list argument of a PROGV ... can be done in N*log N time. You can put a mark on the property lists of the variables for a linear algorithm. Nit: no you can't. Antinit: Sure you can. Putting a mark on a property list takes linear time (length of the property list to see if it is already there) I had in mind putting a GENSYMmed on the front of the property list and only testing for it there. (Nit me no nits about multiple processes until they're in CLtL.) and you have to do this for N variables. So you are back to N^2 again, Nit: That's N E(L), for L the length of a property list. and you are likely consing, My PROGV checker would keep all its conses for use the next time. and misusing property lists, I would spend the extra CONS to keep the plists legal. and... if there is further discussion, we can do it between ourselves. Anyone out there who wants to write a PROGV checker should check with David or me for the latest in variable uniqueness theory. Dan  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 08:47:33 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 1 Aug 86 05:36:48 PDT Received: from CREEPER.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54637; Fri 1-Aug-86 08:36:16 EDT Date: Fri, 1 Aug 86 08:36 EDT From: David C. Plummer Subject: Proposal #9: Fast testing in PROGV To: Dan Hoey , jbarnett@NRTC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8607312211.AA13507@nrl-aic> Message-ID: <860801083615.2.DCP@CREEPER.SCRC.Symbolics.COM> Date: Thu, 31 Jul 86 18:11:20 edt From: Dan Hoey From: Jeff Barnett It was assumed in this and a previous message that looking for duplicate names in the variable-list argument of a PROGV is an N**2 operation.... It can be done in N*log N time. You can put a mark on the property lists of the variables for a linear algorithm. Nit: no you can't. Putting a mark on a property list takes linear time (length of the property list to see if it is already there), and you have to do this for N variables. So you are back to N^2 again, and you are likely consing, and misusing property lists, and...  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 07:09:02 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 1 Aug 86 03:41:58 PDT Received: by hplabs.HP.COM ; Fri, 1 Aug 86 03:40:43 pdt Received: from hpfcjrd.UUCP; Thu, 31 Jul 86 23:49:27 Received: by hpfcjrd; Thu, 31 Jul 86 23:49:27 mdt Date: Thu, 31 Jul 86 23:49:27 mdt From: John Diamant Return-Path: To: common-lisp@sail.stanford.edu Subject: Proposal #13: Structure Sharing in Arguments Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14 From: Kent M Pitman Proposal #13: Structure Sharing in Arguments In the case of &REST in macros, I see no reason to not simply say that the argument list is -always- shared. Is there an argument for why this might not always be possible? In the case of &BODY, it may not be possible to do the sharing, so I'm willing to leave this undefined and say it "is an error" to modify the list. A language specification has no business specifying implementation details. Requiring that the list be shared is an efficiency requirement, not a language specification. I agree with the warning that the list may be shared, but I certainly wouldn't require it! John  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 01:53:14 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 31 Jul 86 22:29:23 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54240; Thu 31-Jul-86 16:05:24 EDT Date: Thu, 31 Jul 86 16:04 EDT From: Kent M Pitman Subject: QUIT To: Common-Lisp@SU-AI.ARPA cc: KMP@SCRC-STONY-BROOK.ARPA References: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>, <8607290714.AA22657@ccut.u-tokyo.junet> Message-ID: <860731160402.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I'm sorry, but I just will not support the idea of a single function QUIT as is currently being discussed. If the problem were re-cast, it might be soluble, but I believe the problem as I've seen it stated thus far is just plain insoluble. I base my criticisms on experience that I have from create a portable QUIT function for use in Macsyma internals. I created such a function using various non-portable primitives provided by particular dialects I was studying. As with the GC problem, I found that the idea seemed superficially plausible but just didn't work out in practice. Here are some of my observations and conclusions ... 1. Where is control transfered? Of the implementations which primitively offer some variant of QUIT, all that I know of are on partitioned address space machines which have a basically tree-structured process system that offers a distinguished superior (usually an exec) to which it is obvious that control should be transfered upon call to QUIT. Shared address space machines (ie, Lisp Machines) have the problem that there is no tree of processes. All occupy an equal status and there is no obvious process to which control should be returned. 2. What is a process? On partitioned address space machines, each process typically comes with its own "global" state. Killing a process means killing its "global" state. On shared address machines, killing the process will generally kill only its dynamic state, not its global state (which is generally intertwined with the global state of other processes). To kill its global state means killing the global state of sibling activities, which may be highly undesirable. 3. Can the process be resumed? Even among partitioned address space machines, there is disagreement about whether exiting (to the exec) means that you can re-enter later. 4. What does it mean for a process to be resumed? Presumably resuming leaves the global state intact. Does it restart the process or does the call to QUIT just return NIL? 5. If a process is killed permanently, are the associated UNWIND-PROTECT cleanup forms guaranteed to run first? Obviously, some of these issues cannot be answered by the Common-Lisp committee. They are architectural issues beyond the scope of the language. If we standardize on any meaning for QUIT, however, it must be guided by an understanding that people do not use linguistic primitives in the absence of intent, and that we should not provide primitives which do not allow the programmer to clearly specify some meaningful intent. In light of the questions I've raised above, I hope it's clear that definitions like "Exits the Lisp system" do not make any intent clear. Here are some real-life scenarios that I see... 1. If the intent was to exit, what if there was no place to go? On the 3600, the Lisp Listener doubles as an exec. It is the standard place to which programmers return to give commands, not a place to be returned from. Having a "user interface" function named QUIT which was a no-op when typed to Lisp would be very confusing. Having it randomly select another activity would be fairly useless. I feel that people don't interactively ask to exit something unless they think there is an obvious place to go. 2. If the intent is to exit temporarily and the exit turns out to be permanent, this can have remarkably drastic consequences. A user of Macsyma would be phenomenally irritated if I offered a temporary-exit function and it ended up exiting permanently before s/he had a chance to save the MACSYMA's state. 3. If the intent was to exit permanently and the program was allowed to proceed, the effects of continuing could be very strange. I've found myself resorting to things like: (PROGN (QUIT) ;Try a permanent exit (...)) ;If we got here, the QUIT didn't work, ;so try cleaning up enough to continue or even: (LOOP (QUIT)) ;Insist on a permanent exit! 4. If the intent was to exit "lisp" permanently, destroying global state, I'd argue that it could not possibly have been the intent of any portable program to really kill everything on the machine since those other things are beyond the scope of Common Lisp and not something that CL programs have any obvious way to reason about. On the 3600, you can't opt to "start over" without taking the Editor, Mail Reader, Peek, Telnet Windows, etc. with it. Some people here at Symbolics do all their work from the same Lisp for several weeks at a time, building up lots of state which they don't want thrown away casually. There is no "starting over" that is not synonymous with "cold booting". In the case of server machines, this would mean that file connections would be broken, mail would stop being delivered until the (sometimes long) cold boot sequence had run, etc. In fact, the boot sequence may not begin automatically just because I halt my machine. If I was dialing in from home, I might have to go to work to initialize the system again. Some non-Lispms have an in-Lisp editor even though they have other processes which are separable. Perhaps some of those users use that editor only for editing Lisp and are content to have the editor and the lisp go away as a unit because they do other text editing in an editor that doesn't go away with Lisp, but that's presumably a property of the user rather than the system. The real problem here is that there is no such thing as exiting in the pure abstract. Exiting means to pass through an abstract boundary between an abitrarily chosen inside and outside. In the CL spec, we have remained intentionally silent on the issue of where that line is drawn in order to accomodate both Lispm-based and conventional systems. I think that corollary to this silence is the fact that functions which attempt to cross the boundary are ill-defined. Not only do some systems draw the boundary in different places than others, but some intentionally don't draw it at all. I don't care whether the primitive is called QUIT, EXIT, EXIT-TO-SYSTEM, or whatever. The names themselves are not the problem. I only care that any names we choose have a very clear behavior and that I can reason about at coding time, or that my programs can reason about at runtime prior to actually invoking the primitive which actually attempts to exit. I don't plan to seriously consider any proposal for a QUIT primitive which does not carefully address these issues.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 01:45:21 EDT Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 31 Jul 86 22:29:25 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54292; Thu 31-Jul-86 17:01:24 EDT Date: Thu, 31 Jul 86 17:01 EDT From: David A. Moon Subject: Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!)) To: common-lisp@SU-AI.ARPA In-Reply-To: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860731170132.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I believe that Plummer's suggestion of adding &DECLARATIONS and &DOC-STRING is superior to the previous two proposals for extensions to DEFMACRO for parsing bodies. I disagree with Plummer's suggestion that &KEY and &BODY are mutually exclusive. The semantics of &BODY is not an implicit progn; the only semantics of &BODY involves code formatting and indentation (CLtL p.145). I agree that &KEY and &DECLARATIONS are mutually exclusive.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 01:23:55 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 22:10:47 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66811; Fri 1-Aug-86 00:45:01 EDT Date: Fri, 1 Aug 86 00:44 EDT From: Kent M Pitman Subject: Comments on DCP's revised &BODY proposal To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860801004440.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I mostly like this variation of the &BODY proposal. I would prefer the name &DOCUMENTATION. In fact, given that we have &ENV instead of &ENVIRONMENT, it might be more consistent to have a short names like &DOC and &DECLS. I'm won't champion that very strongly, but I think it's worth pointing out both for the sake of consistency and the sake of reducing indentation. By using &DOCUMENTATION and &DECLARATIONS you're virtually assuring that things like: (DEFUN SOMETHING (NAME BVL &DECLARATIONS DECLS &DOCUMENTATION DOC &BODY FORMS) ...) will be pushing the right margin on an 80-column screen even given reasonably concice choices of macro and variable names. In the presence of displacing macros, I feel fairly strongly that we can't currently guarantee that the &BODY will contain unexpanded forms. My feeling is that we should either guarantee that the expanded (rather than unexpanded) form be returned if an expansion happened, or that we should be explicitly vague. It would be very unwise to document something we couldn't reliably provide. With regard to your aside about &KEY, I agree that &KEY and &BODY should be exclusive. Alternatively, though, we could revise the description of &KEY to do something useful. It comes up in the current error proposal that there are a lot of forms with bodies that have leading keywords. ie, (name bvl :key1 :value1 :key2 :value2 ... . body) The body is defined to start when the keyword pairs run out. Right now, these have to be "manually" parsed. It would be amazingly convenient to be able to say (NAME BVL &KEY KEY1 KEY2 &BODY FORMS) I'd be content for now to just leave this syntax undefined and let people think about a proposal on this subject later, but my desire to have this work makes this it seem very desirable to at least just disallow the current meaning to a coupled &BODY/&KEY configuration for the interim.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 1 Aug 86 01:05:00 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 21:55:22 PDT Received: ID ; Fri 1 Aug 86 00:55:43-EDT Date: Fri, 1 Aug 1986 00:55 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Japanese Subset Proposal Profesor Masayuki Ida, the chairman of the Common Lisp subcomittee of JEIDA in Japan, has sent me a draft of a subset proposal that a number of Japanese researchers have been working on. He is interested in discussing this with the U.S. Common Lisp community, and especially those people interested in subsets. The proposal is too long to send to the whole Common-Lisp mailing list, so I have put it on C.CS.CMU.EDU as file "prva:japan-core.txt". Discussion of this proposal should probably take place on the CL-SUBSET mailing list. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 22:58:52 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 19:49:05 PDT Date: 31 Jul 1986 22:49-EDT Sender: NGALL@G.BBN.COM Subject: Re: Declarations in MACROLET From: NGALL@G.BBN.COM To: RAM@C.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]31-Jul-86 22:49:06.NGALL> In-Reply-To: Date: Wed, 30 Jul 1986 10:05 EDT From: Rob MacLachlan I don't think that it would be correct for a declaration at the head of a macrolet to affect the bodies of any of the macros, since the bodies of the macros are defined to be in the null environment. You raise an interesting question: (flet ((foo ())) (locally (declare (inline foo)) (macrolet ((bar () (foo 1 2 3))) (foo)...))) Currently, does the inline decl affect both calls to foo? I can't tell from CLtL. -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 22:53:15 EDT Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 19:39:22 PDT Date: 31 Jul 1986 22:39-EDT Sender: NGALL@G.BBN.COM Subject: Re: declarations in macrolet puzzle From: NGALL@G.BBN.COM To: MASINTER.PA@XEROX.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]31-Jul-86 22:39:13.NGALL> In-Reply-To: <860730-064109-1194@Xerox> Date: 30 Jul 86 6:40:17 PDT From: MASINTER.PA@Xerox.COM (macrolet ((specials () (specials) '(declare (special special-list ,@special-list)))) (specials) special-list)) ... The missing piece to your puzzle is that declarations are expanded BEFORE any bindings take place (perhaps this should be stated explicitly in CLtL). Thus, the call to specials in the body of the macrolet does NOT refer to the specials being bound in the head of macrolet. This is true, not only of bindings made by macrolet, but also those made by let, flet, etc. -- Nick  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 22:03:05 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 18:47:32 PDT Received: ID ; Thu 31 Jul 86 21:47:43-EDT Date: Thu, 31 Jul 1986 21:47 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: What's going on? Several people have asked what became of the summaries I promised for issue #14 and for the declaration scope stuff. I have not sent these out yet. It has become clear to me that the discussion/decision process is not working at all well: the mail volume is too high, the load on the moderator is MUCH too high, the rate of progress is negligible, a lot of time is being wasted discussing issues that don't really matter, and my efforts to improve all this have antagonized a lot of people without solving any of the problems. My top-level task right now is to discuss these problems with the technical committee members and others to see if we can figure out some procedural changes that will get things moving in useful directions with less wear and tear on everyone. Until we've decided how to proceed, I won't be pushing too hard to make progress on specific technical issues. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 21:38:06 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 18:27:15 PDT Received: ID ; Thu 31 Jul 86 21:27:32-EDT Date: Thu, 31 Jul 1986 21:27 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Proposal #9 Status: Variable Name Conflicts In response to: DCP@TENEX.SCRC.Symbolics.COM I think PROGV should be removed from the list of forms that check for variable name conflicts. I think variable name conflicts should be detected by the compiler; not the runtime system. I think the semantics of PROGV are that the LAST symbol/value pair takes presedence in case there is more than one pair for a given symbol. As I said in response to this question earlier, nobody is proposing a "list of forms that CHECK FOR variable name conflicts". There is a proposal for forms in which the use of duplicate variable names "is an error". Not the same thing. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 18:48:12 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 15:33:39 PDT Received: from CREEPER.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66534; Thu 31-Jul-86 14:59:38 EDT Date: Thu, 31 Jul 86 14:59 EDT From: DCP@TENEX.SCRC.Symbolics.COM Sender: Zippy@TENEX.SCRC.Symbolics.COM Subject: Re: Proposal #9 Status: Variable Name Conflicts To: Common-Lisp@SU-AI.ARPA, Jeff Barnett In-Reply-To: The message of 30 Jul 86 16:55 EDT from Jeff Barnett Message-ID: <860731145915.3.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM> Date: Wed, 30 Jul 86 13:55:54 PDT From: Jeff Barnett It was assumed in this and a previous message that looking for duplicate names in the variable-list argument of a PROGV is an N**2 operation. Not true. In the first place, if the list is short N**2 is small. In the second place it can be done in N*log N time. To wit: (1) copy the list-- order n, (2) sort the list--order N*log N, and (3) search the ordered list for adjacent duplicates--order N. Any implementation that did this would probably discourage users from using PROGV because it would be costly (inefficient) to use. copying the list conses and takes time. Sorting can potentially cons, may be NlogN, but is quite expensive in the smaller cases. PROGV has so real and valid uses; it should be relatively inexpensive to use. I think PROGV should be removed from the list of forms that check for variable name conflicts. I think variable name conflicts should be detected by the compiler; not the runtime system. I think the semantics of PROGV are that the LAST symbol/value pair takes presedence in case there is more than one pair for a given symbol.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 18:25:51 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 15:14:29 PDT Date: Thu, 31 Jul 86 18:11:20 edt From: Dan Hoey Message-Id: <8607312211.AA13507@nrl-aic> To: jbarnett@nrtc.ARPA, common-lisp@su-ai.ARPA Subject: Proposal #9: Fast testing in PROGV From: Jeff Barnett It was assumed in this and a previous message that looking for duplicate names in the variable-list argument of a PROGV is an N**2 operation.... It can be done in N*log N time. You can put a mark on the property lists of the variables for a linear algorithm. Dan  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 18:23:29 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 15:06:43 PDT Received: from CREEPER.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26023; Thu 31-Jul-86 15:07:00 EDT Date: Thu, 31 Jul 86 15:08 EDT From: dcp@TENEX.SCRC.Symbolics.COM Sender: Zippy@TENEX.SCRC.Symbolics.COM Subject: Proposal #5 (aside) To: David A. Moon , common-lisp@SU-AI.ARPA In-Reply-To: <860729224641.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860731150815.5.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM> Date: Tue, 29 Jul 86 22:46 EDT From: David A. Moon Date: Mon, 21 Jul 1986 21:46 EDT From: "Scott E. Fahlman" Proposal #5: PARSE-BODY ....PARSE-BODY may perform macro-expansion (using the given environment) in order to determine whether an initial macro-call expands into a DECLARE form or documentation string. Since when can macros expand into documentation strings? Sidestepping the issue of whether or not it is currently allowed, I see no reason it shouldn't be allowed. Consider a program-writing-program that generates some code like (defun helper-function-259 (...args...) (declare (safety 2) (speed 1)) (compute-documentation-string :safety 2 :speed 1 :parent "helper-function" :contract "factor the number 259") (declare (inline aref)) ...)  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 18:21:56 EDT Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 14:59:57 PDT Received: from CREEPER.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26022; Thu 31-Jul-86 15:03:33 EDT Date: Thu, 31 Jul 86 15:04 EDT From: dcp@TENEX.SCRC.Symbolics.COM Sender: Zippy@TENEX.SCRC.Symbolics.COM Subject: Re: Staus of proposals 10, 11, and 12 To: NGALL@G.BBN.COM, Common-Lisp@SU-AI.ARPA cc: Fahlman@C.CS.CMU.EDU In-Reply-To: <[G.BBN.COM]29-Jul-86 21:47:02.NGALL> Message-ID: <860731150441.4.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM> Date: 29 Jul 1986 21:47-EDT From: NGALL@G.BBN.COM Date: Tue, 29 Jul 86 11:50 EDT From: David C. Plummer I may have thought of one usage: (macrolet ((print-them (list) `(mapc #'print ,list))) (declare (notinline mapc)) ...) If anybody else believes this, perhaps it should be one of the examples? I don't believe it. The stuff inside the backquoted list is not code, it is data. Here's a similar one that I believe: (macrolet ((print-them (list) `(progn ,@(mapcar #'(lambda (item) `(print ',item)) list))) (declare (notinline mapcar)) ...) In this, the mapcar funcall form IS code. You misunderstand. Declarations have a scoping for code that it sees. My intention was that anybody who calls (print-them some-list) expands into (mapc #'print some-list) and that the declaration forces MAPC to be open coded. Your definition has two differences from mine: (1) Your declaration tries to affect the expansion PROCESS (mine affects the processing of the expansion), and (2) your contract is different than mine (mine takes a runtime list, your's takes a compile time list). To get (1), I claim your declaration is in the wrong place. It should have been (macrolet ((print-them (list) (declare (notinline mapcar)) `(progn ,@(mapcar #'(lambda (item) `(print ',item)) list)))) ...) Note that this still is not a strong argument for decls in the body of a macrolet, since the decl could have been put in the body of the print-them macro definition. "must" not "could" But I agree that we should allow decls in the body of a macrolet.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 14:53:05 EDT Received: from BBNCC5.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 11:42:51 PDT To: Kent M Pitman cc: Common-Lisp@su-ai.ARPA Subject: Re: #13, #14 In-reply-to: Your message of Wed, 30 Jul 86 01:32 EDT. <860730013252.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> References: , <12226310687.19.LOOSEMORE@UTAH-20.ARPA>, The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU, <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>, <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>, <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>, Date: 31 Jul 86 14:26:30 EDT (Thu) From: Andy Latto Proposal #13: Structure Sharing in Arguments Kent says: ... For a function that takes &REST arguments, I would prefer that a copy always be made unless the interpreter or compiler can prove that it won't be necessary. If we cannot agree to do that, then it must be noted both that it "is an error" to modify such a list AND that it is an error to pass such a list to someone else using APPLY and then later modify it. eg, (PROGN (APPLY #'FOO L) (SETF (CDR L) ...)) may screw up state that FOO has encached for later use. I don't see why allowing the &rest list to be the same list that was passed to apply requires any of the above suggestions about what "is an error". Lisp functions are allowed to modify their arguments, or save them for later use. Proposal 13 says that APPLY, like NCONC, is such a function in the case where the function being APPLYed does destructive operations on its &rest argument. (apply #'rplacd args) and (apply #'foo args) both modify their arguments if foo is a function that does destructive operations on its &rest argument, and I don't see a big difference between them. In general, if I write a function that destructively modifies its arguments (or use an existing one, like NCONC), I must be careful that no other part of the code assumes that the structure I have modified will not change. If you use argument-modifing functions recklessly, you will produce obscure, hard-to-find, bugs. This is certainly true of normal arguments to functions, and I don't see why it shouldn't be true of &rest arguments as well, particularly if it can make some implementations more efficient. I also believe their should be some kind of &temp-rest lambda list keyword that produces an &rest list with dynamic extent, but that's a separate proposal that should be dealt with later. Proposal #14: THE and VALUES The purpose of THE is to give the compiler or interpreter information on the type of the value(s) returned by the form, since this may help produce more efficient code. Information on the number of values reuturned can presumably be put to similar use. It would be nice to have syntax to say either "These are the types of the first two returned values, and I don't know the types of any others, if any" or "Exactly two values will be returned, and here are their types". (THE (VALUES type1 type2 &rest T)) and (THE (VALUES type1 type2)) seems like as good a syntax as any for expressing these two concepts. I have no strong feelings as to whether (THE type1) should be equivalent to (THE (VALUES type1)) or (THE (VALUES type1 &rest T)). On the subject of VALUES, I noticed that Cltl says, on the issue of checking the type of the value(s) returned by a form in a THE special form, "Implementations are encouraged to make an explicit error check when running interpretively" (P 163). It seems to me that this check should be made if it is declared (optimize (safety 3) (speed 0)), and should not be made if it is declared (optimize (safety 0) (speed 3)), regardless of whether it is interpreted or compiled, and that the reference to the interpreter should be removed. Andy Latto alatto@bbn.ARPA  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 31 Jul 86 08:02:28 EDT Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 31 Jul 86 04:51:49 PDT Received: from HAL.MCC.DialNet.Symbolics.COM (HAL.CAD.MCC.COM.#Internet) by MCC.COM with TCP; Thu 31 Jul 86 06:52:37-CDT Date: Thu, 31 Jul 86 06:51 CDT From: David D. Loeffler Subject: Re: exit-to-system To: common-lisp@SU-AI.ARPA In-Reply-To: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM> Message-ID: <860731065106.0.LOEFFLER@HAL.MCC.DialNet.Symbolics.COM> Reply-To: Loeffler@[10.3.0.62] Postal-address: P.O. Box 200195, 9430 Research Blvd., Austin, TX 78720 Date: Wed, 30 Jul 86 12:12 EDT From: Bernard S. Greenberg The name QUIT does not sound reasonable. Quit what? Is ease of typing an issue, for something which is typed once per session and probably appears once in even the largest subsystem? EXIT-LISP sounds much better. I can easily (and have) had internal functions, and macros called QUIT. I don't think the name should be used up in this way. I agree with Bernie on this one. EXIT-LISP is better than QUIT. I used to work on a system that had a very uniform command set and QUIT meant "exit" from almost every one of the subsystems. Other system used EXIT. If a programmer wants to put an escape out of lisp in their code then EXIT-LISP is the right thing. Vendors may wish to incorporate their own QUIT or EXIT functions so that users will know how to get out of the interpreter. -- Dave