Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Sep 85 18:21:12 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Sep 85 15:12:06 PDT Received: ID ; Fri 27 Sep 85 18:12:35-EDT Date: Fri, 27 Sep 1985 18:12 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Steven Haflich Cc: common-lisp@SU-AI.ARPA Subject: Argument Type Mismatch Errors In-reply-to: Msg of 25 Sep 1985 14:31-EDT from Steven Haflich Unofficially: An implementation obviously should detect and signal errors when convenient. The primary force against always doing so is run-time efficiency. Personally, I feel that once an implementation detects an error such as an inappropriate argument type, it should always signal the error rather than silently proceeding. There's no reason not to signal the error, assuming the price of detecting it has already been paid. I disagree with this slightly. In some cases the book says "is an error" rather than "signals an error" because we recognized that on some machines it might be costly to detect and signal certain errors. But in other cases, the motivation was to allow flexibility for experimenting with non-standard language extensions. So I can certainly imagine some situations in which an implementation detects an error but deliberately goes on to do something other than signalling the error. The existence of such extensions should not be taken as a license for sloppy implementation, however: extensions of this sort should be carefully considered and should be well-documented. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 18:27:01 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 15:16:00 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 322160; Thu 26-Sep-85 18:16:10-EDT Date: Thu, 26 Sep 85 18:16 EDT From: David A. Moon Subject: disassemble and compile questions To: Bob Shaw cc: common-lisp@SU-AI.ARPA In-Reply-To: <8509252351.AA00218@HP-VENUS> Message-ID: <850926181620.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 25 Sep 85 16:35:06 pdt From: Bob Shaw I'm in need of enlightenment. The answers to the following two questions are not obvious from my readings of the book. I think you've come up with some good places where the book would benefit from more precise language. 1. If f is an interpreted function, does (disassemble 'f) cause f to become a compiled function? That seems like a bad idea (as you say below). 2. What is the appropriate way to compile a function object that is not compiled, not a lambda-expression and not the function definition for a symbol? Consider the "lexical closure" example in section 2.13 of CLtL. The only kind of uncompiled function object that exists is the lambda expression. More on 1: According to CLtl section 25.1, in the definition of disassemble, "The argument should be either a function object, a lambda-expression, or a symbol with a function definition. If the relevent function is not a compiled function, it is first compiled. ... This is primarily useful for debugging the compiler ... ." Side-effecting the function cell by disassembling does not seem like a result I would desire, especially when debugging the compiler. Is (compile 'symbol) or (compile nil (symbol-function 'symbol)) the intended means of compilation? In Symbolics' implementation, disassemble will compile a lambda expression, but if given a symbol whose function definition is interpreted, it will complain rather than compile it. This seems consistent with the statement that the feature of disassemble compiling interpreted things is for debugging the compiler. More on 2: The definition of compile states that it will only handle lambda- expressions: "If definition is supplied, it should be a lambda-expression, the interpreted function to be compiled. If it is not supplied, then name should be a symbol with a definition that is a lambda-expression; ... ." Section 2.13 states that lists other than lambda expessions may, in certain implementations, serve as functions. Should the definition of compile include such cases? I hope so. I don't think the language designers intended that you be able to compile lexical closures. Note that it is possible to create two lexical closures that have a binding in common; in order to compile one of these, leave the other interpreted, and obtain correct semantics, the compiler would have to use the same representation of lexical variable binding environments as the interpreter. Also note that the argument to COMPILE is specified as a lambda-expression, not as a function in the general sense of section 2.13.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 18:05:34 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 14:54:59 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 322135; Thu 26-Sep-85 17:55:12-EDT Date: Thu, 26 Sep 85 17:55 EDT From: David A. Moon Subject: go and return-from inside unwind-protect cleanup To: Guy Steele cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <850926104847.3.GLS@DESIDERIUS.THINK.COM> Message-ID: <850926175528.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I have no objection, stylistic or otherwise, to GO inside the first subform of UNWIND-PROTECT. It's only GO inside of the cleanup subforms (the second, third, ...) of UNWIND-PROTECT that makes me barf. The same applies to RETURN, RETURN-FROM, THROW, and any other transfer-of-control device.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 17:20:02 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 12:50:08 PDT Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 205393; Thu 26-Sep-85 15:49:37-EDT Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 140473; Thu 26-Sep-85 12:55:33-PDT Date: Thu, 26 Sep 85 12:51 PDT From: DDYER@SCRC-RIVERSIDE.ARPA Subject: Infinite optimization To: common-lisp@SU-AI.ARPA Fcc: W:>ddyer>mail.sent In-Reply-To: <850926125521.9.GLS@DESIDERIUS.THINK.COM> Supersedes: <850926124913.8.DDYER@PURPLE.SWW.Symbolics.COM> Message-ID: <850926125125.9.DDYER@PURPLE.SWW.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Thu, 26 Sep 85 12:55 EDT From: Guy Steele Date: 26 Sep 1985 0859-PDT From: Rem@IMSSS I like your idea. If an optimizing compiler happens to discover that the code it's trying to optimize absolutely cannot ever return nor produce any output, it would be nice for the LUSER if the compiler would inform the LUSER of that fact instead of blindly compiling a hung CPU and blindly leading the LUSER into executing it and having to reboot the system to escape it. Of course if the compiler doesn't happen to discover it, caveat emptor. I don't think this is a very likely case. Any loop that calls a function, or which can be interrupted, can exit via *THROW.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 13:06:02 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 09:54:22 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 12:55:14 edt Date: Thu, 26 Sep 85 12:55 EDT From: Guy Steele Subject: Infinite optimization To: Rem@IMSSS, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 26 Sep 85 11:59-EDT from Rem at IMSSS Message-Id: <850926125521.9.GLS@DESIDERIUS.THINK.COM> Date: 26 Sep 1985 0859-PDT From: Rem@IMSSS I like your idea. If an optimizing compiler happens to discover that the code it's trying to optimize absolutely cannot ever return nor produce any output, it would be nice for the LUSER if the compiler would inform the LUSER of that fact instead of blindly compiling a hung CPU and blindly leading the LUSER into executing it and having to reboot the system to escape it. Of course if the compiler doesn't happen to discover it, caveat emptor. Note such a very-smart compiler would wreak havoc with some timing benchmarks that do nothing useful over and over and throw away all the results; a good compiler could totally optimize-away such moot calculations, making the LISP system seem a million times faster than microcode when in fact it is simply punting the moot calculations. I have long advocated benchmarks being careful to do truly non-moot calculations. The CRAY-2 test whereby a large Mersenne prime is verified is a good benchmark. There's no way an optimizing compiler can turn the benchmark into a punt-cheat, providin it's a new Mersenne prime nobody computed before and hence couldn't be included as a special-case optimization a priori. (Did you see/hear the news story about that CRAY-2 test earlier this week?) ------- A few years ago a vendor did advertise a set of FORTRAN benchmarks comparing their machine to a VAX. Most of the numbers were reasonable, but on one benchmark Brand X was several orders of magnitude faster than the VAX. This appeared in the table without comment. The fact was that their compiler had noticed that the results of the inner loops were unused, and optimized away an entire timing subroutine. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 11:18:54 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 08:05:45 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 11:06:48 edt Date: Thu, 26 Sep 85 11:06 EDT From: Guy Steele Subject: CLtL error re function special form To: smh@MIT-EMS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <8509261201.AA12317@mit-ems.ARPA> Message-Id: <850926110656.6.GLS@DESIDERIUS.THINK.COM> Date: Thu, 26 Sep 85 08:01:25 edt From: Steven Haflich Surely this must have been noticed before, but on page 87: function fn [Special Form] The value of function is always the functional interpretation of fn; fn is interpreted as if it had appeared in the functional-position of a function invocation. In particular, if fn is a symbol, the functional definition associated with that symbol is returned; see symbol-function. If fn is a lambda-expression ... Unlike the function special form, symbol-function does not see lexical function bindings. The reference to symbol-function here was probably intended just to convey the distinction between a symbol's `functional' interpretation and it's `regular' i.e. symbol-value interpretation. But it's wrong, and potentially misleading. Fixing the text is awkward because lexical function binding special forms are not presented until p.113. But CLtL is more of a reference than a teaching manual. Perhaps the reference to symbol function should just be deleted. You're right. The text as it stands is misleading. Thanks for catching it. A similar but less bothersome slip occurs on p.32 about functional data types: A symbol may serve as a function; an attempt to invoke a symbol as a function causes the contents of the symbol's function cell to be used. See symbol-function and defun. I don't regard this one as a slip. In a case such as (cons a b) the symbol CONS is not being invoked as a function; rather, it is evaluated in a functional context to yield a function object, and it is that object that is invoked. In a situation such as (apply 'cons args) then the symbol CONS is invoked as a function (APPLY actually sees the symbol and must dereference it by fetching the function cell); in the context (apply #'cons args) it is not (APPLY never sees the symbol, only the function object). Some examples of this may be needed. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 11:06:35 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:58:04 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:58:56 edt Date: Thu, 26 Sep 85 10:59 EDT From: Guy Steele Subject: More corrections to CLtL To: Steiner@RUTGERS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 26 Sep 85 04:00-EDT from Dave Message-Id: <850926105901.5.GLS@DESIDERIUS.THINK.COM> Date: 26 Sep 85 04:00:01 EDT From: Dave I've found several printing bugs in the format chapter. 1) The code on p. 394 to show the scale factor doesn't work. It should be something like: (dotimes (k 13) (format t "~%Scale factor ~2D:~:* |~13,6,2,VE|" (- k 5) 3.14159)) Ie, Missing % at the beginning and a missing ~:* to back up to the scale factor again (or add (- k 5) as a third arg in the second position and don't include the ~:*). You are quite right. 2) The output to this code with scale factor of 7 is missing a 0 after the decimal point. Ie. |3141590.0E-06|, not | 3141590.E-06|. I disagree. In this case k=7 and d=6. Page 392 specifies that there will be k (7) digits before the decimal point and d-k+1 (0) digits after the decimal point. The requirement on page 393, that a zero digit should appear after the decimal point if permitted by the width constraint, applies only in the case that the parameter d is omitted. 3) The format expr in the function definition of FOO (on p 396) is missing a 4th x arg. Right. ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS ------- Thanks for the corrections. Keep those cards and letters coming! --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 10:58:52 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:50:19 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:51:21 edt Date: Thu, 26 Sep 85 10:51 EDT From: Guy Steele Subject: Discouraged programming practices To: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <850926105132.4.GLS@DESIDERIUS.THINK.COM> Date: Wed, 25 Sep 1985 22:12 EDT From: Rob MacLachlan Another discouraged programming practice is to write (without-interrupts (loop)) as it may be difficult to terminate the execution of this form. WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be. :-)? Rob Maybe we should regard it as a valid compiler optimization to compile this idiom as an exit to the operating system with a message such as "I'm bored. This program will never terminate, so let's do something else." This could give greater credence to the joke about a supercomputer so fast it executes an infinite loop in two seconds. :-? ! --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 10:57:40 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:47:29 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:48:38 edt Date: Thu, 26 Sep 85 10:48 EDT From: Guy Steele Subject: go and return-from inside unwind-protect cleanup To: Moon@SCRC-STONY-BROOK.ARPA, gls@THINK-AQUINAS.ARPA Cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <850925220118.5.MOON@NEPONSET.SCRC.Symbolics.COM> Message-Id: <850926104847.3.GLS@DESIDERIUS.THINK.COM> Date: Wed, 25 Sep 85 22:01 EDT From: David A. Moon Date: Mon, 9 Sep 85 13:01 EDT From: Guy Steele Date: Mon, 9 Sep 85 09:43 EDT From: David C. Plummer in disguise Are the following legal? (defun foo (go-p) (prog nil tag (unwind-protect (return (compute)) (if go-p (go tag))))) (defun bar (return-p) (prog nil tag (unwind-protect (progn (compute) (go tag)) (if return-p (return nil))))) I regard both of these as completely legal. While they may be legal and implementable, I feel that this programming style should be strongly discouraged. For one thing, it can be rather difficult to stop the execution of (FOO T), since any attempt to THROW out of it will simply cause it to re-enter its infinite loop. I agree that GO should not be used capriciously, especially in company with UNWIND-PROTECT. (For some *really* awful code of this type, see the early SCHEME papers.) I do think that the interaction between GO/RETURN and UNWIND-PROTECT should be well-defined, however, because of the following kind of situation: (DEFMACRO HAIRY-PROTECTED-MACRO-WITH-BODY (...) `(UNWIND-PROTECT (PROGN ... ,@BODY) ...)) (TAGBODY ... (HAIRY-PROTECTED-MACRO-WITH-BODY ... (WHEN (GROSS-ME-OUT) (GO LOSE)) ...) ... LOSE (ERROR "I am grossed out.")) The GO ought to work more-or-less as expected; you shouldn't have to know that the macro has an UNWIND-PROTECT in it. On the other hand, the UNWIND-PROTECT must do its job of protecting things, and shouldn't have to know anything special about a GO being in its body. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 10:52:36 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 07:44:50 PDT Received: from hplabs by csnet-relay.csnet id ab17614; 26 Sep 85 10:41 EDT Received: by HP-VENUS id AA26541; Thu, 26 Sep 85 07:16:13 pdt Message-Id: <8509261416.AA26541@HP-VENUS> Date: Thu 26 Sep 85 07:16:07-PDT From: Alan Snyder Subject: Re: missing function: typep-type-p To: smh Cc: common-lisp@su-ai.arpa In-Reply-To: Message from "Steven Haflich " of Thu 26 Sep 85 01:38:35-PDT Source-Info: From (or Sender) name not authenticated. I agree with the desirability of a predicate for testing legal type specifiers. I would call it TYPE-SPECIFIER-P, however. One might also wish to find out more information about a type specifier, such as whether it is a structure type or not and, if so, what type, if any, it is a subtype of. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 10:36:22 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 26 Sep 85 07:27:52 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 26 Sep 85 10:29:02 edt Date: Thu, 26 Sep 85 10:29 EDT From: Guy Steele Subject: Joke To: JAR@MIT-MC.ARPA Cc: gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].659523.850925.JAR> Message-Id: <850926102903.1.GLS@DESIDERIUS.THINK.COM> Date: Wed, 25 Sep 85 18:14:16 EDT From: Jonathan A Rees It was a joke, Guy. Sure fooled me. I figured you just wanted people to know about T as well as various Common Lisps. If you were willing to send the data, I was willing to include it.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 08:08:09 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 05:01:04 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA12317; Thu, 26 Sep 85 08:01:25 edt Date: Thu, 26 Sep 85 08:01:25 edt From: Steven Haflich Message-Id: <8509261201.AA12317@mit-ems.ARPA> To: common-lisp@sail Subject: CLtL error re function special form Surely this must have been noticed before, but on page 87: function fn [Special Form] The value of function is always the functional interpretation of fn; fn is interpreted as if it had appeared in the functional-position of a function invocation. In particular, if fn is a symbol, the functional definition associated with that symbol is returned; see symbol-function. If fn is a lambda-expression ... Unlike the function special form, symbol-function does not see lexical function bindings. The reference to symbol-function here was probably intended just to convey the distinction between a symbol's `functional' interpretation and it's `regular' i.e. symbol-value interpretation. But it's wrong, and potentially misleading. Fixing the text is awkward because lexical function binding special forms are not presented until p.113. But CLtL is more of a reference than a teaching manual. Perhaps the reference to symbol function should just be deleted. A similar but less bothersome slip occurs on p.32 about functional data types: A symbol may serve as a function; an attempt to invoke a symbol as a function causes the contents of the symbol's function cell to be used. See symbol-function and defun.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 07:39:18 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 04:31:55 PDT Received: from hplabs by csnet-relay.csnet id af16310; 26 Sep 85 7:24 EDT Received: by HP-VENUS id AA00218; Wed, 25 Sep 85 16:51:09 pdt Message-Id: <8509252351.AA00218@HP-VENUS> Date: Wed, 25 Sep 85 16:35:06 pdt From: Bob Shaw Received: by HP-MARS id AA24583; Wed, 25 Sep 85 16:35:06 pdt To: common-lisp@su-ai.arpa Subject: disassemble and compile questions Cc: bs@hplabs.CSNET Source-Info: From (or Sender) name not authenticated. I'm in need of enlightenment. The answers to the following two questions are not obvious from my readings of the book. 1. If f is an interpreted function, does (disassemble 'f) cause f to become a compiled function? 2. What is the appropriate way to compile a function object that is not compiled, not a lambda-expression and not the function definition for a symbol? Consider the "lexical closure" example in section 2.13 of CLtL. More on 1: According to CLtl section 25.1, in the definition of disassemble, "The argument should be either a function object, a lambda-expression, or a symbol with a function definition. If the relevent function is not a compiled function, it is first compiled. ... This is primarily useful for debugging the compiler ... ." Side-effecting the function cell by disassembling does not seem like a result I would desire, especially when debugging the compiler. Is (compile 'symbol) or (compile nil (symbol-function 'symbol)) the intended means of compilation? More on 2: The definition of compile states that it will only handle lambda- expressions: "If definition is supplied, it should be a lambda-expression, the interpreted function to be compiled. If it is not supplied, then name should be a symbol with a definition that is a lambda-expression; ... ." Section 2.13 states that lists other than lambda expessions may, in certain implementations, serve as functions. Should the definition of compile include such cases? I hope so. Thanks.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 07:11:30 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 26 Sep 85 04:03:27 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA12169; Thu, 26 Sep 85 07:03:50 edt Date: Thu, 26 Sep 85 07:03:50 edt From: Steven Haflich Message-Id: <8509261103.AA12169@mit-ems.ARPA> To: common-lisp@sail Subject: CLtL ambiguity in trace The description on page 440: trace {function-name}* [Macro] Invoking trace with one or more function names (symbols) causes the functions named to be traced. Henceforth, whenever such a function is invoked ... It is unclear whether the named function may legally be a macro. This obviously-useful feature should not cause problems for any implementation. It should be required, and the manual clarified.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Sep 85 04:08:34 EDT Received: from BLUE.RUTGERS.EDU by SU-AI.ARPA with TCP; 26 Sep 85 01:00:06 PDT Date: 26 Sep 85 04:00:01 EDT From: Dave Subject: More corrections to CLtL To: common-lisp@SU-AI.ARPA Reply-To: Steiner@Rutgers I've found several printing bugs in the format chapter. 1) The code on p. 394 to show the scale factor doesn't work. It should be something like: (dotimes (k 13) (format t "~%Scale factor ~2D:~:* |~13,6,2,VE|" (- k 5) 3.14159)) Ie, Missing % at the beginning and a missing ~:* to back up to the scale factor again (or add (- k 5) as a third arg in the second position and don't include the ~:*). 2) The output to this code with scale factor of 7 is missing a 0 after the decimal point. Ie. |3141590.0E-06|, not | 3141590.E-06|. 3) The format expr in the function definition of FOO (on p 396) is missing a 4th x arg. ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 22:21:26 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 25 Sep 85 19:11:31 PDT Received: ID ; Wed 25 Sep 85 22:12:38-EDT Date: Wed, 25 Sep 1985 22:12 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Discouraged programming practices Another discouraged programming practice is to write (without-interrupts (loop)) as it may be difficult to terminate the execution of this form. WITHOUT-INTERRUPTS is not a part of Common-Lisp, but it should be. :-)? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 22:09:38 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 19:00:36 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321241; Wed 25-Sep-85 22:00:55-EDT Date: Wed, 25 Sep 85 22:01 EDT From: David A. Moon Subject: go and return-from inside unwind-protect cleanup To: Guy Steele cc: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <850909130121.2.GLS@IGNATIUS.THINK.COM> Message-ID: <850925220118.5.MOON@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 9 Sep 85 13:01 EDT From: Guy Steele Date: Mon, 9 Sep 85 09:43 EDT From: David C. Plummer in disguise Are the following legal? (defun foo (go-p) (prog nil tag (unwind-protect (return (compute)) (if go-p (go tag))))) (defun bar (return-p) (prog nil tag (unwind-protect (progn (compute) (go tag)) (if return-p (return nil))))) I regard both of these as completely legal. While they may be legal and implementable, I feel that this programming style should be strongly discouraged. For one thing, it can be rather difficult to stop the execution of (FOO T), since any attempt to THROW out of it will simply cause it to re-enter its infinite loop.  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 21:53:12 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 18:45:46 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321231; Wed 25-Sep-85 21:46:07-EDT Date: Wed, 25 Sep 85 21:46 EDT From: David A. Moon Subject: Returning additional values from advertised functions To: MLY@OZ.MIT cc: common-lisp@SU-AI.ARPA In-Reply-To: <12144601298.71.MLY@MIT-OZ> Message-ID: <850925214630.4.MOON@NEPONSET.SCRC.Symbolics.COM> Date: Thu 19 Sep 85 19:27:24-EDT From: Richard Mlynarik I have been inconvenienced several times recently by the fact the multiple-value-setq is not multiple-value-setf. This is a somewhat curious shortcoming, especially now that the All-New Fashion in lisp code seems to be to entirely eschew setq in favour of setf. (multiple-value-setq (a b c) (foo)) and (setf (values a b c) (foo)) are identical, and the latter allows you to put the values into other places besides variables. The latter form is not standard Common Lisp, but it should be.  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 21:52:02 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 18:44:19 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 321222; Wed 25-Sep-85 21:39:26-EDT Date: Wed, 25 Sep 85 21:39 EDT From: David A. Moon Subject: Lisp Test To: Tim McNerney cc: GJC@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].658760.850925.TIM> Message-ID: <850925213949.3.MOON@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 25 Sep 85 02:59:30 EDT From: Tim McNerney Date: Sun, 22 Sep 85 21:15:09 EDT From: George J. Carrette [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g)) ...(SETF (FUNCTION ...) ...) does not appear to be defined in CLtL. Perhaps you meant to use SYMBOL-FUNCTION instead. Does Common Lisp provide any way to side effect "lexical function cells" such as G above? No. They are constants. (More accurately, they take on a new value every time the FLET is evaluated, but you can't change their value.)  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 18:43:55 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 15:35:17 PDT Date: Wed, 25 Sep 85 18:36:54 EDT From: Jonathan A Rees Subject: Public relations: data so far To: common-lisp@SU-AI.ARPA In-reply-to: Msg of Wed 25 Sep 85 17:39 EDT from Guy Steele Message-ID: <[MIT-MC.ARPA].659546.850925.JAR> Lest anyone be confused about the appearance of T in Guy's list of Common Lisps, I just want to make sure people realize that it was a joke. I intended it to be a cynical comment on the vacuity of the concept of "extended subset". Jonathan  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 17:50:01 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 25 Sep 85 14:38:21 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 25 Sep 85 17:39:13 edt Date: Wed, 25 Sep 85 17:39 EDT From: Guy Steele Subject: Public relations: data so far To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <850925173916.5.GLS@DESIDERIUS.THINK.COM> I have collated the data given to me so far about Common Lisp implementations and have put it into a more-or-less standardized format. The data appears at the end of this message. Some of the information was so incomplete that I could not include it here (though that same information was useful in giving me leads to chase down further). Implementations that I believe to exist in some form but that are not given below, and which I would like to have data on: DEC VAX LISP; Data General; Texas Instruments for Explorer; Intermetrics for IBM 370; Symbolics; LMI; Franz, Inc., for machines other than Tektronix; Gold Hill for IBM PC; MIT NIL for VAX. Please send data if you can! Thanks to all who have responded. Can you please check my summaries for accuracy and completeness? Some respondents sent rather long descriptions that are very interesting but won't fit on a slide. I would be happy to redistribute these long responses to this mailing list, but perhaps it would be more appropriate for the original senders to do so if they wish. (One or two messages contained some data that might be sensitive in the near future, and so I don't want to redistribute the messages wholesale without permission.) --Guy ---------------------------------------------------------------- The data given in my talk will be preceded by a notice such as the following: The following Common Lisp implementation data is provided for purposes of information only. It is accurate and complete to the best of my knowledge, but I (Guy Steele) cannot guarantee that it is correct. I do not speak for or represent the implementors and vendors in any way. If you wish further information, please contact the vendors at the addresses given. ---------------------------------------------------------------- [I realize that the formatting is ugly. I am going to fix it up using TeX or something.] Name: Portable Common Lisp Subset (PCLS, ``pickles'') Supported by: University of Utah Hardware and operating system: Sun, Apollo, HP, Vax/VMS, Vax/Unix, Dec-20, IBM-370/CMS, Cray, Gould Availability: Spring 1986 Full language or subset: subset Missing features: rational and complex numbers, characters, closures. Remarks: PCLS is a subset of Common Lisp that will run in any PSL implementation. Contact: Prof. Robert R. Kessler 3160 M.E.B. Department of Computer Science University of Utah Salt Lake City, Utah 84112 USA Name: Gould Common Lisp Supported by: Gould Electronics, Computer Systems Division Hardware and operating system: Gould Powernode 9000 and 6000 series with UTX-32 (UNIX 4.2BSD with System V enhancements) Availability: 1986 Full language or subset: full Remarks: Ability to call C and Fortran functions from within Lisp. Contact: International Sales and Marketing Gould Computer Systems Division 6901 W. Sunrise Blvd. Fort Lauderdale, Florida 33313 USA Name: Hewlett Packard Development Environment for Common Lisp Supported by: Hewlett Packard, Fort Collins Systems Division Hardware and operating system: HP 9000 models 310 (68010-based) and 320 (68020-based) with HP-UX (UNIX System V plus Berkeley enhancements) Availability: January 1986 Full language or subset: full Remarks: EMACS-like editor with browsers. Support for object-oriented programming. Not based on CMU implementation. Contact: Mike Bacco, AI Products Manager (marketing) or Roger Ison, Project Manager (technical) Ft. Collins Systems Division Hewlett Packard Company Ft. Collins, Colorado 80525 USA (303) 226-3800 Name: TekCommonLisp Implemented by: Tektronix, Inc., in conjunction with Franz, Inc. Supported by: Tektronix, Inc. Hardware and operating system: Tektronix 4404 (68010-based), 4405, 4406 (68020-based) Availability: First quarter 1986 Full language or subset: full Remarks: Flavors, calls to functions in other programming languages, Lisp structure editor, and other utilities. Contact: Mike Taylor Marketing Manager Artificial Intelligence Machines Group Tektronix Inc. PO Box 1000, MS 60-405 Wilsonville, Oregon 97070 USA (503) 685-2942 Franz, Inc. 1141 Harbor Bay Parkway, Alameda, California 94501 USA (415) 769-5656. Name: ETI Lisp (formerly called Spice Lisp) Implemented by: Carnegie-Mellon University Supported by: Expert Technologies, Inc. Hardware and operating system: PERQ with Accent version S6 (release 2) Availability: now Full language or subset: subset Missing features: complex numbers Remarks: Flavors, remote process spawning, remote procedure calls, HEMLOCK (EMACS-like editor). Contact: Joseph R. Ginder Expert Technologies, Inc. 461 Melwood Avenue Pittsburgh, Pennsylvania 15213 USA For the UK and Europe: Roger Vinnecombe Advent, Ltd. 12 The Business Centre Molley Millars Lane Wokingham, Berkshire RG11 2RT ENGLAND Name: Sun Common Lisp Implemented by: Lucid, Inc. Supported by: Sun Hardware and operating system: Sun workstation (68xxx-based) with UNIX Availability: December 1985 (in USA) Full language or subset: full Remarks: Calls to functions in other programming languages. By August 1986 are expected editor, windows, object-oriented programming. Contact: ??? Name: Apollo Common Lisp Implemented by: Lucid, Inc. Supported by: Apollo Hardware and operating system: Apollo workstation (68xxx-based) with Aegis and DomainIX Availability: January 1986 (in USA) Full language or subset: full Remarks: Calls to functions in other programming languages. By August 1986 are expected editor, windows, object-oriented programming. Contact: ??? Name: Prime Common Lisp Implemented by: Lucid, Inc. Supported by: Prime Hardware and operating system: Prime 50 series with Primos (IX mode) Availability: to be determined Full language or subset: full Remarks: Calls to functions in other programming languages. By August 1986 are expected editor, object-oriented programming. Contact: ??? Name: Symbolics Cross Compiler for Sun and Apollo Implemented by: Lucid, Inc. Supported by: Symbolics, Inc. Hardware and operating system: Symbolics 3600 Availability: March 1986 Full language or subset: full Contact: ??? Name: T Implemented by: Yale University Supported by: unsupported Hardware and operating system: Apollo (68000-based), VAX with UNIX, VAX with VMS Availability: now Full language or subset: incompatible subset Missing features: DEFUN, FUNCTION, arrays, sequences, packages, and others No plans to implement missing features. Remarks: T is more closely related to SCHEME than to Common Lisp. Features include tail recursion, single function/variable namespace, lexical environments used instead of packages, LAMBDA special form, NIL is different from (). Contact: Jim Philbin Yale University New Haven, Connecticut 06520 USA Philbin-Jim@Yale.ARPA  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 17:16:08 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 11:53:05 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA07882; Wed, 25 Sep 85 14:53:27 edt Date: Wed, 25 Sep 85 14:53:27 edt From: Steven Haflich Message-Id: <8509251853.AA07882@mit-ems.ARPA> To: common-lisp@su-ai Subject: missing function: typep-type-p It is an error if the "typep" and "subtypep" functions are passed something other than a valid type specifier. The set of valid type specifiers is extensible by defstruct (and possibly by some proposed active object extensions). However, there appears to be no way to determine if an arbitrary expression is a valid second argument to typep (or declaration type, or first argument to the "the" special form). Sometimes one might need to know -- for instance, to determine if a "foo" defstruct has ever been defined. I can think of no non-implementation-dependent way to find out. By the way, typep is not required to signal an error if passed an invalid type specifier, so it might return t, or nil, or whatever. I suggest a new predicate with an ugly name: typep-type-p expr [Function] The expr can be anything at all, and this predicate is true iff expr is a valid type specifier in the current Lisp world.  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 15:57:09 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 11:31:16 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA07704; Wed, 25 Sep 85 14:31:20 edt Date: Wed, 25 Sep 85 14:31:20 edt From: Steven Haflich Message-Id: <8509251831.AA07704@mit-ems.ARPA> To: KESSLER@UTAH-20.ARPA, common-lisp@SU-AI.ARPA Subject: Re: Argument Type Mismatch Errors From: Robert R. Kessler Subject: Argument Type Mismatch Errors Since the standard doesn't say that an error is required, couldn't one write a legal implementation of CL where it ignores the offending argument? CLtL section 1.2.4 (pg.5) precisely defines what is required of an implementation. The short answer to your question is, yes, you can write a valid CL with an append that ignores invalid arguments, but you *cannot* write a valid CL program that exploits this behaviour! Unofficially: An implementation obviously should detect and signal errors when convenient. The primary force against always doing so is run-time efficiency. Personally, I feel that once an implementation detects an error such as an inappropriate argument type, it should always signal the error rather than silently proceeding. There's no reason not to signal the error, assuming the price of detecting it has already been paid.  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 12:55:34 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 25 Sep 85 09:46:08 PDT Date: Wed 25 Sep 85 10:46:19-MDT From: Robert R. Kessler Subject: Argument Type Mismatch Errors To: common-lisp@SU-AI.ARPA Message-ID: <12146101145.24.KESSLER@UTAH-20.ARPA> Is there any agreement as to what a CL system should do when a type error occurs? What I am thinking about are things like append, which specifies that all arguments (except) the last are to be lists. If one element is not a list should an error occur? In Hedrick's Dec-20 CL, it does cause an error. Since the standard doesn't say that an error is required, couldn't one write a legal implementation of CL where it ignores the offending argument? Along similar lines is our PCLS implementation of the package system. Packages are implemented as defstructs, so if a non package argument is passed to a function that expect the package, our system currently causes an error as it tries to access a field in the defstruct (defstructs are vectors so the error message says something like illegal to index non vector `bar'). At least in this case it gets an error, although one that could be confusing to the programmer. [The obvious reason for not type checking that the argument is in fact a package defstruct is because of efficiency.] Thanks. Bob. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 03:06:21 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Sep 85 23:57:56 PDT Date: Wed, 25 Sep 85 02:59:30 EDT From: Tim McNerney Subject: Lisp Test To: GJC@MIT-MC.ARPA cc: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of Sun 22 Sep 85 21:15:09 EDT from George J. Carrette Message-ID: <[MIT-MC.ARPA].658760.850925.TIM> Date: Sun, 22 Sep 85 21:15:09 EDT From: George J. Carrette [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g)) George, I had been wondering about this for a while. I thought that FUNCTION might be magic, but (SETF (FUNCTION ...) ...) does not appear to be defined in CLtL. Perhaps you meant to use SYMBOL-FUNCTION instead. If so, it would indeed make a good teaser for testing to see if people had carefully read page 90. Folks, Does Common Lisp provide any way to side effect "lexical function cells" such as G above?  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Sep 85 00:42:42 EDT Date: 24 Sep 85 2129 PDT From: Dick Gabriel Subject: Meeting To: common-lisp@SU-AI.ARPA It being a year since the last Common Lisp Meeting, I would like to propose a second meeting. To be accurate, DARPA has suggested that someone ought to propose a second meeting. I think we are in a position to finally settle the following questions: 1) How shall the charter be constructed for Common Lisp? 2) Are we all agreed that the minor changes to Common Lisp, especially the errata, are to be part of the Common Lisp standard? 3) Shall we adopt an error handling facility? I think we can have reasonable discussions on the following: 1) How shall windows be handled? 2) Shall we agree to experiment with CommonLoops (appropriately named) as the object-oriented programming paradigm? There are several new topics that deserve discussion: 1) What shall be our approach to ANSI standardization. 2) How shall we handle changes to the Common Lisp book? (This topic includes copyright questions that have come up). I have some thoughts as to the organization of the meeting and other administrative details. First, the meeting would best be held on the East Coast - it was held in Monterey, California last year. Second, attendance should be limited to 2 or 3 representatives from each organization. This rule will help us to keep the discussions from getting out of control. I would be willing to let more people attend the meeting, but restrict commentary to a small number of people. If only 2 people are allowed, we should probably leave the actual decisions to a written ballot after the meeting, with advisory votes at the meeting. Third, the meeting should be held at a location that is easily accessible. Several possibilities that come to mind are Washington, New York, and Boston. Fourth, I think that the meeting should be held towards the end of November, so that there is plenty of time to arrange schedules. Fifth, I think we should decide on the above before the end of September. Please mail to me (RPG@SAIL) your responses to these ideas, and I will attempt to coalesce them into some sort of decision or into a condensed set of issues for all of us to consider - I want to keep the discussion about the meeting streamlined. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Sep 85 17:37:43 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 23 Sep 85 14:25:05 PDT Received: from sebastian by GODOT.THINK.COM via CHAOS; Mon, 23 Sep 85 17:26:11 edt Date: Mon, 23 Sep 85 17:25 EDT From: Guy Steele Subject: Public relations: second time around To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <850923172551.4.GLS@SEBASTIAN.THINK.COM> This is a retransmission of an earlier note requesting information on Common Lisp implementations. So far I have gotten NO replies. Am I to assume that no one wants to be mentioned when I talk in Japan? I could make up a list without any help, but it would probably have holes and stale information in it. I really do want to use accurate information, but I need this information by Thursday, September 26, to be useful. Please help me out. --Thanks, Guy ---------------------------------------------------------------------- I am seeking summary data about existing Common Lisp implementations. I am planning to travel to Japan in October and give seminars there about Common Lisp. (This is in connection with the recent publication of the Japanese translation by Dr. Masayuki Ida of the Common Lisp manual.) While most of the content will be technical, I will surely be asked about existing implementations, particularly those in the United States. I would like to be accurate and complete, and so I need your help. If you are supporting an implementation of Common Lisp (or a subset), could you please send me the following information about it? (1) Name of implementation (2) Name of support organization (implementor, vendor, or whatever) (3) Hardware configuration(s) and operating system(s) (4) Available now? If not, when? (5) Full Common Lisp or subset? (6) If a subset, what's missing? Will missing parts be implemented later? (7) (optional) Address of support organization or other contact (8) (optional) Any interesting language extensions or applications packages you want mentioned? This won't be a sales presentation, and I won't recommend any implementation over any other, so I'm not interested in prices. (Actually, I am, but if you send me price information I won't use it in these seminars.) I intend simply to present a list, both on overhead transparencies during my talk and in hardcopy form. I think it would give Common Lisp a boost to have a nice long list of implementors to show off. I have also requested my contacts in Japan to prepare a similar list of Japanese implementations, and I will report any information received to this mailing list. Thank you for your help. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Sep 85 14:45:43 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 Sep 85 11:31:38 PDT Received: from WHITE.SWW.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 204097; Mon 23-Sep-85 14:31:34-EDT Received: from SWW-PURPLE by SWW-WHITE via CHAOS with CHAOS-MAIL id 139578; Mon 23-Sep-85 11:36:30-PDT Date: Mon, 23 Sep 85 11:33 PDT From: DDYER@SCRC-RIVERSIDE.ARPA Subject: Lisp Test To: George J. Carrette , common-lisp@SU-AI.ARPA Fcc: W:>ddyer>mail.sent In-Reply-To: <[MIT-MC.ARPA].654263.850922.GJC> Message-ID: <850923113338.7.DDYER@PURPLE.SWW.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Sun, 22 Sep 85 21:15:09 EDT From: George J. Carrette Here are some questions I'm thinking about putting into a lisp teasers test. In order so that I can get an idea of how difficult the questions are, please reply with your answers. Take no longer than 4 minutes. What are the return values of the following expressions when evaluated: [1] (let ((x (list nil))) (car x)) nil [2] (let ((x (list nil))) (setf (car x) 5) (car x)) 5 [3] (flet ((g () 5)) (g)) 5 [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g)) 7 Except, it actually returns 5, and the global function (g) returns 7. This has to be a bug.  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Sep 85 21:54:23 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85 18:46:32 PDT Received: ID ; Sun 22 Sep 85 21:47:25-EDT Date: Sun, 22 Sep 1985 21:47 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: common-lisp@SU-AI.ARPA Subject: Lisp Test -- oops! In-reply-to: Msg of 22 Sep 1985 21:15-EDT from George J. Carrette Sorry, I meant to send that just to GJC and not to the whole list, but I hit the wrong key. Hope I didn't spoil the fun. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Sep 85 21:51:50 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Sep 85 18:45:05 PDT Received: ID ; Sun 22 Sep 85 21:46:04-EDT Date: Sun, 22 Sep 1985 21:46 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: common-lisp@SU-AI.ARPA Subject: Lisp Test In-reply-to: Msg of 22 Sep 1985 21:15-EDT from George J. Carrette [1] (let ((x (list nil))) (car x)) nil [2] (let ((x (list nil))) (setf (car x) 5) (car x)) 5 [3] (flet ((g () 5)) (g)) 5 [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g)) error The error is "FUNCTION not a SETF-able form." or words to that effect. If in 4 you meant to setf (symbol-function 'g), then the answer is 5. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 22 Sep 85 21:21:01 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Sep 85 18:14:30 PDT Date: Sun, 22 Sep 85 21:15:09 EDT From: George J. Carrette Subject: Lisp Test To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].654263.850922.GJC> Here are some questions I'm thinking about putting into a lisp teasers test. In order so that I can get an idea of how difficult the questions are, please reply with your answers. Take no longer than 4 minutes. What are the return values of the following expressions when evaluated: [1] (let ((x (list nil))) (car x)) [2] (let ((x (list nil))) (setf (car x) 5) (car x)) [3] (flet ((g () 5)) (g)) [4] (flet ((g () 5)) (setf #'g #'(lambda () 7)) (g))  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Sep 85 17:15:55 EDT Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 21 Sep 85 13:50:13 PDT Received: by su-navajo.arpa with Sendmail; Sat, 21 Sep 85 13:47:40 pdt Received: by edsel.uucp (2.0/SMI-2.0) id AA28888; Sat, 21 Sep 85 13:41:51 pdt Date: Sat, 21 Sep 85 13:41:51 pdt From: edsel!jim@su-navajo.arpa (Jim McDonald) Message-Id: <8509212041.AA28888@edsel.uucp> To: navajo!common-lisp@su-ai Subject: listen, etc. CLtL currently says "The predicate LISTEN is true if there is a character immediately available from input-stream, and false if not." This precludes any reasonable use for LISTEN on non-character streams, which seems to me to be a flaw. It is not hard to imagine a program that loads binary data from a network while carrying on other tasks (like responding to the user!) during the pauses between arrival of packets. There might even be non-character, non-byte streams that act as pipes or queues of complex objects. It would be useful if LISTEN could be used to poll arbitrary input streams, even if many such applications might be handled better by interrupt-driven routines. Are there any objections to changing the definition to say "The predicate LISTEN is true if a transaction datum is immediately available from input-stream, and false if not."? Note that with this revised definition, READ-CHAR-NO-HANG and potential, analogous, routines such as READ-BYTE-NO-HANG would be too specialized to define LISTEN. Thus as long as the change I propose is not completely ruled out, it would be premature to define LISTEN in terms of READ-CHAR-NO-HANG. --- In a similar vein, the book groups CLEAR-INPUT among those routines that act on character streams, but the definition itself does not seem to imply that the stream must be a character stream. Likewise, FINISH-OUTPUT, FORCE-OUTPUT, and CLEAR-OUTPUT are grouped with functions on character streams, but seem to be reasonable for arbitrary output streams. I propose that such routines should work for all streams with the appropriate direction. Could someone involved with their definition clarify this? --- Would READ-DATUM, PEEK-DATUM, READ-DATUM-NO-HANG, and UNWRITE-DATUM be appropriate stream functions, with -CHAR- and -BYTE- forms available for clarity and/or efficiency? --- Finally, have there been any proposals for mechanisms to create non-character, non-byte streams, and if not, is it due to lack of interest or lack of agreement? I think a good queueing primitive would find many uses. Jim McDonald  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Sep 85 14:50:03 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Sep 85 07:29:05 PDT Date: Sat, 21 Sep 85 10:31:45 EDT From: robbins@DEC-HUDSON Subject: LISTEN Proposal To: common-lisp@su-ai Cc: GSB@MIT-MC Obviously there is no pressing need to do anything to the current definition of LISTEN. However, I think that it is kind of strange to have a pair of similar functions whose definitions are just inconsistent enough so that the "intuitive" implementation of one fails. ... one can always do (defun listen (&optional (input-stream *standard-input*)) (let ((char (read-char-no-hang stream nil nil))) (cond ((null char) nil) (t (unread-char char) t)))) I agree that this will work just fine. Am I the only one who objects to the extra IO implicit in this definition? From the definition of READ-CHAR-NO-HANG CLtL page 380: "LISTEN does not distinguish between end-of-file and no input being available, whereas READ-CHAR-NO-HANG does make that distinction returning EOF-VALUE at end-of-file ..." Is there a good reason for this seemingly gratuitous inconsistency in the language?  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Sep 85 02:19:08 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 23:12:17 PDT Date: Sat, 21 Sep 85 02:12:53 EDT From: Glenn S. Burke Subject: Modification to LISTEN To: robbins@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].653117.850921.GSB> Aside from some already mentioned reasons, one can always do (defun listen (&optional (input-stream *standard-input*)) (let ((char (read-char-no-hang stream nil nil))) (cond ((null char) nil) (t (unread-char char) t)))) instead of the other way around, without changing the definition of anything.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 20:29:36 EDT Date: 20 Sep 85 1702 PDT From: Martin Frost Subject: EQUAL isn't really correct, I agree Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85 19:37:44 PDT Received: ID ; Tue 17 Sep 85 22:38:35-EDT Date: Tue, 17 Sep 1985 22:38 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Rem@MIT-MC.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: EQUAL isn't really correct, I agree Comment: Remailed at SU-AI after delay caused by distribution list problem. Once this super-general function is properly defined and implemented, special cases can be described in a uniform way as canned arguments to this function, and then can be handcoded more efficiently if desired. In many cases there are oodles of special-case functions and nothing properly general in CL currently. Perhaps general functions should be defined and some of the special cases flushed, as such cases are recognized? Super-general-EQUAL could be the first such super-general function? Gee, maybe we should provide COND and DEFMACRO and let the user code up whatever equality predicate he really wants. Would that be general enough? Oops, we did that already... But seriously, it is a very serious step to put in some piece of special-purpose programmable mechanism for some random part of the language. This might be called for in the case of iteration (if we could ever agree on a syntax for something like the loop macro), but I can't see any compelling reason to put in yet another load of hair for a customizable equality predicate. If there are kinds of equality that are FREQUENTLY needed and are not currently provided (and I think there are a couple) we should consider adding these, but let's not go overboard (yet again). -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 16:56:46 EDT Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 13:48:14 PDT Received: by glacier with Sendmail; Fri, 20 Sep 85 13:48:20 pdt Received: from escargot.UUCP (escargot.ARPA) by mips.UUCP (4.12/4.7) id AA00574; Fri, 20 Sep 85 12:21:37 pdt Received: by escargot.UUCP (4.12/4.7) id AA09473; Fri, 20 Sep 85 13:05:36 pdt Date: Fri, 20 Sep 85 13:05:36 pdt From: mips!escargot.earl@glacier (Earl Killian) Message-Id: <8509202005.AA09473@escargot.UUCP> To: Common-Lisp@SU-AI.ARPA In-Reply-To: "Scott E. Fahlman"'s message of Thu, 19 Sep 1985 21:19 EDT Subject: Arguments and values to get. When you really need to know whether the value was present in the property list or not, I agree that the &OPTIONAL default argument to GET is painful. Other times, however, it is exactly what you want (you really just want a default value), and implementing the default from a second return value is painful. Thus the current definition is not a mistake, although it may not be featureful enough.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 15:31:53 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85 12:21:31 PDT Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:22:35 edt Date: Fri, 20 Sep 85 15:22 EDT From: Guy Steele Subject: erratum: logic error on p.125 To: DLW@SCRC-QUABBIN.ARPA, sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <850920103525.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <850920152246.3.GLS@JEHOSEPHAT.THINK.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Fri, 20 Sep 85 10:35 EDT From: Daniel L. Weinreb .... There is, however, a picotypo in this example: the introductory text says "...suppose that ENV holds a list of conses...", but the example doesn't use the variable ENV anywhere. (Do I get the "picky, picky" award for submitting the most trivial erratum?) It's as legitimate a typo as anything else. Do I get an award for generating the trivial error in the first place? --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 15:30:09 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85 12:19:48 PDT Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:20:46 edt Date: Fri, 20 Sep 85 15:20 EDT From: Guy Steele Subject: erratum: logic error on p.125 To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 19 Sep 85 20:58-EDT from S Sridhar Message-Id: <850920152057.2.GLS@JEHOSEPHAT.THINK.COM> Date: Thursday, 19 Sep 85 17:58:26 PDT From: S Sridhar On p.125 about the middle of the page in the ribcage-lookup function in the scope of the second do: REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v))) [the cdar is replaced by cadar] Thank you for your comment. The code as it stands is consistent with the description in the preceding paragraph, and in particular with the remark that the ribcage resembles an association list. There are two styles of coding that I have observed people using in LISP code with respect to associating lists. One is the traditional a-list: ((A . B) (C . D) (E . F)) The other is similar, but uses 2-lists instead of dotted pairs: ((A B) (C D) (E F)) The first saves CONS cells, but is more complicated to print. The second looks neater, but takes more memory space and requires extra CAR operations to access. I think this latter style has been promulgated by the SCHEME community in particular. Either is fine, but the example was intended to use the first style of list. Perhaps more explanation is needed for this example. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 15:23:30 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 20 Sep 85 12:15:18 PDT Received: from jehosephat by GODOT.THINK.COM via CHAOS; Fri, 20 Sep 85 15:16:10 edt Date: Fri, 20 Sep 85 15:16 EDT From: Guy Steele Subject: Erratum on p.107Subject: To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 19 Sep 85 13:09-EDT from S Sridhar Message-Id: <850920151620.1.GLS@JEHOSEPHAT.THINK.COM> Date: Thursday, 19 Sep 85 10:09:07 PDT From: S Sridhar On p.107 at the bottom of the page where the setq's and apply's occur: Replace respectively: (setq f '+) ... and (apply 'cons ...) BY (setq f #'+) ... and (apply #'cons ...) This will improve consistency of syntax for function symbols. Sridhar ...!tektronix!tekchips!sridhar Thank you for your comment. The examples are indeed inconsistent as to style, but all are legitimate. The cases without #' were intended to demonstrate that it is legitimate to give a symbol to APPLY, and it will implicitly "dereference" the symbol by looking at its global functional value. Some remarks to this effect shou;ld be added in the prose to elucidate this. Depending on one's purpose, one may wish to use ' or #'. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 10:48:09 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 07:40:56 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317634; Fri 20-Sep-85 10:40:00-EDT Date: Fri, 20 Sep 85 10:37 EDT From: Daniel L. Weinreb Subject: Erratum on p.107Subject: To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 19 Sep 85 13:09-EDT from S Sridhar Message-ID: <850920103750.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Thursday, 19 Sep 85 10:09:07 PDT From: S Sridhar On p.107 at the bottom of the page where the setq's and apply's occur: Replace respectively: (setq f '+) ... and (apply 'cons ...) BY (setq f #'+) ... and (apply #'cons ...) This will improve consistency of syntax for function symbols. This is not an error. Read the textual description of "apply". The description explicitly mentions that you can use a symbol as the first argument to apply, and gives some rules about doing so. The examples that you're referring to were included to illustrate the use of symbols as functions. That is, the number-signs were omitted intentionally.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 10:44:25 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 07:37:32 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317626; Fri 20-Sep-85 10:37:37-EDT Date: Fri, 20 Sep 85 10:35 EDT From: Daniel L. Weinreb Subject: erratum: logic error on p.125 To: sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 19 Sep 85 20:58-EDT from S Sridhar Message-ID: <850920103525.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Thursday, 19 Sep 85 17:58:26 PDT From: S Sridhar On p.125 about the middle of the page in the ribcage-lookup function in the scope of the second do: REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v))) [the cdar is replaced by cadar] I don't think so. It appears to me that the example is correct. Read the text above the example carefully. It says "...the cdr of each cons is a list...". That is, the elements of the top-level lists are conses, not two-element lists. There is, however, a picotypo in this example: the introductory text says "...suppose that ENV holds a list of conses...", but the example doesn't use the variable ENV anywhere. (Do I get the "picky, picky" award for submitting the most trivial erratum?)  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 10:17:54 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 07:08:53 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 317574; Fri 20-Sep-85 10:09:02-EDT Date: Fri, 20 Sep 85 10:09 EDT From: Kent M Pitman Subject: Arguments and values to get. To: Fahlman@C.CS.CMU.EDU, Gregor.pa@XEROX.ARPA cc: cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: References: Msg of 19 Sep 85 19:39-EDT from Gregor.pa at Xerox.ARPA Message-ID: <850920100928.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu, 19 Sep 1985 21:19 EDT From: "Scott E. Fahlman" To: Gregor.pa@XEROX.ARPA In-reply-to: Msg of 19 Sep 1985 19:39-EDT from Gregor.pa at Xerox.ARPA Why does Common-Lisp GET take a default-value argument instead of returning a second value indicating whether the property actually exists? The default argument is useful in some cases, but admittedly is a bit inelegant -- if you want to know for sure whether a value was found, you have to be careful to choose some default argument that couldn't possibly be stored in any property list. The reasoning (If I recall it correctly) was that this occasional creation of a unique default is less hassle than having to write an ugly multiple-value-bind every time we want to return a default value in the property-not-found case. I'm not sure I believe that any more. -- Scott It would be reasonable to propose a more-or-less upward-compatible extension to GET (for CL86 or whatever) which provided that GET both accepted a argument specifying the default to be used -and- returned two values (one the result, the second a boolean saying whether the argument had been defaulted).  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 09:56:16 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 06:51:02 PDT Received: from tektronix by csnet-relay.csnet id aa04939; 20 Sep 85 9:46 EDT From: S Sridhar To: common-lisp@su-ai.ARPA Fcc: cl-mail Received: from tekchips by tektronix with smtp ; 19 Sep 85 18:03:46 PDT Date: Thursday, 19 Sep 85 17:58:26 PDT Subject: erratum: logic error on p.125 On p.125 about the middle of the page in the ribcage-lookup function in the scope of the second do: REPLACE (v (cdar r) (cdr v))) BY (v (cadar r) (cdr v))) [the cdar is replaced by cadar]  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Sep 85 09:54:34 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 Sep 85 06:49:52 PDT Received: from tektronix by csnet-relay.csnet id ae04939; 20 Sep 85 9:43 EDT From: S Sridhar To: common-lisp@su-ai.ARPA Fcc: cl-mail Received: from tekchips by tektronix with smtp ; 19 Sep 85 10:13:47 PDT Date: Thursday, 19 Sep 85 10:09:07 PDT Subject: Erratum on p.107Subject: On p.107 at the bottom of the page where the setq's and apply's occur: Replace respectively: (setq f '+) ... and (apply 'cons ...) BY (setq f #'+) ... and (apply #'cons ...) This will improve consistency of syntax for function symbols. Sridhar ...!tektronix!tekchips!sridhar  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Sep 85 21:50:36 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Sep 85 18:19:31 PDT Received: ID ; Thu 19 Sep 85 21:19:45-EDT Date: Thu, 19 Sep 1985 21:19 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Gregor.pa@XEROX.ARPA Cc: cl-object-oriented-programming@SU-AI.ARPA, Common-Lisp@SU-AI.ARPA Subject: Arguments and values to get. In-reply-to: Msg of 19 Sep 1985 19:39-EDT from Gregor.pa at Xerox.ARPA Why does Common-Lisp GET take a default-value argument instead of returning a second value indicating whether the property actually exists? The default argument is useful in some cases, but admittedly is a bit inelegant -- if you want to know for sure whether a value was found, you have to be careful to choose some default argument that couldn't possibly be stored in any property list. The reasoning (If I recall it correctly) was that this occasional creation of a unique default is less hassle than having to write an ugly multiple-value-bind every time we want to return a default value in the property-not-found case. I'm not sure I believe that any more. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Sep 85 21:30:00 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 19 Sep 85 17:58:09 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 85 17:43:45 PDT Date: 19 Sep 85 16:39 PDT Sender: bobrow.pa@Xerox.ARPA Subject: Arguments and values to get. To: Common-Lisp@SU-AI.ARPA cc: cl-object-oriented-programming@su-ai.ARPA From: Gregor.pa@Xerox.ARPA Message-ID: <850919-174345-1059@Xerox> This (admittedly minor) question came up while we were writing up some of the CommonLoops metaclass protocols. Why does Common-Lisp GET take a default-value argument instead of returning a second value indicating whether the property actually exists? Originally we had wanted to make CommonLoops' internal slot-access function return a second value saying whether or not the slot-existed but we ended up changing it to be more like GET.  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Sep 85 20:49:59 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Sep 85 16:25:52 PDT Date: Thu 19 Sep 85 19:27:24-EDT From: Richard Mlynarik Subject: Returning additional values from advertised functions Sender: MLY%MIT-OZ@MIT-MC.ARPA To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Reply-To: MLY@MIT-OZ In-Reply-To: Message-ID: <12144601298.71.MLY@MIT-OZ> Date: Wed, 18 Sep 1985 12:56 EDT From: "Scott E. Fahlman" To: robbins@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Modification to LISTEN In-reply-to: Msg of 18 Sep 1985 11:07-EDT from robbins at DEC-HUDSON I would like to have LISTEN return two values. [...] Looks like a good suggestion to me. It could be implemented in a completely upward-compatible way. I am a little worried about this answer. The existence of the multiple-value-call special form means that no such change can truly be made upward-compatibly. The lisp I maintain has a number of functions which return useful, additional values (though usually somewhat too implementation-specific or marginal to be advocated as a an enhancement for "official" cl) beyond those specified by GSSB, and I am somewhat loathe to flush them simply for compatibility when I am sure that most receivers of multiple values are either multiple-value-bind/setq's. I remember that at the time of the initial discussion of the cl multiple-value scheme there were a number of people (kmp stands out most distinctly in my memory) who advocated as rigorous checking in receiving multiple values from calls as in receiving arguments to calls. Perhaps they were right. As it stands, I think that anybody using multiple-value-call is except in very constrained situations is probably Courting Lossage Just a point to bear in mind.... [BTW I have been inconvenienced several times recently by the fact the multiple-value-setq is not multiple-value-setf. This is a somewhat curious shortcoming, especially now that the All-New Fashion in lisp code seems to be to entirely eschew setq in favour of setf] -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Sep 85 12:27:10 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 19 Sep 85 07:02:43 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Thu, 19 Sep 85 10:03:33 edt Date: Thu, 19 Sep 85 10:03 EDT From: Guy Steele Subject: Erratum To: wagner@GSWD-VMS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 18 Sep 85 18:16-EDT from wagner at GSWD-VMS Message-Id: <850919100326.1.GLS@DESIDERIUS.THINK.COM> Date: Wed, 18 Sep 85 17:16:00 CDT From: wagner@GSWD-VMS On the top of page 295 of CLtL, three examples are given for the bit-array logic functions. The third example is (bit-andc1 #*1100 #*1010) => #*0100 Given the definition of BIT-ANDC1 on page 294 ("and complement argument1 with argument2"), this example is in error. Either the function should be BIT-ANDC2, or the return value should be #*0010. Fran Right you are. Thanks. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 21:35:30 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 18:22:22 PDT Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 316386; Wed 18-Sep-85 21:18:44-EDT Date: Wed, 18 Sep 85 21:22 EDT From: Mike McMahon Subject: Modification to LISTEN To: Scott E. Fahlman cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850918212239.2.MMCM@MERRIMACK.SCRC.Symbolics.COM> Date: Wed, 18 Sep 1985 12:56 EDT From: "Scott E. Fahlman" I would like to have LISTEN return two values. The first value is the same as it is now and the second value is true if end of file is encountered. The new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR and LISTEN. Looks like a good suggestion to me. It could be implemented in a completely upward-compatible way. In good lisp machine style, programs use both READ-CHAR-NO-HANG and LISTEN. LISTEN is treated only as a (possibly spurious) wakeup. Imagine a network stream interface, where LISTEN returns when some packet-ready-for-reciept hardware flag gets set. READ-CHAR-NO-HANG might return NIL if the packet that it reads out is damaged, out of sequence, etc. The rule is that LISTEN is allowed to return T when READ-CHAR-NO-HANG will return NIL, provided that READ-CHAR-NO-HANG will tend to clear the spurious condition. I'm not sure this advocates against the above proposal, but I do feel that there is good reason for having both primitives.  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 18:24:16 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 15:16:22 PDT Date: Wed, 18 Sep 85 17:16:00 CDT From: wagner@GSWD-VMS Subject: Erratum To: common-lisp@su-ai.arpa Cc: wagner On the top of page 295 of CLtL, three examples are given for the bit-array logic functions. The third example is (bit-andc1 #*1100 #*1010) => #*0100 Given the definition of BIT-ANDC1 on page 294 ("and complement argument1 with argument2"), this example is in error. Either the function should be BIT-ANDC2, or the return value should be #*0010. Fran  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 17:25:36 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 18 Sep 85 14:14:37 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 18 Sep 85 17:15:28 edt Date: Wed, 18 Sep 85 17:15 EDT From: Guy Steele Subject: Concatenated Stream Query To: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <850918161848.7.SOLEY@CHERRY.MIT> Message-Id: <850918171522.6.GLS@DESIDERIUS.THINK.COM> I am in agreement with Fahlman and Soley on this matter. The manual should be clearer on the point that the user of a concatenated stream does not see any end-of-file indication when subsidiary streams other than the last hit end of file. However, the manual certainly does not support the implicit inclusion of any additional separator characters or other such phenomena as one subsidiary stream ends and the next one comes into use. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 16:26:55 EDT Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 13:18:49 PDT Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 8171; Wed 18-Sep-85 16:20:33-EDT Date: Wed, 18 Sep 85 16:18 EDT From: Soley@MIT-MC.ARPA Subject: Concatenated Stream Query To: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 18 Sep 85 15:50-EDT from robbins at DEC-HUDSON Message-ID: <850918161848.7.SOLEY@CHERRY.MIT> Date: Wed, 18 Sep 85 15:50:09 EDT From: robbins@DEC-HUDSON Subject: Concatenated Stream Query To: common-lisp@su-ai Cc: robbins Given the following streams: (setf stream-1 (make-string-input-stream "A line without a newline.")) (setf stream-2 (make-string-input-stream "Our generic second line.")) (setf stream-3 (make-concatenated-stream stream-1 stream-2)) What should (read-line stream-3) return, I can imagine two possibilities (1) "A line without a newline.Our generic second line." t (2) "A line without a newline." nil I think it definitely MUST return (1). Consider (setf stream-1 (make-string-input-stream "A line without a newline. ")) (setf stream-2 (make-string-input-stream "Our generic second line.")) (setf stream-3 (make-concatenated-stream stream-1 stream-2)) which should return (2). [The next (read-line stream-3) shouldn't return "", but {"Our generic second line.", t}. -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 16:19:59 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85 13:11:27 PDT Received: ID ; Wed 18 Sep 85 16:12:08-EDT Date: Wed, 18 Sep 1985 16:12 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: robbins@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Concatenated Stream Query In-reply-to: Msg of 18 Sep 1985 15:50-EDT from robbins at DEC-HUDSON (setf stream-1 (make-string-input-stream "A line without a newline.")) (setf stream-2 (make-string-input-stream "Our generic second line.")) (setf stream-3 (make-concatenated-stream stream-1 stream-2)) What should (read-line stream-3) return, I can imagine two possibilities "A line without a newline.Our generic second line." t "A line without a newline." nil I think the first candidate is the obvious winner. I see nothing in the manual that would support the existence of an implicit newline character between the concatenated streams, and I don't think that this would be desirable. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 15:59:16 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 12:47:04 PDT Date: Wed, 18 Sep 85 15:50:09 EDT From: robbins@DEC-HUDSON Subject: Concatenated Stream Query To: common-lisp@su-ai Cc: robbins Given the following streams: (setf stream-1 (make-string-input-stream "A line without a newline.")) (setf stream-2 (make-string-input-stream "Our generic second line.")) (setf stream-3 (make-concatenated-stream stream-1 stream-2)) What should (read-line stream-3) return, I can imagine two possibilities "A line without a newline.Our generic second line." t "A line without a newline." nil -- Rich  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 13:02:04 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Sep 85 09:55:53 PDT Received: ID ; Wed 18 Sep 85 12:56:44-EDT Date: Wed, 18 Sep 1985 12:56 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: robbins@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Modification to LISTEN In-reply-to: Msg of 18 Sep 1985 11:07-EDT from robbins at DEC-HUDSON I would like to have LISTEN return two values. The first value is the same as it is now and the second value is true if end of file is encountered. The new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR and LISTEN. Looks like a good suggestion to me. It could be implemented in a completely upward-compatible way. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 11:11:41 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Sep 85 08:04:37 PDT Date: Wed, 18 Sep 85 11:07:13 EDT From: robbins@DEC-HUDSON Subject: Modification to LISTEN To: common-lisp@su-ai Cc: robbins@dec-hudson I would like to have LISTEN return two values. The first value is the same as it is now and the second value is true if end of file is encountered. The new definition allows READ-CHAR-NO-HANG to be implemented using only READ-CHAR and LISTEN. (defun read-char-no-hang (&optional input-stream eof-error-p eof-value recursive-p) (multiple-value-bind (char-available-p eof-encountered-p) (listen input-stream) (cond (char-available-p (read-char input-stream eof-error-p eof-value recursive-p)) (eof-encountered-p (if eof-error-p (error ...) eof-value)))))  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Sep 85 09:44:14 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 18 Sep 85 06:37:11 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 18 Sep 85 09:37:58 edt Date: Wed, 18 Sep 85 09:37 EDT From: Guy Steele Subject: Franz -> Common Lisp To: leite@UCI-ICSD.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 17 Sep 85 19:52-EDT from Julio Leite Message-Id: <850918093747.1.GLS@DESIDERIUS.THINK.COM> Date: 17 Sep 85 16:52:10 PDT (Tue) From: Julio Leite Dear Mr Steele, We at the Reuse Project, over University of California at Irvine, are working in a conversion of a large prototype system from Franz Lisp to Common Lisp. We suppose that other people had this experience before, and we would like to know if you know somebody who did it, and if there are any references available. We appreciate your attention, and be sure that any information you may have will be very useful to us. Thank you, Julio Cesar Leite UCI - ICS Irvine,Ca 92717 leite@uci-icsd.arpa ucbvax!ucivax!leite I am forwarding this message to the common-lisp mailing list to see what information we can come up with. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Sep 85 10:35:27 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Sep 85 07:27:35 PDT Received: ID ; Tue 17 Sep 85 10:28:14-EDT Date: Tue, 17 Sep 1985 10:28 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: snyder%hplabs.csnet@CSNET-RELAY.ARPA Cc: common-lisp@SU-AI.ARPA Subject: compiling anonymous functions In-reply-to: Msg of 16 Sep 1985 11:03-EDT from snyder%hplabs.csnet at CSNET-RELAY.ARPA Disclaimer: All of the following is a suggestion for how the language specification might be improved, once we have a mechanism in place for considering such improvements. Clearly the whole section on top-level forms needs to be reconsidered and tightened up. We got off on the wrong foot on that one, and never recovered. Probably we should flush the whole notion of top-level forms and just provide some rules about what the compiler does. We can probably go ahead and assume that there is a compiler of some sort and that it is written in Common Lisp without saying much about what code it generates or how intensively it hacks things. What we need to specify more clearly are which things get compiled (whatever that may mean) and which forms are "seen" by the compiler in the sense of causing side effects -- macro definitions, constant definitions, declarations, and the like. I think that the following are more or less standard practice now, and should probably be required (or at least strongly suggested and assumed by portable code libraries) at some future time: 1. Occurrences of (function (lambda ...)) within forms that are being compiled are themselves compiled. So if a function definition is (defun foo () (setf x #'(lambda () (mumble)))) then if we compile foo and then call it, X will contain a function object that is compiled as if it had been a top-level defun. Note that if you want to set X to an uncompiled expression, you can use '(lambda ...). 2. Embedded Defuns get compiled, roughly as if they were embedded (setf (symbol-function ) (function (lambda ...))) forms. We don't want to force users to write the long form in order to ensure compilation. If an implementation has defun doing additional things, such as maintaining data structures for the programming environment, then it is up to the implementor to do the right thing when compiling embedded Defuns, but the actual definition still should end up compiled. 3. "Random" Top-level forms (anything whose semantics are not special to the compiler) are compiled and then executed at load time. So if a file being compiled contains (mumble ...) it is compiled more or less as if it were (defun () (mumble ...)) () The point is not to force all implementations to execute these things fast at load time, though that is certainly a plus for any implementation. The point of including this in the standard is to standardize what happens when the random form contains constructs that might have side effects on the compiler or sub-forms that might want to be compiled. (This was discussed at some length before the manual came out, but I don't think the manual currently takes a stand on this.) So, if all the above were to become standard, a user could employ an idiom like (let ((x 0) (y 1024)) (defun foo () ...) (defun bar () ...)) and be sure that FOO and BAR would be compiled, whatever that means for a given implementaiton. I don't think this is guaranteed now, though it is an idiom I use a lot. I think that this subsumes Snyder's suggestions for extending the list of forms whose interiors are considered to be "top-level", at least on the issue of what gets compiled. The question of where you can put PROCLAIM forms and the like might be more complicated. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Sep 85 18:03:22 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 14:55:55 PDT Received: from hplabs by csnet-relay.csnet id am07932; 16 Sep 85 17:52 EDT Received: by HP-VENUS id AA23982; Mon, 16 Sep 85 11:13:54 pdt Message-Id: <8509161813.AA23982@HP-VENUS> Date: Monday, September 16, 1985 11:03:01 From: snyder%hplabs.csnet@CSNET-RELAY.ARPA Subject: compiling anonymous functions To: common-lisp@su-ai.arpa X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Source-Info: From (or Sender) name not authenticated. I agree with Jonathan Rees that compilers should compile anonymous functions, and that it is important that programmers be able to assume this behavior. I also agree with Scott Fahlman that the best approach would be to require (or at least strongly suggest) that compilers treat all compilable functions equally. Thus, if a compiler compiles top-level defuns in a given implementation, it must also compile other compilable function definitions as well. However, this notion depends on being able to come up with a clear definition of "compilable function". Anyone have any suggestions on how to define this? Can this notion be defined in a way that does not unduly restrict the implementation? One thing that has bothered me in the definition of CL is the limited definition of "top-level form" (page 66). I would suggest extending it (recursively) to include forms directly nested in top-level occurrences of LOCALLY, MACROLET, COMPILER-LET, EVAL-WHEN, and PROGN. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Sep 85 16:01:13 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 16 Sep 85 12:51:35 PDT Received: from IMSSS by Score with Pup; Mon 16 Sep 85 12:50:06-PDT Date: 16 Sep 1985 1251-PDT From: Rem@IMSSS Subject: EQUAL isn't really correct, I agree To: RAM%C.CS.CMU.EDU@SCORE cc: COMMON-LISP%SU-AI@SCORE Several months ago I came to the same conclusion, that none of the equality predicates are correct for many structure-comparing operations, and I roughly sketched out what would be better: a flexible structure-comparing function. Basically you tell the function what kinds of primitive cells should be STOP points and what should be recurse-through cells (the union of the two sets should be the universe of data types, or at least should include every kind of cell encountered in the task at hand). At STOP points, some more primitive function is needed to perform the actual comparison, so you tell the general function what primitive comparison function is to be used at each STOP point. Also, at each recurse-through some method of mapping all the components is needed, which would be implicit in the function definition for built-in datatypes but may need to be described explicitly for user-defined datatypes or for deliberately not recursing down certain branches. Typical variations on the usual EQUAL that would be supported trivially by this method: Identifiers get compared by PNAME rather than EQ, thus matching non-interned identifiers correctly. Numbers get compared with fudge factor that is magnitude-dependent in unusual way. Recursion occurs through the VALUE and PROPERTY-LIST of each identifier that is in the FOO package but stops on other identifiers (hint, make identifiers STOP points but define the comparison function at that point to look at the package cell and explicitly call the super-equal function recursively in some cases). ... Once this super-general function is properly defined and implemented, special cases can be described in a uniform way as canned arguments to this function, and then can be handcoded more efficiently if desired. In many cases there are oodles of special-case functions and nothing properly general in CL currently. Perhaps general functions should be defined and some of the special cases flushed, as such cases are recognized? Super-general-EQUAL could be the first such super-general function? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Sep 85 14:37:05 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 16 Sep 85 11:14:17 PDT Received: ID ; Mon 16 Sep 85 14:14:56-EDT Date: Mon, 16 Sep 1985 14:14 EDT Message-ID: From: Rob MacLachlan To: David.Butcher@ML.RI.CMU.EDU Cc: Gripe@ML.RI.CMU.EDU, Scott.Fahlman@C.CS.CMU.EDU, Skef.Wholey@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Subject: structure equality in slisp In-reply-to: Msg of 13 Sep 1985 14:23-EDT from David.Butcher at ML.RI.CMU.EDU From: David.Butcher at ML.RI.CMU.EDU To: Gripe at ML.RI.CMU.EDU Re: structure equality in slisp (equal (make-point) (make-point)) returned nil. a point is just three slots containing a number each. according to the book, things that have the same print name are equal. so shouldn't equal work on structures? Unfortunately, EQUAL is not a structural equality predicate. For historical reasons, EQUAL on any atom other than a string (or a bit-vector) is equivalent to EQL. Even worse, *there is no structural equality predicate* in Common Lisp. You can use EQUALP, but then comparisons of characters are case-insensitive. Yes, this is misleading, confusing and inconsistent. I think it sucks. Flame flame. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Sep 85 17:47:07 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Sep 85 14:41:39 PDT Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 313991; Sun 15-Sep-85 17:38:27-EDT Date: Sun, 15 Sep 85 17:42 EDT From: Mike McMahon Subject: LAMBDA expression to the SATISFIES type specifier To: Guy Steele cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <850911163632.9.GLS@DESIDERIUS.THINK.COM> Message-ID: <850915174204.1.MMCM@MERRIMACK.SCRC.Symbolics.COM> Date: Wed, 11 Sep 85 16:36 EDT From: Guy Steele The case I was worried about was (defun foo (x y) (declare (type (satisfies (lambda (q) (eq q y))) x)) ...) That doesn't seem to me substantially different from (defun foo (x) (flet ((foo-p (q) (eq q x))) (let ((y x)) (declare (type (satisfies foo-p) y)) ...))) which the manual is quite clear on (it doesn't work). I have no objection to the first example not working either. It seems that we should allow LAMBDA expressions and be consistent about the lexical environment for both functions and variables, presumably global.  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Sep 85 08:41:46 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 05:36:17 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 312265; Thu 12-Sep-85 08:33:30-EDT Date: Thu, 12 Sep 85 08:45 EDT From: Bernard S. Greenberg Subject: Not sharp-sign dot, fools! To: ksh@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 12 Sep 85 07:38-EDT from Mail Delivery Subsystem Message-ID: <850912084526.2.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed, 11 Sep 85 23:34:13 EDT From: Kjeld Hvatum To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].642224.850911.KSH> From: Stephen E. Bacher To: Common LISP mailing list Re: Modifying constants in compiled code From Evan Kirshenbaum: > (defmacro compute-once (form) > (let ((cell (cons nil nil))) > `(if (car ',cell) (cdr ',cell) > (progn > (setf (car ',cell) t) > (setf (cdr ',cell) ,form))))) > From Bernard S. Greenberg: > (defun switch () > (let ((y '#.(generate-cellx))) > (prog1 (car y) (rplaca y t)))) > > (defun generate-cellx () (cons nil nil)) It seems to me that both of the above examples of self-modifying code that won't modify "read-only" structures are highly dependent upon the behavior of the compiler. I generally expect the compiler, when it sees a form (QUOTE (mumble frotz)), to generate machine code to reference a LISP structure (mumble frotz) built in an area where constants are habitually placed, most likely a read-only area (if the implementation permits it). King of sloppily typing fools, whose typos even work properly! Thank you for paying attention! I meant sharp-sign comma -of course-, where the compiler's behavior is not an issue. Now there's food for thought.  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Sep 85 07:43:54 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Sep 85 04:38:59 PDT Received: from SCRC-PEGASUS.ARPA by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 312236; Thu 12-Sep-85 07:36:11-EDT Received: by scrc-pegasus id AA21117; Thu, 12 Sep 85 07:38:53 edt Date: Thu, 12 Sep 85 07:38:53 edt From: Bernard S. Greenberg To: ksh@mc Subject: Not pound-sign dot, fools! Cc: common-lisp@su-ai Date: Wed, 11 Sep 85 23:34:13 EDT From: Kjeld Hvatum To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].642224.850911.KSH> From: Stephen E. Bacher To: Common LISP mailing list Re: Modifying constants in compiled code From Evan Kirshenbaum: > (defmacro compute-once (form) > (let ((cell (cons nil nil))) > `(if (car ',cell) (cdr ',cell) > (progn > (setf (car ',cell) t) > (setf (cdr ',cell) ,form))))) > From Bernard S. Greenberg: > (defun switch () > (let ((y '#.(generate-cellx))) > (prog1 (car y) (rplaca y t)))) > > (defun generate-cellx () (cons nil nil)) It seems to me that both of the above examples of self-modifying code that won't modify "read-only" structures are highly dependent upon the behavior of the compiler. I generally expect the compiler, when it sees a form (QUOTE (mumble frotz)), to generate machine code to reference a LISP structure (mumble frotz) built in an area where constants are habitually placed, most likely a read-only area (if the implementation permits it). King of sloppily typing fools, whose typos even work properly. I meant sharp-sign comma -of course-. Now there's food for thought.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 23:44:57 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 20:36:16 PDT Date: Wed, 11 Sep 85 23:34:13 EDT From: Kjeld Hvatum To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].642224.850911.KSH> From: Stephen E. Bacher To: Common LISP mailing list Re: Modifying constants in compiled code From Evan Kirshenbaum: > (defmacro compute-once (form) > (let ((cell (cons nil nil))) > `(if (car ',cell) (cdr ',cell) > (progn > (setf (car ',cell) t) > (setf (cdr ',cell) ,form))))) > From Bernard S. Greenberg: > (defun switch () > (let ((y '#.(generate-cellx))) > (prog1 (car y) (rplaca y t)))) > > (defun generate-cellx () (cons nil nil)) It seems to me that both of the above examples of self-modifying code that won't modify "read-only" structures are highly dependent upon the behavior of the compiler. I generally expect the compiler, when it sees a form (QUOTE (mumble frotz)), to generate machine code to reference a LISP structure (mumble frotz) built in an area where constants are habitually placed, most likely a read-only area (if the implementation permits it). So what is the difference between '(nil) and '#.(cons nil nil), if we assume that what the compiler's call to READ returns is what the compiler sees? The same applies to a form to be compiled that is the result of a macro expansion (as in the macro-expansion-time-let example above). I can see how this might work if you compile from within the LISP environment and simply create a pointer to previously built LISP structure, but when you compile a file things are usually different. At least in my compiler, which works on files only, this is the case. (And in fact, if the compiler doesn't collapse EQUAL list structures, which mine doesn't, the first example doesn't work AT ALL anyway! But that point has already been brought out, so it needs no further discussion.) So wherein lies the "non-read-only-ness" of the thing???  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 22:42:20 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Sep 85 19:35:42 PDT Received: ID ; Wed 11 Sep 85 22:36:32-EDT Date: Wed, 11 Sep 1985 22:36 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Masinter.pa@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Top-level forms and eval-when in the compiler [and macrolet In-reply-to: Msg of 11 Sep 1985 20:55-EDT from Masinter.pa at Xerox.ARPA Date: Wednesday, 11 September 1985 20:55-EDT From: Masinter.pa at Xerox.ARPA To: Fahlman Re: Top-level forms and eval-when in the compiler [and macrolet too!] Your answer isn't acceptable. No Common Lisp is "serious" unless it has a compiler, and there are many things in Guy's book that are meaningless unless there's a compiler (compile-file, declarations, defconst, optimize, etc.) While it might have been politic at the time the book was being put together to say "Common Lisp compilers are not required to do any work at all, or even to exist for a given implementation", all of the real ones *do*, and if most implementations have a feature, then the feature should be standardized. In answering these queries, I try to keep three things separate: what is required by the current language definition, as I understand it; what I think that every reasonable implementation ought to do; and what I think ought to be added to the language specification in the future. So what I was saying is that, according to the current definition of Common Lisp, I think that it is legal either to compile or not to compile a Defun within a Macrolet; I also said that I thought an implementation ought to compile such forms. Do you disagree with either of those statements? Presumably what you found unacceptable was that the language specification allowed something like this (and almost everything else about what the compiler does) to be unspecified. I can't subscribe to your sweeping statement that "if most implementaitons have a feature, then the feature should be standardized". Our strategy has been to standardize all those things which must be standardized in order to allow code to be portable. Things which do not impact the portability of code have in general been left unspecified. In particular, we have tried not to specify too much about the internals of an implementation so that Common Lisp can be implemented on a wide variety of machines using a wide variety of implementation techniques. Similarly, we have not specified more than is absolutely necessary about the user interface, so that implementors have some freedom in adapting Common Lisp to thier own system's local culture. We had in mind, for example, Interlisp people who might want to stick with an internal editor instead of being required to live with an EMACS front end. It is of course a tricky balancing act to decide just how much to nail down. For example, I think that we would all agree that the language spec ought not to specify exactly which things are to be open-coded by the compiler and which left as function calls; to do so would be to put some class of machines at a severe disadvantage. On the other hand, writers of code intended to be portable will tend to write code whose performance is optimized according to some assumptions about how most Common Lisps are organized. For example, they will tend to assume that it is OK to use macros freely because these are expanded out at compile time and are probably cached by the interpreter. If we can make such implementation techniques more uniform without really screwing any reasonable implementation, then we should probably do so; it will make it possible to port more code to more machines without extensive retuning. This could be done by REQUIRING certain implementation techniques to be followed, or it could be done by "implementation notes" in the manual suggesting that things be done in certain ways if at all possible. In the past we have favored the latter, perhaps because there was so little implementation experience to draw upon that we didn't want to absolutely rule out any alternatives. I suppose it would be reasonable to require that Defuns embedded in random top-level forms get compiled just like top-level Defuns do (whatever that may entail in a given implementation). At least, future editions of the manual should make some strong suggestions along these lines. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 17:54:18 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 14:46:45 PDT Received: from MIT-REAGAN.ARPA by SU-SCORE.ARPA with TCP; Wed 11 Sep 85 14:45:41-PDT Received: from MIT-CHERRY by MIT-REAGAN via CHAOS with CHAOS-MAIL id 7917; Wed 11-Sep-85 17:45:54-EDT Date: Wed, 11 Sep 85 17:46 EDT From: SOLEY@MIT-MC.ARPA Subject: Compiling anonymous functions embedded in structure To: Rem@IMSSS, COMMON-LISP%SU-AI@SU-SCORE.ARPA In-Reply-To: The message of 11 Sep 85 15:32-EDT from Rem at IMSSS Message-ID: <"850911174600.5.Soley@MC"@CHERRY.MIT> Date: 11 Sep 1985 1232-PDT From: Rem@IMSSS Subject: Compiling anonymous functions embedded in structure To: COMMON-LISP%SU-AI@SCORE Instead of saying #'(LAMBDA ...) which the compiler doesn't recognize as something to compile, you could say (DEFUN TEMPNAME ...) then explicitly copy that codepointer from the function cell of TEMPNAME to the place it's really wanted. This is a simple way for the esoteric programmer to get around this deficiency in the compiler. Yeah, and while we're being esoteric, let's scrap FUNCALL (which should be called CALL anyway . . .) in favor of the phrase ... (setf (get '*MAJIC* 'EXPR) ) (*MAJIC* ) ... which I think I actually saw in some piece of MacLisp some time ago . . .  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 16:41:53 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 11 Sep 85 13:37:05 PDT Received: from desiderius by GODOT.THINK.COM via CHAOS; Wed, 11 Sep 85 16:35:29 edt Date: Wed, 11 Sep 85 16:36 EDT From: Guy Steele Subject: LAMBDA expression to the SATISFIES type specifier To: MMcM@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <850911162347.6.MMCM@MERRIMACK.SCRC.Symbolics.COM> Message-Id: <850911163632.9.GLS@DESIDERIUS.THINK.COM> Date: Wed, 11 Sep 85 16:23 EDT From: Mike McMahon Page 43 specifies that the predicate name must be a symbol because of scoping problems. First off, I don't see any reason to disallow lexical closures: (deftype foo (x) `(satisfies ,#'(lambda (y) (eq x y)))) As for LAMBDA expressions, I would think that the same scoping rules would apply as for DEFMACRO. That is, (deftype foo (x) '(satisfies (lambda (y) (eq x y)))) should not be expected to work any more than (defmacro foo (x y) `((lambda (z) (eq x z)) ,y)) In summary, I believe that anything FUNCTIONP is valid as the predicate in SATISFIES. Is there some more subtle scoping problem that I have overlooked? The case I was worried about was (defun foo (x y) (declare (type (satisfies (lambda (q) (eq q y))) x)) ...) That's sensible enough, I suppose, but I was leery of the extra complexity required in a compiler to deal with this (you have to make closures over type specifiers before handing them off to SUBTYPEP, etc.). --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 16:30:24 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 13:23:33 PDT Received: from MERRIMACK.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 311820; Wed 11-Sep-85 16:20:44-EDT Date: Wed, 11 Sep 85 16:23 EDT From: Mike McMahon Subject: LAMBDA expression to the SATISFIES type specifier To: Common-Lisp@SU-AI.ARPA Message-ID: <850911162347.6.MMCM@MERRIMACK.SCRC.Symbolics.COM> Page 43 specifies that the predicate name must be a symbol because of scoping problems. First off, I don't see any reason to disallow lexical closures: (deftype foo (x) `(satisfies ,#'(lambda (y) (eq x y)))) As for LAMBDA expressions, I would think that the same scoping rules would apply as for DEFMACRO. That is, (deftype foo (x) '(satisfies (lambda (y) (eq x y)))) should not be expected to work any more than (defmacro foo (x y) `((lambda (z) (eq x z)) ,y)) In summary, I believe that anything FUNCTIONP is valid as the predicate in SATISFIES. Is there some more subtle scoping problem that I have overlooked?  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 15:38:46 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 12:31:55 PDT Received: from IMSSS by Score with Pup; Wed 11 Sep 85 12:30:51-PDT Date: 11 Sep 1985 1232-PDT From: Rem@IMSSS Subject: Compiling anonymous functions embedded in structure To: COMMON-LISP%SU-AI@SCORE Instead of saying #'(LAMBDA ...) which the compiler doesn't recognize as something to compile, you could say (DEFUN TEMPNAME ...) then explicitly copy that codepointer from the function cell of TEMPNAME to the place it's really wanted. This is a simple way for the esoteric programmer to get around this deficiency in the compiler. By the way, PSL is strange in this respect. When *COMP is turned on so that forms typed into the interpretor get compiled, it recognizes only PUTD as a trigger for actual compilation (which in turn is generated by macro expansion of DE et al), thus it fails to compile the (SETF ... (FUNCTION (LAMBDA ...))). But when compiling file-to-file using FASLOUT, absolutely everything in the file is compiled, the toplevel cruft being put in initcode and the stuff inside (PUTD ...) or (FUNCTION ...) being put in permanent BPS, so that the original (SETF ...) actually compiles as desired without needing the trick. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 14:51:39 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 11:44:12 PDT Received: ID ; Wed 11 Sep 85 14:17:05-EDT Date: Wed, 11 Sep 1985 11:05 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Tim McNerney Cc: common-lisp@SU-AI.ARPA Subject: Top-level forms and eval-when in the compiler [and macrolet too!] In-reply-to: Msg of 11 Sep 1985 01:15-EDT from Tim McNerney Common Lisp compilers are not required to do any work at all, or even to exist for a given implementation. So it is legal for a CL compiler to look at your macrolet and just pass it on through untouched. However, it would be much more tasteful to compile the included forms, with the lexically scoped macros in effect. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 14:41:53 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 11 Sep 85 11:33:40 PDT Date: Wed, 11 Sep 85 11:40:11 EDT From: Jonathan A Rees Subject: Top-level forms and eval-when in the compiler [and macrolet too!] To: TIM@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, RAM@CMU-CS-C.ARPA In-reply-to: Msg of Wed 11 Sep 85 01:15:31 EDT from Tim McNerney Message-ID: <[MIT-MC.ARPA].641160.850911.JAR> Date: Wed, 11 Sep 85 01:15:31 EDT From: Tim McNerney Should a CL compiler generate interpreted or compiled definitions for the the functions f and g in the following form? (macrolet (...) (defun f ...) (defun g ...)) In my opinion, Lisp compilers should compile any LAMBDA-expressions, explicit or implicit, which could possibly exist at and after load time. So the answer is yes. This subsumes the case of top-level (setf (get 'foo 'bar) #'(lambda ...)), The LAMBDA-expression doesn't get compiled by at least one aspiring Common Lisp that I know of. One shouldn't have to do a DEFUN here just in order to cause compilation to happen. That defeats the whole purpose of anonymous functions. Jonathan Rees  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Sep 85 01:30:16 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 22:17:43 PDT Date: Wed, 11 Sep 85 01:15:31 EDT From: Tim McNerney Subject: Top-level forms and eval-when in the compiler [and macrolet too!] To: RAM@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Thu 5 Sep 1985 13:36 EDT from Rob MacLachlan Message-ID: <[MIT-MC.ARPA].640743.850911.TIM> Should a CL compiler generate interpreted or compiled definitions for the the functions f and g in the following form? (macrolet (...) (defun f ...) (defun g ...))  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Sep 85 18:03:28 EDT Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 10 Sep 85 14:57:55 PDT Received: from edxa.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000917; 10 Sep 85 21:03 BST From: DALTON FHL (on ERCC DEC-10) Date: Tuesday, 10-Sep-85 17:25:29-GMT Message-ID: <132356-563-566@EDXA> To: common-lisp , J.Dalton%edxa@ucl-cs.arpa Subject: More errata -------- I hope the following textual errors have not been noted before: 461 The index entry "replacd" should be "rplacd". 189 In the line ";;; I just want a few thing from RELATIVITY,", "thing" should be "things". 190-1 phlogiston:heat-flow is called with one argument on p. 190 but defined with three on p. 191. 191 In the function heat-flow, the symbol feeling-weak should either be called as a function or declared special. And one possible style-warning: 147 It's confusing (in the block of code near the bottom of the page) to have cadr ... cadddr and then fifth. I'm not sure, though, which way I'd want it instead. -- Jeff Dalton, AIAI, University of Edinburgh --------  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Sep 85 13:54:16 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 9 Sep 85 09:33:42 PDT Received: from ignatius by GODOT.THINK.COM via CHAOS; Mon, 9 Sep 85 12:32:33 edt Date: Mon, 9 Sep 85 12:33 EDT From: Guy Steele Subject: Closing Synonum Streams. To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: The message of 7 Sep 85 13:46-EDT from greek at DEC-HUDSON Message-Id: <850909123351.1.GLS@IGNATIUS.THINK.COM> The subject header from GREEK was obviously a typo, but I cannot let it pass. Surely we can design some clever language feature that deserves the name "synonum". --Quux  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Sep 85 13:30:27 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Sep 85 09:10:45 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 309229; Mon 9-Sep-85 09:39:13-EDT Date: Mon, 9 Sep 85 09:43 EDT From: David C. Plummer in disguise Subject: go and return-from inside unwind-protect cleanup To: Common-Lisp@SU-AI.ARPA Message-ID: <850909094352.2.NFEP@NEPONSET.SCRC.Symbolics.COM> Are the following legal? (defun foo (go-p) (prog nil tag (unwind-protect (return (compute)) (if go-p (go tag))))) (defun bar (return-p) (prog nil tag (unwind-protect (progn (compute) (go tag)) (if return-p (return nil))))) I say no, because the unwind-protect could be usurping the values of the first form of unwind-protect (in the case of normal exit) or could be usurping a THROW (in the abnormal exit). There is no mention of this in CLtL (in the unwind-protect section, at least). If it is legal, would somebody please tell me what FOO does.  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Sep 85 13:08:29 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 9 Sep 85 10:01:27 PDT Received: from ignatius by GODOT.THINK.COM via CHAOS; Mon, 9 Sep 85 13:00:13 edt Date: Mon, 9 Sep 85 13:01 EDT From: Guy Steele Subject: go and return-from inside unwind-protect cleanup To: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <850909094352.2.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <850909130121.2.GLS@IGNATIUS.THINK.COM> Date: Mon, 9 Sep 85 09:43 EDT From: David C. Plummer in disguise Are the following legal? (defun foo (go-p) (prog nil tag (unwind-protect (return (compute)) (if go-p (go tag))))) (defun bar (return-p) (prog nil tag (unwind-protect (progn (compute) (go tag)) (if return-p (return nil))))) I say no, because the unwind-protect could be usurping the values of the first form of unwind-protect (in the case of normal exit) or could be usurping a THROW (in the abnormal exit). There is no mention of this in CLtL (in the unwind-protect section, at least). If it is legal, would somebody please tell me what FOO does. I regard both of these as completely legal. (FOO NIL) and (BAR T) call COMPUTE exactly once. (FOO T) and (BAR NIL) call COMPUTE repeatedly. These can be explained adequately in terms of continuations. Informally, whenever some internal computational process that is unwinding the stack (such as a RETURN, GO, or THROW) encounters an UNWIND-PROTECT, it makes up a continuation that, when invoked, will continue the stack-unwinding process and then perform whatever was to occur after that (return a value, transfer to a tag, etc.). The cleanup forms of the UNWIND-PROTECT are then executed with that continuation as their continuation (that is, the action to be taken when they have all been evaluated and control "flows off the end" of the implicit PROGN. In the case of the protected form of a PROGN completing, the continuation is "return a value from the UNWIND-PROTECT", and that is the continuation to be performed after the cleanup forms. GO, RETURN, and CATCH are operations that discard their normal continuations, and perform some other control action instead. In FOO, therefore, the use of RETURN begins a stack unwinding. Hitting the UNWIND-PROTECT causes a "return the value of (COMPUTE) from the PROG" continuation to be made up and used as the continuation for the expression (IF GO-P (GO TAG)). If GO-P is NIL, the IF exits normally, the return-continuation is used, and the PROG is exited. If GO-P is not NIL, then the GO is executed, which discards its normal continuation, and so it completely forgets that it was intending to return from the PROG. Control is transfered to the tag. (A cleanup form is not protected by its own UNWIND-PROTECT, and so no other unusual actions occur before transfer to the tag.) After completing this analysis, I tried out routines FOO and BAR both in Symbolics 3600 Common Lisp and in DEC VAX LISP. In both implementations both FOO and BAR behave exactly as I have described. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Sep 85 16:43:12 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 7 Sep 85 13:37:18 PDT Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA25263; Sat, 7 Sep 85 13:34:29 pdt Received: by ucbkim.ARPA (5.5/5.3) id AA29871; Sat, 7 Sep 85 13:34:30 PDT Received: by franz.uucp (5.5/3.14) id AA25140; Sat, 7 Sep 85 12:55:26 PDT Date: Sat, 7 Sep 85 12:55:26 PDT From: franz!jkf@Berkeley (John Foderaro) Message-Id: <8509071955.AA25140@franz.uucp> To: Moon@SCRC-STONY-BROOK.ARPA Subject: longwinded reply to close queries Cc: common-lisp@SU-AI.ARPA, robbins@DEC-HUDSON.ARPA In-Reply-To: Your message of Sat, 7 Sep 85 01:12 EDT From: David A. Moon Since the function OPEN doesn't return synonym streams, it's difficult to say what "a synonym stream is 'opened'" means exactly. I'd say "a synonym stream is made'", since we make them by calling MAKE-SYNONYM-STREAM. Sure, call it whatever you wish, I always think in terms of streams being created by 'open' so I'll just use that term and you can mentally substitute the appropriate function name. This doesn't address my comment: I don't see why close should be treated differently from other stream operations. I can give a few reasons: 1) A stream has three classes of functions which operate on it: creation/destruction query (which file is connected, which byte position) action (read/write) A typical stream is atomic so all operations apply just to the stream. A synonym stream (and the other make-xxx-stream types) are different. As I see it, the creation/destruction function apply to the stream itself, and the query and action functions apply to the bound stream. Thus: creation/destruction stream itself ----- query bound stream action Of course what is needed are a set of query function that act on the stream itself, providing such information as what symbol is the synonym stream bound to, thus it really should be something like this: creation/destruction query' ----- query action In this model, making close act only on the synonym stream is natural, and not an exception. You'll (probably) agree that every other function already follows this model. 2) here is a puzzle: (setq p (make-synonym-stream '*foo*)) Can I now safely (close p) if I using the semantics for close that you believe are correct? How can I write a program in common lisp to tell me if by doing a (close p) I won't shut off my keyboard and display? I can't think of a program and I would thus conclude that one should never close a synonym stream. 3) The real question is of course what makes sense to do for real programs doing real things. Consider a simulation program which wants to watch and log ten different types of events. It wants to create ten streams. At the start of the simulation the user interactively decides for each even whether the information should go in a file, or go to *standard-output* or to *debug-io*. For the latter two cases, we create synonym streams. In the middle of the simulation, after which time events of type X should no long longer occur, we want to close the *x-event-stream*. We can't just (close *x-event-stream*) or we may shut down *terminal-io*. If we simply refuse to close a synonym stream then we are forced to leave copies of this 'live' synonym stream floating around and we can't detect when someone uses it again when they really weren't supposed to. --- end list-- From: David A. Moon If one adopts your suggestion that closing a synonym stream means to disconnect it from the stream it forwards to, and prevent further operations on the synonym stream, then surely closing *debug-io* is just as bad as closing *terminal-io*. How you gonna debug it if *debug-io* doesn't work? I was just using *debug-io* as an example of a synonym stream, but as long as you asked I can imagine a program that wants to use another stream for *debug-io* first doing a close of *debug-io* before opening another stream and storing it in *debug-io*. Let's look at it a different way: you propose for synonym streams to treat CLOSE differently from all other stream operations. Okay, they could do that. What would be gained by introducing this extra complexity, other than an extra page of thickness of the manual? I would claim that without this extra complexity, synonym streams are too dangerous to be used in most of the applications I would see for them. -john foderaro  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Sep 85 14:18:20 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 7 Sep 85 11:15:04 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA23511; Sat, 7 Sep 85 11:12:02 pdt Received: by ucbdali.ARPA (5.5/4.48) id AA12961; Sat, 7 Sep 85 11:13:04 PDT Date: Sat, 7 Sep 85 11:13:04 PDT From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8509071813.AA12961@ucbdali.ARPA> To: common-lisp@su-ai, greek@DEC-HUDSON Subject: comment and errata on synonyms, streams. The notion of synonym stream seems to me to be the inconsistency. Why do we not have "make-synonym-symbol" by which we mean that if we do (setq x (make-synonym-symbol 'y)) any operation performed on x is actually performed on y? Then we could add an extra layer of indirection to ANYTHING. e.g. (+ x x) would be like (+ y y). There are great uses for this. :-) contribution to ERRATA: In reading over the chapter on streams, I see on p331 of CLtL that (with-input-from-string (s "Animal Crackers" :index j :start 6) (read s)) is alleged to return crackers This seems to me highly unlikely. It would be consistent if it returned CRACKERS An interesting puzzle is to figure out how to make it return the answer Crackers -- RJF  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Sep 85 13:47:25 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 7 Sep 85 10:43:23 PDT Date: Sat, 07 Sep 85 13:46:26 EDT From: greek@DEC-HUDSON Subject: Closing Synonum Streams. To: common-lisp@su-ai Moon is right -- it certainly would make CLOSE a special case if it only closed the synonym stream and not the target stream. And we would have to describe this "strange" behavior in CLtL. However, I still think closing synonym streams should NOT close the target streams. And synonym streams aren't the only special case. Broadcast, concatenated, two-way, and echo streams should also not close the target streams. Now a reasonable distinction emerges: indirect streams do not close their target streams when they themselves are closed. If these indirect streams do close their targets then you can never close the stream created by DRIBBLE or you would surely end up closing *TERMINAL-IO*. "You" here means the system itself. Program A may create a stream that program B wants to use indirectly (e.g., as a synonym stream or perhaps a target of a broadcast stream or what have you). Certainly it is often the case that program B has no right to close program A's stream just because B closes its own indirect stream. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Sep 85 01:16:29 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 22:12:26 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 308582; Sat 7-Sep-85 01:10:11-EDT Date: Sat, 7 Sep 85 01:12 EDT From: David A. Moon Subject: Re: close queries To: John Foderaro cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8509061849.AA20802@franz.UUCP> Message-ID: <850907011208.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 6 Sep 85 11:49:44 pdt From: franz!jkf@Berkeley (John Foderaro) From: David A. Moon I don't see why close should be treated differently from other stream operations. I don't know what it would mean to "close the synonym stream but not the stream bound to" -- what aspect of a synonym stream is there to be closed, other than the stream it is bound to? I disagree. When a synonym stream is 'opened', it creates a conduit to another stream. Since the function OPEN doesn't return synonym streams, it's difficult to say what "a synonym stream is 'opened'" means exactly. I'd say "a synonym stream is made'", since we make them by calling MAKE-SYNONYM-STREAM. When it is closed, the only action should be to close the conduit, preventing further reading and writing operations through the synonym stream. This is completely safe. Closing down the stream bound to the synonym stream can be unsafe and you are forced to come up with rules like 'you can close *terminal-io*' which is something processes wish to do on occasion in Unix. This doesn't address my comment: I don't see why close should be treated differently from other stream operations. One way to decide which is the correct thing to do when a close is done is to consider examples of synoynm streams. The only example I know of is that *standard-input*, *standard-output*, *error-output*, *trace-output*, *query-io*, and *debug-io* are all synonym streams for *terminal-io*. It doesn't make sense to me that if I close *debug-io*, *standard-input* should be affected, thus I claim this example supports my view. If one adopts your suggestion that closing a synonym stream means to disconnect it from the stream it forwards to, and prevent further operations on the synonym stream, then surely closing *debug-io* is just as bad as closing *terminal-io*. How you gonna debug it if *debug-io* doesn't work? Let's look at it a different way: you propose for synonym streams to treat CLOSE differently from all other stream operations. Okay, they could do that. What would be gained by introducing this extra complexity, other than an extra page of thickness of the manual?  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Sep 85 20:13:15 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 17:08:42 PDT Received: ID ; Fri 6 Sep 85 20:10:04-EDT Date: Fri, 6 Sep 1985 20:10 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: franz!jkf@Berkeley (John Foderaro) Cc: common-lisp@SU-AI.ARPA Subject: close queries In-reply-to: Msg of 6 Sep 1985 14:49-EDT from franz!jkf at Berkeley (John Foderaro) I think we've got some misunderstandings going here. For what it's worth, I think Foderaro is right. I think this is more or less what Moon was saying too, but it was possible to read his meassge a couple of different ways. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Sep 85 14:57:49 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 6 Sep 85 11:54:33 PDT Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA03424; Fri, 6 Sep 85 11:51:41 pdt Received: by ucbkim.ARPA (5.5/5.3) id AA19258; Fri, 6 Sep 85 11:55:18 PDT Received: by franz.UUCP (2.0/SMI-2.0) id AA20802; Fri, 6 Sep 85 11:49:44 pdt Date: Fri, 6 Sep 85 11:49:44 pdt From: franz!jkf@Berkeley (John Foderaro) Message-Id: <8509061849.AA20802@franz.UUCP> To: Moon@SCRC-STONY-BROOK.ARPA, robbins@DEC-HUDSON.ARPA Subject: Re: close queries Cc: common-lisp@SU-AI.ARPA In-Reply-To: Your message of Fri, 6 Sep 85 00:41 EDT From: David A. Moon I don't see why close should be treated differently from other stream operations. I don't know what it would mean to "close the synonym stream but not the stream bound to" -- what aspect of a synonym stream is there to be closed, other than the stream it is bound to? I disagree. When a synonym stream is 'opened', it creates a conduit to another stream. When it is closed, the only action should be to close the conduit, preventing further reading and writing operations through the synonym stream. This is completely safe. Closing down the stream bound to the synonym stream can be unsafe and you are forced to come up with rules like 'you can close *terminal-io*' which is something processes wish to do on occasion in Unix. One way to decide which is the correct thing to do when a close is done is to consider examples of synoynm streams. The only example I know of is that *standard-input*, *standard-output*, *error-output*, *trace-output*, *query-io*, and *debug-io* are all synonym streams for *terminal-io*. It doesn't make sense to me that if I close *debug-io*, *standard-input* should be affected, thus I claim this example supports my view. Are there any other examples of synonym streams? -john foderaro  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Sep 85 00:44:38 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 21:41:17 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 149830; Fri 6-Sep-85 00:40:17-EDT Date: Fri, 6 Sep 85 00:41 EDT From: David A. Moon Subject: close queries To: robbins@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 21 Aug 85 13:59-EDT from robbins@DEC-HUDSON Message-ID: <850906004107.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 21 Aug 85 13:59:15 EDT From: robbins@DEC-HUDSON What is supposed to happen when an attempt is made to close a synonym stream? The manual seems to indicate that it is the stream which is bound to the synonym symbol that should be closed, but, I am not sure that this is the most desirable behaviour. What about someone that desires to close the synonym stream but not the stream bound to the synonym symbol? I don't see why close should be treated differently from other stream operations. I don't know what it would mean to "close the synonym stream but not the stream bound to" -- what aspect of a synonym stream is there to be closed, other than the stream it is bound to? Is it an error to close *terminal-io*? I'd think so. Probably it's a no-op in a lot of implementations, but I can imagine implementations where it would disconnect your terminal.  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Sep 85 13:50:22 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 10:36:30 PDT Received: ID ; Thu 5 Sep 85 13:36:45-EDT Date: Thu, 5 Sep 1985 13:36 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Top-level forms and eval-when in the compiler There are various forms (defconstant, defmacro, eval-when) which can cause things to happen in the compiler environment when they are encountered. When at top-level, the correct action seems clear, but anyplace else things become more confusing. What should be done when a random (eval-when (compile) ...) is encountered during the compilation of some function? Does the compiler always do compile-time evaluation even though the code might be unreachable? I don't think that it is acceptable to say that these forms are only meaningful at top-level. In a lexical lisp it is quite useful to put a definition inside of a let. Often user-defined definition forms contain eval-whens. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Sep 85 10:17:45 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 5 Sep 85 07:10:08 PDT Date: Thu, 05 Sep 85 09:09:41 CDT From: wagner@GSWD-VMS Subject: Erratum To: common-lisp@su-ai.arpa Cc: wagner In CLtL, page 287, bottom line, :type should be :element-type. Fran  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 18:41:11 EDT Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 15:35:32 PDT Date: Wed 4 Sep 85 15:35:50-PDT From: Evan Kirshenbaum Subject: GLisp for Common Lisp To: common-lisp@SU-AI.ARPA Does anyone know if there is a compiler for Gordon Novak's GLisp language which compiles to Common Lisp? Evan Kirshenbaum -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 16:59:54 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 13:49:54 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 306629; Wed 4-Sep-85 16:47:27-EDT Date: Wed, 4 Sep 85 16:48 EDT From: Daniel L. Weinreb Subject: Re: Side effecting constants inside functions To: evan@SU-CSLI.ARPA cc: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Sep 85 15:05-EDT from Evan Kirshenbaum Message-ID: <850904164848.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Tue 3 Sep 85 12:05:09-PDT From: Evan Kirshenbaum Out of curiousity, is there any way to define a form which caches values (computes them once) that is not self-modifying? If there's a cache, there must be side-effects on some data structure somewhere. Exactly where that state should be depends on what circumstance should provoke the actual computation. If the computation should happen only once per Lisp world, you could put it in a global variable (or several global variables, or a global variable with a structured value that can hold several objects).  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 16:00:48 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 12:50:57 PDT Date: Wed 4 Sep 85 15:49:53-EDT From: "Rodney A. Brooks" Subject: Re: Errata for Common Lisp manual To: gls@AQUINAS.THINK.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <850904150821.2.GLS@POLYCARP.THINK.COM> Message-ID: <12140629539.28.BROOKS@MIT-OZ> Another typo: On page 221, and in the table on page 222, logorc1 and logorc2 are used, but in the definitions of these at the top of page 222 they are called logiorc1 and logiorc2. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 15:20:10 EDT Received: from THINK.COM by SU-AI.ARPA with TCP; 4 Sep 85 12:08:26 PDT Received: from polycarp by GODOT.THINK.COM via CHAOS; Wed, 4 Sep 85 15:07:24 edt Date: Wed, 4 Sep 85 15:08 EDT From: Guy Steele Subject: Errata for Common Lisp manual To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <850904150821.2.GLS@POLYCARP.THINK.COM> At the end of this message is my current list of "trivial" errata for the Common Lisp manual. These are changes for problems that I regard as either (a) simple typographical errors, or (b) ambiguities or inconsistencies whose resolution is "obvious" and "noncontroversial". As an example of an error for which a correction is not included here: page 202 blithely states that "Mathematically, (lcm) should return infinity." Wrong. Mathematically, the result should be 1, if anything. (That's my fault, the result of fuzzy thinking.) The "obvious" fix is to define (lcm) to return 1. However, that would not be merely a textual correction, but a substantive change to the language possibly requiring action by implementors, and it is not appropriate for me to make such changes unilaterally. --Guy ---------------------------------------------------------------- Corrections to first printing of Common Lisp: The Language 10 First two paragraphs should have monospace comma and colon, respectively, at the left margin. 18 3.1010299957f-1 should be 3.010299957f-1 (first "1" should be deleted). 43 Table 43-1 should include the names "signed-byte" and "unsigned-byte". 67 The comment in (defun discriminant ...) is wrong, because the code works for complex coefficients. Change the line The quadratic equation a*x^2+b*x+c=0 has real, multiple to be the two lines If the coefficients a, b, and c are all real numbers, then the quadratic equation a*x^2+b*x+c=0 has real, multiple 69 Top line, last word but one, should be "replace", not "replaces". 99 In first line of second paragraph, delete the italicized word "newvalue". 145 Three lines from the bottom, the term "&environment" should appear at the left in monospace. 147 Last line on this page should be deleted; it duplicates first line on page 148. 157 In third line, "declaration-form" should be "decl-spec" (in italics). 200 At the end of the first paragraph "returns the result." add the sentence "It is an error if any argument other than the first is zero." After "With one argument, / reciprocates the result" add the sentence "The argument must not be zero." 204 Halfway down, the last line of a paragraph "#C(0.5 1.73205)." should say "#C(1.0 1.73205)." 216 Alter "The divisor may be any non-complex number." to read "The divisor may be any non-zero non-complex number." 216 Change "For example, (floor 5 2) @EQ (floor (/ 5 2)) ..." to "For example, (values (floor 5 2)) @EQ (values (floor (/ 5 2))) ...". [Actually, it would be better to rewrite this whole section, but this fix at least makes it accurate.] 216 Before last paragraph, insert this new paragraph: Note that while (floor 5 2) and (floor (/ 5 2)) return the same first value, they return different remainders as the second value: (floor 5 2) => 2 1 (floor (/ 5 2)) => 2 1/2 This is why @f[values] was used above in the remark that (values (floor 5 2)) @EQ (values (floor (/ 5 2))). 276 Halfway down, in the display line before "See pushnew.", the phrase "(fn item)" should be "(funcall fn item)", with "funcall" in monospace and "fn" and "item" in italics as before. 307 In the header line for "defstruct", "{slot-description}+" should be "{slot-description}*" (star instead of plus). 309 First paragraph should end "see section 19.6)." not "see section 19.6."; there is a missing parenthesis. 325 The name of the variable "-" does not appear in the header line. 347-348 The page layout is a bit confused here; some connection should be made between the description of ";" and the example. 349 Before the first complete paragraph, there should be a heading line consisting of a single monospace backquote (accent grave). 349 In the first example of the use of backquote, the character just before " (print ,x)" is a "t". (It is badly printed in several copies.) 357 All occurrences of "constructor macro" should read "constructor function". 373 Third line from bottom: "print-array" in monospace should be "*print-array*". 454 In index entry for "defun", first page number should be 67, not 57. 458 In index entry for "macrolet", page numbers should be 113-114 instead of 93-94. 465 "zerop" is missing from the index (it is defined on page 195). 458 First reference for "macrolet" should be 113-114, not 93-94. 459 Add index entry "newline 20, 21-22, 235, 243, 336, 347, 378, 383, 384, 397".  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 11:52:45 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 08:42:55 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 149252; Wed 4-Sep-85 11:41:59-EDT Date: Wed, 4 Sep 85 11:44 EDT From: David C. Plummer in disguise Subject: Re: compiling multiple files To: Robert W. Kerns , SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA cc: LOOSEMORE%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <850904060013.0.RWK@CROW.SCRC.Symbolics.COM> Message-ID: <850904114419.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 4 Sep 85 06:00 EDT From: Robert W. Kerns Date: Tue 3 Sep 85 16:57:21-PDT From: SCHUMACHER%hplabs.csnet@csnet-relay.arpa What you need can be done using the require function (sec 11.8 modules in CLtL) assuming that the appropriate provide calls have been made, or you can simply use (eval-when (eval compile) (load ...)) . Lee Schumacher ------- This isn't the same thing at all, especially this last suggestion. Loading a file into the compilation environment is not the same as compiling it into the file! Nor is putting a REQUIRE into a file the same as compiling the required software into a resulting file, which is what was request. I believe this describes the desired behaviour: (defmacro insert-file-and-compile (file) (with-open-file (stream file) (do* ((eof (cons 'eof nil)) (form (read stream nil eof) (read stream nil eof)) (forms)) ((eq form eof) `(progn ,@(nreverse forms))) (push form forms)))) Nit: This isn't quite right because it doesn't take into account the possible effects of eval-when which might change the readtable or something for processing the rest of the file. Instead of kludges like this, it would be better to have a defined interface to the compiler which compiles a list of files. Maybe COMPILE-FILE can simply be extended to allow a list as its first argument, INPUT-FILE.  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 11:39:52 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 08:32:39 PDT Received: ID ; Wed 4 Sep 85 11:33:18-EDT Date: Wed, 4 Sep 1985 11:33 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: inconsistency in the definitions of round-off functions Responding to wilensky at ucblarch (Robert Wilensky). I believe that the inconsistency you point out has already been reported to this mailing list a couple of times and is on Steele's list of things to fix up next time around. I believe that the resolution of this is that the manual should say that (floor 5 2) is equivalent to (floor (/ 5 2)) AS FAR AS THE FIRST VALUE IS CONCERNED, but that the treatment of the second return value is different. Yes, I agree that we desperately need to get the current errata collected and to make them available to the community. This is one of the tasks for which we need some sort of support organization. We're working on this, but it is going very slowly. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 11:11:35 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 08:04:34 PDT Date: Wed 4 Sep 85 09:06:07-MDT From: SANDRA Subject: Re: compiling multiple files To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <8509032357.AA17278@HP-VENUS> Message-ID: <12140577882.31.LOOSEMORE@UTAH-20.ARPA> I believe a distinction needs to be made here between "loading" a file and having a file processed by the compiler. Using (eval-when (eval compile) (load "foobar")) would be appropriate when the file "foobar" contains definitions (macros, etc.) that are required a compile time. However, this form alone, even if seen in a compilation context, would *not* cause the contents of file "foobar" to be compiled. Again, what I'm looking for is a function/macro/special form that causes the contents of a given file to be processed exactly as if the forms within the file were replacing the call to this function/macro/special form. A possible (though inefficient) implementation as a macro would look something like: (defmacro include-file (pathname) (let ((results nil) (form nil)) (with-open-file (stream pathname :direction :input) (loop (setq form (read stream nil '*eof*)) (if (eq form '*eof*) (return nil) (push form results)))) `(progn ,@(nreverse results)))) -Sandra -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 09:55:08 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 06:49:39 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 306104; Wed 4-Sep-85 09:47:16-EDT Date: Wed, 4 Sep 85 09:54 EDT From: Bernard S. Greenberg Subject: Re: Side effecting constants inside functions To: evan@SU-CSLI.ARPA, DLW@SCRC-QUABBIN.ARPA cc: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Sep 85 15:05-EDT from Evan Kirshenbaum Message-ID: <850904095440.6.BSG@CONCORD.SCRC.Symbolics.COM> Date: Tue 3 Sep 85 12:05:09-PDT From: Evan Kirshenbaum Well, it ran on my interpreter (Hedrick's TOPS-20), and that's roughly the form I have used in the past. Out of curiousity, is there any way to define a form which caches values (computes them once) that is not self-modifying? I have more than a casual interest, as this is a problem we are facing in a language I'm working on. evan ------- I have mixed feelings about the ritual legality of this: (defun switch () (let ((y '#.(generate-cellx))) (prog1 (car y) (rplaca y t)))) (defun generate-cellx () (cons nil nil))  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 09:19:46 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 06:14:49 PDT Received: from IMSSS by Score with Pup; Wed 4 Sep 85 06:13:43-PDT Date: 4 Sep 1985 0615-PDT From: Rem@IMSSS Subject: More on reference/pure data, declaration not really needed To: common-lisp%SU-AI@SCORE After sending that message I realized declarations aren't needed in the case of (+InPlace Result A B C ... Z). The only true requirement is that Result get initialized to a modifyable number of the desired type before calling +InPlace. +InPlace would compute the result as normal, except being careful not to do any number-consing, then would coerce the result to the same type as Result previously had, and modify Result to contain that result. Note that when you use +InPlace you lose the ability to nest function calls, thus the in-place-efficient version of (SETQ A (+ B (* C D))) would be (PROGN (*InPlace A C D) (+InPlace A A B)) using A as a temporary, although a smart compiler or interpretor ought to be able to recognize (+InPlace A B (* C D)) and convert it into a totally-efficient calculation so the user can retain the ability to nest * inside +(InPlace). -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 09:10:37 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 06:04:49 PDT Received: from IMSSS by Score with Pup; Wed 4 Sep 85 06:03:43-PDT Date: 4 Sep 1985 0601-PDT From: Rem@IMSSS Subject: LISP has both pure and reference data types To: COMMON-LISP%SU-AI@SCORE Tonite while thinking about my work interfacing PSL to Fortran, and recent discussions about how in CL you aren't supposed to modify any structure that was quoted in sourcecode, it occurred to me that LISP in general has two distinct classes of data, which point hasn't been raised in any manual I've read: (1) pure data, readonly, you are assured nobody will change it out from under you, but to compute a new value you must allocate new memory; (2) reference data, readwrite, designed to efficiently share side-effects and/or to efficiently compute new values in place without having to allocate a new place to put the newly-computed value. You can't mix the two. If you try to modify a datum that somebody else expects to be pure, all hell breaks loose, constants change out from under programs or you get a memory exception from trying to modify a readonly page. But if you go to the bother of making reference data but then don't bother to ever modify it in place, rather always copy the whole thing to new memory every time you change something, your program runs really slow. Examples of pure data are: integers and reals (and complexes and rationals in CL), strings that are given by syntax "...", and any other expression that is given in source code explicitly or generated by macro expansion. Examples of reference data are: all arrays constructed at runtime (which generally means *all* arrays since most LISPs don't have a syntax for giving arrays explicitly in source), any other non-atomic object that is created at runtime, value cells, property-list cells, funtion cells. Perhaps LISP (read CL and PSL) should make the distinction explicit, perhaps even having parallel datatypes for those which are supposed to be readonly (write once when allocating, thence readonly until GC'd) and those which are supposed to be modifyable. For example, you could compute an integer cell which had an initial value but that value could be changed out from under the functions that referenced it, so that the side effects of changing that integer could be shared more efficiently than if you shared the name of a global or lexical variable whose value cell was modified to point to different integers, and you could safely pass that integer cell to FORTRAN or other software that wanted to modify the value in place; but you could also keep around oldstyle integers that weren't supposed to be changed, and any FORTRAN interface or other software could automatically know to make a copy of the integer into a reference-integer cell before proceeding with the code that modified it, leaving the oldstyle integer unmunged. Having explicit data types for pure-integer versus modifyable-integer would be cleaner than trapping memory exceptions on attempt to modify a readonly page, and implementable on more systems. Meanwhile, it should be documented that currently LISP doesn't have such distinct data types in the language nor in most implementations, so it's up to the user to manually keep track of which values are safe to change and which aren't (and thus to be massively copied before passing them to a routine which will modify in place for efficiency). Also, perhaps we should have some new functions that do arithmetic in place, to support efficient arithmetic in cases where shared type-declared lexical variables aren't efficient enough or aren't general enough? Thus in addition to Value <- (+ A B C ... Z) which can generate slightly efficient code when all arguments are declared integer or real, we can have (+InPlace Result A B C ... Z) which requires all arguments including Result to be declared of the same type, likewise for the other primitive arithmetic functions. +InPlace would not have to do a number-cons, even if Result was a place deep inside some s-expression that was assumed (user's responsibility currently) to already contain a modifyable number of the correct type. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 06:06:33 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Sep 85 03:01:04 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 305986; Wed 4-Sep-85 05:59:18-EDT Date: Wed, 4 Sep 85 06:00 EDT From: Robert W. Kerns Subject: Re: compiling multiple files To: SCHUMACHER%hplabs.csnet@CSNET-RELAY.ARPA cc: LOOSEMORE%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8509032357.AA17278@HP-VENUS> Message-ID: <850904060013.0.RWK@CROW.SCRC.Symbolics.COM> Date: Tue 3 Sep 85 16:57:21-PDT From: SCHUMACHER%hplabs.csnet@csnet-relay.arpa What you need can be done using the require function (sec 11.8 modules in CLtL) assuming that the appropriate provide calls have been made, or you can simply use (eval-when (eval compile) (load ...)) . Lee Schumacher ------- This isn't the same thing at all, especially this last suggestion. Loading a file into the compilation environment is not the same as compiling it into the file! Nor is putting a REQUIRE into a file the same as compiling the required software into a resulting file, which is what was request. I believe this describes the desired behaviour: (defmacro insert-file-and-compile (file) (with-open-file (stream file) (do* ((eof (cons 'eof nil)) (form (read stream nil eof) (read stream nil eof)) (forms)) ((eq form eof) `(progn ,@(nreverse forms))) (push form forms))))  Received: from SU-AI.ARPA by MIT-MC.ARPA 4 Sep 85 00:18:19 EDT Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 21:11:22 PDT Received: by su-navajo.arpa with TCP; Tue, 3 Sep 85 21:10:23 pdt Received: by edsel.uucp (2.0/SMI-2.0) id AA16018; Tue, 3 Sep 85 20:07:30 pdt Date: Tue, 3 Sep 85 20:07:30 pdt From: edsel!eb@su-navajo.arpa (Eric Benson) Message-Id: <8509040307.AA16018@edsel.uucp> To: navajo!Common-Lisp@SAIL Subject: Modifying constants in programs Here is a paragraph from CLtL which has some bearing on the discussion of modifying constants in code: ''An additional problem with EQ is that the implementation is permitted to "collapse" constants (or portions thereof) appearing in code to be compiled if they are EQUAL. An object is considered to be a constant in code to be compiled if it is a self-evaluating form or is contained in a QUOTE form. This is why (EQ "Foo" "Foo") might be true or false; in interpreted code it would normally be false, because reading in the form (EQ "Foo" "Foo") would construct distinct strings for the two arguments to EQ, but the compiler might choose to use the same identical string or two distinct copies as the two arguments in the call to EQ. Similarly, (EQ '(A . B) '(A . B)) might be true or false, depending on whether the constant conses appearing in the QUOTE forms were collapsed by the compiler. However, (EQ (CONS 'A 'B) (CONS 'A 'B)) is always false, because every distinct call to the CONS function necessarily produces a new and distinct cons.'' This implies that it is illegal to modify a constant in compiled code, since the compiler is licensed to share all or part of that constant with other compiled code. For the particular example of COMPUTE-ONCE, it is not necessary to use a special variable to hold the computed value. A lexical variable will suffice. The scope of the lexical variable must include the entire function in which it is referenced. This is similar to an OWN variable in Algol 60.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 21:56:44 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 18:49:22 PDT Received: from hplabs by csnet-relay.csnet id ar25737; 3 Sep 85 21:34 EDT Received: by HP-VENUS id AA17278; Tue, 3 Sep 85 16:57:06 pdt Message-Id: <8509032357.AA17278@HP-VENUS> Date: Tue 3 Sep 85 16:57:21-PDT From: SCHUMACHER%hplabs.csnet@csnet-relay.arpa Subject: Re: compiling multiple files To: LOOSEMORE Cc: common-lisp@su-ai.ARPA In-Reply-To: Message from "SANDRA " of Mon 2 Sep 85 04:33:30-PDT Source-Info: From (or Sender) name not authenticated. What you need can be done using the require function (sec 11.8 modules in CLtL) assuming that the appropriate provide calls have been made, or you can simply use (eval-when (eval compile) (load ...)) . Lee Schumacher -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 19:34:20 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:26:51 PDT Received: from ucblarch.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA07954; Tue, 3 Sep 85 16:24:05 pdt Date: Tue, 3 Sep 85 16:25:13 pdt From: wilensky@ucblarch (Robert Wilensky) Message-Id: <8509032325.6681@ucblarch.ARPA> Received: by ucblarch.ARPA (2.0/3.5) id AA06681; Tue, 3 Sep 85 16:25:13 pdt To: common-lisp@su-ai Subject: inconsistency in the definitions of round-off functions Cc: hilfingr%ernie@Berkeley, fateman%dali@Berkeley, wilensky%dali@Berkeley, jkf%mike@Berkeley The definition of the functions ``floor'', etc. is inconsistent. In one paragraph (p. 216) it is stated that ``(floor 5 2) is equivalent to (floor (/ 5 2))''. However, according to the very next paragraph, this is not true of the second value returned. This is because, ``If any of these functions is given the two arguments x and y and produces results q and r, then q . y + r = x''. Thus, ``(floor 5 2)'' returns 2 and 1, while ``(floor (/ 5 2))'' returns 2 and 1/2. This is fact appears to be true of VAXLISP.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 19:26:13 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:19:15 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 197368; Tue 3-Sep-85 14:29:06-EDT Date: Tue, 3 Sep 85 14:29 EDT From: Daniel L. Weinreb Subject: Re: lexical madness To: Masinter.pa@XEROX.ARPA, MLY@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850902-151936-2212@Xerox> Message-ID: <850903142930.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: 2 Sep 85 15:27 PDT From: Masinter.pa@Xerox.ARPA Would removing this ambiguity in the language seriously affect any current implementation? Our implementation considers a LET that names the same variable twice to be in error. The interpreter does not check for the error, but the compiler does and signals an error. When I wrote that part of the compiler in 1981, Common Lisp was still in its early stages of life, but I thought it was apparent that such a case is an error. I still think that it ought to be considered an error, since to define it to be legal, with any of the possible meanings that suggest themselves, would only introduce a construct that would be confusing to someone reading the program, and which has no benefits of its own.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 19:25:21 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 16:18:51 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 197360; Tue 3-Sep-85 14:15:31-EDT Date: Tue, 3 Sep 85 14:15 EDT From: Daniel L. Weinreb Subject: constructor function vs constructor macro To: Fahlman@CMU-CS-C.ARPA, Masinter.pa@XEROX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850903141553.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Mon, 2 Sep 1985 21:55 EDT From: "Scott E. Fahlman" Looks to me like the use of the word "macro" on page 357 is wrong. Agreed. This is probably a hangover from Zetalisp, in which the constructors really are macros. This micro-mistake has been around at least since the Colander Edition.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 16:19:43 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 13:10:07 PDT Received: from IMSSS by Score with Pup; Tue 3 Sep 85 13:08:42-PDT Date: 3 Sep 1985 1306-PDT From: Rem@IMSSS Subject: shared structure, other restrictions on program=data To: COMMON-LISP%SU-AI@SCORE It is well known that not all valid LISP data objects are executable forms. But which restrictions are enforced by CL and which aren't doesn't seem clear/obvious and should be spelled out in the manual. Dotted lists are illegal at the toplevel of any form (and recursively at the toplevel of any sub-form that gets EVALuated), except in the case of macro forms before expansion. That part is obvious to nearly all. Car of form must be a lambda expression or defined function or macro, number and type of arguments must be correct, etc., etc., all obvious. No shared structure may be present, even in quoted data, in a form. This is surprizing, but has come up in this current discussion. This applies both to shared structure typed in via the #: mechanism, and to expansions of macros that generate multiple references to some structure. This all should be documented clearly. No undeclared free variables may be referenced. This causes a difference between interpreted and compiled behaviour in other LISPs, but causes both interpretor and compiler to fail the same in CL. Any other restrictions I missed? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 15:28:42 EDT Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 12:19:01 PDT Date: Tue 3 Sep 85 12:17:46-PDT From: Evan Kirshenbaum Subject: Re: Side effecting constants inside functions To: DLW@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA In-Reply-To: Message from "Daniel L. Weinreb " of Tue 3 Sep 85 10:36:01-PDT Whoops! I didn't look at the function I sent. I inserted it from a file, and of course it was the wrong file (a first attempt). The final version is of course: (defmacro compute-once (form) (let ((cell (cons nil nil))) `(if (car ',cell) (cdr ',cell) (progn (setf (car ',cell) t) (setf (cdr ',cell) ,form))))) Which uses the car as a valuep flag and the cdr as a value field. As to typing it in directly, could you do something like (this hasn't been tested): (if (car '#1:(nil)) (cdr '#1#) (progn (setf (car '#1#) t) (setf (cdr '#1#)
))) This notation has come in handy more than once. Unfortunately, unless there is another way to do things like caching, Common Lisp should have some concrete definition of what we can and can't expect the semantics of code which is self modifying or contains shared structure to be. evan -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 15:18:08 EDT Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 12:06:52 PDT Date: Tue 3 Sep 85 12:05:09-PDT From: Evan Kirshenbaum Subject: Re: Side effecting constants inside functions To: DLW@SCRC-QUABBIN.ARPA cc: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA In-Reply-To: Message from "Daniel L. Weinreb " of Tue 3 Sep 85 10:24:32-PDT Well, it ran on my interpreter (Hedrick's TOPS-20), and that's roughly the form I have used in the past. Out of curiousity, is there any way to define a form which caches values (computes them once) that is not self-modifying? I have more than a casual interest, as this is a problem we are facing in a language I'm working on. evan -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 13:48:01 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 10:34:06 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 197331; Tue 3-Sep-85 13:33:07-EDT Date: Tue, 3 Sep 85 13:33 EDT From: Daniel L. Weinreb Subject: Re: Side effecting constants inside functions To: evan@SU-CSLI.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Sep 85 05:37-EDT from Evan Kirshenbaum Message-ID: <850903133318.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Tue 3 Sep 85 02:37:29-PDT From: Evan Kirshenbaum (defmacro compute-once (form) (let ((cell (cons nil nil))) `(if (car ',cell) (cdr ',cell) (setf (car ',cell) ,form)))) This has a bug too: if the form returns NIL, it will be computed more than once. However, the more interesting point is that it returns a form that has internal sharing of list structure. It seems quite possible to me that some Common Lisp implementation out there might not handle this properly. For example, if a function using this compute-once were written in a file, and the file were compiled with compile-file, and the resulting bin file were loaded, the resulting compiled function might end up having three different copies of the cell. Another way to look at it is that the expansion of a function that uses compute-once will be a piece of list structure that has no readable printed representation. That is, the macro lets you build programs that are impossible to type in directly. In my opinion, a Common Lisp implementation should not be required to deal with cases such as this, just as it is not required to deal with iteration implemented out of circular CONDs.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 13:34:43 EDT Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 10:23:52 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 32398; Tue 3-Sep-85 13:23:46-EDT Date: Tue, 3 Sep 85 13:22 EDT From: Daniel L. Weinreb Subject: Re: Side effecting constants inside functions To: evan@SU-CSLI.ARPA, Masinter.pa@XEROX.ARPA cc: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Sep 85 01:01-EDT from Evan Kirshenbaum Message-ID: <850903132259.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Mon 2 Sep 85 22:01:34-PDT From: Evan Kirshenbaum (defmacro compute-once (form) (let ((var (gensym))) `(if (boundp ',var) ,var (setf ,var ,form)))) This lacks the self-modifying-ness of the original example. And it doesn't work, if you run it interpreted and the interpreter handles macros in the straightforward way (no automatic memoization, etc). A new symbol is created each time by the call to gensym. I believe that the claim in CLtL that the interpreter and the compiler have precisely the same semantics "so far as possible" must be read with the understanding that the semantics can differ in the face of macros whose expansion causes side-effects.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 10:27:39 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 07:19:49 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA20078; Tue, 3 Sep 85 10:19:31 edt Date: Tue, 3 Sep 85 10:19:31 edt From: Steven Haflich Message-Id: <8509031419.AA20078@mit-ems.ARPA> To: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA Subject: Re: Side effecting constants inside functions > From: Evan Kirshenbaum > Subject: Re: Side effecting constants inside functions > > ... > (defmacro compute-once (form) > (let ((cell (cons nil nil))) > `(if (car ',cell) (cdr ',cell) > (setf (car ',cell) ,form)))) > ... All these proposed mechanisms work in compiled code, but CLtL intentionally [?] provides no guarantee that a macro will be expanded only the first time an interpreted function is evaluated. Questionable macro hacks like these are a wonderful tool to retain a few unpredictable differences between compiler and interpreter semantics in the language ;-). The original issue was whether modification of code or internal constants in code ought be defined in the language. I plead all code modification should be `an error', but with no guarantee that the error will be signalled. (In particular, the practice might happen to work in some implementations.) This is exactly the situation now. The only change would be to the manual. Below is an attempt at a clean formal statement: ===== It is an error to attempt subsequently to modify the closure created when the @I(function) special form is passed a lambda expression. (It may, of course, be discarded.) For these purposes, defun, defmacro, and friends such as defstruct may all be considered to create functions by evaluating a @I(function) special form. Note: The function created by defmacro, of course, is not the macro itself, but the unnamed lambda stored in the macro-function cell of the named symbol. ===== I anticipate argument that this restriction makes impossible all the neat code modification hacks for which lisp is famous. So be it. Hacking the insides of a lambda has never worked for compiled code, and (p.143): an implementation of Common Lisp has great latitude in deciding exactly when to expand macro calls inside a program. ... (An implementation might even choose always to compile functions defined by @B(defun), even when operating in an "interpretive" mode!) It is but a small additional step to permit "(function (lambda ... ))" also to invoke the compiler, and on this CLtL is silent. (I admit the performance issues might be horrendous in some cases.) Remember, messing with the innards of a lambda, for example, changing the identity of lexically referenced variables, completely invalidates any lexical analysis performed by @I(function). Read p.89 for details. If one feels it is absolutely necessary to modify code, the correct way to do it is by passing a form to an explicit call to eval. A final side issue: Perhaps CLtL should provide a plausible *sketch* for the defun macro. This would make clearer to the neophyte the connection between @I(defun) and @I(function). Something simple, ignoring any messy complications, like: (defmacro defun (name lambda-list . body) `(setf (symbol-function ,name) (function (lambda ,lambda-list ,@body))))  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 09:29:32 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 06:23:27 PDT Date: Tue, 03 Sep 85 09:24:57 EDT From: greek@DEC-HUDSON Subject: STRING-CHAR-CODE-LIMIT = CHAR-CODE-LIMIT To: common-lisp@su-ai Yes, now that I think about the rich repertoire of keys on the 3600's keyboard, that was clearly a stupid bet I made. I owe Mr. Moon a beer. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 05:45:04 EDT Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 3 Sep 85 02:38:22 PDT Date: Tue 3 Sep 85 02:37:29-PDT From: Evan Kirshenbaum Subject: Re: Side effecting constants inside functions To: Masinter.pa@XEROX.ARPA, TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA In-Reply-To: Message from "Evan Kirshenbaum " of Mon 2 Sep 85 22:01:35-PDT Actually, my earlier suggestion compiles inefficiently since it uses a special variable in a way a compiler might not be able to catch and simplify. A slightly better solution (more patterned after the original suggestion) would be: (defmacro compute-once (form) (let ((cell (cons nil nil))) `(if (car ',cell) (cdr ',cell) (setf (car ',cell) ,form)))) The main difference between this and the original is that the let is done at expansion time rather than at execution time. This code does modify itself (although I had to try it out to make sure that it actually worked the way I thought it would), but it doesn't run into the problem with read-only areas that as inherent in the other one. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Sep 85 01:09:22 EDT Received: from SU-CSLI.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 22:02:29 PDT Date: Mon 2 Sep 85 22:01:34-PDT From: Evan Kirshenbaum Subject: Re: Side effecting constants inside functions To: Masinter.pa@XEROX.ARPA cc: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, evan@SU-CSLI.ARPA In-Reply-To: Message from "Masinter.pa@Xerox.ARPA" of Mon 2 Sep 85 17:53:00-PDT >(defmacro compute-once (form) > `(let ((value '(,nil . ,nil))) > (cond ((car value) (cdr value)) > (t (setf (car value) t) > (setf (cdr value) ,form)))) But wouldn't it be more reasonable to do something more like: (defmacro compute-once (form) (let ((var (gensym))) `(if (boundp ',var) ,var (setf ,var ,form)))) This lacks the self-modifying-ness of the original example. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Sep 85 22:00:43 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 18:55:04 PDT Received: ID ; Mon 2 Sep 85 21:55:38-EDT Date: Mon, 2 Sep 1985 21:55 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Masinter.pa@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: constructor function vs constructor macro In-reply-to: Msg of 2 Sep 1985 21:17-EDT from Masinter.pa at Xerox.ARPA Yes, I think that section 19.3 makes very clear that the constructor created by a defstruct is a function. There's certainly nothing about the syntax described there that suggests that the constructor should be a macro. Looks to me like the use of the word "macro" on page 357 is wrong. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Sep 85 21:34:24 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 18:29:05 PDT Received: ID ; Mon 2 Sep 85 21:29:41-EDT Date: Mon, 2 Sep 1985 21:29 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Masinter.pa@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: lexical madness In-reply-to: Msg of 2 Sep 1985 18:27-EDT from Masinter.pa at Xerox.ARPA Most implementations of PSETQ that I've seen eval the values onto the stack and then pop and bind in reverse order. LET is sometimes handled in the same way. Sure, we could remove the ambiguity by requiring every compiler to be rewritten so that it looks for twice-bound variables in a single parallel-binding form. But it seems to me that this is too much extra work in order to remove the ambiguity in a profoundly worthless case. I think we should just tell the user that if he really cares which value X gets bound to, he shouldn't bind it twice in the same LET or PSETQ. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Sep 85 21:13:13 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 18:08:45 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 02 SEP 85 18:09:26 PDT Date: 2 Sep 85 18:17 PDT From: Masinter.pa@Xerox.ARPA Subject: constructor function vs constructor macro To: common-lisp@su-ai.ARPA Message-ID: <850902-180926-2266@Xerox> On p. 308, it says that defstruct defines a constructor function named make-name, and talks about the automatically defined constructor-function. However, on page 357, it says that #S calls the constructor . Am I right in assuming that p 357 is wrong, and the constructor is a function rather than a macro?  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Sep 85 20:50:24 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 17:45:39 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 02 SEP 85 17:45:37 PDT Date: 2 Sep 85 17:53 PDT From: Masinter.pa@Xerox.ARPA Subject: Re: Side effecting constants inside functions In-reply-to: Charles Hornig 's message of Mon, 26 Aug 85 10:36 EDT To: TIM@MIT-MC.ARPA, common-lisp@SU-AI.ARPA Message-ID: <850902-174537-2252@Xerox> What's wrong with this style? Normally, there's an invariant that running a piece of code doesn't change its semantics, or how it prints out. The example you gave violates that invariant, and thus seems clearly to be "bad style". (A lot of things attributed to "style" actually have good reasons behind them, if you think about it.) (Your example doesn't act like a lexical closure because its not reentrant.) Here's a more reasonable, although not compelling, example. (defmacro compute-once (form) `(let ((value '(,nil . ,nil))) (cond ((car value) (cdr value)) (t (setf (car value) t) (setf (cdr value) ,form)))) (compute-once ) executes once, the first time it is run. Well, its a more reasonable example... I have to admit that I thought it was pretty awful when I first saw it, but then, that's what I thought of #. too.  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Sep 85 18:23:53 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 85 15:18:55 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 02 SEP 85 15:19:36 PDT Date: 2 Sep 85 15:27 PDT From: Masinter.pa@Xerox.ARPA Subject: Re: lexical madness In-reply-to: Richard Mlynarik 's message of Sat, 31 Aug 85 09:16:45 EDT To: MLY@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <850902-151936-2212@Xerox> there's no reason for the order to be "unpredictable". It would be more reasonable to say "all all assigments are done in left-to-right order". A smart compiler can then possibly detect that none of the variables are duplicated and that there are no interrupts and thus it doesn't matter what order they're done in. Similarly, LET should be defined so that the last binding of a variable is the one that applies. Would removing this ambiguity in the language seriously affect any current implementation?  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Sep 85 22:51:23 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 19:44:45 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 304826; Sun 1-Sep-85 22:36:36-EDT Date: Sun, 1 Sep 85 22:37 EDT From: David A. Moon Subject: STRING-CHAR-CODE-LIMIT To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 1 Sep 85 12:49-EDT from greek@DEC-HUDSON Message-ID: <850901223739.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 01 Sep 85 12:49:37 EDT From: greek@DEC-HUDSON I guess it would be wrong to assume that STRING-CHAR-CODE-LIMIT = CHAR-CODE-LIMIT. But I bet that equality holds for every implementation. Pay up. :-)  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Sep 85 19:11:18 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 16:06:43 PDT Date: Sun 1 Sep 85 17:08:44-MDT From: SANDRA Subject: compiling multiple files To: common-lisp@SU-AI.ARPA Message-ID: <12139879306.28.LOOSEMORE@UTAH-20.ARPA> I cannot find any mention in the CLM of how one might compile several source files into a single binary file. Most dialects of FORTRAN, C, etc. have some sort of "include" construct to allow indirection. In PSL, the DSKIN function serves this purpose; if the compiler sees a DSKIN as a top level form, it will compile the forms within that file rather than compiling a call to DSKIN. Typically, this is used to modularize nonportable code into separate files for each system instead of lumping everything together into a single file. It's much less awkward than #+ and #- when dealing with a half-dozen different implementations and many pages of implementation-specific code for each case. I realize it is not too difficult to write a macro to do this in CL, but it seems like this feature would be useful enough to be standardized. Do any CL implementations already provide such a feature? Or have I missed something in the manual? -Sandra -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Sep 85 12:52:38 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 09:48:08 PDT Date: Sun, 01 Sep 85 12:49:37 EDT From: greek@DEC-HUDSON Subject: STRING-CHAR-CODE-LIMIT To: common-lisp@su-ai The definition given for STRING-CHAR-CODE-LIMIT is too simplistic. In VAX LISP for example, a character can't have bits or font if it is to be stored into a simple-string. As Scott says, STRING-CHAR-P exists exactly so that you can find out if a character is a string-char. You might want to build a table with an entry for every string-char; then STRING-CHAR-CODE-LIMIT might be useful. However, you can figure out how big to make the table using CODE-CHAR. I guess it would be wrong to assume that STRING-CHAR-CODE-LIMIT = CHAR-CODE-LIMIT. But I bet that equality holds for every implementation. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Sep 85 12:46:32 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 09:42:01 PDT Date: Sun, 01 Sep 85 12:43:31 EDT From: greek@DEC-HUDSON Subject: Letting LET bind the same variable more than once. To: common-lisp@su-ai I would have thought that was an error. It's OK for LET*, but just seems like a mess for LET. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 1 Sep 85 10:48:41 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Sep 85 07:43:21 PDT Received: ID ; Sun 1 Sep 85 10:43:45-EDT Date: Sun, 1 Sep 1985 10:43 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: edsel!eb@Navajo (Eric Benson) Cc: Common-Lisp@SU-AI.ARPA Subject: New constants needed In-reply-to: Msg of 31 Aug 1985 17:45-EDT from edsel!eb at Navajo (Eric Benson) I have no particular objection to your proposed new constants, but I don't see the reason for String-Char-Code-Limit, as long as each implementation is required to provide a correct implementation of String-Char-P. Requiring such a limit would implicitly require that the string chars occupy a continuous range starting at 0 and with no holes. I don't think we require that now, and it might be awkward for some odd encodings -- I'm not sure what EBCDIC does. If it were up to me, we'd just define the language in terms of ASCII and be done with it, but if we are going to straddle the fence on this (as Guy has done so carefully), we must be careful not to fall off. I suppose that if we were to define these limits as bounds on the set of legal string or readtable characters, without saying that characters within these bounds are necessarily legal, then we can at least use them to see how large certain tables and fields have to be. CHAR-CODE-LIMIT already gives us a loose bound of this sort, but perhaps these other numbers would give a somewhat tighter bound for some implementations. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Aug 85 17:54:35 EDT Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 31 Aug 85 14:50:24 PDT Received: by edsel.uucp (2.0/SMI-2.0) id AA07008; Sat, 31 Aug 85 14:45:38 pdt Date: Sat, 31 Aug 85 14:45:38 pdt From: edsel!eb@Navajo (Eric Benson) Message-Id: <8508312145.AA07008@edsel.uucp> To: navajo!Common-Lisp@SAIL Subject: New constants needed I suggest adding the following defined constants to the next edition of Common Lisp: STRING-CHAR-CODE-LIMIT The upper bound of character codes in string characters. (STRING-CHAR-P X) is equivalent to (AND (<= 0 (CHAR-CODE X)) (< (CHAR-CODE X) STRING-CHAR-CODE-LIMIT)) READTABLE-CHAR-CODE-LIMIT The upper bound of character codes for characters which may be readtable indices, i.e. legal first arguments to SET-SYNTAX-FROM-CHAR, SET-MACRO-CHARACTER, etc. In many implementations CHAR-CODE-LIMIT is the same as STRING-CHAR-CODE-LIMIT and READTABLE-CHAR-CODE-LIMIT, but not in all implementations, for example Symbolics Common Lisp.  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Aug 85 09:21:25 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Aug 85 06:17:15 PDT Date: Sat, 31 Aug 85 09:16:45 EDT From: Richard Mlynarik Subject: lexical madness To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].629495.850831.MLY> The definition of psetf specifies that the evaluations are performed from left to right, but specifies that "all the assignments are performed in an unpredicatable order" There is, however, nothing said about the order in which `let' bindings are made, only that "all the variables ... are bound to the corresponding values in parallel" So, to what should "(let ((x 1) (x 2)) x)" evaluate? Other lacks of insight from the latest descent into Interpreted Hell: * Was anything definitive resolved about the pervasiveness of (not)inline and ftype declarations in the presence of flet and labels? * I assume that "(let* ((x 1) (x (1+ (symbol-value 'x)))) (declare (special x)) x)" evaluates to 2 (ie the special declaration applies to all bindings) The same goes for multiply-bound variables in lambda-lists. Next week: confessions of a wimplementor..  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Aug 85 22:43:31 EDT Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 19:38:12 PDT Date: Fri 30 Aug 85 19:37:27-PDT From: System-Assoc Dir Subject: Re: close queries To: robbins@DEC-HUDSON.ARPA cc: IMSSS@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message from "robbins@DEC-HUDSON" of Wed 21 Aug 85 11:18:49-PDT Message-ID: <12139393016.27.IMSSS@SUMEX-AIM.ARPA> To close a synonym stream without closing the underlying stream, you could reset the mediating symbol to point at a closed stream. This is less than adequate for the general case, but might suggest some mechanism that would work generally. (One problem of course is that you may still want to access the name, etc., of the closed stream.) I'm inclined to argue that the underlying stream should not be closed, simply to give the user finer control. jim mcdonald -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Aug 85 17:18:49 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 30 Aug 85 14:10:41 PDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 28 AUG 85 23:03:39 EDT Received: from MIT-DUANE by MIT-OZ via Chaosnet; 28 Aug 85 23:03-EDT Date: Wed, 28 Aug 85 23:03 EDT From: Christopher Fry Subject: put me on mailing list To: common-lisp@OZ Message-ID: <850828230313.2.CFRY@DUANE> Please put me on the common lisp mailing list. Is there an archive of previous messages?  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Aug 85 10:46:32 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Aug 85 07:37:01 PDT Received: from HUDSON.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 301214; Mon 26-Aug-85 10:36:18-EDT Date: Mon, 26 Aug 85 10:36 EDT From: Charles Hornig Subject: Side effecting constants inside functions To: Tim McNerney , common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC.ARPA].618598.850820.TIM> Message-ID: <850826103633.1.HORNIG@HUDSON.SCRC.Symbolics.COM> Date: Tue, 20 Aug 85 02:52:22 EDT From: Tim McNerney In CLtL, I can't find any mention of the issue of side effecting internal constants. In Maclisp, NIL, Zetalisp, and presumably most Common Lisp implementations, the function: (defun withdraw (amount) (let ((balance '(1000))) (decf (first balance) amount))) acts much like a lexical closure with a local state variable. Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This behaviour has always bothered me. Is this rather questionable style condoned by Common Lisp? We consider the fact that this "works" in Symbolics-Lisp (nee Zetalisp) a deficiency which we intend to remedy now that our VM system can handle read-only areas. I would certainly hope that no one would depend on this working. (Faint hope, from talking to people at IJCAI.)  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Aug 85 03:19:38 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 25 Aug 85 00:15:48 PDT Date: Sun, 25 Aug 85 03:15:02 EDT From: Tim McNerney Subject: Side effecting constants inside functions To: GSB@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Tue 20 Aug 85 03:51:17 EDT from Glenn S. Burke Message-ID: <[MIT-MC.ARPA].623486.850825.TIM> Date: Tue, 20 Aug 85 03:51:17 EDT From: Glenn S. Burke Date: Tue, 20 Aug 85 02:52:22 EDT From: Tim McNerney In CLtL, I can't find any mention of the issue of side effecting internal constants. In Maclisp [interpreted code], NIL, Zetalisp [both interpreted and compiled code], and presumably most Common Lisp implementations, the function: (defun withdraw (amount) (let ((balance '(1000))) (decf (first balance) amount))) acts much like a lexical closure with a local state variable. Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This behaviour has always bothered me. Is this rather questionable style condoned by Common Lisp? This extremely questionable style is considered "an error" in both Maclisp and NIL, which take the view that such constants are permissible to be made read-only, and potentially made EQ to other constants which are EQUAL. This would be a good position for Common Lisp to take, my point being that this is not written down anywhere (not even in the NIL manual). The rest of my letter merely supports this position by pointing out some issues that would have to be dealt with if this were NOT considered an error. Perhaps I did not make myself sufficiently clear. Tim McNerney P.S... In NIL when the code is compiled this does not work, as such constants in compiled code in NIL are currently ALWAYS read-only... Glenn S. Burnout Had you actually compiled the above function and tried it out, you would have noticed that the NIL compiler produces code with exactly the same behavior as Zetalisp, and furthermore, that the bogus state variable is, despite your claims, preserved across COMPILE.  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Aug 85 14:07:32 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Aug 85 10:56:45 PDT Date: Wed, 21 Aug 85 13:59:15 EDT From: robbins@DEC-HUDSON Subject: close queries To: common-lisp@su-ai What is supposed to happen when an attempt is made to close a synonym stream? The manual seems to indicate that it is the stream which is bound to the synonym symbol that should be closed, but, I am not sure that this is the most desirable behaviour. What about someone that desires to close the synonym stream but not the stream bound to the synonym symbol? Is it an error to close *terminal-io*? -- Rich Robbins  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Aug 85 03:59:55 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 20 Aug 85 00:49:39 PDT Date: Tue, 20 Aug 85 03:51:17 EDT From: Glenn S. Burke Subject: Side effecting constants inside functions To: TIM@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].618692.850820.GSB> Date: Tue, 20 Aug 85 02:52:22 EDT From: Tim McNerney In CLtL, I can't find any mention of the issue of side effecting internal constants. In Maclisp, NIL, Zetalisp, and presumably most Common Lisp implementations, the function: (defun withdraw (amount) (let ((balance '(1000))) (decf (first balance) amount))) acts much like a lexical closure with a local state variable. Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This behaviour has always bothered me. Is this rather questionable style condoned by Common Lisp? This extremely questionable style is considered "an error" in both Maclisp and NIL, which take the view that such constants are permissible to be made read-only, and potentially made EQ to other constants which are EQUAL. Efficiency aside, it would be cleaner for the semantics of a function which side effects its internal constants to be as though a fresh copy were made each time the function was evaluated, effectively making '(1000) == (list 1000) and #(1 2 3) == (vector 1 2 3), etc. This way, the above function would always return 900. Please take 2000 mg of Thorazine, and 10 mg cogentin to counteract the smooth muscle contractions which might ensue. This might help to reduce the level of distortion in your perception. If such a function is to behave as it does in Maclisp, there is a subtle issue having to do with the interaction between the interpreter and the compiler: Should COMPILE reset the local state of such a function? (In NIL and Zetalisp it doesn't, but one can imagine that a "digested" copy of the original lambda expression might be cached by the interpreter, and that the compiler uses the original unscathed version). In a standard Maclisp scenario of loading compiled code, purifying and dumping the environment, this does not work. In NIL when the code is compiled this does not work, as such constants in compiled code in NIL are cuurently ALWAYS read-only. If i interpret "reset the local state of such a function" correctly, NIL always does so, since currently the in-core compilatioin is only a kludge of to-file compilation so no datastructure gets preserved. Otherwise, NIL never bashes anything, and such things as cached macro expansions performed by the interpreter have absolutely no effect on the expansions performed by the compiler. Timothy Leary Glenn S. Burnout p.s. I have a manic-depressive friend who, while i haven't seen him in a number of years, i can probably track down if given a few hours. He would no doubt have a good supply of thorazine, cogentin, and lithium on hand.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Aug 85 03:00:12 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 23:50:44 PDT Date: Tue, 20 Aug 85 02:52:22 EDT From: Tim McNerney Subject: Side effecting constants inside functions To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].618598.850820.TIM> In CLtL, I can't find any mention of the issue of side effecting internal constants. In Maclisp, NIL, Zetalisp, and presumably most Common Lisp implementations, the function: (defun withdraw (amount) (let ((balance '(1000))) (decf (first balance) amount))) acts much like a lexical closure with a local state variable. Thus, (withdraw 100) => 900, then (withdraw 100) => 800, etc. This behaviour has always bothered me. Is this rather questionable style condoned by Common Lisp? Efficiency aside, it would be cleaner for the semantics of a function which side effects its internal constants to be as though a fresh copy were made each time the function was evaluated, effectively making '(1000) == (list 1000) and #(1 2 3) == (vector 1 2 3), etc. This way, the above function would always return 900. If such a function is to behave as it does in Maclisp, there is a subtle issue having to do with the interaction between the interpreter and the compiler: Should COMPILE reset the local state of such a function? (In NIL and Zetalisp it doesn't, but one can imagine that a "digested" copy of the original lambda expression might be cached by the interpreter, and that the compiler uses the original unscathed version). Tim McNerney  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Aug 85 14:16:12 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Aug 85 11:04:34 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 298471; Mon 19-Aug-85 12:56:04-EDT Date: Mon, 19 Aug 85 12:57 EDT From: David A. Moon Subject: with-output-to-string query To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850819125712.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 18 Aug 1985 18:19 EDT From: "Scott E. Fahlman" It seems clear to me that no one intended WITH-OUTPUT-TO-STRING to throw away characters if given a non-adjustable string to fill. Since it can't return a value to say whether it filled the string, it should signal an error. I think this is just looseness in the manual, not a real language issue. If someone else disagrees they should speak up! I agree that it would be preferable in this case to signal an error -- as I said in my earlier note, it is rather treacherous to just discard charaters without warning. However, the curent text of the manual seems to say more or less clearly (though by indirection thropugh Vector-Push) that no error is signalled in this case I don't see this implication in the text. The only thing that is clear is that it says the output is appended to the string. This is getting awfully rabbinical! , so to "clarify" the manual as Moon suggests is really a change, though one in a corner so obscure that it wouldn't bother people too much. Perhaps the best resolution is for now to say that "it is an error" to overflow the string being written, and to change this to "signals an error" in Common Lisp 86 (or whenever). Or leave it "is an error" for all time, allowing individual implementations to choose between safety, efficiency, and compatible with past broken implementations. That seems like the best resolution to me. Of course no matter what the resolution, it doesn't affect my implementation, since all strings are adjustable, so I'm happy.  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Aug 85 18:27:07 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 15:19:05 PDT Received: ID ; Sun 18 Aug 85 18:20:02-EDT Date: Sun, 18 Aug 1985 18:19 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: with-output-to-string query In-reply-to: Msg of 18 Aug 1985 14:59-EDT from David A. Moon It seems clear to me that no one intended WITH-OUTPUT-TO-STRING to throw away characters if given a non-adjustable string to fill. Since it can't return a value to say whether it filled the string, it should signal an error. I think this is just looseness in the manual, not a real language issue. If someone else disagrees they should speak up! I agree that it would be preferable in this case to signal an error -- as I said in my earlier note, it is rather treacherous to just discard charaters without warning. However, the curent text of the manual seems to say more or less clearly (though by indirection thropugh Vector-Push) that no error is signalled in this case, so to "clarify" the manual as Moon suggests is really a change, though one in a corner so obscure that it wouldn't bother people too much. Perhaps the best resolution is for now to say that "it is an error" to overflow the string being written, and to change this to "signals an error" in Common Lisp 86 (or whenever). -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Aug 85 15:07:26 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Aug 85 11:59:02 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 298206; Sun 18-Aug-85 14:58:44-EDT Date: Sun, 18 Aug 85 14:59 EDT From: David A. Moon Subject: with-output-to-string query To: Scott E. Fahlman cc: robbins@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850818145935.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 16 Aug 1985 15:41 EDT From: "Scott E. Fahlman" The definition of WITH-OUTPUT-TO-STRING given in the Common Lisp reference manual states that: "If string is specified ... the output is incrementally appended to the string, as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH." This implies that after a non-adjustable output string is "filled" any extra characters output to it will simply be dropped and no error will be signalled. Is this correct? Yeah, given that VECTOR-PUSH is documented not to complain when a non-adjustable string overflows, it seems to follow that WITH-OUTPUT-TO-STRING should just ignore excess output in this case and not signal an error. This seems like a treacherous mechanism that could screw the unwary, but in the vast majoirty of cases users will let the system create the string or will use an adjustable one if this meant to implement some sort of non-consing buffer. I'm not sure why we decided that VECTOR-PUSH should fail silently, but we must have had some good reason at the time. Probably we just copied Zetalisp and THEY had a good reason. VECTOR-PUSH doesn't fail silently, it returns a value to say whether or not it was able to store into the vector. I don't remember why this Zetalisp design decision, made in 1974 or 1975, was done this way. Actually I wasn't around then. It seems clear to me that no one intended WITH-OUTPUT-TO-STRING to throw away characters if given a non-adjustable string to fill. Since it can't return a value to say whether it filled the string, it should signal an error. I think this is just looseness in the manual, not a real language issue. If someone else disagrees they should speak up!  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Aug 85 19:21:56 EDT Date: 16 Aug 85 1536 PDT From: Dick Gabriel Subject: Greetings To: common-lisp@SU-AI.ARPA As I have observed, we have all had a productive year in implementing and thinking about Common Lisp. The various subcommittees have been busily considering issues of interest to the Common Lisp community. It has been nearly a year since the Monterey meeting, and DARPA feels that it is time for a second meeting. At this meeting, I think it is possible to settle matters in the following areas: Charter Validation I think we can make great headway in these areas: Object Oriented Programming Error Handling I think concerns can be aired in the remaining areas. After some thought, it seems that the East Coast in late October or mid-November is a good time. Comments as to exact dates and a location would be appreciated. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Aug 85 15:52:14 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 12:40:38 PDT Received: ID ; Fri 16 Aug 85 15:41:26-EDT Date: Fri, 16 Aug 1985 15:41 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: robbins@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: with-output-to-string query In-reply-to: Msg of 16 Aug 1985 14:59-EDT from robbins at DEC-HUDSON The definition of WITH-OUTPUT-TO-STRING given in the Common Lisp reference manual states that: "If string is specified ... the output is incrementally appended to the string, as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH." This implies that after a non-adjustable output string is "filled" any extra characters output to it will simply be dropped and no error will be signalled. Is this correct? Yeah, given that VECTOR-PUSH is documented not to complain when a non-adjustable string overflows, it seems to follow that WITH-OUTPUT-TO-STRING should just ignore excess output in this case and not signal an error. This seems like a treacherous mechanism that could screw the unwary, but in the vast majoirty of cases users will let the system create the string or will use an adjustable one if this meant to implement some sort of non-consing buffer. I'm not sure why we decided that VECTOR-PUSH should fail silently, but we must have had some good reason at the time. Probably we just copied Zetalisp and THEY had a good reason. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Aug 85 15:10:22 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 12:00:08 PDT Date: Fri, 16 Aug 85 14:59:35 EDT From: robbins@DEC-HUDSON Subject: with-output-to-string query To: common-lisp@su-ai The definition of WITH-OUTPUT-TO-STRING given in the Common Lisp reference manual states that: "If string is specified ... the output is incrementally appended to the string, as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH." This implies that after a non-adjustable output string is "filled" any extra characters output to it will simply be dropped and no error will be signalled. Is this correct? -- Rich Robbins  Received: from SU-AI.ARPA by MIT-MC.ARPA 16 Aug 85 04:03:32 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 16 Aug 85 00:56:32 PDT Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA28468; Fri, 16 Aug 85 00:57:56 pdt Received: by ucbkim.ARPA (5.5/5.3) id AA03790; Fri, 16 Aug 85 00:58:06 PDT Received: by franz.uucp (1.2/3.14) id AA02318; Thu, 8 Aug 85 07:13:12 pdt Date: Thu, 8 Aug 85 07:13:12 pdt From: franz!jkf@Berkeley (John Foderaro) Message-Id: <8508081413.AA02318@franz.uucp> To: common-lisp@su-ai Subject: endp or not consp Cc: On page 27 the book defines the terms 'list', 'true list' and 'dotted list', and states that most functions that expect a 'list' expect a 'true list', not a 'dotted list'. Does someone have a list (true or dotted) of precisely which functions expect and 'true list' and which will take a 'dotted list'? Only because of an example on page 267 do we learn that 'last' can take a 'dotted list'. -john foderaro  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Aug 85 20:41:27 EDT Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 15 Aug 85 15:17:56 PDT Received: from computer-lab.cambridge.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a001101; 15 Aug 85 23:15 BST Date: Thu, 15 Aug 85 23:08:19 bst From: Nick Maclaren Message-Id: <8508152208.AA09181@UK.AC.cam.cl> To: Common-Lisp@su-ai.arpa Does anyone know of anyone who is producing a Common Lisp (especially a Spice Lisp port) for IBM machines? We are interested in versions that will be available either with proper support and maintenance or as source in a working state. We are prepared to convert from any other 370-series operating system to ours (MVS), if the program is sufficiently well-suited for such conversion; this includes Amdahl UNIX. Thanks for any information. Nick Maclaren University of Cambridge Computer Laboratory Try replying to: nmm%uk.ac.cam.cl@ucl-cs.arpa  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Aug 85 15:53:43 EDT Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 13 Aug 85 12:40:48 PDT Date: 13 Aug 1985 15:39-EDT Sender: SQUIRES@USC-ISI.ARPA Subject: Re: CommonLoops: Merging Common Lisp Object-Oriented Program... From: Stephen L. Squires To: MGardner.PA@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA, Info-1100@SUMEX-AIM.ARPA Message-ID: <[USC-ISI.ARPA]13-Aug-85 15:39:47.SQUIRES> In-Reply-To: <850812-155220-3348@Xerox> Please send a copy of the report. I would also like to know when it will be in a form that we could try it out. Stephen L. Squires DARPA/IPTO Assistant Director 1400 Wilson Blvd Arlington, VA 22209  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Aug 85 19:05:47 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Aug 85 15:51:06 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 12 AUG 85 15:52:20 PDT Date: 12 Aug 85 15:53 PDT From: Masinter.pa@Xerox.ARPA Subject: CommonLoops: Merging Common Lisp Object-Oriented Programming To: Common-Lisp@SU-AI.ARPA, Info-1100@Sumex-aim.ARPA Reply-to: MGardner.PA@Xerox.ARPA Message-ID: <850812-155220-3348@Xerox> CommonLoops is is a merger of object-oriented programming and Lisp. We are proposing that it be adopted as a standard within the Common Lisp. We have written a paper about CommonLoops, which we are distributing to members of the Common Lisp Object-Oriented Programming group for discussion at a meeting during IJCAI. If you would like a copy of the paper, please send your name and complete address to Mimi Gardner (MGardner.PA@Xerox). (Copies have been distributed to members of CL-Object-Oriented-Programming). There is a discussion list, CommonLoops^.PA@XEROX, for discussions about technical issues. This discussion group is open, and currently includes members both from within and outside of Xerox. If you wish to be included, please reply. ABSTRACT Object oriented programming has long been recognized as a key programming technique for many applications. CommonLoops blends object oriented programming harmoniously with the function oriented design of Lisp. In CommonLoops, Lisp functions are methods, Lisp data types are classes, and message passing is invoked via normal Lisp function call; programs can incrementally be moved between the functional and object-oriented style. CommonLoops has a small kernel, yet it is powerful enough to be a base for implementing the features of the major object-oriented systems in use today. Through the use of metaclasses, multiple paradigms can gracefully coexist. Thus, CommonLoops provides the basic mechanism of object oriented programming as an extension to Common Lisp, while allowing a wide variety of experimentation with different styles of using it. Over the next few months, we expect the this design to profit greatly from the discussions of the community.  Received: from SU-AI.ARPA by MIT-MC.ARPA 8 Aug 85 10:23:40 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Aug 85 07:14:12 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 291294; Thu 8-Aug-85 10:14:31-EDT Date: Thu, 8 Aug 85 10:14 EDT From: Kent M Pitman Subject: Disallowing NIL as a feature To: KSH@MIT-MC.ARPA cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA In-Reply-To: <[MIT-MC.ARPA].604537.850807.KSH> Message-ID: <850808101436.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 7 Aug 85 22:45:47 EDT From: Kjeld Hvatum FROM: BACHER, STEPHEN E. SENT ON: 07/01/85 AT 08:04 DATE - 07/01/85 Reply to CL flame on disallowing NIL as a feature: If you make it an error (signalled or otherwise) for NIL to be a feature, then an awful lot of Macsyma source code will break, for NIL (the language, that is) is used as a feature name throughout in #+/#- conditionals. Since it's been proposed that features be defaultly read in the keyword package and since :NIL is not what's under discussion, this probably doesn't affect Macsyma. Presumably you'd have to type #+LISP:NIL to get the problemsome case, and I don't think anyone does that. Even if we didn't defaultly read features in the keyword package, I am the one who originally suggested disallowing NIL as a feature name and I also happen to maintain the Macsyma sources for Symbolics and I can assure you that if such a change ever "broke" Macsyma, then it could be easily be fixed in less than 15 minutes using Tags Query Replace. Let's try to distinguish between the situation of something being affected by a change and something being broken by a change. -kmp  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Aug 85 22:52:46 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 19:44:15 PDT Date: Wed, 7 Aug 85 22:45:47 EDT From: Kjeld Hvatum To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].604537.850807.KSH> FROM: BACHER, STEPHEN E. SENT ON: 07/01/85 AT 08:04 DATE - 07/01/85 Reply to CL flame on disallowing NIL as a feature: If you make it an error (signalled or otherwise) for NIL to be a feature, then an awful lot of Macsyma source code will break, for NIL (the language, that is) is used as a feature name throughout in #+/#- conditionals.  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Aug 85 15:04:56 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Aug 85 11:55:12 PDT Received: ID ; Wed 7 Aug 85 14:43:49-EDT Date: Wed, 7 Aug 1985 14:43 EDT Message-ID: From: Skef Wholey To: Common-Lisp@SU-AI.ARPA Subject: CLTL tablos and indexos (not really typos) The symbols Unsigned-Byte and Mod are not listed in the table of "standard type specifier symbols" on page 43 of CLTL. These symbols are described on pages 48 and 49 as type specifiers, however. Neither is listed in the index as a type specifier (although both have references to Open for the :element-type keyword argument). In fact, no type specifier symbols are listed as such in the index. All this was confusing to a new Common Lisp programmer who was trying to understand an existing Common Lisp program. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Aug 85 17:34:16 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 14:20:54 PDT Received: from faustinas by GODOT.THINK.COM via CHAOS; Tue, 6 Aug 85 17:21:30 edt Date: Tue, 6 Aug 85 17:20 EDT From: Guy Steele Subject: defstruct syntax To: Bobrow.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <850806-135354-1018@Xerox> Message-Id: <850806172053.6.GLS@FAUSTINUS.THINK.COM> Date: 6 Aug 85 13:50 PDT From: Bobrow.pa@Xerox.ARPA On page 307 defstruct syntax is defined as defstruct name-and-options [doc-string] {slot-description}+ we believe it should be defstruct name-and-options [doc-string] {slot-description}* since it is perfectly reasonable to have (defstruct (foo (:include bar (x 33)))) to make foo be like bar but have a different initial value for x. ken kahn & danny bobrow I agree. I should have known. "+" is almost never the right thing compared with "*". --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Aug 85 17:08:23 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 6 Aug 85 13:56:36 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 06 AUG 85 13:53:54 PDT Date: 6 Aug 85 13:50 PDT From: Bobrow.pa@Xerox.ARPA Subject: defstruct syntax To: common-lisp@su-ai.ARPA Message-ID: <850806-135354-1018@Xerox> On page 307 defstruct syntax is defined as defstruct name-and-options [doc-string] {slot-description}+ we believe it should be defstruct name-and-options [doc-string] {slot-description}* since it is perfectly reasonable to have (defstruct (foo (:include bar (x 33)))) to make foo be like bar but have a different initial value for x. ken kahn & danny bobrow  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Aug 85 13:20:48 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Aug 85 10:10:28 PDT Received: ID ; Mon 5 Aug 85 13:12:27-EDT Date: Mon, 5 Aug 1985 13:12 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Robert R. Kessler" Cc: common-lisp@SU-AI.ARPA Subject: Lambda Keywords In-reply-to: Msg of 5 Aug 1985 12:38-EDT from Robert R. Kessler No, the &foo symbols reside in the LISP package, from which almost every other package can inherit them without qualifiers. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Aug 85 12:50:06 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 5 Aug 85 09:38:24 PDT Date: Mon 5 Aug 85 10:38:22-MDT From: Robert R. Kessler Subject: Lambda Keywords To: common-lisp@SU-AI.ARPA I can't remember if this was discussed already or not, but: Should lambda keywords be installed in the keyword package (i.e. & is some how similar to :)? Bob. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 Jul 85 14:22:58 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 Jul 85 11:07:23 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286563; Wed 31-Jul-85 13:12:04-EDT Date: Wed, 31 Jul 85 13:13 EDT From: David C. Plummer in disguise Subject: Clearing the screen and other such things. To: Kent M Pitman , Earl Killian , Tim McNerney , Richard Fateman , Skef Wholey , Rob MacLachlan , Bernard S. Greenberg , Guy Steele , COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA, fateman@UCBDALI.ARPA In-Reply-To: <850726144908.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, <8507262335.AA25005@mips.UUCP>, <[MIT-MC.ARPA].590150.850727.TIM>, <8507271838.AA20272@ucbdali.ARPA>, <[MIT-MC.ARPA].590458.850727.TIM>, , , <[MIT-MC.ARPA].591637.850729.TIM>, , <850729090643.0.BSG@CONCORD.SCRC.Symbolics.COM>, <850729125323.3.GLS@POLYCARP.ARPA>, <[MIT-MC.ARPA].592267.850729.TIM> Message-ID: <850731131314.2.NFEP@NEPONSET.SCRC.Symbolics.COM> I am tempted to propose that there be a "font" whose character codes range from 0 to #o377, and are interpreted according to the SUPDUP and SUPDUP Graphics protocol. There would be some function which returns the 400 or so bits of state the describe the terminal. If nothing else, this will give people something generic to use in the n>2 years it will take to agree on something more powerful. [This is 75% serious, modulo the rough edges. I've dealt with SUPDUP quite a bit in the past and will right up a 80% complete proposal if there is enough interest.]  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 23:45:03 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 20:34:00 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 286025; Tue 30-Jul-85 21:09:40-EDT Date: Tue, 30 Jul 85 21:10 EDT From: Robert W. Kerns Subject: Terminal operations. To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 30 Jul 85 09:42-EDT from greek@DEC-HUDSON Message-ID: <850730211028.5.RWK@CROW.SCRC.Symbolics.COM> Date: Tue, 30 Jul 85 09:42 EDT From: greek@DEC-HUDSON In fact, Symbolics' use of the term "window" is grossly at odds with its use in the graphics literature, where a window is a (usually) rectangular region in the world coordinate system which is of interest to some function (e.g., one which displays it in a viewport on the screen). I hope we all agree that Common LISP should use the accepted terms when adding graphics to the language. The terms we use for the "windowing" portion of the overall graphics facility must not conflict with the terms in the remainder of the graphics facility. The concept of windows does not come from the hard-core graphics community, it comes out of the research into user-interfaces and workstations. I don't see why the graphics terminology should be considered any more "accepted". Certainly Symbolics did not invent the term "window" as we use it. This is one reason I wonder why there are two separate committees involved here. Because the concept of managing your screen real-estate between different processes and interactions has very little in common with protocols for drawing pictures and repesenting graphics. About the only thing they have in common is the use of the word "window" and that they make good use of bit-map screens. We do have to address issues like "what do we do with the word window", but the solution isn't just to declare one usage "non-standard". Personally, I don't find it confusing to talk about "A window running Lisp" vs "A window into a large diagram". In some sense, they're the same thing, but are connected into their respective universes differently. I think we can come up with a definition which will satisfy both camps.  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 17:34:58 EDT Received: from YALE.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 12:09:37 PDT Received: by YALE-BULLDOG.YALE.ARPA; 29 Jul 85 12:21:25 EDT (Mon) Message-Id: <8507291621.AA10053@YALE-BULLDOG.YALE.ARPA> Date: Mon, 29 Jul 85 10:57:46 EDT From: Jim Meehan Subject: Re: Clearing the screen and other such things. To: Kent M Pitman Cc: COMMON-LISP@SU-AI In-Reply-To: Kent M Pitman , Fri, 26 Jul 85 14:49 EDT I'm afraid I agree with most of the criticism of your proposal. It all sounds a little odd in an age where bitmaps and variable-width fonts are so popular. The fact that you propose functions to erase the character in front of the cursor and behind the cursor but not *at* the cursor suggests that you yourself are accustomed to something smarter than a glass teletype. In any case, I wanted specifically to object to your use of VALUES: ... It should be possible to say (SETF (CHARACTER-POSITION) (VALUES x y)) to later restore the cursor to the given coordinates. VALUES is an "upward only" construction, and special forms notwithstanding, you're trying to pass multiple values to the "setter" of CHARACTER-POSITION. Granted, VALUES is asymmetric, and (MULTIPLE-VALUE-CALL SET-CHARACTER-POSITION (VALUES x y)) is uglier, but VALUES in CL is a first attempt at providing a notation for passing values to the continuation of the caller, not a substitute for CONS. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 14:50:00 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 07:56:44 PDT Received: ID ; Tue 30 Jul 85 10:58:12-EDT Date: Tue, 30 Jul 1985 10:58 EDT Message-ID: From: Rob MacLachlan To: masinter.pa@XEROX.ARPA Cc: COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA Subject: CHAR-BIT In-reply-to: Msg of 30 Jul 1985 04:39-EDT from masinter.pa at Xerox.ARPA I think that in the case of I/O (and thus characters) it makes a great deal of sense to have language features which are optional. While it is true that no program that counts on the existance of such a feature is totally portable, there is at least an accepted way to describe how the program is non-portable, and a canonical implementation if the feature is implemented. If I sit down at a J. Random & Co. Lisp machine and type Control-Meta-Hyper-A, there is no guarantee that the obvious character will be sent, but if it isn't the manufacturer is guilty of criminal bogosity. It is true that if old J.R. didn't see fit to put the key on his keyboard, then any program that counted on reading characters with bits won't work too well, thus such a program is non-portable. No program which contains any character that isn't standard-char-p is portable, so implementors of portable programs must find some way to factor out implementation-dependent information about characters. Note that it is quite possible for a Common Lisp program (such as a text editor) to do sensible things with character bits if they exist, and ignore them if they don't. The text editor is still portable, it is just the key bindings which are non-portable. I see no advantage in merging bits and code. The fact that ASCII merges information that would be better encoded as separate bits is irrelevant; Common Lisp implementors have no obligation to perpetuate ASCII bogosity. I agree that the "font" support in Common Lisp is totally worthless. Fortunately it is easy to ignore. It seems that what the "font" information is really intended to represent is a facecode, e.g. "bold", "italic", rather than an absolute font "timesroman10b". As such, it would make more sense to have named character facecodes instead of these silly numbers. Even so, this wouldn't be terribly useful, since having some bits hung off of every character is a pretty poor way to represent font information. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 13:06:09 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 06:43:14 PDT Date: Tue, 30 Jul 85 09:42:48 EDT From: greek@DEC-HUDSON Subject: Terminal operations. To: common-lisp@su-ai In fact, Symbolics' use of the term "window" is grossly at odds with its use in the graphics literature, where a window is a (usually) rectangular region in the world coordinate system which is of interest to some function (e.g., one which displays it in a viewport on the screen). I hope we all agree that Common LISP should use the accepted terms when adding graphics to the language. The terms we use for the "windowing" portion of the overall graphics facility must not conflict with the terms in the remainder of the graphics facility. This is one reason I wonder why there are two separate committees involved here. I also object to the use of one GRAPHICSOP function. If we are going to add graphics, then we must decide on the semantics first, then on the function syntax. In particular, we could stipulate that all graphics/windowing/text-display functions to in a separate package. This would help some with the name conflict problem. (oops, that's "go in a separate...") Yes, we could wait until ANSII comes out with a standard. On the other hand, if we're so worried about standards, why didn't we just adopt an existing standard (e.g., GKS) in the first place? - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 05:14:35 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 02:06:30 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 30 JUL 85 02:07:17 PDT Date: 30 Jul 85 02:07 PDT From: masinter.pa@Xerox.ARPA Subject: Re: Clearing the screen etc. In-reply-to: Dave Dyer 's message of 29 Jul 85 23:05:33 PDT To: DDYER@USC-ISIB.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <850730-020717-3379@Xerox> Calling all of the display operation functions "displayop ...." doesn't help any more than proclaiming that all display operations will be symbols in the "display" package, does it? I mean, if you want something to be Common and Portable then you have to make choices. Deciding the form without the content is a non-choice.  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 04:45:09 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 30 Jul 85 01:37:52 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 30 JUL 85 01:38:41 PDT Date: 30 Jul 85 01:39 PDT From: masinter.pa@Xerox.ARPA Subject: Re: CHAR-BIT In-reply-to: Kent M Pitman 's message of Fri, 26 Jul 85 14:02 EDT To: KMP@SCRC-STONY-BROOK.ARPA cc: COMMON-LISP@SU-AI.ARPA Message-ID: <850730-013841-3371@Xerox> The control bit isn't the same as what ASCII calls "control". It cannot be, since control-A and control-a are defined to be distinct, yet those are the same in ASCII. Anything that purports to be a standard should avoid things of the nature "implementations are free to ignore this". It just leads to a false sense of portability. If you have code that relies on the Coke-Bottle feature, it won't run or be particularly meaningful in code that doesn't have Coke-Bottles. "Truthfully claim portability" is only in name. I think it makes sense to merge "bits" with "code" (since ASCII does this anyway). Implementations that want to have more "bits" can define them as extensions of the code space. new:char-code-limit = (* old:char-code-limit old:char-bits-limit) new:char-bits-limit = 1 (There's also a serious problems with fonts and font-numbers, and we've abandoned them for Interlisp-D, but that's another story.)  Received: from SU-AI.ARPA by MIT-MC.ARPA 30 Jul 85 02:24:37 EDT Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 23:07:02 PDT Date: 29 Jul 1985 23:05:33 PDT Subject: Clearing the screen etc. From: Dave Dyer To: common-lisp@SU-AI.ARPA cc: cl-windows@SU-AI.ARPA Symbolics has adopted "window" in place of "screen" in its naming conventions. I think this is the right thing, and is superior to both "screen" and "terminal" except possibly in cases where the display operation really does refer to a screen or a terminal. Also, with respect to naming, let me plug my preference; rather than add a lot of DO-THIS-OR-THAT functions, I'd rather add ONE function, which encapsulates all screen operations. I have in mind the general form; (displayop <> <> &rest args) This general form permits all "window" operations to be recognized trivially, permits generic and implementation specific extensions, and permits both "flavorized" and "macroized" implementations. It also has the advantage of not polluting the language with a lot more random function names. The CL-WINDOWS mailing list (which I theoretically moderate) is pretty moribund, mainly from the inability to sustain a conversation. I have a feeling that each of the CL implementations is pretty set in its own way of handling displays, and the efficiency issues, combined with the extremely low-level nature of display drivers, make any compromise agreement on "standards" for fully elaborated displays unlikely. As such, I support the idea of chipping off this piece of the problem. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 21:05:47 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 17:52:32 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 284905; Mon 29-Jul-85 20:51:52-EDT Date: Mon, 29 Jul 85 20:51 EDT From: David A. Moon Subject: Does READ-CHAR echo? To: Kent M Pitman , Robert W. Kerns , Earl Killian cc: Common-Lisp@SU-AI.ARPA, CWH@SCRC-STONY-BROOK.ARPA In-Reply-To: <850726150233.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, <850726172130.7.RWK@CROW.SCRC.Symbolics.COM>, <8507262313.AA24168@mips.UUCP> Message-ID: <850729205156.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 26 Jul 85 15:02 EDT From: Kent M Pitman I could not find any place in CLtL where it says whether READ-CHAR echos the character that it has read. Likewise for PEEK-CHAR. Also, there is no discussion of whether UNREAD-CHAR should unecho the character. The manual says on page 328 that READ-CHAR from the terminal echos. I don't know why this isn't repeated on page 379. The manual should say that UNREAD-CHAR doesn't unecho characters; it implies it by saying that UNREAD-CHAR is only for parsers and can only back up one character. I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess) decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR does not un-echo the character. PEEK-CHAR echos characters it eats, but not the one it leaves in the stream's input buffer. Yes, the manual ought to say something about echoing in PEEK-CHAR. This has the odd effect that: (PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR)) echos the character twice. This is a bug in our operating system, not in Common Lisp. The problem is that if instead you had written (PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (PRINT 'FOO) (READ-CHAR)) then it really was supposed to echo it twice, once before the FOO and again after it. It's somewhat difficult to fix your example without breaking this one. Does anyone have any thoughts about whether we should think about adding functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO? Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms which affect calls to the character readers within the dynamic scope of their body. I don't see anything about this in the manual, but I remember discussions of the Common Lisp committee at which we decided that Common Lisp (first edition) wasn't going to try to be a language you could write a display editor in. The problem is that this quickly gets you mired in a host of operating-system dependencies. We decided it was better to have to go outside the portable language to do the terminal input and output sections of your display editor; of course all the difficult parts could be written in Common Lisp. In addition to the ways of reading one character of input with echoing you suggested (different function, dynamically-scoped state), one should also mention using a different stream, adding a fifth optional argument to READ-CHAR, and providing functions to turn an echoing "mode" on and off. I can't guess which implementors would have difficulty getting their operating system to conform to which of these methods. Date: Fri, 26 Jul 85 17:21 EDT From: Robert W. Kerns I think the only one needed would be READ-CHAR-NO-ECHO. I agree. [From: KMP] I kind of assume that we all agree that READ and READ-LINE should echo the characters as they come in from an interactive terminal. Perhaps, we should state that explicitly in the next edition of the manual. Page 328. Date: Fri, 26 Jul 85 16:13:10 pdt From: mips!earl@Glacier (Earl Killian) Does READ-CHAR echo, or does the terminal handler, which supplied the character in the first place, echo? Echoing is terminal-specific (you don't want READ-CHAR from a file to echo) so it makes more sense to talk about what the terminal handler does. See the carefully evasive language on page 328. This starts to get into the controversy over whether you want to echo the character when it is typed ("interrupt level") or when it is read, or try to rise above these simple alternatives to do the right thing. Here comes the morass of operating-system dependencies! In some systems these concepts aren't even meaningful. In some others the implementor of Common Lisp has no control over these affairs.  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 17:19:06 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 12:34:34 PDT Received: from Cabernet.MS by ArpaGateway.ms ; 29 JUL 85 12:33:27 PDT Date: 29 Jul 85 12:30 PDT From: Fischer.pa@Xerox.ARPA Subject: RE: Clearing the screen and other such things. To: Common-lisp@SU-AI.arpa cc: CL-windows@SU-AI.arpa Message-ID: <850729-123327-2607@Xerox> Its pretty clear that the CL-Windows group became disheartened when it was reported that ANSI was working on a standard. This may not be the case. One can hope it was actually a mass defection to the ANSI group, but I doubt that. Perhaps now that the subjec thas been warmed up to, and since not much seems to have solved the problem in the interim, perhaps we can get someone to describe what the state of the various "standards committees" are. There were two mentioned just before the CL-Windows group closed its shutters, one was a band of rowdy manufacturers (including Microsoft, DRI, Intel, Apollo, Masscomp, Sun Micro Sys, Olivetti, Motorola, Nova Graphics) the other of couse ANSI. Can anyone comment immediately on the state of these committees to the CL-windows@SU-AI.arpa mailing list? (ron)  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 14:01:15 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 10:48:47 PDT Date: Mon, 29 Jul 85 13:49:44 EDT From: Tim McNerney Subject: Clearing the screen and other such things. To: BSG@SCRC-STONY-BROOK.ARPA cc: COMMON-LISP@SU-AI.ARPA, Glacier!COMMON-LISP@SU-AI.ARPA, RAM@CMU-CS-C.ARPA, Wholey@CMU-CS-C.ARPA, mips!earl@SU-GLACIER.ARPA, fateman@UCBDALI.ARPA, KMP@SCRC-STONY-BROOK.ARPA Message-ID: <[MIT-MC.ARPA].592267.850729.TIM> Date: Mon, 29 Jul 85 09:06 EDT From: Bernard S. Greenberg Date: Fri, 26 Jul 85 14:49 EDT From: Kent M Pitman As nearly as I can tell, Common Lisp offers no way to even clear the screen. It hurts me to see various sanded-edged parallelipipeds and egg-shaped frobs being offered for the reinvention of the wheel. Fine. I just assume NOT waste time re-inverting the wheel. I would be perfectly happy if we copied verbatim the functional of the ITS TTY code. Unfortunately there are problems with this. Some of which I have alluded to in previous messages. The main problem with ITS, in this respect, is that it is difficult to tell it about new terminals. This is because the knowledge of each supported terminal in embodied in assembly language code which many users are afraid to touch. Now, given the ideocyncracies of various terminals, there are clear advantages to this over any declarative database like unix termcap. Furtunately we can do it in Lisp this time around. Are there any ITS wizards who would like to write a proposal for an ITS-style terminal system for Common Lisp? How about you, Bernie? Tim McNerney  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 13:38:42 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:09:07 PDT Date: Mon, 29 Jul 85 10:08:42 EDT From: greek@DEC-HUDSON Subject: A comment on our community. To: common-lisp@su-ai It seems pretty clear to me that the Common LISP community can't agree on anything too controversial such as flavors, graphics, error handling, windows, etc. My experience with trying to set up a registration service for package names, which has all but died, left me with a similar feeling. I received notes with comments like "Well, this isn't an official statement, but my company probably wouldn't use the registrar." We should all run for Congress. Seriously, though, those of us who work on existing implementations should admit that we have a vested interest in our current flavor system, graphics system, etc. Those of us who work for profit-making organizations should admit that we want an edge over our competition. And we should all admit that, as "computer scientists", we're probably some of the most gratuitously opinionated people around. If we really can't agree on something, let's just say so and leave it at that. What I'm really afraid of is oversimplified or abbreviated proposals which address small subsets of the problem. In particular, if we ever do manage to agree on the bigger problem, we will end up with the original burp in Common LISP that looks out of place. I don't want to attack Kent's proposal as some kind of ill omen, but these simple character-oriented functions don't address a lot of problems. How does LISP know how to do them? What do some of them mean on a bitmapped terminal? Do you really want to try to program portable algorithms by continually using SCREEN-OPERATION- HANDLED-P and having multiple code paths? Earl, Tim, and Rob have pointed out other issues. Let's face it, windows, graphics, and text display are not solved problems. Why do we think we can agree on them? Perhaps our time is better spent on topics we're more likely to resolve, such as a kernel object-oriented subsystem or error handling facility? But please let's agree that a lot of politics is involved here. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 13:35:59 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:08:22 PDT Date: Mon, 29 Jul 85 10:07:01 EDT From: greek@DEC-HUDSON Subject: A comment on our community. To: common-lisp@su-ai  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 13:05:44 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 09:54:00 PDT Received: by THINK.ARPA with CHAOS; Mon, 29 Jul 85 12:53:32 edt Date: Mon, 29 Jul 85 12:53 EDT From: Guy Steele Subject: Clearing the screen and other such things. To: TIM@MIT-MC.ARPA, KMP@SCRC-STONY-BROOK.ARPA Cc: COMMON-LISP@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <[MIT-MC.ARPA].590150.850727.TIM> Message-Id: <850729125323.3.GLS@POLYCARP.ARPA> Date: Sat, 27 Jul 85 05:11:22 EDT From: Tim McNerney ... ERASE-CHAR-BACKWARD, ERASE-CHAR-FORWARD Many terminals don't support these operations. If we are trying to limit ourselves to a set of essential primitives, I would suggest that these be flushed, since they are merely abstractions for printing the sequences, backspace-space-backspace and space-backspace, respectively. Tim McNerney ... This remark raises the question of whether the terminal has overstrike capabilities or not; and if it does not, whether space is transparent or replacing. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 11:34:55 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:08:05 PDT Date: Mon, 29 Jul 85 10:07:41 EDT From: greek@DEC-HUDSON Subject: A comment on our community. To: common-lisp@su-ai  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 11:33:21 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 07:07:09 PDT Date: Mon, 29 Jul 85 10:06:44 EDT From: greek@DEC-HUDSON Subject: A comment on our community. To: common-lisp@su-ai  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 11:22:32 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 05:58:24 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283954; Mon 29-Jul-85 08:57:55-EDT Date: Mon, 29 Jul 85 09:06 EDT From: Bernard S. Greenberg Subject: Clearing the screen and other such things. To: KMP@SCRC-STONY-BROOK.ARPA, mips!earl@SU-GLACIER.ARPA, TIM@MIT-MC.ARPA, Wholey@CMU-CS-C.ARPA, RAM@CMU-CS-C.ARPA, COMMON-LISP@SU-AI.ARPA, fateman@UCBDALI.ARPA cc: Glacier!COMMON-LISP@SU-AI.ARPA In-Reply-To: <850726144908.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, <8507262335.AA25005@mips.UUCP>, <[MIT-MC.ARPA].590150.850727.TIM>, <[MIT-MC.ARPA].590458.850727.TIM>, , , <[MIT-MC.ARPA].591637.850729.TIM>, Message-ID: <850729090643.0.BSG@CONCORD.SCRC.Symbolics.COM> Date: Fri, 26 Jul 85 14:49 EDT From: Kent M Pitman As nearly as I can tell, Common Lisp offers no way to even clear the screen. It hurts me to see various sanded-edged parallelipipeds and egg-shaped frobs being offered for the reinvention of the wheel. I think all the problems addressed in the referenced messages were solved pretty adequately by any number of virtual terminal systems in the past 10 years, ITS's seeming to me to be the canonical one. You provide primitives that are as general and powerful as possible. Scroll region N lines, Insert entire character string, Delete n lines, and so forth. You provide an entry that says what capabilities are available. Extensibly. Auto-CRLF at end of line and every other known stupid feature, culled from the hundreds of person-years of experience of Editor Implementors of the Time Sharing Era are assigned standard names. The support system masks some incompatibilities, like deleting N lines by loop if there is no Delete N Lines in the terminal. You do NOT attempt to simulate insertions and deletions, or any feature X such that an acceptable redisplay program would choose a different strategy in the absence of X. I think that set is fairly well defined. The "antsy standard" terminal protocol (e.g., the Ann Arbor Ambassador) also makes not a bad cut at defining the canonical capabilities generically.  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 04:42:49 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 29 Jul 85 01:36:07 PDT Received: ID ; Mon 29 Jul 85 04:37:20-EDT Date: Mon, 29 Jul 1985 04:37 EDT Message-ID: From: Rob MacLachlan To: Tim McNerney Cc: COMMON-LISP@SU-AI.ARPA Subject: Clearing the screen and other such things. In-reply-to: Msg of 29 Jul 1985 01:06-EDT from Tim McNerney Perhaps this "virtual terminal" package would be best put into the yellow pages. Given a sufficiently efficient implementation of the basic terminal I/O stream or at least a binary stream to the terminal, it could be written entirely in Lisp. This is only true given that there is a physical terminal which can be controlled by sequences of characters --- a totally unwarranted assumption. From an earlier message: ERASE-CHAR-BACKWARD, ERASE-CHAR-FORWARD Many terminals don't support these operations. If we are trying to limit ourselves to a set of essential primitives, I would suggest that these be flushed, since they are merely abstractions for printing the sequences, backspace-space-backspace and space-backspace, respectively. This argument is not valid, since there is no reason to suppose that "printing" these characters on the "terminal" will have the desired effect. A Common Lisp implementation doesn't even have to have a backspace character. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 Jul 85 01:12:54 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Jul 85 22:05:04 PDT Date: Mon, 29 Jul 85 01:06:02 EDT From: Tim McNerney Subject: Clearing the screen and other such things. To: RAM@CMU-CS-C.ARPA cc: COMMON-LISP@SU-AI.ARPA In-reply-to: Msg of Sun 28 Jul 1985 17:31 EDT from Rob MacLachlan Message-ID: <[MIT-MC.ARPA].591637.850729.TIM> Date: Sun, 28 Jul 1985 17:31 EDT From: Rob MacLachlan It may or may not be a good idea to have a Common Lisp virtual terminal, as is being suggested, but in any case, I think it is important that this idea not be confused with the default stream terminal I/O. I think it would be a bad idea to force the default stream interaction into a fixed-width character-oriented model. Whatever interface is chosen should be willing to admit the possibility of virtual terminal emulation being done in a totally different fashion that default terminal I/O. Perhaps this "virtual terminal" package would be best put into the yellow pages. Given a sufficiently efficient implementation of the basic terminal I/O stream or at least a binary stream to the terminal, it could be written entirely in Lisp. A useful bit of white pages support for a virtual terminal package would be a way for the Lisp to find out whether the operating system has trashed the screen (by sending out a system notice, or something) thus randomizing the cursor position, etc. This could be in the form of an "environment query" function. There should probably be another function which returns T or NIL depending on whether the implementation supports this feature.  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Jul 85 17:38:14 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Jul 85 14:30:36 PDT Received: ID ; Sun 28 Jul 85 17:31:49-EDT Date: Sun, 28 Jul 1985 17:31 EDT Message-ID: From: Rob MacLachlan To: Kent M Pitman Cc: COMMON-LISP@SU-AI.ARPA Subject: Clearing the screen and other such things. In-reply-to: Msg of 26 Jul 1985 14:49-EDT from Kent M Pitman It may or may not be a good idea to have a Common Lisp virtual terminal, as is being suggested, but in any case, I think it is important that this idea not be confused with the default stream terminal I/O. I think it would be a bad idea to force the default stream interaction into a fixed-width character-oriented model. Whatever interface is chosen should be willing to admit the possibility of virtual terminal emulation being done in a totally different fashion that default terminal I/O. As a case in point, default terminal interaction in Spice Lisp is done by a remote procedure call interface to the typescript server, which is basically a base editor. The Typescript server doesn't provide any facility such as "cursor positioning" since this doesn't fit into the stream-oriented paradigm on which it is based. If we wanted to provide virtual terminal emulation, we would have to do it using a totally different mechanism, operating on a different piece of the screen. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 Jul 85 00:37:22 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 21:10:57 PDT Received: ID ; Sun 28 Jul 85 00:11:55-EDT Date: Sun, 28 Jul 1985 00:11 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Kent M Pitman Cc: COMMON-LISP@SU-AI.ARPA Subject: Clearing the screen and other such things. In-reply-to: Msg of 26 Jul 1985 14:49-EDT from Kent M Pitman Date: Friday, 26 July 1985 14:49-EDT From: Kent M Pitman To: COMMON-LISP at SU-AI.ARPA Re: Clearing the screen and other such things. As nearly as I can tell, Common Lisp offers no way to even clear the screen. In the absence of a graphics standard, can we commit to even something so simple as a CLEAR-SCREEN function? In fact, I'd like to see as many of the functions below as we could agree on; please note that this suggestion is not meant to preclude a more sophisticated graphics proposal. It is only meant to acknowledge the fact that many interesting portable applications can be written using a single fixed width fonts and character coordinates. However many months ago all of those wonderful "special interest group" CL-mumble mailing lists were set up, I thought that such a thing would be what the CL-Windows group would try to put together first. Instead, people in the group got caught up in worrying about "real" (read "hairy, ANSI, and COBOLISH") window/graphics systems and how one might get Lisp to talk to them. I would really like to see a well-specified pseudo-standard text window system that has enough hooks for, say, a text editor wanting to do reasonably clever redisplay. We should be able to agree on something at about the level of what KMP proposed, I should hope. This is something a lot of us want, but doesn't exactly fall in the domains of either the CL-Graphics or CL-Windows groups. We could perhaps create a CL-Text-Windows group for just such a thing. Or perhaps we should keep it "out here in the open", where issues don't die as easily as in the smaller groups. Or a bunch of us could do things with a private mailing list, implement this thing for our various Common Lisps, and present it (perhaps along with semi-portable code to implement stuff) to the Common Lisp community when we like what we've got. Any takers on any of the above? --Skef