Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 16:26:57 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 13:06:47 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Apr 87 16:04-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38194; 15 Apr 87 14:59:02-EDT Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 32893; 14 Apr 87 16:34:08-EDT Date: Tue, 14 Apr 87 16:32 EDT From: Don Morrison Subject: Compiling CASE To: Hvatum@MIT-MULTICS.ARPA, barmar@Think.COM cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA> Message-ID: <870414163245.2.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Sat, 11 Apr 87 06:07 EDT From: Hvatum@MIT-MULTICS.ARPA To Don Morrison: What is the meaning of declaring a MACRO NOTINLINE? CLtL doesn't imply that this is even possible. (Which is not to say that CLtL implies that it ISN'T possible - I'm being very careful with my wording here.) You and barmar are right; my brain was turned off. Notinline has nothing to do with it. Sorry about that. Date: Fri, 10 Apr 87 12:58 EDT From: Barry Margolin Date: Wed, 8 Apr 87 10:37 EDT From: Don Morrison I wonder, however, if all implementations do the right thing if you declare a macro which is treated specially as notinline? I don't think it should be necessary to declare/proclaim a macro notinline. For the macro to work at all, the defmacro must be seen by the compiler before it tries to compile the use of the macro. I would hope that the macro would be smart enough to notice that the user has overridden the default definition.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 13:50:40 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 10:34:00 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 10:34:02 PDT Date: 15 Apr 87 10:35 PDT From: Masinter.pa@Xerox.COM Subject: Re: EVAL-WHEN symbols In-reply-to: MURRAY%cs.umass.edu@RELAY.CS.NET's message of Tue, 14 Apr 87 15:45 EDT To: MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <870415-103402-4296@Xerox> If you want to shadow any of EVAL, LOAD or COMPILE and leave EVAL-WHEN, you can do so by shadowing EVAL-WHEN with a new EVAL-WHEN which checks for your new symbols and transforms them to the old. Ugly, but simple.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 13:19:42 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:55:14 PDT Received: from hplb29a by hplabs.HP.COM with TCP ; Wed, 15 Apr 87 08:51:53 pst Received: from hplbgw (hplbgw) by hplb29a ; Wed, 15 Apr 87 08:52:10 pst Received: by hplbgw ; Wed, 15 Apr 87 08:54:32 pst Date: Wed, 15 Apr 87 08:54:32 pst From: Gregory Weeks Message-Id: <8704151654.AA00676@hplbgw> To: MURRAY%RELAY.CS.NET%%SAIL.STANFORD.EDU%hplabs@cs.umass.edu, common-lisp@SAIL.STANFORD.EDU Subject: Re: EVAL-WHEN symbols While on the topic of symbols and such, I have a question about EVAL-WHEN. Does it only allow LISP:EVAL, LISP:COMPILE and LISP:LOAD, or does it only check the print-name? I think it should check print-names, so you can shadow these symbols. Otherwise, you would be forced to add the package prefix in all the EVAL-WHEN forms. Now that you mention it: EVAL, COMPILE, and LOAD should have been keywords.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 13:19:40 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:57:06 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 15 APR 87 09:55:07 PDT Date: 15 Apr 87 09:53 PDT From: Masinter.pa@Xerox.COM Subject: Re: macroexpand inside of macrolet... In-reply-to: David Bein 's message of 15 Apr 87 01:59 PDT To: common-lisp@sail.stanford.edu Message-ID: <870415-095507-4213@Xerox> The issue of a lexical environment argument to macroexpand and macroexpand-1 was discussed at length on this list as well as on the cleanup committee list. The problem doesn't go away with the removal of macrolet, because FLET and LABELS can shadow macros, too.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 12:22:04 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 09:03:03 PDT Received: ID ; Wed 15 Apr 87 11:55:44-EDT Date: Wed, 15 Apr 1987 11:55 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: MURRAY%cs.umass.edu@RELAY.CS.NET Cc: common-lisp@SAIL.STANFORD.EDU Subject: EVAL-WHEN symbols In-reply-to: Msg of 14 Apr 1987 15:45-EDT from MURRAY%cs.umass.edu at RELAY.CS.NET While on the topic of symbols and such, I have a question about EVAL-WHEN. Does it only allow LISP:EVAL, LISP:COMPILE and LISP:LOAD, or does it only check the print-name? I think it should check print-names, so you can shadow these symbols. Otherwise, you would be forced to add the package prefix in all the EVAL-WHEN forms. Eval-when is currently defined to look for EVAL, COMPILE, and LOAD as symbols in the Lisp package. Maybe they should have been keywords, but it's too late now. There's a reasonably good chance that EVAL-WHEN will be replaced in some future badly-needed cleanup of the compiler semantics. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 11:34:30 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:18:22 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76897; Wed 15-Apr-87 11:14:49 EDT Date: Wed, 15 Apr 87 11:18 EDT From: David C. Plummer Subject: macroexpand inside of macrolet... To: David Bein cc: common-lisp@SU-AI.ARPA In-Reply-To: <545474120/bein@pyrnova> Message-ID: <870415111824.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 15 Apr 1987 01:59 PDT From: David Bein I was playing around inside some macrolet code and came across what seems to a be a problem (if this issue was discussed ages ago on this mailing list, please pardon me for raising it again). (MACROLET ((CONS (A B) `(LIST ',A ',B))) (MACROEXPAND '(CONS 1 2))) returns (CONS 1 2) and NIL, while (MACROLET ((CONS (A B) `(LIST ',A ',B))) #'CONS) blows up since FUNCTION sees the local macro definition. You are confusing compile-time environments with runtime environments. MACROLET works on code. MACROEXPAND works on structure. Unless you can somehow grab ahold, at runtime, of the environment MACROLET has created and pass that environment to MACROEXPAND you won't get what you are looking for. How about (MACROEXPAND-all '(MACROLET ((CONS (A B) `(LIST ',A ',B))) (CONS 1 2))) => (MACROLET ((CONS (A B) `(LIST ',A ',B))) (LIST '1 '2)) where MACROEXPAND-all (not in CL) does a macroexpanding code walk.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 11:30:50 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 08:18:05 PDT Received: ID ; Wed 15 Apr 87 11:08:02-EDT Date: Wed, 15 Apr 1987 11:07 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jim Kempf Cc: common-lisp@SAIL.STANFORD.EDU Subject: Redefinition of Common Lisp Functions In-reply-to: Msg of 14 Apr 1987 20:06-EDT from Jim Kempf Attempts to directly redefine the functions may cause an error to be signalled. This technique would require no changes in the standard, or the standard could be toughened up to require that an error be signalled, as long as it is not toughened to the point where shadowing Common Lisp functions is an error. Unless I missed something, nobody is proposing that SHADOWING a built-in function using the package system should signal an error or should "be an error". That's what the package system is for. Clobbering the definitions of built-in symbols in the Lisp package is another matter. I think there's pretty general agreement that this should be an "is an error situation", and that it would be tasteful to at least issue a warning in such cases, perhaps under control of a magic implementation-dependent switch. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 05:48:31 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Apr 87 02:36:13 PDT Received: by hplabs.HP.COM ; Wed, 15 Apr 87 01:36:06 pst Received: from manpyrnova by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86) id AA26478; Wed, 15 Apr 87 02:09:31 PDT Received: by pyrnova.pyramid.COM (5.52/UUCP-Project/rel-1.0/09-11-86) id AA11138; Wed, 15 Apr 87 02:09:17 PDT Date: 15 Apr 1987 01:59 PDT From: David Bein Subject: macroexpand inside of macrolet... To: hplabs!common-lisp@sail.stanford.edu@hplabs.HP.COM Message-Id: <545474120/bein@pyrnova> I was playing around inside some macrolet code and came across what seems to a be a problem (if this issue was discussed ages ago on this mailing list, please pardon me for raising it again). (MACROLET ((CONS (A B) `(LIST ',A ',B))) (MACROEXPAND '(CONS 1 2))) returns (CONS 1 2) and NIL, while (MACROLET ((CONS (A B) `(LIST ',A ',B))) #'CONS) blows up since FUNCTION sees the local macro definition. Getting a handle on the local macro environment seems to be next to impossible. Is there some good reason for this? Should function be paying attention to the MACROLET environment in the same way as it does for FLET/LABELS or is this a bug in my implementation? Does anyone out there agree with the idea that macroexpanding something inside the body of a macrolet is a useful thing to do? From a debugging standpoint, the current situation makes it difficult to see what is going on since there is no "defined" way to see what is currently defined and of course using something like #'FOO is ok except if FOO is a macrolet creation. I suggest the following: (1) Either MACRO-FUNCTION should be changed to notice the local macro or some new function be defined for getting at the local macro environment. (2) Either MACROEXPAND should by default use the current environment (implementation specific of course!) or a new function should be defined for doing the same thing or perhaps the time has arrived for a way to access the environment in a general way. Comments? --David p.s. This whole bag of %&$# would go away if macrolet were to vaporize itself from the language.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 02:09:50 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Apr 87 22:56:10 PDT Received: from relay2.cs.net by RELAY.CS.NET id ah21989; 15 Apr 87 1:31 EDT Received: from cs.umass.edu by RELAY.CS.NET id bd04862; 15 Apr 87 1:28 AST Date: Tue, 14 Apr 87 15:45 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: EVAL-WHEN symbols X-VMS-To: CSNET%"common-lisp@sail.stanford.edu" While on the topic of symbols and such, I have a question about EVAL-WHEN. Does it only allow LISP:EVAL, LISP:COMPILE and LISP:LOAD, or does it only check the print-name? I think it should check print-names, so you can shadow these symbols. Otherwise, you would be forced to add the package prefix in all the EVAL-WHEN forms. Kelly  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Apr 87 00:11:59 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 20:56:40 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 14 Apr 87 16:06:24 pst Received: by hplabsc ; Tue, 14 Apr 87 16:06:53 pst Date: Tue, 14 Apr 87 16:06:53 pst From: Jim Kempf Message-Id: <8704150006.AA14181@hplabsc> To: common-lisp@sail.stanford.edu Subject: Re: Redefinition of Common Lisp Functions I guess I need to clarify my comments. I see two competing needs here: 1) On the one hand, system vendors and applications distributors require the option of not allowing users to redefine Common Lisp functions. Allowing users to do so makes supplying safe, good quality software difficult because regression testing becomes next to impossible. 2) On the other, researchers and people prototyping advanced applications might want to modify the semantics of certain Common Lisp functions for experimental purposes. It seems to me that protection of functions could be included in postdevelopment packaging, perhaps by setting a switch or on a package by package basis. The method I used to modify EQ, etc. in CommonObjects may, in fact, be the desired one: shadow those Common Lisp functions in the packages where the modified functions are desired with noninterned symbols having the same print names as the functions. Attempts to directly redefine the functions may cause an error to be signalled. This technique would require no changes in the standard, or the standard could be toughened up to require that an error be signalled, as long as it is not toughened to the point where shadowing Common Lisp functions is an error. With regard to Moon's comments about the CLOS: > 3. (More constrained redefining) Presuming the CLOS, which of the > predefined Common Lisp functions should be specializable for > user-defined classes? How should such specialization affect the rest of > the behavior of Common Lisp? > >The working group for defining the proposed object-oriented programming >standard ("CLOS") has thought about this just enough to realize that it >is complex and difficult. The group, or someone, will have to do more >work in this area, but it's not going to be easy. I agree. There are a core set of functions which object-oriented application developers usually say they want to be specializable, but, considering the wide variety of Common Lisp implementations out there, it may be difficult to provide them without stepping on someone's toes. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 21:47:57 EDT Received: from ORNL-MSR.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 18:29:04 PDT Received: by ORNL-MSR.ARPA (5.51/4.9) id AA21592; Tue, 14 Apr 87 21:29:58 EST Date: Tue, 14 Apr 87 21:29:58 EST From: jcm@ORNL-MSR.ARPA (James A. Mullens) Message-Id: <8704150229.AA21592@ORNL-MSR.ARPA> To: common-lisp@sail.stanford.edu Subject: Flavors and DEC's VMS Common Lisp? [He was new to the group, he couldn't locate the mail archives, so he had to ask a newcomer's question... ] Has anyone done a public-domain implementation of Symbolics-style flavors for DEC VMS CL? We have found a flavors package for Golden Common Lisp which we are considering porting... any comments? jim mullens / jcm@ornl-msr.arpa / oak ridge national lab  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 20:21:17 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 17:05:58 PDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA29331; Tue, 14 Apr 87 16:06:46 PST Message-Id: <8704150006.AA29331@decwrl.dec.com> Date: Tuesday, 14 Apr 1987 10:10:11-PDT From: sears%wrs.DEC@decwrl.DEC.COM To: common-lisp@SAIL.STANFORD.EDU, sears%wrs.DEC@decwrl.DEC.COM Subject: Re: Redefinition of CL Functions Are there cases where shadowing COMMON LISP symbols, then giving the shadowing symbols new definitions does not provide sufficient capability to layer extensions on a COMMON LISP implementation? I built a layered language for instrumentation, and used shadowed symbols to provide the new definitions. This works fine in VAXLISP. It was necessary to provide type definitions for symbols used as both a function and a type (LIST, STRING, etc), and to provide DEFSETF expanders for the new names. Are there other known problems? This approach is well defined because you know which definition you are using (It depends on the package in effect when the file is read or compiled), and it is straightforward to reference the standard definition if it is needed. It also works with our compiler, which does not optimize any of the new definitions, since it doesn't recognize any of the new functions. Incidentally, VAX LISP gives a warning message when you try to redefine a built-in COMMON-LISP function. /wrs  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 15:21:56 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 12:04:27 PDT Received: ID ; Tue 14 Apr 87 15:04:20-EDT Date: Tue, 14 Apr 1987 15:04 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: VERACSD@A.ISI.EDU Cc: common-lisp@SAIL.STANFORD.EDU Subject: Format In-reply-to: Msg of 14 Apr 1987 14:47-EDT from VERACSD at A.ISI.EDU Is there a FORMAT directive that prints real numbers as integers (truncated or rounded), without a decimal point? I'm not sure, but I don't think so. Why not call Truncate or Round on the number and then format it with ~D ? -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 15:04:39 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 11:48:20 PDT Date: 14 Apr 1987 14:47-EDT Sender: VERACSD@A.ISI.EDU Subject: Format From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Message-ID: <[A.ISI.EDU]14-Apr-87 14:47:31.VERACSD> Is there a FORMAT directive that prints real numbers as integers (truncated or rounded), without a decimal point?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 14:52:54 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 11:20:33 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115605; Tue 14-Apr-87 14:19:35 EDT Date: Tue, 14 Apr 87 14:19 EDT From: David A. Moon Subject: redefining Common Lisp functions To: masinter.PA@Xerox.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <870411-154536-1554@Xerox> Message-ID: <870414141907.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: 11 Apr 87 14:44:52 PST From: masinter.PA@Xerox.COM Rather than attempting to divine meaning in CLtL, lets focus on some related but different questions: 1. (Current practice) In your favorite Common Lisp implementation, which of the predefined Common Lisp functions, macros, and special forms can be safely redefined without causing unpredictable behavior somewhere else in the system? I don't know what "safely" means; I made an assumption about what you meant such that the answer is "none of them, not only in my favorite implementation, but in all the others too." 2. (Future standards) Which of the predefined Common Lisp functions, macros, and special forms do you think *should* be redefinable. I don't believe that Common Lisp should define the meaning of redefining any of the predefined functions. Thus I believe that it should "be an error" to redefine any predefined function. JonL's point about the difference between truly redefining something and merely encapsulating it (e.g. for TRACE) is relevant here. But note that I do not believe that Common Lisp should require compiled code that appears to call a predefined function, macro, or special form to be necessarily affected by any encapsulation of that functionoid. 3. (More constrained redefining) Presuming the CLOS, which of the predefined Common Lisp functions should be specializable for user-defined classes? How should such specialization affect the rest of the behavior of Common Lisp? The working group for defining the proposed object-oriented programming standard ("CLOS") has thought about this just enough to realize that it is complex and difficult. The group, or someone, will have to do more work in this area, but it's not going to be easy.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 13:34:19 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Apr 87 10:12:57 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 115506; Tue 14-Apr-87 13:10:15 EDT Date: Tue, 14 Apr 87 13:09 EDT From: David A. Moon Subject: Inconsistent keywords for sequence functions To: DON%atc.bendix.com@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 13 Apr 87 14:07 EDT from DON%atc.bendix.com@RELAY.CS.NET Message-ID: <870414130937.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 13 Apr 87 14:07 EDT From: DON%atc.bendix.com@RELAY.CS.NET Why do most of the sequence functions have the :key keyword but reduce doesn't? Why isn't there a reduce-if and a reduce-if-not? An example which came up recently is (reduce #'+ box-contents :key #'weight) which should return the sum of the weights of the objects in the box. :key, -if, and -if-not only apply to functions that have :test arguments. I can't imagine what reduce-if and reduce-if-not would do. I can see what you want reduce :key to do, but I'm not sure :key is the right name for that. In retrospect, it might have been better language design to have fewer options combined with stronger encouragement of implementations to compile efficient code for nested function invocations, compiling out temporary storage. Thus your example would be written: (reduce #'+ (mapcar #'weight box-contents)) I realize quite well that there are a number of practical and philosophical problems connected with actually doing this; please let's not start a long discussion of them.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 13:33:44 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 10:10:27 PDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA19382; Tue, 14 Apr 87 09:10:14 PST Message-Id: <8704141710.AA19382@decwrl.dec.com> Date: Tuesday, 14 Apr 1987 09:48:40-PDT From: sears%wrs.DEC@decwrl.DEC.COM To: common-lisp@SAIL.STANFORD.EDU, sears%wrs.DEC@decwrl.DEC.COM Subject: Re: Inconsistencies in Sequence Function Arguments I agree that REDUCE should take a :KEY keyword. There seems to be little difficulty in implementing it, I have found it frequently useful, and it provides consistency with the other sequence functions. The change is upward compatible with the existing language. /wrs  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 13:14:26 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 14 Apr 87 09:48:58 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71623; Tue 14-Apr-87 12:38:03 EDT Date: Tue, 14 Apr 87 12:34 EDT From: Daniel L. Weinreb Subject: Re: Redefinition of CL Functions To: kempf%hplabsc@hplabs.HP.COM, ROSENKING@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8704141544.AA07256@hplabsc> Message-ID: <870414123431.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 14 Apr 87 07:44:30 pst From: Jim Kempf While I understand the concern about redefinition causing code to become nonportable, I think a case can be made for redefinition in experimental systems. However, as Rob explained in a recent message, the only reason for the Common Lisp specification to provide for anything is in order to make sure that doing the thing is guaranteed to be portable across all implementations of Common Lisp. If it's not going to be portable, then there's no point in putting it in the Common Lisp specification. If it is supposed to be portable, there are all the serious problems that have been pointed out in recent mail. There's nothing wrong with a particular implementation having some kind of feature that allows redefinition of built-in functions/macros/etc.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 12:43:43 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 09:24:31 PDT Received: ID ; Tue 14 Apr 87 12:13:37-EDT Date: Tue, 14 Apr 1987 12:13 EDT Message-ID: From: Rob MacLachlan To: Jim Kempf Cc: common-lisp@SAIL.STANFORD.EDU, ROSENKING@A.ISI.EDU Subject: Redefinition of CL Functions In-reply-to: Msg of 14 Apr 1987 11:44-EDT from Jim Kempf One point that should be introduced into this discussion is the distinction between "legal" and "reasonable". It is not feasible for Common Lisp to mandate reasonableness; users will have to decide for themselves whether a given implementation is reasonable. With any standard it is possible to create a system that complies with the letter of the standard, but is still totally unusable. In the case of redefinitions of standard functions and macros I would say that reasonable implementations should both: -- Warn when the user redefines a standard function or macro and -- Do its best to make the user redefinition work. I don't think either property can be brought within the formal language definition, so an implementation that flames out and dies when you redefine a standard function would be legal. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 12:07:57 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Apr 87 08:51:30 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Tue, 14 Apr 87 07:43:17 pst Received: by hplabsc ; Tue, 14 Apr 87 07:44:30 pst Date: Tue, 14 Apr 87 07:44:30 pst From: Jim Kempf Message-Id: <8704141544.AA07256@hplabsc> To: ROSENKING@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU Subject: Re: Redefinition of CL Functions Cc: rosenking@A.ISI.EDU While I understand the concern about redefinition causing code to become nonportable, I think a case can be made for redefinition in experimental systems. Particularly when one is developing embedded languages, the semantics of certain Common Lisp functions may need to be changed. An example here is CommonObjects, which extends the semantics of certain Common Lisp functions to include user defined types. Naturally, this is not something one does casually, in the course of developing a Common Lisp application, but rather should be labelled by the developer as being an extension to be used with care. A warning message upon redefinition would be sufficient, signalling an error would remove some of the flexibility which makes Common Lisp such an ideal environment for developing embedded languages. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Apr 87 11:06:18 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Apr 87 07:47:13 PDT Date: 14 Apr 1987 10:44:12 EDT Subject: Redefinition of CL Functions From: Jeffrey Rosenking To: common-lisp@SAIL.STANFORD.EDU cc: rosenking@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: rosenking@A.ISI.EDU Subject: Redefinition of CL Functions ------------------------------------------------------------------------ 13-Apr-87 18:57:41-EDT,3913;000000000001 Return-Path: <@SAIL.STANFORD.EDU,@diamond.s4cc.symbolics.com:DCP@QUABBIN.SCRC.Symbolics.COM> Received: FROM SAIL.STANFORD.EDU BY USC-ISI.ARPA WITH TCP ; 13 Apr 87 18:53:02 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 15:28:26 PDT Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT Date: Mon, 13 Apr 87 09:57 EDT From: David C. Plummer Subject: Compiling CASE To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan , masinter.PA@xerox.com, Jim Kempf , Jon L White , Mike Hewett , common-lisp@sail.stanford.edu, navajo!Common-Lisp%sail@navajo.stanford.edu In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>, , , <870411-154536-1554@Xerox>, <8704120544.AA05619@hplabsc>, <8704130006.AA04788@bhopal.edsel.com>, <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU> Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sun, 12 Apr 87 22:24:43 PDT From: Mike Hewett As someone more concerned with using Common LISP and in the portability of it, I can't believe any responsible software engineer would even think of redefining a CL-defined function, macro, or special form. I agree, and the implication (or my inference) is that there are irresponsible engineers, or even the responsible ones make mistakes. Therefore, the question of allowing redefinition is purely a CL environment implementation question, and I would think that it should be perfectly legal to protect the user from himself and not allow redefinition. I agree here too. Various implementations do protect the user. The Symbolics implementation does this by remembering the source file of the original definition, and if the new source file doesn't match it queries. This applies to all functions, not just the core language. I agree here too, too ! In response to the discussions above (Hewett, Masinter, Plummer, and Steele), and my feelings on the subject, I THINK that the CL standard should support a mechanism to, at least, warn the user if he attempts to redefine a CL-defined function, macro, or special form [ or perhpas initiate an error, though I believe that this will not coincide with the tradional flexibility which LISP has always had ]. The Symbolics implementation [of a redefinition WARNING mechanism] would be a good model for the analagous CL mechanism, and it has the advantage of working for the definition of all functions, not just those which are strictly CL-defined. I BELIEVE that this mechanism is an essential part of a language, especially one which was mainly designed to support portability and commonality among various LISP implementations. -: Jeff ------- -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Apr 87 23:26:07 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Apr 87 20:16:07 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa02842; 13 Apr 87 23:08 EDT Received: from atc.bendix.com by RELAY.CS.NET id aa27455; 13 Apr 87 23:04 AST Date: Mon, 13 Apr 87 14:07 EDT From: DON%atc.bendix.com@RELAY.CS.NET Subject: Inconsistent keywords for sequence functions To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"common-lisp@sail.stanford.edu" Why do most of the sequence functions have the :key keyword but reduce doesn't? Why isn't there a reduce-if and a reduce-if-not? An example which came up recently is (reduce #'+ box-contents :key #'weight) which should return the sum of the weights of the objects in the box. Don Mitchell Don@atc.bendix.com Bendix Aero. Tech. Ctr. Don%atc.bendix.com@relay.cs.net 9140 Old Annapolis Rd. (301)964-4156 Columbia, MD 21045  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Apr 87 18:42:01 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Apr 87 15:28:26 PDT Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Mon, 13 Apr 87 15:24:54 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT Date: Mon, 13 Apr 87 09:57 EDT From: David C. Plummer Subject: Compiling CASE To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan , masinter.PA@xerox.com, Jim Kempf , Jon L White , Mike Hewett , common-lisp@sail.stanford.edu, navajo!Common-Lisp%sail@navajo.stanford.edu In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>, , , <870411-154536-1554@Xerox>, <8704120544.AA05619@hplabsc>, <8704130006.AA04788@bhopal.edsel.com>, <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU> Message-Id: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sun, 12 Apr 87 22:24:43 PDT From: Mike Hewett As someone more concerned with using Common LISP and in the portability of it, I can't believe any responsible software engineer would even think of redefining a CL-defined function, macro, or special form. I agree, and the implication (or my inference) is that there are irresponsible engineers, or even the responsible ones make mistakes. Therefore, the question of allowing redefinition is purely a CL environment implementation question, and I would think that it should be perfectly legal to protect the user from himself and not allow redefinition. I agree here too. Various implementations do protect the user. The Symbolics implementation does this by remembering the source file of the original definition, and if the new source file doesn't match it queries. This applies to all functions, not just the core language. Date: Sat, 11 Apr 1987 11:09 EDT From: Rob MacLachlan ... The significance of code walkers has also been exaggerated. For one thing, modern Lisp compilers tend not to use source code as the internal representation, and their operation cannot really be modeled as a source code walk. Given a sufficiently rich representation, many things can be determined without actually grovelling the code. Of course internal compiler representations are highly implementation dependent, but this isn't necessarily a problem. One of the main things that source code walkers have been used for is writing "optimizing macros" for non-optimizing compilers. As long as the compiler adequately optimizes the code, macros can expand in a simple-minded way without understanding their arguments. Speak for yourself. They are also used to write embedded languages or to make semantic extensions to existing languages that require source-to-source translation to convert the embedded syntax to CLtL. This is precisely my main use of code walkers. Consider a simple object oriented system where slots are referenced with AREF. I could (1) go in and change the compiler, (2) try to use the compiler's internal representation, or (3) code walk looking for slot names and replace them with the appropriate AREF forms. (3) is the only method that has any hope of portability, and the funarg to the code walker is 9 lines of code.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Apr 87 18:30:42 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 13 Apr 87 15:16:29 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75945; Mon 13-Apr-87 09:53:51 EDT Date: Mon, 13 Apr 87 09:57 EDT From: David C. Plummer Subject: Compiling CASE To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan , masinter.PA@Xerox.COM, Jim Kempf , Jon L White , Mike Hewett , common-lisp@SAIL.STANFORD.EDU, navajo!Common-Lisp%sail@navajo.stanford.edu In-Reply-To: <870411100755.599053@MIT-MULTICS.ARPA>, , , <870411-154536-1554@Xerox>, <8704120544.AA05619@hplabsc>, <8704130006.AA04788@bhopal.edsel.com>, <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU> Message-ID: <870413095719.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Sun, 12 Apr 87 22:24:43 PDT From: Mike Hewett As someone more concerned with using Common LISP and in the portability of it, I can't believe any responsible software engineer would even think of redefining a CL-defined function, macro, or special form. I agree, and the implication (or my inference) is that there are irresponsible engineers, or even the responsible ones make mistakes. Therefore, the question of allowing redefinition is purely a CL environment implementation question, and I would think that it should be perfectly legal to protect the user from himself and not allow redefinition. I agree here too. Various implementations do protect the user. The Symbolics implementation does this by remembering the source file of the original definition, and if the new source file doesn't match it queries. This applies to all functions, not just the core language. Date: Sat, 11 Apr 1987 11:09 EDT From: Rob MacLachlan ... The significance of code walkers has also been exaggerated. For one thing, modern Lisp compilers tend not to use source code as the internal representation, and their operation cannot really be modeled as a source code walk. Given a sufficiently rich representation, many things can be determined without actually grovelling the code. Of course internal compiler representations are highly implementation dependent, but this isn't necessarily a problem. One of the main things that source code walkers have been used for is writing "optimizing macros" for non-optimizing compilers. As long as the compiler adequately optimizes the code, macros can expand in a simple-minded way without understanding their arguments. Speak for yourself. They are also used to write embedded languages or to make semantic extensions to existing languages that require source-to-source translation to convert the embedded syntax to CLtL. This is precisely my main use of code walkers. Consider a simple object oriented system where slots are referenced with AREF. I could (1) go in and change the compiler, (2) try to use the compiler's internal representation, or (3) code walk looking for slot names and replace them with the appropriate AREF forms. (3) is the only method that has any hope of portability, and the funarg to the code walker is 9 lines of code.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Apr 87 15:29:38 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 13 Apr 87 12:16:35 PDT Received: from falling-star by Think.COM via CHAOS; Mon, 13 Apr 87 14:19:17 EST Date: Mon, 13 Apr 87 15:16 EDT From: Guy Steele Subject: redefining Common Lisp functions To: masinter.PA@xerox.com, common-lisp@sail.stanford.edu Cc: gls@think.com In-Reply-To: <870411-154536-1554@Xerox> Message-Id: <870413151618.1.GLS@FALLING-STAR.THINK.COM> Date: 11 Apr 87 14:44:52 PST From: masinter.PA@xerox.com Everyone (including Guy Steele!) seems to be challenging me to quote "chapter and verse" in Guy Steele's book supporting my assertion that it is an error to redefine any of the predefined Common Lisp functions and macros. (The appropriate verse which claims that it is an error to redefine one of the predefined special forms with DEFUN having been found.) Larry, the point is that the phrase "is an error" has a precise technical meaning in CLTL, and is furthermore understood in conversations on this mailing list to mean "is explicitly stated by CLTL to `be an error'". If it's just your opinion, then you can legitimately say "It is stupid to ..." or "It is wedged to ..." or even "It is erroneous to ..." or (best) "I think it should be an error to ..."; but if you say simply "It is an error to..." then that is understood to be a statement of fact about what is in CLTL, and it is reasonable for others to ask what part of the book backs it up. We all like you, and we don't mean to challenge you or give you a hard time. Many of us even agree that it SHOULD be an error. But (unless I have overlooked the relevant passage) it isn't an error yet. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Apr 87 13:31:15 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 13 Apr 87 10:17:56 PDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA20408; Mon, 13 Apr 87 09:17:36 PST Message-Id: <8704131717.AA20408@decwrl.dec.com> Date: Monday, 13 Apr 1987 09:57:04-PDT From: sears%wrs.DEC@decwrl.DEC.COM To: common-lisp@sail.stanford.edu, sears%wrs.DEC@decwrl.DEC.COM Subject: Re: Redefining Common LISP Functions, MACROS and Special Forms I think this is a deep issue in the language. This is especially true for those applications that are evolving systems starting from COMMON-LISP as a base. I think the questions are: 1. What is the protocol for adding an extension for an interpreted function. 2. What is the protocol for adding an extension that is compiled. 3. How are "META" functions, such as SETF and DEFSTRUCT, to be handled. 4. Are some functions to be handled differently than others? (Forms like OR and MULTIPLE-VALUE-RETURN). In the case of (1), changing the function cell seems to be adequate. In the case of (2), the compiler needs to know which definition is intended. Using a new symbol solves this problem. The problem in the case of (3) is that a redefined function may imply (or not) a change to SETF. DEFSETF is the function that does this, but it in turn is affected by compilation. A related problem is the handling of DEFSTRUCT accessor, creator and setting functions. In the case of (4), it may well be the case that the language can be defined as consisting of layers, but this should be specified explicitly if this is to be the case. I think the exact handling of these features needs to be defined in a way that gives the system builder explicit control. /wrs  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Apr 87 01:39:35 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 22:25:45 PDT Date: Sun, 12 Apr 87 22:24:43 PDT From: Mike Hewett Subject: Redefining CL fns To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU> As someone more concerned with using Common LISP and in the portability of it, I can't believe any responsible software engineer would even think of redefining a CL-defined function, macro, or special form. Therefore, the question of allowing redefinition is purely a CL environment implementation question, and I would think that it should be perfectly legal to protect the user from himself and not allow redefinition. Mike Hewett (HEWETT@SUMEX-AIM.STANFORD.EDU) -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Apr 87 21:05:31 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 17:50:50 PDT Received: by navajo.stanford.edu; Sun, 12 Apr 87 17:49:09 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA15379; Sun, 12 Apr 87 15:58:51 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA04732; Sun, 12 Apr 87 16:55:48 PDT Date: Sun, 12 Apr 87 16:55:48 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8704122355.AA04732@bhopal.edsel.com> To: navajo!Common-Lisp%sail@navajo.stanford.edu Subject: all symbols [and delayed mail] [The following message was sent when the "775 LISP symbols" was a hot topic. Unfortunately, the gateway at navajo.stanford.edu seems to be a bit recalcitrant -- a problem suffered all too often.] Return-Path: Date: Fri, 10 Apr 87 17:33:35 PST From: Mail Delivery Subsystem Subject: Returned mail: Cannot send message for 3 days To: bhopal!jonl@edsel.com ----- Transcript of session follows ----- ----- Unsent message follows ----- Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA01258; Tue, 7 Apr 87 14:10:20 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA25834; Tue, 7 Apr 87 15:06:28 PDT Date: Tue, 7 Apr 87 15:06:28 PDT From: edsel!bhopal!jonl (Jon L White) Message-Id: <8704072206.AA25834@bhopal.edsel.com> To: navajo!smh%EMS.MEDIA.MIT.EDU Cc: navajo!DALY%ibm.com, navajo!common-lisp%sail navajo!hornig%QUABBIN.SCRC.Symbolics.COM In-Reply-To: navajo!smh@EMS.MEDIA.MIT.EDU's message of Tue, 7 Apr 87 11:31:13 EST Subject: all symbols I don't think SIZE belongs in the Lisp package -- it isn't one of the symbols mentioned in CLtL, p160, as optimization qualities. Perhaps it is a Franz extension? As to how it came about that Symbolics has 775 symbols: it occured nearly a year ago, before the Franz-circulated list I believe, as a consequence of a cooperative effort between Symbolics and Lucid. I found the following msg header in my old mail file: Date: Sun, 18 May 86 18:09 EDT From: Daniel L. Weinreb Subject: Orthodoxy in the package world layout. To: edsel!bhopal!jonl@SU-NAVAJO.ARPA Cc: dlw@SCRC-QUABBIN.ARPA In-Reply-To: <8605180533.AA25219@bhopal.edsel.uucp> Yes, it is certainly our intention that the CL package contain exactly the documented external symbols, and we've tried hard to get it right. Checking our set against your set is clearly an excellent cross-check. In fact, I'm surprised none of us ever thought of it. I'm glad you did, and thanks for doing the comparison. Now, lemme see what I can figure out about these discrepencies and how to fix them. . . . -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Apr 87 21:04:02 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Apr 87 17:50:56 PDT Received: by navajo.stanford.edu; Sun, 12 Apr 87 17:49:15 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA15405; Sun, 12 Apr 87 16:09:47 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA04788; Sun, 12 Apr 87 17:06:46 PDT Date: Sun, 12 Apr 87 17:06:46 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8704130006.AA04788@bhopal.edsel.com> To: navajo!Common-Lisp%sail@navajo.stanford.edu Subject: redefining Common Lisp functions Unfortunately, it is hard for an implementation to determine when a user is truly "redefining" a function, or merely changing it's symbol-function cell in a way compatible with portable Common Lisp. The most obvious case in point is the need to install "wrapper-like" function in order to do traceing. A user ought to be able to implement his own monitoring scheme, which would involve changing the contents of the symbol-function cell of an arbitrary Common Lisp function (name), without bumping into some kind of hard barrier. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Apr 87 03:15:41 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Apr 87 00:05:28 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Sat, 11 Apr 87 21:44:51 pst Received: by hplabsc ; Sat, 11 Apr 87 21:44:52 pst Date: Sat, 11 Apr 87 21:44:52 pst From: Jim Kempf Message-Id: <8704120544.AA05619@hplabsc> To: common-lisp@sail.stanford.edu, masinter.PA@Xerox.COM Subject: Re: redefining Common Lisp functions In the process of implementing CommonObjects on CommonLoops (COOL) I found it necessary to re-implement the following functions: EQUAL, EQL, EQUALP, TYPEP, and TYPE-OF. I tried a number of ways to do this, but none seemed safe (= infinite recursions) or effective (= slowed down the system), except to provide a macro which a user actually wanting the semantics of the redefined functions could invoke. This macro defined the functions on uninterned symbols then shadowing imported the symbols into the package where the user wanted them. Although this sounds inconvenient, it did allow me to match CommonObjects semantics (at the user's option, however) which require these functions to be user specializable, i.e. generic functions. Jim Kempf kempf@hplabs.hp.com PS: Portable CommonLoops already allows PRINC and other print functions to be specialized via. the :PRINT-FUNCTION option. Don't remember if that made it into the standard, since my CLOS specification is at the office.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Apr 87 18:57:00 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Apr 87 15:47:00 PDT Received: from Salvador.ms by ArpaGateway.ms ; 11 APR 87 15:45:36 PDT From: masinter.PA@Xerox.COM Date: 11 Apr 87 14:44:52 PST Subject: redefining Common Lisp functions To: common-lisp@sail.stanford.edu Message-ID: <870411-154536-1554@Xerox> Everyone (including Guy Steele!) seems to be challenging me to quote "chapter and verse" in Guy Steele's book supporting my assertion that it is an error to redefine any of the predefined Common Lisp functions and macros. (The appropriate verse which claims that it is an error to redefine one of the predefined special forms with DEFUN having been found.) Rather than attempting to divine meaning in CLtL, lets focus on some related but different questions: 1. (Current practice) In your favorite Common Lisp implementation, which of the predefined Common Lisp functions, macros, and special forms can be safely redefined without causing unpredictable behavior somewhere else in the system? 2. (Future standards) Which of the predefined Common Lisp functions, macros, and special forms do you think *should* be redefinable. 3. (More constrained redefining) Presuming the CLOS, which of the predefined Common Lisp functions should be specializable for user-defined classes? How should such specialization affect the rest of the behavior of Common Lisp?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Apr 87 11:20:57 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87 08:09:57 PDT Received: ID ; Sat 11 Apr 87 11:09:51-EDT Date: Sat, 11 Apr 1987 11:09 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SAIL.STANFORD.EDU Subject: Compiling CASE I think that this entire issue has been blown up out of porportion. For one thing, there aren't many macros that there is a really good reason for compiler to special-case: MULTIPLE-VALUE-BIND, OR and xxxCASE are the main examples. It is feasible to avoid special-casing even these. Note also that writers of portable code walkers can anticipate that certain macros may want to be special-cased by incorporating knowledge about their syntax. The code walker doesn't need to do this, but the resulting code may perform better in some implementations. The code walker will still work even if the macro really is just a macro The significance of code walkers has also been exaggerated. For one thing, modern Lisp compilers tend not to use source code as the internal representation, and their operation cannot really be modeled as a source code walk. Given a sufficiently rich representation, many things can be determined without actually grovelling the code. Of course internal compiler representations are highly implementation dependent, but this isn't necessarily a problem. One of the main things that source code walkers have been used for is writing "optimizing macros" for non-optimizing compilers. As long as the compiler adequately optimizes the code, macros can expand in a simple-minded way without understanding their arguments. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Apr 87 10:52:21 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87 07:40:17 PDT Received: ID ; Sat 11 Apr 87 10:39:54-EDT Date: Sat, 11 Apr 1987 10:39 EDT Message-ID: From: Rob MacLachlan To: Hvatum@MIT-MULTICS.ARPA Cc: common-lisp@SAIL.STANFORD.EDU Subject: Compiling CASE In-reply-to: Msg of 11 Apr 1987 06:07-EDT from Hvatum at MIT-MULTICS.ARPA Date: Saturday, 11 April 1987 06:07-EDT From: Hvatum at MIT-MULTICS.ARPA Re: Compiling CASE The package system will not protect Common LISP from having its functions redefined, since a user who wants to define his/her own CAR function will likely not call it USER:CAR; thus, since there is already a CAR in the LISP package, that's the one that will get defined. This is what SHADOW is for. [...] What if the function was not CAR, but (say) ENCODE-UNIVERSAL-TIME? It is reasonable to suppose that Joe Lisphacker will not wish to look up every potential function name to see if it is already defined. [...] It is reasonable to suppose that programmers won't want to look up every symbol before they use it, but it is not reasonable to redefine system functions. Programs that redefine system functions are not portable for two reasons: -- You might redefine a system facility that other parts of the system depend on, for example, it you redefine DECODE-UNIVERSAL-TIME, our compiler will not work. -- Even if a program attempts to redefine a facility in an upward compatible way, that program cannot coexist with other programs that redefine the same facility an in incompatible upward compatible way. Just as in COBOL, the programming environment should provide ways to prevent users from screwing themselves by redefining the system. [...] It is also not reasonable for the compiler to reject this usage because it is an error to redefine ENCODE-UNIVERSAL-TIME [...]. It's also likely that the interpreter will make different choices in the same matter, probably all bad ones. This is another good reason to forbid redefinition of standard functions and macros. If you allow redefinition, then you must specify what the result is; this is difficult to do in the presence of a variety of implementations of evaluation such as compilers and interpreters. Note on a point of dogma: it doesn't make any sense to say that a construct is "Legal in Common Lisp but implementation dependent"; Common Lisp is nothing if not a specification of how to write portable Lisp programs. In some cases it is reasonable for Common Lisp to suggest standard mechanisms for accessing common implementation features, but programs that rely on such constructs having any particular effect are not portable, and thus not really Common Lisp programs. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Apr 87 06:23:07 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 11 Apr 87 03:09:53 PDT Date: Sat, 11 Apr 87 06:07 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: Compiling CASE To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870411100755.599053@MIT-MULTICS.ARPA> From: Steve Bacher (Draper Lab) In-Reply-To: DCP at SCRC-QUABBIN, DFM%JASPER at LIVE-OAK.LCS.MIT.EDU, Masinter.pa at XEROX.COM OK, the CLtL paragraph on page 57 is well known to me. But what if the user redefines a macro, which is presumably legal? It may be an error to redefine a special form, but what protection does the LISP system have from the user doing it to a macro (or, better perhaps, what protection does the user have from the LISP system ignoring such a redefinition)? Seems that the user will somehow have to know which macros are really implemented as special forms, or at least special-to-compiler forms, or else the compiler will have to be able to distinguish between built-in macro definitions and user-provided macro definitions. Probably this isn't that hard to do for an implementation developed from scratch. In fact, a macro like CASE could expand alternately into SYSTEM::INTERNAL-SPECIAL-FORM-CASE sometimes, and SYSTEM::INTERNAL-MACRO-CASE other times. To Don Morrison: What is the meaning of declaring a MACRO NOTINLINE? CLtL doesn't imply that this is even possible. (Which is not to say that CLtL implies that it ISN'T possible - I'm being very careful with my wording here.) Btw, looking at page 57 again I see that CLtL explicitly states that the compiler may have special knowledge about forms like TYPECASE. So I guess the only issues left are how to deal with user-provided redefinitions, which should be properly handled by most implementations in their own ways; and what code-walkers should do with them. As far as what one code-walks for, there are two general areas: (1) truly portable code-walking, e.g. looking for certain kinds of function or variable references. Such walking needs to know only about syntax, and cares little for how constructs are actually implemented. Thus, it's OK to do maximal macroexpansion and minimal special-form analysis. (2) internal-use code-walking, e.g. the kind done by a phase of the compiler. This is not limited to chunks of the compiler itself, as various metasystems (e.g. source transforms) may wish to code-walk to aid in compilation of a particular body of code. Here, any special knowledge the compiler has about certain forms must be retained, and it would be inadvisable to macroexpand such forms. Thing is, (2) is not limited to compiler hackers; users will wish to provide their own functions to perform such code-walking feats. Therefore, there ought to be a standard way of telling whether a particular symbol names a form of which the compiler has special knowledge. Perhaps COMPILER-SPECIAL-FORM-P? (Of course, the question is then what to do with the damned thing...) To Larry Masinter: Where is the quote in CLtL that supports your statement that it is an error to redefine any of the built-in functions or macros defined in Common LISP? The package system will not protect Common LISP from having its functions redefined, since a user who wants to define his/her own CAR function will likely not call it USER:CAR; thus, since there is already a CAR in the LISP package, that's the one that will get defined. Maybe you think this is a silly example. What if the function was not CAR, but (say) ENCODE-UNIVERSAL-TIME? It is reasonable to suppose that Joe Lisphacker will not wish to look up every potential function name to see if it is already defined. It is also not reasonable for the compiler to reject this usage because it is an error to redefine ENCODE-UNIVERSAL-TIME (and it is even worse for it NOT to tell you because, after all, it's only "an error" and the user doesn't have to be warned). It's also likely that the interpreter will make different choices in the same matter, probably all bad ones. What we wind up with here is COBOL LISP, with 775 reserved words, subject to increase with the next edition of the reference manual.   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Apr 87 13:11:34 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 10 Apr 87 09:58:09 PDT Received: from ignatius by Think.COM via CHAOS; Fri, 10 Apr 87 12:58:03 EST Date: Fri, 10 Apr 87 12:58 EDT From: Barry Margolin Subject: Compiling CASE To: Don Morrison Cc: Hvatum@mit-multics.arpa, common-lisp@sail.stanford.edu In-Reply-To: <870408103703.5.DFM@WHITBY.PALLADIAN.COM> Message-Id: <870410125829.4.BARMAR@IGNATIUS.THINK.COM> Date: Wed, 8 Apr 87 10:37 EDT From: Don Morrison [...] I wonder, however, if all implementations do the right thing if you declare a macro which is treated specially as notinline? I don't think it should be necessary to declare/proclaim a macro notinline. For the macro to work at all, the defmacro must be seen by the compiler before it tries to compile the use of the macro. I would hope that the macro would be smart enough to notice that the user has overridden the default definition. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 17:26:09 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Apr 87 14:13:03 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191488; Thu 9-Apr-87 16:58:30 EDT Date: Thu, 9 Apr 87 16:57 EDT From: Robert W. Kerns Subject: DEFVAR semantics To: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870409165750.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Tue, 7 Apr 1987 13:04 EDT From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Looking over page 68 of CLtL, I have a question about DEFVAR: From the description, it seems the (DEFVAR ) should never give any sort of value. It should simply "proclaim to be special and may perform other system-dependent \bookkeeping-actions/." Giving a default value seems like more than simple bookkeeping. Is this a reasonable interpretation? Yes.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 16:25:58 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 13:10:07 PDT Received: from feuerbach by Think.COM via CHAOS; Thu, 9 Apr 87 16:08:24 EST Date: Thu, 9 Apr 87 16:09 EDT From: Guy Steele Subject: Re-defining COMMON-LISP symbols To: Fahlman@c.cs.cmu.edu, sears%wrs.DEC@decwrl.dec.com Cc: common-lisp@sail.stanford.edu, gls@think.com In-Reply-To: Message-Id: <870409160913.6.GLS@FEUERBACH.THINK.COM> Date: Thu, 9 Apr 1987 14:53 EDT From: "Scott E. Fahlman" ... I don't see any question here. MY-PACKAGE:CONS is a different symbol from LISP:CONS, and you can give it whatever definition you want. This doesn't even confuse macros, since they deal in symbols and not print names. It's sort of like a neutron bomb: Machines survive fine; only people are confused. :-) --Q  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 15:09:39 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 11:53:54 PDT Received: ID ; Thu 9 Apr 87 14:53:47-EDT Date: Thu, 9 Apr 1987 14:53 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: sears%wrs.DEC@DECWRL.DEC.COM Cc: common-lisp@SAIL.STANFORD.EDU Subject: Re-defining COMMON-LISP symbols In-reply-to: Msg of 9 Apr 1987 14:14-EDT from sears%wrs.DEC at decwrl.DEC.COM Obviously we need a clarification about whether you can redefine CONS and friends, globally or with FLET/LABELS. There is a closely related operation, which consists of defining a new symbol of the same name as an existing symbol in COMMON-LISP, and shadowing that symbol in some package of the users choice. This operation is necessary, in my view, for defining new systems on top of COMMON-LISP. A number of systems currently being built depend on this functionality. I don't see any question here. MY-PACKAGE:CONS is a different symbol from LISP:CONS, and you can give it whatever definition you want. This doesn't even confuse macros, since they deal in symbols and not print names. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 14:30:20 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 11:17:05 PDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA27622; Thu, 9 Apr 87 10:18:01 PST Message-Id: <8704091818.AA27622@decwrl.dec.com> Date: Thursday, 9 Apr 1987 11:14:13-PDT From: sears%wrs.DEC@decwrl.DEC.COM To: common-lisp@sail.stanford.edu, sears%wrs.DEC@decwrl.DEC.COM Subject: Re-defining COMMON-LISP symbols I believe that attempts to redefine built-in parts of the system are inherently implementation dependent. It would be a mistake to define the behavior of doing so as part of the specification. LISP implementors may be find it useful to do this in their development. There is a closely related operation, which consists of defining a new symbol of the same name as an existing symbol in COMMON-LISP, and shadowing that symbol in some package of the users choice. This operation is necessary, in my view, for defining new systems on top of COMMON-LISP. A number of systems currently being built depend on this functionality. Presently, there is no clear definition of how the compiler and interpreter interact in the presence of operations such as the redefinition of, say, CONS. Extending the COMMON-LISP specification to clearly define this area would be helpful for system builders who use this set of features. /wrs  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 11:48:36 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Apr 87 08:34:00 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75189; Thu 9-Apr-87 11:33:20 EDT Date: Thu, 9 Apr 87 11:33 EDT From: David C. Plummer Subject: "Compiling CASE" To: las@bfly-vax.bbn.com, common-lisp@sail.stanford.edu cc: allen@bfly-vax.bbn.com In-Reply-To: The message of 8 Apr 87 11:49 EDT from las@bfly-vax.bbn.com Message-ID: <870409113306.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 08 Apr 87 11:49:15 D (Wed) From: las@bfly-vax.bbn.com "Compiling CASE" ... Here are some alternatives to solving this problem; only the first appears to be in the realm of a standards orginization: 1. Expand the set of special forms to include more of the built-in macros. Code walkers would then obviously need work. For the simplest code walkers and for purity/minimality of the language, I don't find this acceptable. 2. Require that all macro expansions be identical to the transforms performed by the compiler. This, of course, is very hard to enforce since a compiler usually operates with much more contextual knowledge than does a macro expander. I think it is impossible. The compiler doesn't necessary "transform" a multiple-value-bind form into source code; it probably generates code sequences for it directly. 3. Ignore the problem. If a code-walker transforms code then compiles it, then it deserves what it gets. Code walkers can optionally be improved to sense the "semi-special" forms. Code walking should unduly affect performance, so I don't like your second sentence. Your third sentence is the tip of an iceberg which I discuss below. The best solution, in my opinion, is (1), since it solves the problem completely: there is no chance that different code sequences could be emitted due to a macro expansion, thus retaining efficiency and avoiding subtle bugs. I realize that it is difficult to swallow such a change, but it should be considered. ... I have another alternative, which I believe is both better and harder to implement. The problem is, what is a code walker? There's been some mumbling about portable code walkers, but do they really solve any cross-machine problems? Do people use code walkers for analysis (in which case you don't have to keep the macroexpansions) or for substitution (in which case there may be a problem)? My proposal is to figure the functional needs of a code walker, and document the interface in CLtL'91. Each implementation would be required to implement the code walker. Each person therefore wouldn't have to write his/her own, and there wouldn't need to be a portable one because there is a "standard." I propose that the code-walker-in-the-sky be allowed to have special knowledge of CLtL macros that are implemented as special forms. There would be a keyword argument saying to use the macro expansions instead. This means you don't lose the benefits of treating some macros as special forms, but you have to make sure that the functional needs of the code walker are still met. I don't think this is an impossible task. I use the Symbolics code walker a moderate amount, and it has many of the above properties. It does a pretty good job. I would classify it as a prototype and a reference point; I have been hampered by it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 10:32:25 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:19:37 PDT Received: ID ; Thu 9 Apr 87 10:20:32-EDT Date: Thu, 9 Apr 1987 10:20 EDT Message-ID: From: Rob MacLachlan To: Guy Steele Cc: common-lisp@SAIL.STANFORD.EDU, Masinter.pa@XEROX.COM Subject: Compiling CASE In-reply-to: Msg of 9 Apr 1987 10:08-EDT from Guy Steele Date: Thursday, 9 April 1987 10:08-EDT From: Guy Steele To: Masinter.pa at xerox.com, common-lisp at sail.stanford.edu Re: Compiling CASE Date: 8 Apr 87 14:56 PDT From: Masinter.pa@xerox.com It is an error to redefine *any* of the built-in symbols of Common Lisp, whether they are macros, special forms, or functions. I can't find, offhand, where in CLtL it says that. Can you give a reference? Or is this a proposed cleanup? This is part of my proposal to the compiler cleanup committee, although I think others have arrived at the same interpretation before. This really seems pretty obvious if you choose to make "correct program" synonomous with "portable program", since programs that attempt to redefine parts of the language are apt to break the system, and in any case won't coexist in the same lisp environment. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 10:20:18 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:07:11 PDT Received: from thorlac by Think.COM via CHAOS; Thu, 9 Apr 87 10:07:11 EST Date: Thu, 9 Apr 87 10:08 EDT From: Guy Steele Subject: Re: Compiling CASE To: Masinter.pa@xerox.com, common-lisp@sail.stanford.edu Cc: gls@think.com In-Reply-To: <870408-145828-1556@Xerox> Message-Id: <870409100809.4.GLS@THORLAC.THINK.COM> Date: 8 Apr 87 14:56 PDT From: Masinter.pa@xerox.com It is an error to redefine *any* of the built-in symbols of Common Lisp, whether they are macros, special forms, or functions. I can't find, offhand, where in CLtL it says that. Can you give a reference? Or is this a proposed cleanup? --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 10:16:52 EDT Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:04:06 PDT Date: 9 Apr 1987 10:01-EDT Sender: NGALL@G.BBN.COM Subject: Re: Compiling CASE From: NGALL@G.BBN.COM To: Masinter.pa@XEROX.COM Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM] 9-Apr-87 10:01:21.NGALL> In-Reply-To: <870408-145828-1556@Xerox> Date: 8 Apr 87 14:56 PDT From: Masinter.pa@Xerox.COM It is an error to redefine *any* of the built-in symbols of Common Lisp, whether they are macros, special forms, or functions. Could you please cite the CLtL passage that forbids such redefinition. I couldn't find it. -- Nick  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 08:47:18 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 05:35:22 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 08:33-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 37016; 9 Apr 87 07:36:27-EST Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 62925; Thu 9-Apr-87 06:58:15-EST Date: Thu, 9 Apr 87 06:58 EDT From: Randy%acorn@oak.lcs.mit.edu To: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Subject: all symbols Cc: hornig@QUABBIN.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU Date: Wed, 8 Apr 87 10:06:07 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) From: hornig@QUABBIN.SCRC.Symbolics.COM From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) I believe there should be 776. Where is SIZE mentioned? It's not in the description of OPTIMIZE. My mistake -- I was confused by some old software, and didn't check CLtL. SIZE should *not* be an external of package LISP. Presumably, you were thinking of '(OPTIMIZE SPACE) [the four optimizable quantities, according to Steele, are SPEED, SPACE, SAFETY, and COMPILATION-SPEED. I assume that the long name was given to the last one to discourage its use... With this correction, I agree that there should be exactly 775 symbols exported from package LISP. Presumably our lists are the same ... (DEFUN EQ (X Y) (OR (AND (LISTP X) (LISTP Y) (= (LENGTH X) (LENGTH Y))) (= (SYS:%GET-PHYSICAL-ADDRESS X) (SYS:%GET-PHYSICAL-ADDRESS Y)))) ;;; :-) Random  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Apr 87 05:35:15 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 02:22:49 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 05:20-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 36999; 9 Apr 87 04:23:07-EST Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 62920; Thu 9-Apr-87 05:16:24-EST Date: Thu, 9 Apr 87 05:16 EDT From: Randy%acorn@oak.lcs.mit.edu To: Masinter.pa@Xerox.COM Subject: Re: Compiling CASE Cc: common-lisp@sail.stanford.edu Date: 8 Apr 87 14:56 PDT From: Masinter.pa@Xerox.COM "The compiler can have special knowledge of particular macros, as long as it ignores this special knowledge if the user redefines the macros." It is an error to redefine *any* of the built-in symbols of Common Lisp, whether they are macros, special forms, or functions. Compilers can therefore assume anything they want about any of the built-in symbols of Common Lisp, whether they are functions, macros, or special forms, since their definition cannot legally be changed. Is "it an error" to FLET them? If not, then the compiler has to be smart enough to not insert the transforms it might have. Transforms are a whole 'nother issue. They are arguably the best way to provide system-dependent optimizations. It would be useful, however, for people whose compilers use the transform abstraction to provide an extension like a NO-TRANSFORM declaration or something similar to this in cases where you know something the compiler doesn't. (Like maybe in a case like this.) Randy Haskins Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 18:11:40 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Apr 87 14:57:30 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 08 APR 87 14:58:28 PDT Date: 8 Apr 87 14:56 PDT From: Masinter.pa@Xerox.COM Subject: Re: Compiling CASE In-reply-to: Barry Margolin 's message of Wed, 8 Apr 87 13:04 EDT To: common-lisp@sail.stanford.edu Message-ID: <870408-145828-1556@Xerox> "Consider the case (n.p.i.) where the user provides an alternate macro definition for his/her own use (possibly because he/she doesn't remember that there already is a CASE macro). ... This could affect a whole class of "non-special-forms", i.e. things like AND, OR, COND, PROG, ...." "The compiler can have special knowledge of particular macros, as long as it ignores this special knowledge if the user redefines the macros." It is an error to redefine *any* of the built-in symbols of Common Lisp, whether they are macros, special forms, or functions. Compilers can therefore assume anything they want about any of the built-in symbols of Common Lisp, whether they are functions, macros, or special forms, since their definition cannot legally be changed. One might expect a good Common Lisp compiler to produce the same code whether one used one of the built in macros or its macro expansion. This is generally possible, although there are some cases where it is difficult. Certainly the resulting code must be behaviorally equivalent.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 17:57:13 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 14:38:51 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Apr 87 17:36-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 36912; 8 Apr 87 16:32:01-EST Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 32361; 8 Apr 87 10:38:02-EDT Date: Wed, 8 Apr 87 10:37 EDT From: Don Morrison Subject: Compiling CASE To: Hvatum@MIT-MULTICS.ARPA cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <870408053906.850449@MIT-MULTICS.ARPA> Message-ID: <870408103703.5.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Wed, 8 Apr 87 01:39 EDT From: Hvatum@MIT-MULTICS.ARPA From: Steve Bacher (C.S.Draper Lab) The question of CASE compiling into a computed GOTO uncovers an interesting dilemma. Should the compiler have special knowledge about certain forms which are normally macro calls, because it knows that they can be compiled into particular machine-code sequences, or should it always honor the macroexpansion? Consider the case (n.p.i.) where the user provides an alternate macro definition for his/her own use (possibly because he/she doesn't remember that there already is a CASE macro). This could affect a whole class of "non-special-forms", i.e. things like AND, OR, COND, PROG, which are supposed to be macros in CL but are generally special forms in (older?) LISP implementations, and recognized by the compiler in order to generate optimal code. Or should there be a class of "quasi-special-forms" which the compiler may deal with on a basis similar to that of true "special forms" so that the best code can get generated? Should it be "an error" to redefine such macros? After all, the rationale here is to keep the number of true "special forms" to a small finite number to enable portable code walking (not "portable-code" walking), though I don't wish to open up THAT can of worms again. But if this means that the compiler is constrained from doing clever things with AND, OR, or CASE, is it worth it? - SEB Open compiling a macro isn't really any different in this respect than open compiling an ordinary function like car or mapcar, which most implementations do for a great many functions. The rational is that so long as the user hasn't declared a function notinline and the open coded sequence does the same thing as the real function you're well within your rights to open code it; the same follows for macros. Note that if the open compiled version does the same thing as the macro, you can still code walk (well at least that's the theory; I suspect how successful it is in practice depends on exactly why you're code walking). I wonder, however, if all implementations do the right thing if you declare a macro which is treated specially as notinline?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 17:20:58 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 14:02:20 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Wed, 8 Apr 87 16:03:40 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA08245; Wed, 8 Apr 87 13:59:10 EST Message-Id: <8704081859.AA08245@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 08 Apr 87 12:56:23 EST Subject: Compiling CASE - back to the fray To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 08 Apr 87 12:56:23 EST I might note that the equivalent case in the PRIME PL/1 compiler (select(value); when(1)...; when(2)...;) is essentially broken down to the nested if type construct in the IL representation and then optimized by the backend into a computed GOTO. This has the feature that if it was 'nicer' to write the code as nested IFs then the code will still be optimized. - Doug Rand  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 15:49:24 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 12:31:46 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA26391; Wed, 8 Apr 87 13:34:10 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA28963; Wed, 8 Apr 87 13:34:07 MDT Date: Wed, 8 Apr 87 13:34:07 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Message-Id: <8704081934.AA28963@utah-orion.ARPA> To: common-lisp@sail.stanford.edu Subject: Re: Compiling CASE Just in case anybody was considering adding more special forms to CL, let me vote NO. I would, however, support any proposals to eliminate some of the existing special forms and make them macros... stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 13:21:56 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Apr 87 10:03:42 PDT Received: from ubaldo by Think.COM via CHAOS; Wed, 8 Apr 87 13:03:42 EST Date: Wed, 8 Apr 87 13:04 EDT From: Barry Margolin Subject: Compiling CASE To: Hvatum@mit-multics.arpa Cc: common-lisp@sail.stanford.edu In-Reply-To: <870408053906.850449@MIT-MULTICS.ARPA> Message-Id: <870408130439.7.BARMAR@UBALDO.THINK.COM> Date: Wed, 8 Apr 87 01:39 EDT From: Hvatum@mit-multics.arpa From: Steve Bacher (C.S.Draper Lab) The question of CASE compiling into a computed GOTO uncovers an interesting dilemma. Should the compiler have special knowledge about certain forms which are normally macro calls, because it knows that they can be compiled into particular machine-code sequences, or should it always honor the macroexpansion? Consider the case (n.p.i.) where the user provides an alternate macro definition for his/her own use (possibly because he/she doesn't remember that there already is a CASE macro). [...] The compiler can have special knowledge of particular macros, as long as it ignores this special knowledge if the user redefines the macros. MIT-derived Lisp Machines also allow users to add to the compiler's optimizations. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 12:16:58 EDT Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 8 Apr 87 08:44:08 PDT To: common-lisp@sail.stanford.edu Cc: allen@bfly-vax.bbn.com Subject: "Compiling CASE" Date: 08 Apr 87 11:49:15 D (Wed) From: las@bfly-vax.bbn.com "Compiling CASE" The problem cited recently regarding macros vs. special forms contains some subtleties that need addressing. Certainly, a compiler should be able to view a macro as a "special form" for purposes of emitting efficient code. Sensing these is not user-visible, and should be okay as long as the semantics of the language is not altered. Problems arise when one uses code-walkers, or other code analyzers, that deliberately expand macros in order to boil down all code to "the" small set of understandable special forms. The program analyzer may do its transform, then compile the code. References to the original macro will then most likely be lost. In this case, the system in essence requires that such macros be expandable, AND that the compiler be able to transform them for optimization. The two transforms may be very different, so that compiling the macro-expanded code and directly compiling the macro reference result in different emitted code. Here are some alternatives to solving this problem; only the first appears to be in the realm of a standards orginization: 1. Expand the set of special forms to include more of the built-in macros. Code walkers would then obviously need work. 2. Require that all macro expansions be identical to the transforms performed by the compiler. This, of course, is very hard to enforce since a compiler usually operates with much more contextual knowledge than does a macro expander. 3. Ignore the problem. If a code-walker transforms code then compiles it, then it deserves what it gets. Code walkers can optionally be improved to sense the "semi-special" forms. The best solution, in my opinion, is (1), since it solves the problem completely: there is no chance that different code sequences could be emitted due to a macro expansion, thus retaining efficiency and avoiding subtle bugs. I realize that it is difficult to swallow such a change, but it should be considered. Note that the problem does not arise with functions, as they are of course not macro-expanded. Thus, the compiler may transform them as it pleases and code-walkers are not affected. Perhaps a study could be made to determine precisely which built-in macros are worth making into special forms, thus reducing the size of the change. I would certainly vote for CASE and friends. - Larry Stabile  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 11:23:08 EDT Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 08:07:40 PDT Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA08402; Wed, 8 Apr 87 10:06:07 EST Date: Wed, 8 Apr 87 10:06:07 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8704081506.AA08402@EMS.MEDIA.MIT.EDU> To: hornig@QUABBIN.SCRC.Symbolics.COM Cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: hornig@QUABBIN.SCRC.Symbolics.COM's message of Tue, 7 Apr 87 12:53 EDT Subject: all symbols From: hornig@QUABBIN.SCRC.Symbolics.COM From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) I believe there should be 776. Where is SIZE mentioned? It's not in the description of OPTIMIZE. My mistake -- I was confused by some old software, and didn't check CLtL. SIZE should *not* be an external of package LISP. With this correction, I agree that there should be exactly 775 symbols exported from package LISP. Presumably our lists are the same ...  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 10:36:30 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Apr 87 07:23:06 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 74771; Wed 8-Apr-87 09:52:56 EDT Date: Wed, 8 Apr 87 09:56 EDT From: David C. Plummer Subject: Compiling CASE To: Hvatum@MIT-MULTICS.ARPA, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <870408053906.850449@MIT-MULTICS.ARPA> Message-ID: <870408095640.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> The job of both the compiler and macros is to preserve the semantics of the source code. Therefore, it doesn't matter if the compiler always uses macro definitions or if it has its own knowledge of macros as "special forms." Many implementations would be unduly hurt if the only forms the compiler knew were special are the couple dozen listed on page 57. For example, the Symbolics implementation has very efficient compilations for many of the multiple-value forms, which by strict Common Lisp are macros. Also see in the middle of page 57: Conversely, an implementation is free to implement as a special form any construct described herein as a macro if an equivalent macro definition is also provided. I believe the intent of this statement is that the interpreter and compiler may use the special form definition and special knowledge, respectively, for efficiency.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 04:12:05 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 8 Apr 87 00:59:02 PDT Received: from relay2.cs.net by RELAY.CS.NET id ae08139; 8 Apr 87 3:51 EDT Received: from utokyo-relay by RELAY.CS.NET id aa19343; 8 Apr 87 3:45 AST Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA01168; Wed, 8 Apr 87 16:12:23 jst Received: by tansei.u-tokyo.junet (4.12/6.2Junet) id AA24015; Wed, 8 Apr 87 16:12:46+0900 Date: Wed, 8 Apr 87 16:12:46+0900 From: Masayuki Ida Return-Path: Message-Id: <8704080712.AA24015@tansei.u-tokyo.junet> To: Moon@SCRC-STONY-BROOK.ARPA, STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: Re: Common Lisp symbols Cc: common-lisp@SAIL.STANFORD.EDU I found KCL dated Nov.4 has 858 symbols in LISP package.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 01:55:47 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 7 Apr 87 22:41:22 PDT Date: Wed, 8 Apr 87 01:39 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: Compiling CASE To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870408053906.850449@MIT-MULTICS.ARPA> From: Steve Bacher (C.S.Draper Lab) The question of CASE compiling into a computed GOTO uncovers an interesting dilemma. Should the compiler have special knowledge about certain forms which are normally macro calls, because it knows that they can be compiled into particular machine-code sequences, or should it always honor the macroexpansion? Consider the case (n.p.i.) where the user provides an alternate macro definition for his/her own use (possibly because he/she doesn't remember that there already is a CASE macro). This could affect a whole class of "non-special-forms", i.e. things like AND, OR, COND, PROG, which are supposed to be macros in CL but are generally special forms in (older?) LISP implementations, and recognized by the compiler in order to generate optimal code. Or should there be a class of "quasi-special-forms" which the compiler may deal with on a basis similar to that of true "special forms" so that the best code can get generated? Should it be "an error" to redefine such macros? After all, the rationale here is to keep the number of true "special forms" to a small finite number to enable portable code walking (not "portable-code" walking), though I don't wish to open up THAT can of worms again. But if this means that the compiler is constrained from doing clever things with AND, OR, or CASE, is it worth it? - SEB   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Apr 87 01:55:36 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 7 Apr 87 22:41:03 PDT Date: Wed, 8 Apr 87 01:38 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: NMAP innefficiency To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870408053838.361428@MIT-MULTICS.ARPA> From: Steve Bacher (C.S.Draper Lab) NMAP and MAP don't need to use LENGTH or ELT to process lists if the compiler can determine that all the sequences passed to it are lists. In this case, the lists can be CDR'd down in traditional LISP 1.5 fashion until one of the sublists is ENDP. If, on the other hand, you wish to mix lists and sequences, you probably don't care much about efficiency anyway. Possible compiler transforms: (map 'list fun list1 list2 list3) ---> (do ((g1 list1 (cdr g1)) (g2 list2 (cdr g2)) (g3 list3 (cdr g3)) (result '())) ((or (endp g1) (endp g2) (endp g3)) (nreverse result)) (push (funcall fun (car g1) (car g2) (car g3)) result)) (nmap rlist fun list1 list2 list3) ---> (do ((gr rlist (cdr gr)) (g1 list1 (cdr g1)) (g2 list2 (cdr g2)) (g3 list3 (cdr g3))) ((or (endp gr) (endp g1) (endp g2) (endp g3)) rlist) (setf (car gr) (funcall fun (car g1) (car g2) (car g3)))) Of course, there are better ways of doing MAP than using NREVERSE, but this is just so you can see what I have in mind. This solution takes into account the case where the list to be updated is shorter than any of the other argument sequences.   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 19:42:48 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 16:27:04 PDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA07131; Tue, 7 Apr 87 15:27:50 PST Message-Id: <8704072327.AA07131@decwrl.dec.com> Date: Tuesday, 7 Apr 1987 13:29:50-PDT From: nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson) To: common-lisp@sail.stanford.edu Subject: Number of Common Lisp symbols VAX LISP has 775 symbols in the COMMON-LISP package. Beryl  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 13:23:53 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 10:07:13 PDT Date: Tue, 7 Apr 1987 13:04 EDT Message-ID: From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: common-lisp@SAIL.STANFORD.EDU Subject: DEFVAR semantics Looking over page 68 of CLtL, I have a question about DEFVAR: From the description, it seems the (DEFVAR ) should never give any sort of value. It should simply "proclaim to be special and may perform other system-dependent \bookkeeping-actions/." Giving a default value seems like more than simple bookkeeping. Is this a reasonable interpretation? - Stephen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 13:13:41 EDT Received: from [192.10.41.223] by SAIL.STANFORD.EDU with TCP; 7 Apr 87 09:53:05 PDT Date: Tue, 7 Apr 87 12:53 EDT From: hornig@QUABBIN.SCRC.Symbolics.COM Sender: File-Server@QUABBIN.SCRC.Symbolics.COM Subject: Re: all symbols To: smh@EMS.MEDIA.MIT.EDU, DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8704071631.AA02759@EMS.MEDIA.MIT.EDU> Message-ID: <870407125319.4.FILE-SERVER@SAPSUCKER.SCRC.Symbolics.COM> Date: Tue, 7 Apr 87 11:31:13 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) From: hornig@QUABBIN.SCRC.Symbolics.COM As a check on all those who have "rolled their own" list of the symbols in the LISP package, there should be exactly 775 of them. I believe there should be 776. Symbolics Genera 7 does not export LISP:SIZE, which is used in (DECLARE (OPTIMIZE SIZE)). In fact, Symbolics may have acquired the error from the list we circulated some time back, from which we subsequently learned SIZE was missing. Steve Haflich Franz Inc. Where is SIZE mentioned? It's not in the description of OPTIMIZE.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 13:00:58 EDT Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 09:38:35 PDT Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA02759; Tue, 7 Apr 87 11:31:13 EST Date: Tue, 7 Apr 87 11:31:13 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8704071631.AA02759@EMS.MEDIA.MIT.EDU> To: DALY@ibm.com, common-lisp@sail.stanford.edu, hornig@QUABBIN.SCRC.Symbolics.COM Subject: Re: all symbols From: hornig@QUABBIN.SCRC.Symbolics.COM As a check on all those who have "rolled their own" list of the symbols in the LISP package, there should be exactly 775 of them. I believe there should be 776. Symbolics Genera 7 does not export LISP:SIZE, which is used in (DECLARE (OPTIMIZE SIZE)). In fact, Symbolics may have acquired the error from the list we circulated some time back, from which we subsequently learned SIZE was missing. Steve Haflich Franz Inc.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 10:19:30 EDT Received: from [192.10.41.223] by SAIL.STANFORD.EDU with TCP; 7 Apr 87 06:58:35 PDT Date: Tue, 7 Apr 87 09:38 EDT From: hornig@QUABBIN.SCRC.Symbolics.COM Sender: File-Server@QUABBIN.SCRC.Symbolics.COM Subject: all symbols To: DALY@ibm.com, common-lisp@sail.stanford.edu In-Reply-To: <040687.214700.daly@ibm.com> Message-ID: <870407093846.7.FILE-SERVER@SAPSUCKER.SCRC.Symbolics.COM> As a check on all those who have "rolled their own" list of the symbols in the LISP package, there should be exactly 775 of them.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 07:44:41 EDT Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 7 Apr 87 04:31:18 PDT Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA19059; Tue, 7 Apr 87 07:32:11 EDT Received: by unido.uucp with uucp; Tue, 7 Apr 87 12:34:34 +0100 Received: by gmdzi.UUCP id AA04069; Tue, 7 Apr 87 12:09:30 -0100 Received: by gmdzi.UUCP id AA02687; Tue, 7 Apr 87 10:11:11 -0100 Received: by unido.uucp with uucp; Tue, 7 Apr 87 01:29:31 +0100 Received: by seismo.CSS.GOV (5.54/1.14) id AA03221; Mon, 6 Apr 87 18:10:43 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Apr 87 14:36:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110163; Mon 6-Apr-87 17:35:49 EDT Date: Mon, 6 Apr 87 17:35 EDT From: "David A. Moon" Subject: Common Lisp symbols To: "Stephen E. Robbins" Cc: common-lisp@sail.stanford.edu In-Reply-To: The message of 6 Apr 87 14:08 EDT from Stephen E. Robbins Message-Id: <870406173533.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Status: R Date: Mon 6 Apr 87 14:08-EDT From: "Stephen E. Robbins" The company I work for is just starting a large project in Common Lisp. For portability, we'd like to create our own special package into which we IMPORT the implementation's Common Lisp and then EXPORT *exactly* the set of CLtL symbols that make up common lisp. Our packages will then USE our private CL package. Does anyone out there have a list of the symbols in CLtL? Or is this going to require going through the manual page by page and figuring out what needs to be [im]ported? Most, but unfortunately not all, implementations of Common Lisp are careful to make the package named LISP contain all and only the CLtL symbols, and to put their own symbols into a package with a different name. I think you will find an increasing number of implementations conforming to this implementation as time goes by. If you need to be portable to an implementation that has not been this careful, you can get the list of symbols from one of the careful implementations, rather than doing your own debugging of the typos in the manual.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 07:43:11 EDT Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 7 Apr 87 04:30:21 PDT Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA19026; Tue, 7 Apr 87 07:31:11 EDT Received: by unido.uucp with uucp; Tue, 7 Apr 87 12:30:12 +0100 Received: by gmdzi.UUCP id AA04138; Tue, 7 Apr 87 12:12:32 -0100 Received: by gmdzi.UUCP id AA03614; Tue, 7 Apr 87 11:34:16 -0100 Received: by unido.uucp with uucp; Tue, 7 Apr 87 10:49:03 +0100 Received: by seismo.CSS.GOV (5.54/1.14) id AA05878; Mon, 6 Apr 87 20:09:04 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 16:38:05 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Mon, 6 Apr 87 19:40:07 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA03399; Mon, 6 Apr 87 16:49:40 EST Message-Id: <8704062149.AA03399@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 06 Apr 87 15:49:53 EST Subject: Re: Common LISP Symbols To: common-lisp@sail.stanford.edu From: unido!primerd!DOUG@seismo.CSS.GOV Date: 06 Apr 87 15:49:53 EST Status: R On page 181 of Steele this is (I think) addressed under the description of the package 'lisp'. This seems to include only those symbols in CL. There is another harder semantic problem for you though: what about extensions to the functionality of the base CL functions? If your CL allows (for example) circular sequences in the sequence functions, etc, this will not flag the incompatibility. Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 04:42:05 EDT Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 7 Apr 87 01:27:45 PDT Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA15280; Tue, 7 Apr 87 04:28:36 EDT Received: by unido.uucp with uucp; Tue, 7 Apr 87 09:46:43 +0100 Received: by gmdzi.UUCP id AA01179; Tue, 7 Apr 87 08:07:53 -0100 Received: by gmdzi.UUCP id AA08673; Mon, 6 Apr 87 22:30:25 -0100 Received: by unido.uucp with uucp; Mon, 6 Apr 87 21:37:26 +0100 Received: by seismo.CSS.GOV (5.54/1.14) id AA27779; Mon, 6 Apr 87 14:47:38 EDT Message-Id: <8704061847.AA27779@seismo.CSS.GOV> Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 11:12:12 PDT Date: Mon 6 Apr 87 14:08-EDT From: "Stephen E. Robbins" Subject: Common Lisp symbols To: common-lisp@sail.stanford.edu Status: R The company I work for is just starting a large project in Common Lisp. For portability, we'd like to create our own special package into which we IMPORT the implementation's Common Lisp and then EXPORT *exactly* the set of CLtL symbols that make up common lisp. Our packages will then USE our private CL package. Does anyone out there have a list of the symbols in CLtL? Or is this going to require going through the manual page by page and figuring out what needs to be [im]ported? -- Stephen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Apr 87 02:02:43 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Apr 87 22:36:03 PDT Received: from relay2.cs.net by RELAY.CS.NET id ae20194; 7 Apr 87 1:17 EDT Received: from cs.umass.edu by RELAY.CS.NET id be10571; 7 Apr 87 1:10 AST Date: Mon, 6 Apr 87 15:46 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: Clipping output X-VMS-To: CSNET%"common-lisp@su-ai.ARPA" > From: ELIOT%cs.umass.edu@RELAY.CS.NET > Is there any good way, preferably in FORMAT to > clip output longer than a specified length? > ... > The effect I need is equivalent to: > (subseq (format nil "~a" XXX) 0 20) > but I would rather not do all the consing that this implies. > In general, I would like to be able to specify > the maximum field width of most of the format directives. The code below would truncate output with minimal consing (at least close to a constant). Of course, this only works for ONE call to FORMAT, and so you would need to break down a format string into separate calls to get the effect on more than one directive. With all the other whiz-bang features of format, a max-width field is probably not too much to ask for. Anybody have any idea how difficult it would be to add it in? - Kelly (defvar *truncate-buffer* (make-array 200 ;; The bigger it is, less consing :element-type 'string-char :adjustable t :fill-pointer 0)) (defun TRUNCATE-FORMAT (max-width stream format-string &rest format-args) (setf (fill-pointer *truncate-buffer*) 0) ;; Start Empty (with-output-to-string (string-stream *truncate-buffer*) ;; Cons a stream. (apply #'format string-stream format-string format-args)) ;; Fill it up (when (> (fill-pointer *truncate-buffer*) max-width) ;; Truncate (setf (fill-pointer *truncate-buffer*) max-width)) (format stream "~A" *truncate-buffer*)) ;; Output  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Apr 87 22:30:01 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 6 Apr 87 19:18:14 PDT Date: 6 April 1987, 21:47:00 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <040687.214700.daly@ibm.com> Subject: all symbols to get a list of all of the symbols do (do-symbols (x (find-package 'lisp)) (print (symbol-name x))) and then sort the list and weed out the garbage. It takes about 1/2 hour to 1 hour. I used the index of Cltl. I should note that the index is not complete so be careful to look up any misses in the body of the text. I've done this for several implementations.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Apr 87 19:50:10 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 16:38:05 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Mon, 6 Apr 87 19:40:07 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA03399; Mon, 6 Apr 87 16:49:40 EST Message-Id: <8704062149.AA03399@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 06 Apr 87 15:49:53 EST Subject: Re: Common LISP Symbols To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 06 Apr 87 15:49:53 EST On page 181 of Steele this is (I think) addressed under the description of the package 'lisp'. This seems to include only those symbols in CL. There is another harder semantic problem for you though: what about extensions to the functionality of the base CL functions? If your CL allows (for example) circular sequences in the sequence functions, etc, this will not flag the incompatibility. Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Apr 87 17:51:27 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Apr 87 14:36:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110163; Mon 6-Apr-87 17:35:49 EDT Date: Mon, 6 Apr 87 17:35 EDT From: David A. Moon Subject: Common Lisp symbols To: Stephen E. Robbins cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 6 Apr 87 14:08 EDT from Stephen E. Robbins Message-ID: <870406173533.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon 6 Apr 87 14:08-EDT From: "Stephen E. Robbins" The company I work for is just starting a large project in Common Lisp. For portability, we'd like to create our own special package into which we IMPORT the implementation's Common Lisp and then EXPORT *exactly* the set of CLtL symbols that make up common lisp. Our packages will then USE our private CL package. Does anyone out there have a list of the symbols in CLtL? Or is this going to require going through the manual page by page and figuring out what needs to be [im]ported? Most, but unfortunately not all, implementations of Common Lisp are careful to make the package named LISP contain all and only the CLtL symbols, and to put their own symbols into a package with a different name. I think you will find an increasing number of implementations conforming to this implementation as time goes by. If you need to be portable to an implementation that has not been this careful, you can get the list of symbols from one of the careful implementations, rather than doing your own debugging of the typos in the manual.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Apr 87 14:27:24 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 11:12:12 PDT Date: Mon 6 Apr 87 14:08-EDT From: "Stephen E. Robbins" Subject: Common Lisp symbols To: common-lisp@SAIL.STANFORD.EDU The company I work for is just starting a large project in Common Lisp. For portability, we'd like to create our own special package into which we IMPORT the implementation's Common Lisp and then EXPORT *exactly* the set of CLtL symbols that make up common lisp. Our packages will then USE our private CL package. Does anyone out there have a list of the symbols in CLtL? Or is this going to require going through the manual page by page and figuring out what needs to be [im]ported? -- Stephen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Apr 87 01:49:12 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Apr 87 22:34:59 PST Received: from relay2.cs.net by RELAY.CS.NET id ae01039; 3 Apr 87 0:16 EST Received: from cs.umass.edu by RELAY.CS.NET id bn04266; 3 Apr 87 1:13 EST Date: Thu, 2 Apr 87 18:33 EDT From: ELIOT%cs.umass.edu@RELAY.CS.NET To: Common-Lisp@SAIL.STANFORD.EDU Subject: Clipping Output X-VMS-To: CSNET%"Common-Lisp@su-ai.arpa" Is there any good way, preferably in FORMAT to clip output longer than a specified length? I am using FORMAT to create a string from a list, but I only want the first 10 or 20 characters. The effect I need is equivalent to: (subseq (format nil "~a" XXX) 0 20)) but I would rather not do all the consing that this implies. In general, I would like to be able to specify the maximum field width of most of the format directives.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 16:55:14 EST Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 13:38:07 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Tue, 31 Mar 87 16:39:27 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA12685; Tue, 31 Mar 87 16:32:51 EST Message-Id: <8703312132.AA12685@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 31 Mar 87 14:30:06 EST Subject: Thanks for all the help To: common-list@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 31 Mar 87 14:30:07 EST Really, I wasn't suggesting munging the language. In PL/1 there isn't an explicit computed goto (well actually you can compute a label) but the select statement is often optimized. I just wanted some opinion on how to accomplish this is the compiler didn't optimize this. Cheers, Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 15:19:57 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Mar 87 12:00:44 PST Received: from Cabernet.ms by ArpaGateway.ms ; 31 MAR 87 10:46:39 PST Date: 31 Mar 87 10:54 PST From: Masinter.pa@Xerox.COM Subject: "computed goto" To: common-lisp@sail.stanford.edu Message-ID: <870331-104639-2597@Xerox> Common Lisp's equivalent for "computed goto" is FUNCALL--it lets you compute where you want to go. The more classic form of computed goto in fortran is useful primarily because of the inability to define lexically nested functions.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 12:11:16 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 31 Mar 87 08:50:32 PST Received: from feuerbach by Think.COM via CHAOS; Tue, 31 Mar 87 11:51:05 EST Date: Tue, 31 Mar 87 11:51 EST From: Guy Steele Subject: MAPing Sequences To: primerd!DOUG@ENX.Prime.PDN Cc: COMMON-LISP@sail.stanford.edu Message-Id: <870331115131.6.GLS@FEUERBACH.THINK.COM> Date: 30 Mar 87 09:35:33 EST From: primerd!DOUG@ENX.Prime.PDN How can one handle circular lists indescriminately in sequence functions? It seems to me that at minimum the function must record or mark each cons to avoid a recursive loop. Am I missing an obvious point? The technique is described in the form of a piece of code for LIST-LENGTH on page 265 of CLTL. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 11:49:07 EST Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 08:30:46 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA24061; Tue, 31 Mar 87 09:33:31 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA09932; Tue, 31 Mar 87 08:25:16 MST Date: Tue, 31 Mar 87 08:25:16 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8703311525.AA09932@utah-orion.ARPA> To: common-lisp@sail.stanford.edu Subject: Computed goto's Just for the record, the PSL compiler does produce jump tables out of a CASE, but there are so many restrictions (enough cases, consecutive small integers, etc) that as far as I know jump tables only appear in type dispatching code. Definitely not worth munging a language for... stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 09:49:14 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 31 Mar 87 06:35:29 PST Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72091; Tue 31-Mar-87 09:34:36 EST Date: Tue, 31 Mar 87 09:34 EST From: David L. Andre Subject: Computed goto's To: primerd!DOUG@ENX.Prime.PDN cc: common-lisp@sail.stanford.edu, DLA@DIAMOND.S4CC.Symbolics.COM In-Reply-To: <8703310550.AA10705@primerd.prime.com> Message-ID: <870331093435.6.DLA@LIMPKIN.S4CC.Symbolics.COM> Date: 31 Mar 87 00:36:09 EST From: primerd!DOUG@ENX.Prime.PDN As is the case for others I have found that the CASE form will not be 'smart' enough. For one thing our compiler first macroexpands it into a cascaded IF form (from which it would require inhuman intuition to correctly transform it into a computed goto). Sorry, but I don't think common lisp should be designed around the deficiencies of individual compilers. If a compiler doesn't have a hook for transforming macros before they're expanded, then the problem is in the compiler, not the language specification.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 02:15:53 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Mar 87 23:00:54 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 105141; Tue 31-Mar-87 01:59:55 EST Date: Tue, 31 Mar 87 01:59 EST From: David A. Moon Subject: Discussion of computed GO and CASE To: Common-Lisp@sail.stanford.edu Message-ID: <870331015943.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Three remarks: (1) It isn't necessarily true that an indexed jump is a faster implementation of CASE than a series of conditional branches. It depends on the number of clauses in the CASE statement, on the particular machine architecture, and in many architectures on the particular machine model. The minimum number of clauses for which an indexed jump is preferable generally increases with the performance of the machine, as more pipelining and branch prediction hardware is used. (2) We would surely rather have our compilers optimize this than do it ourselves, by writing different source code for different machines. (3) If our compilers don't produce code that is as efficient as we would like, we should change our compilers, not our language. The language should only be changed when there is a widely-agreed-upon reason why the language makes efficient compilation impossible; that is clearly not the case here.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Mar 87 01:10:35 EST Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 21:55:25 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Tue, 31 Mar 87 00:56:41 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA10705; Tue, 31 Mar 87 00:50:19 EST Message-Id: <8703310550.AA10705@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 31 Mar 87 00:36:09 EST Subject: Computed goto's To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 31 Mar 87 00:36:09 EST As is the case for others I have found that the CASE form will not be 'smart' enough. For one thing our compiler first macroexpands it into a cascaded IF form (from which it would require inhuman intuition to correctly transform it into a computed goto). Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 21:36:35 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 30 Mar 87 18:19:59 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72018; Mon 30-Mar-87 21:18:44 EST Date: Mon, 30 Mar 87 21:21 EST From: David C. Plummer Subject: Computed goto's To: Barry Margolin , primerd!DOUG@ENX.Prime.PDN cc: common-lisp@sail.stanford.edu In-Reply-To: <870330194324.4.BARMAR@PLATO.THINK.COM> Message-ID: <870330212134.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 30 Mar 87 19:43 EST From: Barry Margolin I don't think an array of compiled function objects should be significantly more expensive than what you want, though. The only added expense I can think of is that you have to push a stack frame to transfer and you have to indirect through the lexical environment to reference variables that would have been local. And if one of the lexical references is a go tag itself, many implementations will arrange to do a THROW to someplace in containing tagbody which will just invoke another computed-go... I think it would be pretty easy to write a macro that does this. In fact, I think this does a simple subcase: (defmacro on-goto (key &body clauses) ;remember BASIC? (let ((array (map '(array function) #'(lambda (clause) (compile nil `(lambda () . ,clause))) clauses))) `(funcall (aref ,array ,key)))) Well, it's not as easy as I thought -- the above macro doesn't do the right thing with lexical variables in the clauses. But I'm pretty sure it could be done.... It's not a good idea to go off and call the compiler at macro expansion time. I'm not sure the above could work in the interpreter if you were able to fix the lexical reference bug. What about a computed-goto out of range, which I think means fall-through? DLA was right: CASE on integers and hope the compiler will notice all the bodies are GO statements and do the right thing. (defmacro on-goto (key &rest wheres) `(case ,key ,@(do ((index 1 (1+ index)) ; fortrash 1 based? (wheres wheres (cdr wheres)) (clauses '() (cons `(,index (go ,(car wheres))) clauses))) ((null wheres) (reverse clauses))))) (on-goto foobar here there anywhere) => (CASE FOOBAR (1 (GO HERE)) (2 (GO THERE)) (3 (GO ANYWHERE)))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 19:58:43 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Mar 87 16:42:37 PST Received: from plato by Think.COM via CHAOS; Mon, 30 Mar 87 19:43:05 EST Date: Mon, 30 Mar 87 19:43 EST From: Barry Margolin Subject: Computed goto's To: primerd!DOUG@ENX.Prime.PDN Cc: common-lisp@sail.stanford.edu In-Reply-To: <8703302250.AA09659@primerd.prime.com> Message-Id: <870330194324.4.BARMAR@PLATO.THINK.COM> Date: 30 Mar 87 16:57:26 EST From: primerd!DOUG@ENX.Prime.PDN Thinking about it there are times when one would like to do a computed goto. I notice that (go tag) in tagbody is explicitly not calculated. For maximum effect the computation should result directly in a dispatched goto. One can get the effect of this by using lambda's in an array and doing an array lookup but this is somewhat more expensive (?). Any suggestions about this? Doug (doug@enx.prime.com) One could hope that a CASE statement in which all the test objects were small fixnums would be compiled into a jump table. I just checked, and Symbolics doesn't do this. I don't think an array of compiled function objects should be significantly more expensive than what you want, though. The only added expense I can think of is that you have to push a stack frame to transfer and you have to indirect through the lexical environment to reference variables that would have been local. I think it would be pretty easy to write a macro that does this. In fact, I think this does a simple subcase: (defmacro on-goto (key &body clauses) ;remember BASIC? (let ((array (map '(array function) #'(lambda (clause) (compile nil `(lambda () . ,clause))) clauses))) `(funcall (aref ,array ,key)))) Well, it's not as easy as I thought -- the above macro doesn't do the right thing with lexical variables in the clauses. But I'm pretty sure it could be done.... barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 19:53:59 EST Received: from ERNIE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 16:38:16 PST Received: by ernie.Berkeley.EDU (5.57/1.23) id AA23818; Mon, 30 Mar 87 16:39:27 PST Date: Mon, 30 Mar 87 16:39:27 PST From: wahlster@ernie.Berkeley.EDU (Prof. Wolfgang Wahlster) Message-Id: <8703310039.AA23818@ernie.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: Remove from Mailing List Since I am leaving the States today, please remove me from the mailing list. It's too expensive to send everything to Germany. Thanks Wolfgang Wahlster  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 19:17:43 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 30 Mar 87 16:02:21 PST Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71984; Mon 30-Mar-87 19:00:48 EST Date: Mon, 30 Mar 87 19:00 EST From: David L. Andre Subject: Computed goto's To: primerd!DOUG@ENX.Prime.PDN cc: common-lisp@sail.stanford.edu In-Reply-To: <8703302250.AA09659@primerd.prime.com> Message-ID: <870330190048.5.DLA@LIMPKIN.S4CC.Symbolics.COM> Date: 30 Mar 87 16:57:26 EST From: primerd!DOUG@ENX.Prime.PDN Thinking about it there are times when one would like to do a computed goto. I notice that (go tag) in tagbody is explicitly not calculated. For maximum effect the computation should result directly in a dispatched goto. One can get the effect of this by using lambda's in an array and doing an array lookup but this is somewhat more expensive (?). Any suggestions about this? Why not use CASE on the dispatching integer? A good compiler could always turn it into a dispatch instruction if the hardware supports it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 18:48:22 EST Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 15:33:22 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Mon, 30 Mar 87 18:34:28 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA09659; Mon, 30 Mar 87 17:50:56 EST Message-Id: <8703302250.AA09659@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 30 Mar 87 16:57:26 EST Subject: Computed goto's To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 30 Mar 87 16:57:26 EST Thinking about it there are times when one would like to do a computed goto. I notice that (go tag) in tagbody is explicitly not calculated. For maximum effect the computation should result directly in a dispatched goto. One can get the effect of this by using lambda's in an array and doing an array lookup but this is somewhat more expensive (?). Any suggestions about this? Doug (doug@enx.prime.com)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 17:54:42 EST Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 14:28:18 PST Date: Mon 30 Mar 87 14:28:45-PST From: Evan Kirshenbaum Subject: NMAP To: common-lisp@Sail.Stanford.EDU Message-ID: <12290604828.28.EVAN@CSLI.Stanford.EDU> When the topic of destructive mapping was first brought up, I thought "What a great idea, but why not just write a function to do it?". So I did. My first attempt took about 5 minutes and looked like: (defun map-into (res-seq fn &rest arg-seqs) (let ((index 0)) (apply #'map nil #'(lambda (&rest args) (setf (elt res-seq index) (apply fn args)) (incf index)) arg-seqs) res-seq)) This worked and was quite elegant, but had the disadvantage that its performance on lists could be much worse than its performance on vectors because elt could be implemented to search from the beginning of the list each time. After thinking a bit, I made the following modifications: (defun map-into (res-seq fn &rest arg-seqs) (let ((rs res-seq) (index 0)) (apply #'map nil (if (listp res-seq) #'(lambda (&rest args) (setf (car rs) (apply fn args)) (pop rs)) #'(lambda (&rest args) (setf (elt res-seq index) (apply fn args)) (incf index))) arg-seqs) res-seq)) This seems to handle the general case quite nicely and would seem to generalize well into a macro for those of you who like them better. This assumes that the result sequence is big enough to handle the result of the map (although it can be too big with no problem). By the way, I also (obviously) vote for MAP-INTO rather than NMAP. evan -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 17:11:53 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Mar 87 13:45:41 PST Received: from plato by Think.COM via CHAOS; Mon, 30 Mar 87 16:45:07 EST Date: Mon, 30 Mar 87 16:44 EST From: Barry Margolin Subject: MAPing Sequences To: primerd!DOUG@ENX.Prime.PDN Cc: COMMON-LISP@sail.stanford.edu In-Reply-To: <8703301541.AA08877@primerd.prime.com> Message-Id: <870330164457.7.BARMAR@PLATO.THINK.COM> Date: 30 Mar 87 09:35:33 EST From: primerd!DOUG@ENX.Prime.PDN To: commonlisp (common-lisp@sail.stanford.edu) From: Doug Rand (DOUG@ENX.PRIME.COM) x4182 bldg 10 Date: 30 Mar 87 9:26 AM Subject: Re: MAPing Sequences >.. an inefficient implementation technique that doesn't support them > seems like a poor reason to not allow them. > Kelly Murray How can one handle circular lists indescriminately in sequence functions? It seems to me that at minimum the function must record or mark each cons to avoid a recursive loop. Am I missing an obvious point? Not obvious, but fairly well known. It is not necessary to mark every element of a list in order to detect circularity. The easiest way I know of to detect circularity (I think this is Plummer's algorithm) is to scan the list simultaneously by ones and twos, i.e. (defun circular-list-p (list) (do ((l1 list (cdr l1)) (l2 (cdr list) (cddr l2))) ;not very robust, it'll ;lose on dotted lists ((or (endp l1) (endp l2)) nil) (when (eq l1 l2) (return t)))) This takes time linear in the length of the circularity plus the length of the subsequence before the circularity begins, and constant space; I don't know if a more efficient algorithm is known. As for mapping functions, as long as you require that at least one of the arguments be finite, they shouldn't have to "detect" circularities at all. When one of their inputs runs out they should throw out of the loop.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 15:09:36 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Mar 87 11:51:45 PST Received: from plato by Think.COM via CHAOS; Mon, 30 Mar 87 14:51:39 EST Date: Mon, 30 Mar 87 14:52 EST From: Barry Margolin Subject: *terminal-io* To: Sandra J Loosemore Cc: common-lisp@sail.stanford.edu In-Reply-To: <8703292147.AA00699@utah-orion.ARPA> Message-Id: <870330145200.2.BARMAR@PLATO.THINK.COM> Date: Sun, 29 Mar 87 14:47:49 MST From: sandra%utah-orion@CS.UTAH.EDU (Sandra J Loosemore) CLtL specifies that *standard-input*, *standard-output*, and friends should initially be bound to synonym streams that pass everything on to *terminal-io*. In the very next paragraph (p329), however, it says that the value of *terminal-io* should never be changed. What is the point of introducing the extra level of indirection? Is there some reason why *standard-input* couldn't be initialized to the same stream as *terminal-io*? -Sandra ------- It says that no USER program should ever change the value of *terminal-io*. *terminal-io* is not, however, a constant. Programs internal to the implementation might have need to set or bind it. Actually, I can think of reasons why a user program would have need to set *terminal-io*. For instance, suppose you write a windowing package in Lisp -- when changing windows you would generally set *terminal-io* to the newly selected window, and all the synonym streams would follow it over to the new window. I interpreted that sentence about *terminal-io* as a warning to users that if they are assigning to *terminal-io* they probably are doing the wrong thing. There's a similar warning in the description of EVAL. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 15:00:14 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Mar 87 11:43:48 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104510; Mon 30-Mar-87 14:28:32 EST Date: Mon, 30 Mar 87 14:28 EST From: David A. Moon Subject: Circular list implementation technique To: primerd!DOUG@ENX.Prime.PDN cc: COMMON-LISP@SAIL.STANFORD.EDU In-Reply-To: <8703301541.AA08877@primerd.prime.com> Message-ID: <870330142823.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 30 Mar 87 09:35:33 EST From: primerd!DOUG@ENX.Prime.PDN How can one handle circular lists indescriminately in sequence functions? It seems to me that at minimum the function must record or mark each cons to avoid a recursive loop. Am I missing an obvious point? See the example code on page 265 of CLtL. This technique doesn't come for free, but it's more efficient than some more obvious techniques.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 14:18:29 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 10:58:06 PST Date: Mon, 30 Mar 87 14:01:36 EST From: Jonathan A Rees Subject: almost scheme in common lisp To: common-lisp@SAIL.STANFORD.EDU, scheme@MC.LCS.MIT.EDU Message-ID: <176048.870330.JAR@AI.AI.MIT.EDU> I have written a macro package which implements Scheme, less general tail-recursion and first-class continuations, in Common Lisp. It appears to be effective at transforming any Common Lisp implementation into an acceptable development environment for Scheme programs. Loops written using LETREC, internal DEFINE, or "named LET" are macroexpanded into an appropriate TAGBODY construct, but other than that, tail recursion is only done at the whim of your particular CL implementation. Being a macro package and not a compiler or interpreter, continuations also clearly can't work in general (unless, again, your CL just happens to support them). Other incompatibilities with the "Revised^3" Scheme report are minor. It's called "Pseudoscheme" and resides in MC.LCS.MIT.EDU: "JAR;PSEUDO >" The documentation is in MC.LCS.MIT.EDU: "JAR;PSEUDO DOC" I'll send it by electronic mail to those unable to FTP it. Please send mail to INFO-CLSCHEME-REQUEST@MC.LCS.MIT.EDU if you start using it, so you can stay up to date on improvements. Feel free to redistribute it, but try to let me know if you do so. The documentation file describes its peculiarities in somewhat more detail. - Jonathan Rees  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 12:52:10 EST Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 09:30:58 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Mon, 30 Mar 87 12:32:17 EST Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA08877; Mon, 30 Mar 87 10:41:27 EST Message-Id: <8703301541.AA08877@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 30 Mar 87 09:35:32 EST To: COMMON-LISP@SAIL.STANFORD.EDU From: primerd!DOUG@ENX.Prime.PDN Date: 30 Mar 87 09:35:33 EST To: commonlisp (common-lisp@sail.stanford.edu) From: Doug Rand (DOUG@ENX.PRIME.COM) x4182 bldg 10 Date: 30 Mar 87 9:26 AM Subject: Re: MAPing Sequences >.. an inefficient implementation technique that doesn't support them > seems like a poor reason to not allow them. > Kelly Murray How can one handle circular lists indescriminately in sequence functions? It seems to me that at minimum the function must record or mark each cons to avoid a recursive loop. Am I missing an obvious point? I am curious to know by what technique one can do NTH without scanning the list (excluding cdr-coded lists)? Cheers, Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 01:25:14 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Mar 87 22:10:15 PST Received: from relay2.cs.net by RELAY.CS.NET id ac14256; 30 Mar 87 1:13 EST Received: from cs.umass.edu by RELAY.CS.NET id at23324; 30 Mar 87 1:08 EST Date: Sun, 29 Mar 87 21:24 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: MAPing Sequences X-VMS-To: CSNET%"common-lisp@su-ai.ARPA" > It has not been established that it is a bug for sequence functions not > to handle circular lists. There seems to be strong sentiment on both > sides of this issue, and there is no clear statement on this in the > manual. At some point the standardization committee will have to make a > decision one way or the other. Calling it a Bug was my own opinion. I should more careful, and I aplogize for any confusion. > If it were up to me (which it isn't) it would be an error to pass a > circular list to any function that does not explicitly allow circular > lists. I don't think the extra cost of handling this style is justified > for most functions. Sequences should be finite. > -- Scott Extra cost for what? Using lists as sequences? LENGTH and ELT are not constant-time operations on lists. AT LEAST FOR THE MAPPING FUNCTIONS, it is a poor implementation which forces every cons of a list to be looked at (paged in) if they will never be used by the function since some other sequence is shorter. It is equally poor to scan the first N-1 elements of a list every time to get the Nth. Whether sequences can be infinite or not, an inefficient implementation technique that doesn't support them seems like a poor reason to not allow them. Kelly Murray  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Mar 87 00:09:02 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Mar 87 20:55:13 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104021; Sun 29-Mar-87 22:07:13 EST Date: Sun, 29 Mar 87 22:05 EST From: Kent M Pitman Subject: *terminal-io* To: sandra%utah-orion@UTAH-CS.ARPA cc: smh@ems.media.mit.edu, common-lisp@sail.stanford.edu In-Reply-To: <8703300028.AA01022@utah-orion.ARPA> Message-ID: <870329220557.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Sun, 29 Mar 87 17:28:03 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Well, suppose the implementation doesn't provide any utilities that mess with the value of *terminal-io*: it might initialize it on startup and that's that. If *terminal-io* is never changed in system code, and users aren't supposed to change it, why bother with the synonym stream? I think the manual is being overly restrictive here.... The responsibility of CL goes beyond legislating simply what implementations must and must not do for the sake of user code. It tries to create formalisms where reasonable implementation-dependent extensions to the language will not break CL programs. This is an example of such a case. Although CL users are told not to directly change *TERMINAL-IO*, users of some CL implementations may invoke system-dependent commands which change it. And when they do so, they do not want their CL programs to break because those programs have made unwarranted assumptions about the constant nature of *TERMINAL-IO*. In fact, once more progress has been made in the window system arena, we may even want to lift the restriction that *TERMINAL-IO* should not change due to user programs. As such, it's best for now that programs continue to assume that *TERMINAL-IO* might change, since some day it might and it would be a shame for them not to be capable of accepting that change.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Mar 87 19:40:33 EST Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 16:25:25 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA10186; Sun, 29 Mar 87 17:28:08 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA01022; Sun, 29 Mar 87 17:28:03 MST Date: Sun, 29 Mar 87 17:28:03 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8703300028.AA01022@utah-orion.ARPA> Subject: Re: *terminal-io* To: smh@ems.media.mit.edu (Steven Haflich) Cc: common-lisp@sail.stanford.edu, sandra%utah-orion@utah-cs.arpa In-Reply-To: smh@EMS.MEDIA.MIT.EDU (Steven Haflich), Sun, 29 Mar 87 17:16:00 EST Well, suppose the implementation doesn't provide any utilities that mess with the value of *terminal-io*: it might initialize it on startup and that's that. If *terminal-io* is never changed in system code, and users aren't supposed to change it, why bother with the synonym stream? I think the manual is being overly restrictive here.... -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Mar 87 17:30:02 EST Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 14:15:28 PST Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA22633; Sun, 29 Mar 87 17:16:00 EST Date: Sun, 29 Mar 87 17:16:00 EST From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8703292216.AA22633@EMS.MEDIA.MIT.EDU> To: common-lisp@sail.stanford.edu, sandra%utah-orion@utah-cs.arpa Subject: Re: *terminal-io* CLtL actually says: "No **user** program should ever change the value of *terminal-io*." [emphasis added] Presumably it is allowable for **environment** managing code such as a window manager to play with *terminal-io* in a multiple process environment. Details left as an exercise for the implementor ...  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Mar 87 17:02:18 EST Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 13:45:11 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA05375; Sun, 29 Mar 87 14:47:53 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA00699; Sun, 29 Mar 87 14:47:49 MST Date: Sun, 29 Mar 87 14:47:49 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8703292147.AA00699@utah-orion.ARPA> Subject: *terminal-io* To: common-lisp@sail.stanford.edu CLtL specifies that *standard-input*, *standard-output*, and friends should initially be bound to synonym streams that pass everything on to *terminal-io*. In the very next paragraph (p329), however, it says that the value of *terminal-io* should never be changed. What is the point of introducing the extra level of indirection? Is there some reason why *standard-input* couldn't be initialized to the same stream as *terminal-io*? -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Mar 87 15:18:41 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 28 Mar 87 12:02:05 PST Received: by hplabs.HP.COM ; Sat, 28 Mar 87 12:02:42 pst Received: by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86) id AA21125; Sat, 28 Mar 87 11:35:42 PST Date: 28 Mar 1987 11:20-PST From: David Bein Subject: Sequence functions .. To: hplabs!common-lisp@su-ai@hplabs.HP.COM Message-Id: <543957653/bein@pyramid> While we are at it, is a list which is terminated by something besides nil considered a legal sequence? My opinion is that a sequence should be properly terminated and as a result, length is legitimate when it complains about improperly terminated lists. Also, what seems to be the consensus about circular lists and sequence functions? I agree with Scott that a function which is not advertised to handle circular lists should be allowed to loop/recurse. My current implementation of length uses list-length, but I think this is overly expensive and would prefer to use a more tradition definition which uses either ENDP or ATOM to stop. --David  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Mar 87 11:39:37 EST Received: from UMN-CS.ARPA by SAIL.STANFORD.EDU with TCP; 28 Mar 87 08:27:54 PST Received: by umn-cs.arpa (5.51/4.7) id AA28737; Sat, 28 Mar 87 10:28:55 CST Date: Sat, 28 Mar 87 10:28:55 CST From: frascado@umn-cs.arpa (Gregory Frascadore) Message-Id: <8703281628.AA28737@umn-cs.arpa> To: common-lisp@sail.stanford.edu Subject: nmap Here is another version of an nmap macro that I think addresses the problems with length vs circular lists: (defmacro nmap (seq fun &rest seqs) (let ((arglist (mapcar #'(lambda (dummy) (gensym)) seqs)) ) `(let ((i 0) (rseq ,seq) ) (map nil #'(lambda ,(cons (gensym) arglist) (setf (elt rseq i) (funcall ,fun ,@arglist)) (incf i) ) rseq ,@seqs ) rseq ))) ------- Gregory Frascadore Computer Science Department frascado%umn-cs.csnet@csnet-relay.arpa University of Minnesota frascado@umn-cs  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Mar 87 10:14:00 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87 07:01:58 PST Received: ID ; Sat 28 Mar 87 10:02:47-EST Date: Sat, 28 Mar 1987 10:02 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: MURRAY%cs.umass.edu@RELAY.CS.NET Cc: common-lisp@SAIL.STANFORD.EDU Subject: NMAP a good idea. In-reply-to: Msg of 27 Mar 1987 16:46-EST from MURRAY%cs.umass.edu at RELAY.CS.NET Just so that your message will not cause a flood of bug reports to Common Lisp implementors: It has not been established that it is a bug for sequence functions not to handle circular lists. There seems to be strong sentiment on both sides of this issue, and there is no clear statement on this in the manual. At some point the standardization committee will have to make a decision one way or the other. If it were up to me (which it isn't) it would be an error to pass a circular list to any function that does not explicitly allow circular lists. I don't think the extra cost of handling this style is justified for most functions. Sequences should be finite. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Mar 87 01:44:54 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Mar 87 22:25:44 PST Received: from relay2.cs.net by RELAY.CS.NET id ab04968; 28 Mar 87 1:19 EST Received: from cs.umass.edu by RELAY.CS.NET id cb12707; 28 Mar 87 1:15 EST Date: Fri, 27 Mar 87 18:48 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp%su-ai.arpa@RELAY.CS.NET Subject: NMAP a good idea if done correctly (blush) X-VMS-To: CSNET%"common-lisp@su-ai.ARPA" I think the NMAP function is an excellent idea. Mapping is generally a good way to express things, and lends itself to parallelism. However, I would call the proposed function MAP-INTO, and have provided a definition below. The definition provided by Sasseen has the same Bug that most implementations have with some sequence functions - they call LENGTH on the arguments, which will never return for circular lists. By having it be a macro instead of a function, it performs NO consing, since the number of arguments are known, and FUNCALL can be used. However, it suffers the macro problem, in that macros cannot be APPLYed. The right way to do it is to have it be a function that has a compiler transform to expand calls at compile time. Unfortunately, compiler transforms are not part of Common Lisp. BTW: It took me 2 hours and 10 minutes to write and debug this macro. -- Kelly Murray (defmacro MAP-INTO (into-seq function &rest arg-seqs) "MAP-INTO into-seq function &rest arg-seqs Calls function on each element of the arg-seqs, storing results in corresponding element of into-seq. Returns modified into-seq." (let* ((rs-sym (gensym "RS-SYM")) (seq-syms (mapcar #'(lambda (ignore) (gensym "SEQ")) arg-seqs)) (consp-syms (mapcar #'(lambda (ignore) (gensym "SEQ-CONSP")) arg-seqs)) (rs-size (gensym "RS-SIZE")) (rs-cons (gensym "RS-CONS")) (seq-index (gensym "SEQ-INDEX")) (max-sym (gensym "MAX-INDEX")) (result-sym (gensym "RESULT")) (fun-sym (gensym "FUN"))) (cond ((null arg-seqs) ; No arguments? `(let* ((,rs-sym ,into-seq) (,fun-sym ,function) (,rs-cons (consp ,rs-sym))) (when ,rs-sym ; Not NIL (if ,rs-cons (do ((,rs-cons ,rs-sym (cdr ,rs-cons))) ((endp ,rs-cons) ,rs-sym) (setf (car ,rs-cons) (funcall ,fun-sym))) (dotimes (,rs-size (length ,rs-sym) ,rs-sym) (setf (elt ,rs-sym ,rs-size) (funcall ,fun-sym)))) ))) (:Else ;; First Eval the arguments. `(let* ((,rs-sym ,into-seq) (,fun-sym ,function) ,@(mapcar #'(lambda(sym seq)(list sym seq)) seq-syms arg-seqs) ; Determine result type (,rs-cons (when (consp ,rs-sym) ,rs-sym)) (,rs-size (unless ,rs-cons (length ,rs-sym))) ,@(mapcar #'(lambda(sym seq)(list sym `(consp ,seq))) consp-syms seq-syms) ; Consp variables (,max-sym nil) (,result-sym nil) ) ;; Determine maximum index for any argument vectors. ,@(mapcar #'(lambda(sym consp) `(unless ,consp (if ,max-sym (setq ,max-sym (min ,max-sym (length ,sym))) (setq ,max-sym (length ,sym))))) seq-syms consp-syms) (or ,max-sym (setq ,max-sym -1)) ; = never true for conses (do ((,seq-index 0 (1+ ,seq-index))) ((or (= ,seq-index ,max-sym) ; Hit smaller ,@(mapcan #'(lambda (sym) `((not ,sym))) ; End of a List. seq-syms)) ,rs-sym) ; Return the result sequence. ;; Call the function. (setq ,result-sym (funcall ,fun-sym ,@(mapcar #'(lambda(sym consp) `(if ,consp (pop ,sym) (elt ,sym ,seq-index))) seq-syms consp-syms))) ;; Store the results (cond (,rs-cons (setf (car ,rs-cons) ,result-sym) (pop ,rs-cons)) ((< ,seq-index ,rs-size) (setf (elt ,rs-sym ,seq-index) ,result-sym))) )))) ))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Mar 87 01:44:50 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Mar 87 22:25:27 PST Received: from relay2.cs.net by RELAY.CS.NET id aa04969; 28 Mar 87 1:19 EST Received: from cs.umass.edu by RELAY.CS.NET id ca12707; 28 Mar 87 1:14 EST Date: Fri, 27 Mar 87 17:46 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: NMAP a good idea. X-VMS-To: CSNET%"common-lisp@su-ai.ARPA" I think the NMAP function is an excellent idea. Mapping is generally a good way to express things, and lends itself to parallelism. However, I would call the proposed function MAP-INTO, and have provided a definition below. The definition provided by Sasseen has the same Bug that most implementations have with some sequence functions - they call LENGTH on the arguments, which will never return for circular lists. By having it be a macro instead of a function, it performs NO consing, since the number of arguments are known, and FUNCALL can be used. However, it suffers the macro problem, in that macros cannot be APPLYed. The right way to do it is to have it be a function that has a compiler transform to expand calls at compile time. Unfortunately, compiler transforms are not part of Common Lisp. BTW: It took me 2 hours to write and debug this macro. -- Kelly Murray (defmacro MAP-INTO (into-seq function &rest arg-seqs) "MAP-INTO into-seq function &rest arg-seqs Calls function on each element of the arg-seqs, storing results in corresponding element of into-seq. Returns modified into-seq." (let* ((rs-sym (gensym "RS-SYM")) (seq-syms (mapcar #'(lambda (ignore) (gensym "SEQ")) arg-seqs)) (consp-syms (mapcar #'(lambda (ignore) (gensym "SEQ-CONSP")) arg-seqs)) (rs-size (gensym "RS-SIZE")) (rs-cons (gensym "RS-CONS")) (seq-index (gensym "SEQ-INDEX")) (max-sym (gensym "MAX-INDEX")) (result-sym (gensym "RESULT")) (fun-sym (gensym "FUN"))) ;; First Eval the arguments. `(let* ((,rs-sym ,into-seq) (,fun-sym ,function) ,@(mapcar #'(lambda(sym seq)(list sym seq)) seq-syms arg-seqs) ; Determine result type (,rs-cons (when (consp ,rs-sym) ,rs-sym)) (,rs-size (unless ,rs-cons (length ,rs-sym))) ,@(mapcar #'(lambda(sym seq)(list sym `(consp ,seq))) consp-syms seq-syms) ; Consp variables (,max-sym nil) (,result-sym nil) ) ;; Determine maximum index for any argument vectors. ,@(mapcar #'(lambda(sym consp) `(unless ,consp (if ,max-sym (setq ,max-sym (min ,max-sym (length ,sym))) (setq ,max-sym (length ,sym))))) seq-syms consp-syms) (or ,max-sym (setq ,max-sym -1)) ; = never true for conses (do ((,seq-index 0 (1+ ,seq-index))) ((or (= ,seq-index ,max-sym) ; Hit smaller ,@(mapcan #'(lambda (sym) `((not ,sym))) ; End of a List. seq-syms)) ,rs-sym) ; Return the result sequence. ;; Call the function. (setq ,result-sym (funcall ,fun-sym ,@(mapcar #'(lambda(sym consp) `(if ,consp (pop ,sym) (elt ,sym ,seq-index))) seq-syms consp-syms))) ;; Store the results (cond (,rs-cons (setf (car ,rs-cons) ,result-sym) (pop ,rs-cons)) ((< ,seq-index ,rs-size) (setf (elt ,rs-sym ,seq-index) ,result-sym))) ))))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Mar 87 16:33:26 EST Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 13:12:11 PST Date: 27 Mar 1987 16:12-EST Sender: VERACSD@A.ISI.EDU Subject: NMAP macro From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU Message-ID: <[A.ISI.EDU]27-Mar-87 16:12:34.VERACSD> (defmacro nmap (result-sequence function &rest sequences) (let (let-clauses min-args function-args gs (result-sequence-gs (gensym)) (function-gs (gensym)) (length (gensym)) (rs (gensym)) (result-element (gensym)) (index (gensym))) (dolist (sequence (reverse sequences)) (setq gs (gensym)) (push '(,gs ,sequence) let-clauses) (push '(cond ((listp ,gs) (pop ,gs)) (t (aref ,gs ,index))) function-args) (push '(length ,gs) min-args)) (push '(,function-gs ,function) let-clauses) (push '(,result-sequence-gs ,result-sequence) let-clauses) (push '(length ,result-sequence-gs) min-args) '(let (,@let-clauses (,length (length ,result-sequence-gs)) (,rs ,result-sequence-gs) ,result-element) (setq ,length (funcall 'min ,@min-args)) (dotimes (,index ,length) (setq ,result-element (funcall ,function-gs ,@function-args)) (cond ((listp ,result-sequence-gs}i) (setf (car ,rs) ,result-element) (setq ,rs (cdr ,rs))) (t (setf (aref ,result-sequence-gs ,index) ,result-element)))) ,result-sequence-gs))) For those who prefer a macro. Don't know why I couldn't come up with this last night. Bob Sasseen veracsd.rs@a.isi.edu (arpanet)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Mar 87 10:53:59 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 07:39:54 PST Received: ID ; Fri 27 Mar 87 10:42:15-EST Date: Fri, 27 Mar 1987 10:42 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: mcvax!lifia!phs@seismo.CSS.GOV (Philippe Schnoebelen) Cc: common-lisp@SAIL.STANFORD.EDU Subject: Practical (values) In-reply-to: Msg of Fri 27 Mar 87 09:09:11 -0200 from mcvax!lifia!phs at seismo.CSS.GOV (Philippe Schnoebelen) I think that you will find that a lot of Common Lisp implementations handle one return value somewhat more efficiently than they handle zero values. There are two reasons for this: first, many implementations are adaptations of older Lisp systems that had only single-value returns, and the multiple value stuff was grafted on as an afterthought; second, many newer implementations handle single-value return as a special case that is carefully tuned for greatest performance, since the overwhelming majority of Common Lisp calls (measured dynamically) either return only a single value or immediately discard any additional values. In some implementations, returning NIL and returning (VALUES) may be equally fast, but I don't know of any in which the latter form would be faster. I suppose one could argue that returning (VALUES) is more perspicuous, since it makes clear that the return value is of no interest. But the practice of returning NIL in such cases is a time-honored idom that is unlikely to confuse anyone; a lot of people would have to stop and consider what (VALUES) means. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Mar 87 04:49:45 EST Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 27 Mar 87 01:35:53 PST Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA27017; Fri, 27 Mar 87 04:36:37 EST Received: by mcvax.cwi.nl; Fri, 27 Mar 87 10:28:21 +0100 (MET) Received: by inria.inria.fr; Fri, 27 Mar 87 09:24:00 +0100 (MET) Received: by imag.UUCP; Fri, 27 Mar 87 09:13:24 -0200 (MET) Received: by lifia.UUCP; Fri, 27 Mar 87 09:09:11 -0200 (MET) Date: Fri, 27 Mar 87 09:09:11 -0200 From: mcvax!lifia!phs@seismo.CSS.GOV (Philippe Schnoebelen) Message-Id: <8703270709.AA19189@lifia.UUCP> To: common-lisp@sail.stanford.edu Subject: Practical (values) I am always wondering about the multiple-values feature of CommonLisp, more specially the possibility of returning NO values, through a (VALUES) form. Very often one defines a function which does not return any informative value (at least it is only meant to have a side effect, but the value that happens to be returned should be irrelevant). This is a situation where I am tempted to put a (VALUES) form a the end of the function body. It is certainly cleaner and it should not compile into less efficient code, at least "there is no reason why it should give worse code" (the usual incantation). Yes, but practically ? Could someone give me (us) explanations about this ? How is it usually implemented ? Is it more, less, equally efficient ? Only in connection with (OPTIMIZE ...) declarations ? (TYPE ...) declarations ? Thanks. -- Philippe SCHNOEBELEN, LIFIA - IMAG, BP 68 UUCP : ...mcvax!imag!lifia!phs 38402 Saint Martin d'Heres, FRANCE "Algebraic symbols are used when you do not know what you are talking about."  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Mar 87 00:55:13 EST Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 21:39:39 PST Date: 27 Mar 1987 00:38-EST Sender: VERACSD@A.ISI.EDU Subject: NMAP From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU Message-ID: <[A.ISI.EDU]27-Mar-87 00:38:32.VERACSD> (defun nmap (result-sequence function &rest sequences) (let ((length (length result-sequence)) (arguments (make-list (length sequences))) (rs result-sequence) result-element) (dolist (sequence sequences) (setq length (min length (length sequence)))) (dotimes (index length) (do* ((args arguments (cdr args)) (seqs sequences (cdr seqs)) (sequence (car sequences) (car seqs))) ((null args)) (setf (car args) (cond ((listp sequence) (setf (car seqs) (cdr sequence)) (car sequence)) (t (aref sequence index))))) (setq result-element (apply function arguments)) (cond ((listp result-sequence) (setf (car rs) result-element) (setq rs (cdr rs))) (t (setf (aref result-sequence index) result-element)))) result-sequence)) I have pursued this simply because I have found nmap to be quite useful. For example, to fill a sequence with random numbers, one can use (nmap sequence #'(lambda () (random 1.0))). (This also illustrates that nmap may take zero additional sequence arguments.) I'd like to encourage Symbolics, TI, et al. to add this as an extension. Note that nmap is a function rather than a macro. This is surely the right thing. I was able to reduce the consing only down to M cells, where M is the number of additional sequences passed, while still remaining within Common Lisp. Lisp machines can reduce it to zero. Probably this code can be improved in other ways, but it is competitive with map on the Explorer. (Our Symbolics crashed earlier today). Caveat emptor: I only just wrote this version, so there could *conceivably* be a bug or two, although I tested it. I also had to type it in by hand on a Mac. (Incidentally, Scott, I found it far from trivial to come up with a macro that correctly implements nmap with no consing. In fact, after a while I decided to give up on it. If you decide to do it for fun, I'd like to see the result.) Bob Sasseen veracsd.rs@a.isi.edu (arpanet)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 20:40:06 EST Received: from IMSSS by SAIL with PUP; 26-Mar-87 17:17 PST Date: 26 Mar 1987 1714-PST From: Rem@IMSSS Subject: Coercion rule for comparisons To: COMMON-LISP@SU-AI Perhaps the rule for binary (two-arg) comparison should be first coerced to least-accurate (a la arithmetic) to see if they can be distinguished (shown non-equal) at that level of precision. If so, we can immediately answer the pending question at minimal cost. If they look equal at least precision, then coerce the other way (most precision) to get a definitive result. If that were the rule for binary comparisons, would transitivity then hold for all the standard comparison operations except not-equal? -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 19:29:53 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 26 Mar 87 13:51:14 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 102278; Thu 26-Mar-87 16:33:29 EST Return-path: <@UCB-VAX.ARPA:fateman@mike.Berkeley.EDU> Received: from ucbvax.Berkeley.EDU (UCB-VAX.ARPA) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 101751; 26 Mar 87 05:27:49 EST Received: by ucbvax.Berkeley.EDU (5.57/1.23) id AA11161; Wed, 25 Mar 87 23:21:10 PST Received: by mike (3.2/5.17) id AA05372; Wed, 25 Mar 87 23:18:49 PST Date: Wed, 25 Mar 87 23:18:49 PST From: fateman@mike.Berkeley.EDU (Richard Fateman) Message-Id: <8703260718.AA05372@mike> To: Moon@stony-brook.scrc.symbolics.com Subject: Re: Numerical Comparison: "required coercions" Resent-To: Common-Lisp@sail.stanford.edu Resent-From: David A. Moon Resent-Date: Thu, 26 Mar 87 16:33 EST Resent-Message-ID: <870326163309.5.MOON@EUPHRATES.SCRC.Symbolics.COM> mixed mode is not covered in IEEE standard. The assumption of most people is, I think that the smaller format is zero-extended and then compared. Rational numbers are not part of the IEEE standard, and that is where jonl's point comes up. This was discussed a year ago, or so.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 19:08:20 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 15:45:30 PST Received: from SWALLOW.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70959; Thu 26-Mar-87 17:29:44 EST Date: Thu, 26 Mar 87 17:29 EST From: Michael Greenwald Subject: Numerical Comparison: "required coercions" To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, DCP@QUABBIN.SCRC.Symbolics.COM, gls@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <870326133440.1.GREENWALD@SWALLOW.S4CC.Symbolics.COM> Message-ID: <870326172927.6.GREENWALD@SWALLOW.S4CC.Symbolics.COM> Date: Thu, 26 Mar 87 13:34 EST From: Michael Greenwald Date: Thu, 26 Mar 87 10:47 EST From: David C. Plummer Date: Thu, 26 Mar 87 10:29 EST From: Guy Steele This issue makes me want to restate an earlier proposed model for the comparison functions: (? x1 x2 x3 x4 ... xn-1 xn) <=> (AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn) (? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn) (? x3 x4) ... (? x3 xn-1) (? x3 xn) . . . . . (? xn-1 xn)) where "?" may be =, /=, <, >, <=, or >=. That is, in principle every pair of arguments is compared. This is the model that justifies the "all different" interpretation for /=, and it is recognized that in practice the other five operations may be implemented cleverly through exploitation of transitivity. Well, maybe such reliance on transitivity is wrong. Why "maybe"? (<= 1234d10 12340000000001 1234e10 12340000000000) => T when you depend on transitivity, but should => NIL according to the above model. On the other hand, SORT clearly depends on transitivity, and one might reasonably expect (APPLY '<= (SORT SEQUENCE '<=)) => T. (Or even more reasonably (APPLY '< (SORT SEQUENCE '<)) => T, which unfortunately isn't true since (SORT '(1234d10 12340000000001 1234e10 12340000000000) '<) returns the original sequence.) I was wrong. The < case isn't a reasonable expectation. Mike McMahon points out: (APPLY '< (SORT '(1 1 1 1 1 1 1) '<)). I guess I wasn't thinking too clearly.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 15:50:28 EST Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 12:24:58 PST Received: by ucbvax.Berkeley.EDU (5.57/1.23) id AA21122; Thu, 26 Mar 87 11:55:09 PST Received: by mike (3.2/5.17) id AA05911; Thu, 26 Mar 87 11:54:28 PST Date: Thu, 26 Mar 87 11:54:28 PST From: fateman@mike.Berkeley.EDU (Richard Fateman) Message-Id: <8703261954.AA05911@mike> To: Common-Lisp@sail.stanford.edu, DCP@quabbin.scrc.symbolics.com, Greenwald@stony-brook.scrc.symbolics.com, Moon@stony-brook.scrc.symbolics.com, gls@think.com Subject: Re: Numerical Comparison: "required coercions" Cc: Numerics@stony-brook.scrc.symbolics.com I think that comparing more than 2 operands could simply be forbidden since the semantics is unclear and the utility is doubtful. I disagree with the statement that "it is misleading to *add* bits of precision during a computation." In fact, unless the language starts by assuming that ALL numbers, floating point numbers or rationals are exact, you are in trouble. (Some languages screw this up, and perhaps this is where the inspiration comes from.) The best model might be to say that changing representations (e.g. float to double conversion) is fine, as long as it doesn't change the value. But rational to float sometimes changes values (sometimes it loses the whole ball of wax when the number over/underflows). This is not good. .... Confusing accuracy with precision is dangerous. No one knows for sure that 1/3 is more accurate than 0.3. In fact, they may both be used as poor approximations to 1/2. .... There is an IEEE "inexact" flag which pertain to operations, not operands. It helps you do things in lower precision than you thought you could, and still get the right answer. More later.,.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 15:36:07 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Mar 87 12:08:23 PST Received: from thoreau by Think.COM via CHAOS; Thu, 26 Mar 87 15:08:11 EST Date: Thu, 26 Mar 87 15:08 EST From: Guy Steele Subject: Re: Numerical Comparison: "required coercions" To: fateman@mike.berkeley.edu, Common-Lisp@sail.stanford.edu, DCP@quabbin.scrc.symbolics.com, Greenwald@stony-brook.scrc.symbolics.com, Moon@stony-brook.scrc.symbolics.com, gls@think.com Cc: Numerics@stony-brook.scrc.symbolics.com, gls@think.com In-Reply-To: <8703261954.AA05911@mike> Message-Id: <870326150845.8.GLS@THOREAU.THINK.COM> Date: Thu, 26 Mar 87 11:54:28 PST From: fateman@mike.berkeley.edu (Richard Fateman) I think that comparing more than 2 operands could simply be forbidden since the semantics is unclear and the utility is doubtful. The convenience is considerable when working with integers in such expressions as (<= 0 J N) (< -1 J K (+ N 1)) Admittedly this does not allow similarly concise expression of such common mathematical idioms as 0 <= j < n where the comparisons differ as to whether equality is to be included. I agree that using more than two arguments with floating-point numbers should perhaps be avoided as a matter of style. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 15:28:11 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 12:02:30 PST Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70837; Thu 26-Mar-87 14:58:18 EST Date: Thu, 26 Mar 87 14:58 EST From: Scott Cyphers Subject: Numerical Comparison: "required coercions" To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, DCP@QUABBIN.SCRC.Symbolics.COM, gls@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <870326133440.1.GREENWALD@SWALLOW.S4CC.Symbolics.COM> Message-ID: <870326145812.3.CYPHERS@RAVEN.S4CC.Symbolics.COM> Date: Thu, 26 Mar 87 13:34 EST From: Michael Greenwald Date: Thu, 26 Mar 87 10:47 EST From: David C. Plummer Date: Thu, 26 Mar 87 10:29 EST From: Guy Steele This issue makes me want to restate an earlier proposed model for the comparison functions: (? x1 x2 x3 x4 ... xn-1 xn) <=> (AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn) (? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn) (? x3 x4) ... (? x3 xn-1) (? x3 xn) . . . . . (? xn-1 xn)) where "?" may be =, /=, <, >, <=, or >=. That is, in principle every pair of arguments is compared. This is the model that justifies the "all different" interpretation for /=, and it is recognized that in practice the other five operations may be implemented cleverly through exploitation of transitivity. Well, maybe such reliance on transitivity is wrong. Why "maybe"? (<= 1234d10 12340000000001 1234e10 12340000000000) => T when you depend on transitivity, but should => NIL according to the above model. On the other hand, SORT clearly depends on transitivity, and one might reasonably expect (APPLY '<= (SORT SEQUENCE '<=)) => T. (Or even more reasonably (APPLY '< (SORT SEQUENCE '<)) => T, which unfortunately isn't true since (SORT '(1234d10 12340000000001 1234e10 12340000000000) '<) returns the original sequence.) I'm a fan of transitivity and also recognize this problem. If this is n^2 computation is to be the law-of-the-land for the non /= cases, I would suggest a declaration that tells the compiler that the user is guaranteeing transitivity so that only a linear number of comparisons is needed. The declaration is unnecessary, (although might be useful), since the check for whether transitivity will work can be done in linear time. (This same strategy reduces /= to NlogN for cases where transitivity holds, and all the elements are orderable by sorting the numbers and then only comparing adjacent elements. This doesn't work if any coercions could lose precision. (This works for complex numbers, too)) In practice, our implementation assumes transitivity holds, except in /=, where we are more scrupulous. All these anomolies are solved by coercing to the *most* exact representation for comparisons. I'm assuming that the floating-point contagion rule was mandated for two reasons: (1) It is misleading to *add* bits of precision during a computation. (although this is belied by the single-to-double conversion rule) (2) Floats put a stricter upper bound on the required storage than do the corresponding rationals and bignums. Both of these rules are more applicable for computations (+, -, etc.) than for comparisons. CLtL chose a single coercion rule ("WhenEVER a rational meets a floating point number, the rational is first converted to a floating-point number of the same format") rather than two coercion rules ("In computations that produce new values, the arguments are first coerced to the least precise representation of the two arguments, and the result has the same, imprecise, representation. In comparisons, arguments that differ in type are first converted to the *most* precise representation of the two arguments."). In some sense (although I don't believe this) you might be able to argue that CLtL's decision made the language "simpler", (although it certainly made the results of some of the numeric functions more "surprising"). If it isn't too late, maybe the coercion rule could be changed in the "cleaned up Common Lisp". (Unless someone knows of equally bizarre results of *that* coercion rule.) Leave things the way they are. You're trying to give too much meaning to something which only derives its meaning from the way it is being used. In normal situations, things behave about how you'd expect them to. It is only when you get into the noise that things fall apart, because the multiple interpretations are no longer distinct. In those cases, I say it is an error to write something like (< x rational), and that you have no right to expect something like transitivity to hold because you're mixing definitions. If you want to say <, then do the coercions yourself in the way appropriate to what your working on. Rationals aren't necessarily any more exact than floating point. If you're computing rationals, then they're exact, but if you're computing reals, then they're no more exact than floating point. What if someone is trying to say (< x (sqrt 2))? Unless they are doing their own coercions (or squaring x) I think there's always going to be some form of default coercion which will do the "unexpected" for them.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 14:56:43 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 11:37:37 PST Received: by navajo.stanford.edu; Thu, 26 Mar 87 11:35:52 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA20846; Thu, 26 Mar 87 11:13:38 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA11270; Thu, 26 Mar 87 11:10:18 PST Date: Thu, 26 Mar 87 11:10:18 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8703261910.AA11270@bhopal.edsel.com> To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!Common-Lisp%sail@navajo.stanford.edu, navajo!Numerics%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu, navajo!fateman%mike.Berkeley.EDU.navajo!gls%Think.COM@navajo.stanford.edu In-Reply-To: David A. Moon's message of Thu, 26 Mar 87 00:59 EST Subject: Numerical Comparison: "required coercions" Having spoken with a number of Lisp users (as opposed to implementors), the overwhelming consensus appears to be that "=" must act like a transitive operation. I should think that this statement alone would be sufficient to clarify sections 12.1 to 12.4 of CLtL. Thus the phrase "required coercions" would have to take on a context-sensitive interpretation -- certain kinds of coercions are required when doing comparisons, others are required when doing operations like addition and multiplication. I don't propose to fix up the inherent non-associativity of floating-point addition and multiplication; this "feature" is a consequence of truncating information (i.e., "rounding" by whatever rule) in order to return a result in the required format. Note, however, that the comparison functions return a boolean value -- not a floating-point value -- and hence aren't subject to the same problems. So I would think that differing kinds of coercions between the two kinds of operations wouldn't violate reasonable expectations. You're quite right that if IEEE specifies what to do when comparing floats of differing precisions (e.g., single-float with double-float) then we ought to go for that. I don't know what it says. How about it Richard J. Fateman, you usually know about these matters? -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 14:56:03 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 11:36:58 PST Received: by navajo.stanford.edu; Thu, 26 Mar 87 11:35:15 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA20788; Thu, 26 Mar 87 10:54:27 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA11230; Thu, 26 Mar 87 10:51:09 PST Date: Thu, 26 Mar 87 10:51:09 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8703261851.AA11230@bhopal.edsel.com> To: navajo!barmar%Think.COM@navajo.stanford.edu Cc: navajo!STEVER%OZ.AI.MIT.EDU%xx.lcs.mit.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: Barry Margolin's message of Thu, 26 Mar 87 00:44 EST Subject: Free variables in a LAMBDA which names a function Re: This would be OK in a dynamically-scoped Lisp (in fact, I believe the Maclisp compiler did exactly this), but not in Common Lisp. Your definition should be equivalent to . . . No, MacLisp never yanked internal lambda applications out of lexical environment -- both it and Interlisp "did the right thing" in the case of a function like: (defun foo (arg) ((lambda (x) (+ x arg)) 5)) Probably you are remembering how both MacLisp and Interlisp would yank an #'(lambda (x) ...) out of lexical context, and make it into a defun with gensym'd name. A point not sufficiently appreciated is that both MacLisp and Common Lisp are *both* lexically and dynamically scoped. For MacLisp, you will find that: (1) had a bug in the interpreter in that local variables weren't treated lexically, as they were by the compiler. (2) couldn't handle lexical functions at all. [Note how "lexical functions" differs from "lambda form applications"]. CLtL Chapter 3 is an excellent treatise on the issue of scope -- I highly recommend re-reading it for anyone who hasn't done so recently. (1) was a persistent misfeature of MacLisp, which everyone adjusted to with some amount of grumbling. Interestingly, Interlisp considered (1) to be a major feature, and its compiler was modified to match! (2) was addressed by the Scheme papers. This, in fact, is probably the most innovative feature of Common Lisp that didn't originate from either MacLisp or ZetaLisp [although VAX/NIL made a stab at implementing something like it]. Giving up any closure over dynamic variables was an aggressive step back then. Full closure over the environment (both lexical and dynamic) required "spaghetti stacks" -- see paper by Dan Bobrow circa 1974. ZetaLisp and NIL had the notion of limited dynamic closures, but these seemed to require "hard" implementation techniques for limited advantage over simply "lexical closures". -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 14:52:39 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 11:35:20 PST Received: by navajo.stanford.edu; Thu, 26 Mar 87 11:34:05 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA20686; Thu, 26 Mar 87 10:23:41 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA11122; Thu, 26 Mar 87 10:20:22 PST Date: Thu, 26 Mar 87 10:20:22 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8703261820.AA11122@bhopal.edsel.com> To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu Cc: navajo!gls%THINK.COM@navajo.stanford.edu, navajo!common-lisp%SAIL@navajo.stanford.edu In-Reply-To: "Scott E. Fahlman"'s message of Wed, 25 Mar 1987 20:03 EST Subject: Extension to MAP [if the shoe doesn't fit?] How about, if the first arg to MAP is an integer, it specifies which argument should be clobbered? This doesn't allow an unrelated sequence to be be clobbered, of course, but it does allow the common case of an in-place MAP operation. This is a joke, right? There are a number of places where the sequence functions are like a size 15 shoe -- it just doesn't quite fit a lumber jack, and is too non-specific for a ballerina. Could I suggest that these "complaints" be considered evidence for the need of a simple iteration paradigm? Each man can then cobble his own shoe and wear it. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 14:11:03 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 10:48:38 PST Received: from SWALLOW.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70790; Thu 26-Mar-87 13:34:59 EST Date: Thu, 26 Mar 87 13:34 EST From: Michael Greenwald Subject: Numerical Comparison: "required coercions" To: DCP@QUABBIN.SCRC.Symbolics.COM, gls@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <870326104752.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Message-ID: <870326133440.1.GREENWALD@SWALLOW.S4CC.Symbolics.COM> Date: Thu, 26 Mar 87 10:47 EST From: David C. Plummer Date: Thu, 26 Mar 87 10:29 EST From: Guy Steele This issue makes me want to restate an earlier proposed model for the comparison functions: (? x1 x2 x3 x4 ... xn-1 xn) <=> (AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn) (? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn) (? x3 x4) ... (? x3 xn-1) (? x3 xn) . . . . . (? xn-1 xn)) where "?" may be =, /=, <, >, <=, or >=. That is, in principle every pair of arguments is compared. This is the model that justifies the "all different" interpretation for /=, and it is recognized that in practice the other five operations may be implemented cleverly through exploitation of transitivity. Well, maybe such reliance on transitivity is wrong. Why "maybe"? (<= 1234d10 12340000000001 1234e10 12340000000000) => T when you depend on transitivity, but should => NIL according to the above model. On the other hand, SORT clearly depends on transitivity, and one might reasonably expect (APPLY '<= (SORT SEQUENCE '<=)) => T. (Or even more reasonably (APPLY '< (SORT SEQUENCE '<)) => T, which unfortunately isn't true since (SORT '(1234d10 12340000000001 1234e10 12340000000000) '<) returns the original sequence.) I'm a fan of transitivity and also recognize this problem. If this is n^2 computation is to be the law-of-the-land for the non /= cases, I would suggest a declaration that tells the compiler that the user is guaranteeing transitivity so that only a linear number of comparisons is needed. The declaration is unnecessary, (although might be useful), since the check for whether transitivity will work can be done in linear time. (This same strategy reduces /= to NlogN for cases where transitivity holds, and all the elements are orderable by sorting the numbers and then only comparing adjacent elements. This doesn't work if any coercions could lose precision. (This works for complex numbers, too)) In practice, our implementation assumes transitivity holds, except in /=, where we are more scrupulous. All these anomolies are solved by coercing to the *most* exact representation for comparisons. I'm assuming that the floating-point contagion rule was mandated for two reasons: (1) It is misleading to *add* bits of precision during a computation. (although this is belied by the single-to-double conversion rule) (2) Floats put a stricter upper bound on the required storage than do the corresponding rationals and bignums. Both of these rules are more applicable for computations (+, -, etc.) than for comparisons. CLtL chose a single coercion rule ("WhenEVER a rational meets a floating point number, the rational is first converted to a floating-point number of the same format") rather than two coercion rules ("In computations that produce new values, the arguments are first coerced to the least precise representation of the two arguments, and the result has the same, imprecise, representation. In comparisons, arguments that differ in type are first converted to the *most* precise representation of the two arguments."). In some sense (although I don't believe this) you might be able to argue that CLtL's decision made the language "simpler", (although it certainly made the results of some of the numeric functions more "surprising"). If it isn't too late, maybe the coercion rule could be changed in the "cleaned up Common Lisp". (Unless someone knows of equally bizarre results of *that* coercion rule.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 11:24:10 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 08:06:12 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70702; Thu 26-Mar-87 10:44:42 EST Date: Thu, 26 Mar 87 10:47 EST From: David C. Plummer Subject: Numerical Comparison: "required coercions" To: Guy Steele , Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <870326102911.2.GLS@THOREAU.THINK.COM> Message-ID: <870326104752.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Thu, 26 Mar 87 10:29 EST From: Guy Steele This issue makes me want to restate an earlier proposed model for the comparison functions: (? x1 x2 x3 x4 ... xn-1 xn) <=> (AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn) (? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn) (? x3 x4) ... (? x3 xn-1) (? x3 xn) . . . . . (? xn-1 xn)) where "?" may be =, /=, <, >, <=, or >=. That is, in principle every pair of arguments is compared. This is the model that justifies the "all different" interpretation for /=, and it is recognized that in practice the other five operations may be implemented cleverly through exploitation of transitivity. Well, maybe such reliance on transitivity is wrong. I'm a fan of transitivity and also recognize this problem. If this is n^2 computation is to be the law-of-the-land for the non /= cases, I would suggest a declaration that tells the compiler that the user is guaranteeing transitivity so that only a linear number of comparisons is needed.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 10:43:16 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Mar 87 07:28:50 PST Received: from thoreau by Think.COM via CHAOS; Thu, 26 Mar 87 10:28:42 EST Date: Thu, 26 Mar 87 10:29 EST From: Guy Steele Subject: Numerical Comparison: "required coercions" To: Moon@stony-brook.scrc.symbolics.com, Common-Lisp@sail.stanford.edu Cc: Numerics@stony-brook.scrc.symbolics.com, gls@think.com In-Reply-To: <870326005921.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <870326102911.2.GLS@THOREAU.THINK.COM> This issue makes me want to restate an earlier proposed model for the comparison functions: (? x1 x2 x3 x4 ... xn-1 xn) <=> (AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn) (? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn) (? x3 x4) ... (? x3 xn-1) (? x3 xn) . . . . . (? xn-1 xn)) where "?" may be =, /=, <, >, <=, or >=. That is, in principle every pair of arguments is compared. This is the model that justifies the "all different" interpretation for /=, and it is recognized that in practice the other five operations may be implemented cleverly through exploitation of transitivity. Well, maybe such reliance on transitivity is wrong. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 10:01:50 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Mar 87 06:48:48 PST Received: from thoreau by Think.COM via CHAOS; Thu, 26 Mar 87 09:48:26 EST Date: Thu, 26 Mar 87 09:48 EST From: Guy Steele Subject: Replies to Extension to MAP To: Fahlman@c.cs.cmu.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: Message-Id: <870326094855.1.GLS@THOREAU.THINK.COM> Date: Wed, 25 Mar 1987 20:03 EST From: "Scott E. Fahlman" How about, if the first arg to MAP is an integer, it specifies which argument should be clobbered? This doesn't allow an unrelated sequence to be be clobbered, of course, but it does allow the common case of an in-place MAP operation. ... --Quux This is a joke, right? (defmacro --Quux () ':-) ... The idea of extending MAP in a compatible way was cute, but dangerous: it is usually a mistake to overload the same function to do two fundamentally different things depending on some subtle type distinction. If you want a destructive operation, you should ask for it by name. Then if a sequence gets clobbered mysteriously, you have some hope of finding the code responsible. "The jam so disgusting, you can't say it on television. Ask for it by name!" -- Fluckers Jam Commercial, Saturday Night Live  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 06:15:40 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Mar 87 03:01:22 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184420; Thu 26-Mar-87 05:57:35 EST Date: Thu, 26 Mar 87 05:57 EST From: Robert W. Kerns Subject: Free variables in a LAMBDA which names a function To: Barry Margolin cc: Stephen E. Robbins , common-lisp@sail.stanford.edu In-Reply-To: <870326004412.0.BARMAR@UBALDO.THINK.COM> Supersedes: <870326055657.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <870326055735.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 26 Mar 87 00:44 EST From: Barry Margolin My guess is that the compiler you are testing translated the definition into: (defun foo (arg) (#:gensym 5)) (defun #:gensym (x) (+ x arg)) This would be OK in a dynamically-scoped Lisp (in fact, I believe the Maclisp compiler did exactly this), but not in Common Lisp. Your definition should be equivalent to I don't know of any compiler which did this. Maclisp's LET was a macro (at least initially) that turned into LAMBDA in the functional position like this; in other words, this was Maclisp's ONLY way to get lexical variables other than arguments in the argument list. Maclisp did do something similar to what you describe when the lambda was not in the functional position; i.e. when you passed it as an argument. This meant you would have had to declare ARG special to get the intended behaviour, and no compiler warning about ARG appearing free inside the LAMBDA.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 06:13:19 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Mar 87 02:59:41 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184419; Thu 26-Mar-87 05:56:59 EST Date: Thu, 26 Mar 87 05:56 EST From: Robert W. Kerns Subject: Free variables in a LAMBDA which names a function To: Barry Margolin cc: Stephen E. Robbins , common-lisp@sail.stanford.edu In-Reply-To: <870326004412.0.BARMAR@UBALDO.THINK.COM> Message-ID: <870326055657.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 26 Mar 87 00:44 EST From: Barry Margolin My guess is that the compiler you are testing translated the definition into: (defun foo (arg) (#:gensym 5)) (defun #:gensym (x) (+ x arg)) This would be OK in a dynamically-scoped Lisp (in fact, I believe the Maclisp compiler did exactly this), but not in Common Lisp. Your definition should be equivalent to I don't know of any compiler which did this. Maclisp's LET was a macro (at least initially) that turned into LAMBDA in the functional position like this; in other words, this was Maclisp's ONLY way to get lexical variables other than arguments in the argument list. Maclisp did do something similar to what you describe when the lambda was not in the functional position; i.e. when you passed it as an argument. This meant you would have had to declare ARG special to get the intended behaviour.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 01:23:42 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Mar 87 22:01:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 101668; Thu 26-Mar-87 00:59:44 EST Date: Thu, 26 Mar 87 00:59 EST From: David A. Moon Subject: Numerical Comparison: "required coercions" To: Common-Lisp@sail.stanford.edu cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <8703252252.AA09954@bhopal.edsel.com> Message-ID: <870326005921.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 25 Mar 87 14:52:35 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Section 12.3 of CLtL, when speaking of the numerical comparison functions -- =, /=, <, etc. -- says that each one works on all types of numbers (unless otherwise indicated), and that any "required coercions" are performed when the arguments are of different type. This part of the book is particularly unclear, but since pages 196 and 199 both use the same "required coercions" phrase I think they must both be referring to the coercions described in section 12.1. .... Wouldn't it make more sense to consider the phrase "required coercions" to mean that when a rational is compared to a float, it is the float that is "coerced" rather than the rational? Offhand it seems like it would make more sense. I would certainly feel better if Common Lisp's = and EQUALP functions were transitive. But I think CLtL as currently written could only be saying that the rule of floating-point contagion is to be followed, the opposite of your suggestion. In short, I don't think the original intent was that "=" be a "fuzzy" operation. Rather it should be mathematically consistent, even if the interpretation of "precision" for floating-point numbers is open to question. Well, it's pretty clear that the original intent wasn't as fully thought-out as we would like! Do you propose that = of two floating-point numbers of different precision use the longer of the two precisions (which appears to be what CLtL prescribes), or use the shorter of the two precisions (which would cause fewer surprises to people who don't really understand what floating-point is and is not)? May I suggest writing this proposal up more formally and running it through the X3J13 cleanup subcommittee? That seems like a good way to ensure that all the ramifications get considered. The IEEE floating-point standard may speak to mixed-mode and mixed-precision comparisons; I don't know about that, but if it does, Common Lisp ought to follow it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 01:01:05 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Mar 87 21:43:39 PST Received: from ubaldo by Think.COM via CHAOS; Thu, 26 Mar 87 00:43:39 EST Date: Thu, 26 Mar 87 00:44 EST From: Barry Margolin Subject: Free variables in a LAMBDA which names a function To: Stephen E. Robbins Cc: common-lisp@sail.stanford.edu In-Reply-To: <8703260503.AA02722@Think.COM> Message-Id: <870326004412.0.BARMAR@UBALDO.THINK.COM> Date: Thu 26 Mar 87 00:01-EST From: "Stephen E. Robbins" Section 5.2 of CLtL point out that there's a distinction between (LAMBDA ...) as a way of \naming/ a function, and as a function object. What are the semantics of a free variable within a LAMBDA which merely \names/ a function? For example: (defun foo (arg) ((lambda (x) (+ x arg)) 5)) I would expect: (setf arg 16) (foo 3) ==> 8 I'm using a beta test of a Common Lisp which returns 21 as the result of that (foo 3). Looking through CLtL, I see nothing that implies that (lambda ...) in the functional position of a form has its free variables interpreted lexically, rather than dynamically. 8 is the correct result. Function parameters have lexical scope, so the scope of the "arg" parameter is the entire body of the function. There is nothing in CLtL that says that lexical scope "skips over" embedded lambda expressions. My guess is that the compiler you are testing translated the definition into: (defun foo (arg) (#:gensym 5)) (defun #:gensym (x) (+ x arg)) This would be OK in a dynamically-scoped Lisp (in fact, I believe the Maclisp compiler did exactly this), but not in Common Lisp. Your definition should be equivalent to (defun foo (arg) (flet ((#:gensyn (x) (+ x arg))) (#:gensym 5))) You should also get the result 8 in a dynamically-scoped Lisp, or in Common Lisp if arg is proclaimed special. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 00:40:26 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 21:24:18 PST Date: Thu, 26 Mar 1987 00:24 EST Message-ID: From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "Stephen E. Robbins" Cc: common-lisp@SAIL.STANFORD.EDU Subject: Free variables in a LAMBDA which names a function In-reply-to: Msg of 26 Mar 1987 00:01-EST from Stephen E. Robbins (defun foo (arg) ((lambda (x) (+ x arg)) 5)) I would expect: (setf arg 16) (foo 3) ==> 8 That is correct. `arg' is lexically scoped. Except for declaration handling you can treat an expression with a lambda, of a fixed number of arguments, in the functional position as if it were the obvious expansion of a let expression (or vice versa). Declarations (especially special declarations) screw up this simple model however.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Mar 87 00:20:19 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 21:01:39 PST Date: Thu 26 Mar 87 00:01-EST From: "Stephen E. Robbins" Subject: Free variables in a LAMBDA which names a function To: common-lisp@SAIL.STANFORD.EDU Section 5.2 of CLtL point out that there's a distinction between (LAMBDA ...) as a way of \naming/ a function, and as a function object. What are the semantics of a free variable within a LAMBDA which merely \names/ a function? For example: (defun foo (arg) ((lambda (x) (+ x arg)) 5)) I would expect: (setf arg 16) (foo 3) ==> 8 I'm using a beta test of a Common Lisp which returns 21 as the result of that (foo 3). Looking through CLtL, I see nothing that implies that (lambda ...) in the functional position of a form has its free variables interpreted lexically, rather than dynamically. Am I overlooking something? Is it reasonable to expect (foo 3) to return 8, or am I depending on coincidence... [This question arose when trying out the Common Lisp version of LOOP which GSB passed on to me a few weeks back. That LOOP expands into expressions which require that free variables in initial lambdas be lexically scoped] - Steve  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 23:48:12 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 20:29:51 PST Received: ID ; Wed 25 Mar 87 23:30:05-EST Date: Wed, 25 Mar 1987 23:30 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: VERACSD@A.ISI.EDU Cc: common-lisp@SAIL.STANFORD.EDU Subject: More on MAP In-reply-to: Msg of 25 Mar 1987 22:37-EST from VERACSD at A.ISI.EDU 4) Perhaps I am putting my foot in my mouth (again), but I question whether > it is trivial to define a macro to do the job of the proposed extension. I imagine Fahlman is thinking of something like '(replace ,seq (map (type-of ,seq) ,fn ,@sequences), but the point of the extension was to have a function which accomplishes this without the extra time and space of consing and the time of replacing. No, I was imagining a macro that would expand into a do-loop that wouldn't cons. It could use ELT and SETF of ELT if you want it to apply to all kinds of sequences. Why don't you write what you think is the right thing -- NMAP or whatever -- in portable Common Lisp, pass the code out, and see if it becomes popular enough that we should consider adding it to the base language. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 23:04:36 EST Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 19:37:28 PST Date: 25 Mar 1987 22:37-EST Sender: VERACSD@A.ISI.EDU Subject: More on MAP From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU Message-ID: <[A.ISI.EDU]25-Mar-87 22:37:15.VERACSD> Apropos Scott Fahlman's remarks: 1) I trust Guy Steele was indeed joking in proposing that > if the first arg to MAP is an integer, it specifies which argument > should be clobbered 2) > If you want a destructive operation, you should ask for it by name. This is reasonable enough. "Samalone", in fact, proposes NMAP. 3) But > it is usually a mistake to overload the same function to do two > fundamentally different things depending on some subtle type > distinction I buy this in general, but wonder about its application to this case, since a) how fundamentally different or subtle is it really, b) MAP already does two different things, when given NIL and when given a (non-NIL) type specifier, and c) it's basically the overloading of NIL and certain other (type-specifying) sequences that caused the original proposal to fail. 4) Perhaps I am putting my foot in my mouth (again), but I question whether > it is trivial to define a macro to do the job of the proposed extension. I imagine Fahlman is thinking of something like '(replace ,seq (map (type-of ,seq) ,fn ,@sequences), but the point of the extension was to have a function which accomplishes this without the extra time and space of consing and the time of replacing. 5) How about NMAP, anyway? Bob Sasseen veracsd.rs@a.isi.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 22:52:49 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 19:31:21 PST Received: from UCBVAX.Berkeley.EDU by navajo.stanford.edu with TCP; Wed, 25 Mar 87 19:29:28 PST Received: by ucbvax.Berkeley.EDU (5.57/1.23) id AA06689; Wed, 25 Mar 87 17:35:13 PST Received: by mike (3.2/5.17) id AA05122; Wed, 25 Mar 87 17:34:29 PST Date: Wed, 25 Mar 87 17:34:29 PST From: fateman@mike.berkeley.edu (Richard Fateman) Message-Id: <8703260134.AA05122@mike> To: edsel!bhopal!jonl@navajo.stanford.edu, navajo!Common-Lisp%su-ai@navajo.stanford.edu Subject: Re: Numerical Comparison: "required coercions" yep.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 20:25:43 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 17:02:29 PST Received: ID ; Wed 25 Mar 87 20:03:13-EST Date: Wed, 25 Mar 1987 20:03 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SAIL.STANFORD.EDU Subject: Replies to Extension to MAP In-reply-to: Msg of 25 Mar 1987 16:20-EST from Guy Steele How about, if the first arg to MAP is an integer, it specifies which argument should be clobbered? This doesn't allow an unrelated sequence to be be clobbered, of course, but it does allow the common case of an in-place MAP operation. This is a joke, right? If people really want a form that works like MAP but is destructive of one of the sequences, it is trivial to define a macro to do the job. If people really think that this is so useful that we need to add it to Common Lisp, the right way to do this is to define some new function, with a new name, that does this job. The idea of extending MAP in a compatible way was cute, but dangerous: it is usually a mistake to overload the same function to do two fundamentally different things depending on some subtle type distinction. If you want a destructive operation, you should ask for it by name. Then if a sequence gets clobbered mysteriously, you have some hope of finding the code responsible. Since the original MAP proposal turned out to be unworkable, I think it is best to let it die rather than trying think up even more subtle ways to sneak this behavior into MAP. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 18:22:32 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 14:57:23 PST Received: by navajo.stanford.edu; Wed, 25 Mar 87 14:55:24 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA16972; Wed, 25 Mar 87 14:55:53 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA09954; Wed, 25 Mar 87 14:52:35 PST Date: Wed, 25 Mar 87 14:52:35 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8703252252.AA09954@bhopal.edsel.com> To: navajo!Common-Lisp%su-ai@navajo.stanford.edu Subject: Numerical Comparison: "required coercions" Section 12.3 of CLtL, when speaking of the numerical comparison functions -- =, /=, <, etc. -- says that each one works on all types of numbers (unless otherwise indicated), and that any "required coercions" are performed when the arguments are of different type. Which kind of coercion is appropriate for the following: (= 314159265358979383256 ;about 20 digits of pi, as integer 3.1415925E20 ; pi * 1.0E20, off by one lsb maybe 314159265358979383250 ;a different "20 digits" of pi ) ?? Some implementations I've looked at appear to do the coercion by the usual rule of float-contagion. I believe this to be sub-optimal in that it prevents "=" from being a transitive operation (because floating the two integers above will typically "lose" information). Wouldn't it make more sense to consider the phrase "required coercions" to mean that when a rational is compared to a float, it is the float that is "coerced" rather than the rational? In short, I don't think the original intent was that "=" be a "fuzzy" operation. Rather it should be mathematically consistent, even if the interpretation of "precision" for floating-point numbers is open to question. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 17:42:04 EST Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 14:26:30 PST Received: by ATHENA (5.45/4.7) id AA19099; Wed, 25 Mar 87 17:14:54 EST From: Received: by HADES (5.45/4.7) id AA20554; Wed, 25 Mar 87 17:13:33 EST Message-Id: <8703252213.AA20554@HADES> To: common-lisp@sail.stanford.edu Subject: Extension to MAP Date: Wed, 25 Mar 87 17:13:32 EST Why not just define a new function, NMAP, which takes as its first argument a sequence to be modified instead of a type specifier? Or am I spoiling your fun? --SAM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Mar 87 16:38:41 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Mar 87 13:21:06 PST Received: from falling-star by Think.COM via CHAOS; Wed, 25 Mar 87 16:20:23 EST Date: Wed, 25 Mar 87 16:20 EST From: Guy Steele Subject: Replies to Extension to MAP To: VERACSD@a.isi.edu, common-lisp@sail.stanford.edu Cc: moon@scrc-stony-brook.arpa, rwk@scrc-yukon.arpa, barmar@think.com, vrotney@venera.isi.edu, norvig%cogsci.berkeley.edu@ucbvax.berkeley.edu, gls@think.com In-Reply-To: <[A.ISI.EDU]23-Mar-87 14:45:49.VERACSD> Message-Id: <870325162049.3.GLS@FALLING-STAR.THINK.COM> I really shouldn't, but I will... How about, if the first arg to MAP is an integer, it specifies which argument should be clobbered? This doesn't allow an unrelated sequence to be be clobbered, of course, but it does allow the common case of an in-place MAP operation. (MAP 1 FN SEQ1 SEQ2) ;clobbers SEQ1 with answers (MAP 2 FN SEQ1 SEQ2) ;clobbers SEQ2 with answers --Quux  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Mar 87 17:58:25 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Mar 87 14:37:37 PST Received: ID ; Tue 24 Mar 87 17:38:15-EST Date: Tue, 24 Mar 1987 17:38 EST Message-ID: From: Rob MacLachlan To: Pavel.pa@XEROX.COM Cc: Common-Lisp@SAIL.STANFORD.EDU Subject: (THE (VALUES ...) ...) with &KEY In-reply-to: Msg of 24 Mar 1987 00:11-EST from Pavel.pa at Xerox.COM In the context of FUNCTION types, these issues are discussed in the cleanup list circulated by Guy way back when. He proposed that keyword arguments be represented by a 2list of the keyword and the type, and that the type specified for a rest arg would be the type of the additional arguments rather than of the rest arg itself. It is an open question whether we really want all this hair in the VALUES type spec, but CLTL currently seems suggest that it is the same as the FUNCTION type spec. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Mar 87 00:25:05 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Mar 87 21:11:13 PST Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 87 21:11:57 PST Date: 23 Mar 87 21:11 PST From: Pavel.pa@Xerox.COM Subject: (THE (VALUES ...) ...) with &KEY To: Common-Lisp@Sail.Stanford.Edu Message-ID: <870323-211157-1162@Xerox> CLtL, on page 48, says, in reference to the VALUES type specifier, ``The &OPTIONAL, &REST, and &KEY markers may appear in the value-type list; they thereby indicate the parameter list of a function that, when given to MULTIPLE-VALUE-CALL along with the values, would be suitable to receiving those values.'' I assume from this that the following form is legal and specifies that it is an error for FOO to return less than 3 values, the first of which should be an integer and the second of which should be a float: (the (values integer &optional float &rest cons) (foo)) The insistence on three or more values comes from the requirement that the &REST list be of type CONS; if fewer values were returned, it would be NIL, not a cons-cell. Thus, the &optional in this case is superfluous. I would also guess that this next form requires BAR to return either one or two values, the first of which must be a string and the second of which, if provided, must be an array: (the (values string &optional array) (bar)) I am at a loss, however, to figure out how to use the &KEY keyword. What is the right syntax for invoking this arcane feature? Perhaps each keyword ``parameter'' should be a list of two elements, a symbol naming the appropriate keyword and the type the corresponding value should have? This seems reasonable (at least relative to the whole notion being reasonable), but none of the implementations I've tried understand any of the lambda-list keywords, let alone &KEY... Does anyone implement this? Does anyone (shudder) use it? Could we just eliminate it from the language? Cleanup committee, are you listening? Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Mar 87 15:07:21 EST Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 11:45:49 PST Date: 23 Mar 1987 14:45-EST Sender: VERACSD@A.ISI.EDU Subject: Replies to Extension to MAP From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: moon@SCRC-STONY-BROOK.ARPA Cc: rwk@SCRC-YUKON.ARPA Cc: barmar@THINK.COM Cc: vrotney@VENERA.ISI.EDU Cc: veracsd@A.ISI.EDU Cc: norvig%cogsci.berkeley.edu@UCBVAX.BERKELEY.EDU Message-ID: <[A.ISI.EDU]23-Mar-87 14:45:49.VERACSD> Thanks for the replies to my suggestion that MAP be extended to take a first arg of a sequence which would be FILLed with the results of the MAPping. Moon is right that a first arg of () would be ambiguous since it could be interpreted either as a zero-length sequence, or NIL specifying to do the mapping but return no results. Kerns and Margolin are right that a first arg such as (ARRAY T) would also be ambiguous because it could be interpreted either as a sequence to be filled or as a type specifier for a new sequence. Kerns seems to be right that these are fatal flaws, the essential problem being that some sequences already have meaning as the first arg MAP. The feature would be nice to have but at the moment I can't see any way to overcome this problem (which I really shouldn't have had to have pointed out to me). Vrotney misinterpreted what I was intending the extension to accomplish. What he suggests can be achieved without much extra trouble by saying (MAP (TYPE-OF seq) FN ... ), especially if TYPE-OF is as specific as possible. Bob Sasseen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Mar 87 13:41:14 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Mar 87 10:05:31 PST Received: from relay2.cs.net by RELAY.CS.NET id aa13137; 23 Mar 87 12:51 EST Received: from sp.unisys.com by RELAY.CS.NET id aa11418; 23 Mar 87 12:47 EST Date: Mon, 23 Mar 87 08:47 CST From: Jim Hassett To: common-lisp@SAIL.STANFORD.EDU Subject: Extension to MAP X-VMS-To: IN%"common-lisp@sail.stanford.edu" Date: Sat, 21 Mar 87 15:42 EST From: Barry Margolin Date: 20 Mar 1987 16:24-EST From: VERACSD@a.isi.edu I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. Unfortunately, MAP already has a defined meaning when its first argument is a sequence, because a list is a sequence and there are type specifiers that are lists. Right. We can't allow another interpretation for something that might be a type specifier. From: vrotney@venera.isi.edu Date: Sat, 21 Mar 87 15:56:37 PDT CLTL states that the first argument to MAP must be NIL or a subtype of sequence. Propose we extend so that if the first argument is anything else then the result type is of the type of the first sequence. In particular, (map t function seq1 ...) => would give you your desired effect. One problem here is that T is a type specifier (though it does not specify a subtype of SEQUENCE). A more serious problem is that it doesn't do what was originally desired: modify an existing sequence (or is it proposed to modify SEQ1?). Also, SEQ1 might not happen to be of the desired result type. One possible upward-compatible extension would be to allow the first argument to be a list of the form (onto ). There is no ambiguity since this is not a type specifier. In actual use, the backquote would be the most convenient means of constructing such a list: (map `(onto ,my-result-sequence) function seq1 ...) Jim Hassett  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Mar 87 23:27:02 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Mar 87 20:09:13 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 22 Mar 87 20:08:55 pst Received: by hplabsc ; Sun, 22 Mar 87 20:10:16 pst Date: Sun, 22 Mar 87 20:10:16 pst From: Jim Kempf Message-Id: <8703230410.AA13557@hplabsc> To: common-lisp@sail.stanford.edu, commonloops.pa@xerox.com Subject: Re: CommonObjects on CommonLoops As several people have noticed, it is not possible to get to /ja/guest/kempf/public via anonymous ftp. I have set up the COOL distribution so that it is in /pub/cool, rather than /ja/guest/kempf/public. If anybody has taken the cool.tar file which was in /pub, it contains the cool distribution in U*NX tar format, but it was not properly made so there may be trouble un-taring it. In any event, I would suggest if you have trouble, that you simply get the new distribution. Again, there are two subdirectories under /pub/cool-cool and pcl, containing, respectively, the COOL release and the 2/24/87 PCL release. The directory /pub/cool itself contains a README file. Thanks for your patience and I'm sorry for the confusion. Let us know how you're doing. Jim Kempf cool@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Mar 87 13:07:43 EST Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 22 Mar 87 09:54:06 PST Received: from epistemi.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa03737; 22 Mar 87 13:46 WET From: Robert Dale Date: Sun, 22 Mar 87 13:45:15 gmt Message-Id: <19382.8703221345@epistemi.ed.ac.uk> To: COMMON-LISP <@Cs.Ucl.AC.UK:COMMON-LISP@sail.stanford.edu> Subject: Request to be added to mailing list Please add me to your mailing list. Thanks Robert Dale University of Edinburgh, Centre for Cognitive Science, 2 Buccleuch Place, Edinburgh, EH8 9LW, Scotland. UUCP: ...!ukc!cstvax!epistemi!rda ARPA: rda%epistemi.ed.ac.uk@ucl.cs JANET: rda@uk.ac.ed.epistemi  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Mar 87 00:30:46 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 Mar 87 21:17:36 PST Received: from hplabsc by hplabs.HP.COM with TCP ; Sat, 21 Mar 87 21:17:27 pst Received: by hplabsc ; Sat, 21 Mar 87 21:19:15 pst Date: Sat, 21 Mar 87 21:19:15 pst From: Jim Kempf Message-Id: <8703220519.AA24502@hplabsc> To: common-lisp@sail.stanford.edu, commonloops.pa@xerox.com Subject: CommonObjects on CommonLoops ******* Announcing CommonObjects on CommonLoops ******* A portable implementation of HP's CommonObjects object-oriented programming language is now available. More information on CommonObjects semantics can be found in the article "CommonObjects: An Overview" by Alan Snyder in the October, 1986 issue of SIGPLAN Notices, or by mailing a request for the technical report ATC-85-1 to mingus@hplabs.hp.com CommonObjects on CommonLoops (COOL) uses the metaclass kernel of Portable CommonLoops (PCL) to implement 95% of CommonObjects functionality. Both COOL and PCL run embedded in Common Lisp. COOL is freely distributable and available via anonymous FTP from ingres.berkeley.edu. It is located in the directory /ja/guest/kempf/public/cool. Tests of COOL in HP Common Lisp (where it was developed) and Kyoto Common Lisp have been made, and it is designed to be as portable as PCL. Currently, COOL runs on the 2/24/87 release of PCL. In order to avoid software tracking problems, the release of PCL in which COOL runs will be distributed along with COOL. In the cool directory are two subdirectories, one containing the PCL source (pcl) and one containing the COOL source (cool). The (upper) cool directory also contains a README file describing how to build and use the system. The cool/cool directory, in addition to the COOL source, contains a series of regression tests and profiling tests. Please report any problems with COOL to cool@hplabs.hp.com. We are interested in any portability problems but cannot attempt to fix them unless we can either get access to a running system where the problem is occuring or get enough information that we can help a knowledgable Common Lisp programmer fix the problem.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Mar 87 19:08:24 EST Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Mar 87 15:55:53 PST Posted-Date: Sat, 21 Mar 87 15:56:37 PDT Received: from hpai00.isi.edu by venera.isi.edu (5.54/5.51) id AA07882; Sat, 21 Mar 87 15:56:39 PST Received: by hpai00 ; Sat, 21 Mar 87 15:56:47 pst From: vrotney@venera.isi.edu Message-Id: <8703212356.AA04228@hpai00> Date: Sat, 21 Mar 87 15:56:37 PDT Subject: Re: Extension to MAP To: common-lisp@sail.stanford.edu In-Reply-To: Your message of 20-Mar-87 16:24:00 X-Mailer: NMail [$Revision: 2.6 $] re: -------------------------------------------------------------------------------- Subject: Extension to MAP From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: veracsd.rs@A.ISI.EDU Message-Id: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD> I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. -------------------------------------------------------------------------------- This sounds like a good idea but your syntax might have problems. For example , a type specifier that is a subtype of type sequence might be (I can't show this) a list (CLTT p42) which is itself a sequence. One way to implement your idea would be to extend CLTL as follows: CLTL states that the first argument to MAP must be NIL or a subtype of sequence. Propose we extend so that if the first argument is anything else then the result type is of the type of the first sequence. In particular, (map t function seq1 ...) => would give you your desired effect. Bill Vrotney USC/ISI -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Mar 87 16:03:52 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 21 Mar 87 12:41:37 PST Received: from sebastian by Think.COM via CHAOS; Sat, 21 Mar 87 15:41:50 EST Date: Sat, 21 Mar 87 15:42 EST From: Barry Margolin Subject: Extension to MAP To: VERACSD@a.isi.edu Cc: common-lisp@sail.stanford.edu, veracsd.rs@a.isi.edu In-Reply-To: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD> Message-Id: <870321154234.3.BARMAR@SEBASTIAN.THINK.COM> Date: 20 Mar 1987 16:24-EST From: VERACSD@a.isi.edu I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. Unfortunately, MAP already has a defined meaning when its first argument is a sequence, because a list is a sequence and there are type specifiers that are lists. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Mar 87 04:57:43 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 21 Mar 87 01:47:01 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182092; Sat 21-Mar-87 04:47:04 EST Date: Sat, 21 Mar 87 04:47 EST From: Robert W. Kerns Subject: Extension to MAP To: David A. Moon cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU In-Reply-To: <870320170530.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870321044705.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Fri, 20 Mar 87 17:05 EST From: David A. Moon Date: 20 Mar 1987 16:24-EST From: VERACSD@A.ISI.EDU I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. The first N elements of the sequence would be modified where N is the min of the lengths of the argument sequences, (including the sequence passed as the first arg). This seems upward-compatible and easy to implement, and would be extremely handy. Any comments? It sounds like a good idea, but what if the sequence is () ? I'm not sure which objection you're making, so I'll clarify by generalizing it twice. 1) Generalize this to "What if the sequence is shorter than the number of times the mapped function would otherwise be called?" 2) Generalize this to "What if the sequence is (array t)?" The first interpretation is a trivial design decision, but the second is a fatal flaw in the scheme. I suspect this is really the point you were trying to make: some sequences already have meaning in that context.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Mar 87 18:30:27 EST Received: from [128.32.130.5] by SAIL.STANFORD.EDU with TCP; 20 Mar 87 15:13:33 PST Received: by cogsci.berkeley.edu (5.57/1.23) id AA11109; Fri, 20 Mar 87 15:14:07 PST Date: Fri, 20 Mar 87 15:14:07 PST From: norvig%cogsci.Berkeley.EDU@berkeley.edu (Peter Norvig) Message-Id: <8703202314.AA11109@cogsci.berkeley.edu> To: common-lisp@sail.stanford.edu Subject: Re: Extension to MAP Cc: moon@stony-brook.scrc.symbolics.com Date: 20 Mar 1987 16:24-EST From: VERACSD@A.ISI.EDU I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. Seems to me the answer is smarter compilers. Then the code could read: (replace seq1 (map (type-of seq1) fnc seq2)) and compile into the same thing as the proposed (map seq1 fnc seq2). Similarly, one could have (mapc f (mapcar g l1)) ==> (mapc #'(lambda (x) (funcall f (funcall g x))) l1) where the "==>" stands for "optimizes into". People expect such optimizations from APL or SetL compilers; why not from CommonLisp? I admit there are complications involving side effects and error signaling. For example, (first (mapcar #'not l)) ==> (not (first l)) but (first (mapcar #'print l)) ==> (unless (null l) (print (first l)) (mapc #'print (rest l))) and (dotimes (i 10000) (cons nil nil)) ==> nil would be valid most of the time, but not when you're trying to test the garbage collector.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Mar 87 17:44:25 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Mar 87 14:30:22 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98379; Fri 20-Mar-87 17:05:49 EST Date: Fri, 20 Mar 87 17:05 EST From: David A. Moon Subject: Extension to MAP To: VERACSD@A.ISI.EDU cc: common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU In-Reply-To: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD> Message-ID: <870320170530.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 20 Mar 1987 16:24-EST From: VERACSD@A.ISI.EDU I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. The first N elements of the sequence would be modified where N is the min of the lengths of the argument sequences, (including the sequence passed as the first arg). This seems upward-compatible and easy to implement, and would be extremely handy. Any comments? It sounds like a good idea, but what if the sequence is () ?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Mar 87 17:02:49 EST Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 13:24:07 PST Date: 20 Mar 1987 16:24-EST Sender: VERACSD@A.ISI.EDU Subject: Extension to MAP From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: veracsd.rs@A.ISI.EDU Message-ID: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD> I'd really like to see MAP take a sequence as its first argument, and have the results be put into that sequence. The first N elements of the sequence would be modified where N is the min of the lengths of the argument sequences, (including the sequence passed as the first arg). This seems upward-compatible and easy to implement, and would be extremely handy. Any comments? Bob Sasseen veracsd.rs  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Mar 87 23:29:35 EST Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87 20:15:14 PST Date: Tue 17 Mar 87 20:16:50-PST From: Sheri Markus Subject: please add me To: common-lisp@Sail.Stanford.EDU Message-ID: <12287260322.13.KVQJ@CSLI.Stanford.EDU> to your mail list. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Mar 87 19:31:06 EST Received: from USC-CSE.USC.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 16:00:55 PST Received: from cseb.usc.edu by usc-cse.usc.edu via TCP (4.12/S2.5) id AA25631; Tue, 10 Mar 87 15:18:09 pst Received: by cseb.usc.edu (4.12/C1.12) id AA04172; Tue, 10 Mar 87 14:47:54 pst Date: Tue, 10 Mar 87 14:47:54 pst From: yeung@cseb.usc.edu (Dit-Yan Yeung) Message-Id: <8703102247.AA04172@cseb.usc.edu> To: common-lisp@su-ai.arpa Subject: Mailing list Could you add me to the mailing list? Thanks, Dit-Yan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Mar 87 15:54:46 EST Received: from CS.COLUMBIA.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 12:20:33 PST Date: Tue 10 Mar 87 15:19:44-EST From: John C. Akbari Subject: please add me To: works-request@RUTGERS.RUTGERS.EDU, cl-windows@SAIL.STANFORD.EDU, common-lisp@SAIL.STANFORD.EDU Message-ID: <12285338462.45.AKBARI@CS.COLUMBIA.EDU> to your list. ad...THANKS...vance! john c akbari ARPANET & Internet akbari@CS.COLUMBIA.EDU BITnet akbari%CS.COLUMBIA.EDU@WISCVM.WISC.EDU uucp & usenet ...!seismo!columbia!cs!akbari DECnet akbari@cs PaperNet 380 riverside drive, no. 7d new york, new york 10025 usa SoundNet 212.662.2476 -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Mar 87 17:46:04 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Mar 87 14:24:49 PST Received: from Cabernet.ms by ArpaGateway.ms ; 08 MAR 87 14:25:25 PST Date: 8 Mar 87 14:23 PST From: vanMelle.pa@Xerox.COM Subject: Does *read-suppress* suppress list construction? To: Common-Lisp@SAIL.Stanford.edu Message-ID: <870308-142525-1326@Xerox> What, if anything, does CLtL require of the value returned from read when *read-suppress* is true? At a glance, I might assume that read should perform all the gross syntactic work of parsing an input, without creating symbols or causing errors, and return no meaningful result. Surely the result cannot be very meaningful if all tokens are uninterpreted. Yet on p346 it says "Note that, no matter what the value of *read-suppress*, parentheses still continue to delimit (and construct) lists; the #( construction continues to delimit vectors; and comments, strings, and the quote and backquote constructions continue to be interpreted properly." This suggests that read must still return a list structure where appropriate, even though it is full of nil tokens. I tried (let ((*read-suppress* t)) (read-from-string "(a b c)")) in 3 implementations. Vax Lisp and 3600 return (nil nil nil). Lucid returns nil. It's hard for me to imagine any good reason to require read to return anything meaningful when *read-suppress* is true. If it were required to, it would inhibit an efficient use of *read-suppress* for programs that simply want to skip over some input, even though they know (or expect) the input is completely legal.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Mar 87 20:51:46 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Mar 87 17:33:00 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87651; Sat 7-Mar-87 20:32:27 EST Date: Sat, 7 Mar 87 20:32 EST From: David A. Moon Subject: eval-when [former subject evalhook, eval-when] To: Rob MacLachlan cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870307203214.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 6 Mar 1987 13:24 EST From: Rob MacLachlan Now for EVAL-WHEN. The problem here is that the concepts of COMPILE, LOAD, and EVAL phases don't apply in an incrementally compiled Lisp - Yes, there are major problems with the specification of EVAL-WHEN. The compiler cleanup committee is currently working on this, but we probably can't offer a great deal of help since the only proposal that deals with these problems advocates flushing EVAL-WHEN and replacing it with new special forms. Although Moon presumably knows the ancestral meaning of EVAL-WHEN, In fact I was working from your proposal for the semantics of compilation when I said what I said (of course keeping the name EVAL-WHEN since we're discussing Common Lisp as it is today, not as it might be after it's cleaned up in various ways). In other words, the distinctive thing about COMPILE-FILE is early evaluation and late evaluation taking place in different Lisp worlds, not anything about representation of programs as executable machine instructions. I don't agree with his interpretation of it on the basis of dumping to files. The rules for evaluation should exist independently of any semantics of COMPILE-FILE. In general that's true, but certainly the rules for evaluating EVAL-WHEN are intimately connected with the semantics of COMPILE-FILE. My current opinion that there are only three EVAL-WHEN situation lists that can be used in portable code: (compile load eval) (load eval) (compile eval) The reason for this restriction is that other situation lists allow programs to "tell the difference" between a compiled and an interpreted implementation. Given that only these situation lists are used, a compile-only system can entirely ignore the EVAL situation, and interpret COMPILE as "do it now" and LOAD as "do it eventually." In any situation where the EVAL-WHEN body is not evaluated, the result of the EVAL-WHEN is NIL. I agree with this, for a strong definition of "portable code" as code that will execute identically in all implementations. A somewhat weaker, but still extremely useful, definition of "portable code" as code that will execute correctly in all implementations allows for other situation lists. For example, (eval-when (compile) ...) is a portable way to get a compile-time-only definition, in systems where that concept is meaningful; programs that use this can be written in such a way that they work correctly in all systems.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Mar 87 19:28:43 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 16:14:28 PST Received: ID ; Sat 7 Mar 87 19:14:17-EST Date: Sat, 7 Mar 1987 19:14 EST Message-ID: From: Rob MacLachlan To: Jeff Dalton Cc: common-lisp@SAIL.STANFORD.EDU, johnw%cvaxa.sussex.ac.uk@CS.UCL.AC.UK Subject: evalhook, eval-when In-reply-to: Msg of 7 Mar 1987 18:39-EST from Jeff Dalton Date: Saturday, 7 March 1987 18:39-EST From: Jeff Dalton To: johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK cc: common-lisp at sail.stanford.edu Re: evalhook, eval-when A key question here is whether Common Lisp requires that the environment obtained via the &ENV parameter of a macro can meaningfully be passed to EVALHOOK and vice-versa. The answer is no. See pp145-146 in CLTL in the discussion of the (omitted) &environment keyword. I believe PCL is no longer doing this, since it works on our system which uses a partial environment for macroexpansion. In any case, POPLOG Common Lisp might still have some use for hook functions. [...] As a user of POPLOG Common Lisp, I often wish there was a single stepper of some sort, even if it didn't see forms "smaller than function calls". Yes, evalhook is one way to implement a stepper. The question is whether providing a portable way to implement steppers is so important that we make life difficult for implementors by requiring it in Common Lisp. There is nothing to stop compile-only implementations from having steppers, but they probably aren't going to want to use evalhook to do it. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Mar 87 19:01:58 EST Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 7 Mar 87 15:43:59 PST Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa06844; 7 Mar 87 23:41 WET From: Jeff Dalton Date: Sat, 7 Mar 87 23:39:06 GMT Message-Id: <3064.8703072339@aiva.ed.ac.uk> To: johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK Subject: Re: evalhook, eval-when Cc: common-lisp@sail.stanford.edu Date: Wednesday, 4 March 1987 15:57-EST From: John Williams [...] I'm tempted to leave *EVALHOOK* and friends out of my Lisp (POPLOG Common Lisp) entirely, seeing as they are so obviously interpreter-oriented, but then people use them in software that's supposed to be portable, eg Portable Common Loops. A key question here is whether Common Lisp requires that the environment obtained via the &ENV parameter of a macro can meaningfully be passed to EVALHOOK and vice-versa. This seems to be what's going on in things like PCL. If this is allowed, then EVALHOOK still has a use of sorts even if hook functions per se are never called. Of course, we might also ask whether this *should* be allowed. In any case, POPLOG Common Lisp might still have some use for hook functions. While it would probably be going too far to compile a check along with each form, it might make sense to check on function calls. In some call implementations, this check could be in the "link" routine and hence wouldn't mean compiling extra code. As a user of POPLOG Common Lisp, I often wish there was a single stepper of some sort, even if it didn't see forms "smaller than function calls". Now for EVAL-WHEN. The problem here is that the concepts of COMPILE, LOAD, and EVAL phases don't apply in an incrementally compiled Lisp - POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT loop. The only distinction that can be sensibly made is between having a form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or 'in due course' (ie when it would have been executed in the normal course of events). Naively, I would expect the following interpretations of EVAL-WHEN "times" in a "compiling EVAL" Common Lisp: EVAL -- when a source file is being loaded. LOAD -- when a compiled file is being loaded. COMPILE -- when a file is being COMPILE-FILE'd That is, the compilation that goes on whenever EVAL is called doesn't in itself count as COMPILE-time. I think this means I agree with Moon -- this interpretation is the same as that for an "interpreting EVAL". So, in addition to the distinction between 'now' and 'in due course', we can distinguish between "'due course' means 'now'" (EVAL), and "'due course' means 'later'" (LOAD/COMPILE). From: Rob MacLachlan The rules for evaluation should exist independently of any semantics of COMPILE-FILE. While this seems right in general, the semantics of EVAL-WHEN might well be considered part of the semantics of COMPILE-FILE. The existence of COMPILER-LET, however, may cast doubt on the view that "evaluation times" make sense in a "compiling EVAL" system (or, as a consequence, in Common Lisp). If loading a source file is supposed to obtain the interpreter-like interpretation (sorry for this word over- loading), it seems that functions defined in this way and containing calls to COMPILER-LET would have to have the binding of the special variables in the COMPILER-LET put into their compiled code (as well as being bound during their compilation) while this should not happen if the functions were COMPILE-FILE'd. -- Jeff  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Mar 87 03:19:44 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 00:06:28 PST Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by navajo.stanford.edu with TCP; Sat, 7 Mar 87 00:03:18 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175102; Sat 7-Mar-87 02:57:39 EST Date: Sat, 7 Mar 87 02:57 EST From: Robert W. Kerns Subject: IMPORTations into keyword package To: Jon L White Cc: navajo!Common-Lisp%sail@navajo.stanford.edu In-Reply-To: <8703041559.AA01992@bhopal.edsel.com> Message-Id: <870307025732.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Wed, 4 Mar 87 07:59:14 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Does anyone have a need/opinion about the meaning of importing an "interned"symbol into the keyword package? ("interned" means already "homed" in some package, such as Lisp or User). CLtL, page 175 strongly suggests that "keywords" ought not to be imported into other packages ("keywords" means "present and owned by the keyword package"); but there is no suggestion about the other direction. Let's just make this "suggestion" symetric. I think this must have just been assumed, given that "whenever a symbol is added to the KEYWORD package the symbol is always made external; the symbol is also automatically declared to be a constant (see DEFCONSTANT) and made to have itself as its value."  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Mar 87 13:41:20 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Mar 87 10:24:44 PST Received: ID ; Fri 6 Mar 87 13:24:19-EST Date: Fri, 6 Mar 1987 13:24 EST Message-ID: From: Rob MacLachlan To: John Williams Cc: common-lisp@SAIL.STANFORD.EDU Subject: evalhook, eval-when In-reply-to: Msg of 4 Mar 1987 15:57-EST from John Williams Date: Wednesday, 4 March 1987 15:57-EST From: John Williams To: common-lisp at sail.stanford.edu Re: evalhook, eval-when [...] I'm tempted to leave *EVALHOOK* and friends out of my Lisp (POPLOG Common Lisp) entirely, seeing as they are so obviously interpreter-oriented, but then people use them in software that's supposed to be portable, eg Portable Common Loops. Since Common Lisp definitely allows compile-only implementations, it is entirely within your rights to fail to support evalhook. A strict interpretation might require the variables and functions to be defined, but they wouldn't have to do anything. For this reason, I think evalhook should be flushed from the language. Programs that require EVALHOOK are broken. Now for EVAL-WHEN. The problem here is that the concepts of COMPILE, LOAD, and EVAL phases don't apply in an incrementally compiled Lisp - POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT loop. The only distinction that can be sensibly made is between having a form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or 'in due course' (ie when it would have been executed in the normal course of events). Yes, there are major problems with the specification of EVAL-WHEN. The compiler cleanup committee is currently working on this, but we probably can't offer a great deal of help since the only proposal that deals with these problems advocates flushing EVAL-WHEN and replacing it with new special forms. Although Moon presumably knows the ancestral meaning of EVAL-WHEN, I don't agree with his interpretation of it on the basis of dumping to files. The rules for evaluation should exist independently of any semantics of COMPILE-FILE. My current opinion that there are only three EVAL-WHEN situation lists that can be used in portable code: (compile load eval) (load eval) (compile eval) The reason for this restriction is that other situation lists allow programs to "tell the difference" between a compiled and an interpreted implementation. Given that only these situation lists are used, a compile-only system can entirely ignore the EVAL situation, and interpret COMPILE as "do it now" and LOAD as "do it eventually." In any situation where the EVAL-WHEN body is not evaluated, the result of the EVAL-WHEN is NIL. If you believe my EVAL-WHEN rules, then both of your examples are incorrect, since the "eventual evaluation" of both EVAL-WHEN forms will be NIL, not a number. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Mar 87 18:26:54 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Mar 87 14:24:49 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 86002; Thu 5-Mar-87 16:55:42 EST Date: Thu, 5 Mar 87 16:54 EST From: David A. Moon Subject: evalhook, eval-when To: John Williams cc: common-lisp@sail.stanford.edu In-Reply-To: <14401.8703042057@cvaxa.sussex.ac.uk> Message-ID: <870305165452.3.MOON@EUPHRATES.SCRC.Symbolics.COM> When EVAL-WHEN refers to "compile", it means the translation of a source file into a binary file, rather than the conversion of list structures into machine language instructions. EVAL-WHEN has to do with the distinction between doing things in a file, which will later be loaded into some other Lisp world, and doing things in the current Lisp world. So I don't think your incrementally compilation technique affects EVAL-WHEN at all. I have no opinion on the *EVALHOOK* issue.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Mar 87 13:47:25 EST Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 5 Mar 87 10:33:18 PST Received: from ucl-cs-vax1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP id af10318; 5 Mar 87 18:03 WET Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK with SMTP id aa02689; 5 Mar 87 17:17 GMT Received: from cs.ucl.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000487; 5 Mar 87 17:12 GMT From: John Williams Date: Wed, 4 Mar 87 20:57:09 gmt Message-Id: <14401.8703042057@cvaxa.sussex.ac.uk> To: common-lisp@sail.stanford.edu Subject: evalhook, eval-when Can anyone help me with how *EVALHOOK* and EVAL-WHEN should operate in an incrementally compiled Common Lisp ? ClTl, p321 "The evaluator is typically implemented as an interpreter that traverses the given form recursively; performing each step of the computation as it goes. An interpretive implementation is not required, however. A permissible alternative approach is for the evaluator first to completely compile the form into machine- executable code and then invoke the resulting code. This technique virtually eliminates incomptibilities between interpreted and compiled code, but also renders the `evalhook' mechanism relatively useless." It would be ludicrous to compile a run-time check on the value of *EVALHOOK* along with every form processed by the compiler. Perhaps one could have a new declaration, COMPILE-HOOKS, to force this. I'm tempted to leave *EVALHOOK* and friends out of my Lisp (POPLOG Common Lisp) entirely, seeing as they are so obviously interpreter-oriented, but then people use them in software that's supposed to be portable, eg Portable Common Loops. Now for EVAL-WHEN. The problem here is that the concepts of COMPILE, LOAD, and EVAL phases don't apply in an incrementally compiled Lisp - POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT loop. The only distinction that can be sensibly made is between having a form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or 'in due course' (ie when it would have been executed in the normal course of events). So POPLOG makes (let ((x 1) (y 2)) (compiler-let ((x 100) (y 200)) (* (eval-when (compile) (+ x y)) 2))) produce 600, and (let ((x 1) (y 2)) (compiler-let ((x 100) (y 200)) (* (eval-when (eval) (+ x y)) 2))) produce 6. However, while this interpretation of EVAL-HOOK seems sensible to me, it may not be what someone who had written the above code would have expected. Again, PCL gives me grief in this respect - the way it uses EVAL-WHEN doesn't seem to fit this interpretation. John Williams, University of Sussex, Cognitive Sciences, Brighton, BN1 9QN, England Tel - (0273) 606755 UUCP: ...mcvax!ukc!cvaxa!johnw ARPANET : johnw%uk.ac.sussex.cvaxa@cs.ucl.ac.uk JANET johnw@cvaxa.sussex.ac.uk  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Mar 87 12:48:36 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87 09:34:27 PST Received: by navajo.stanford.edu; Wed, 4 Mar 87 08:44:54 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA04128; Wed, 4 Mar 87 08:02:11 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA01992; Wed, 4 Mar 87 07:59:14 PST Date: Wed, 4 Mar 87 07:59:14 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8703041559.AA01992@bhopal.edsel.com> To: navajo!Common-Lisp%sail@navajo.stanford.edu Subject: IMPORTations into keyword package Does anyone have a need/opinion about the meaning of importing an "interned"symbol into the keyword package? ("interned" means already "homed" in some package, such as Lisp or User). CLtL, page 175 strongly suggests that "keywords" ought not to be imported into other packages ("keywords" means "present and owned by the keyword package"); but there is no suggestion about the other direction. Consider, for example doing (import 't (find-package "KEYWORD")). After this step, you would have (eq t :t), which might seem desirable; but you wouldn't have (keywordp :t) because t is still owned by the Lisp package. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 87 12:53:57 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Mar 87 09:35:21 PST Received: ID ; Mon 2 Mar 87 12:36:02-EST Date: Mon, 2 Mar 1987 12:35 EST Message-ID: From: Rob MacLachlan To: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: What does this bit of code do? In-reply-to: Msg of 2 Mar 1987 12:26-EST from sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore) Date: Monday, 2 March 1987 12:26-EST From: sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore) To: Kent M Pitman Re: What does this bit of code do? It occurs to me that one of the strangenesses of exiting from the cleanup forms of an unwind-protect is that CLtL requires throw to find a matching catch before proceeding to do anything, even though the throw might never actually return control to that catch! Weird.... Actually this is required anyway, since in the case where the catch tag is not found, the error is required to be signalled without having processed any unwind protect cleanups or done any unwinding. See the Throw definition on page 142 in CLTL. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 87 12:40:25 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 09:24:23 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA28452; Mon, 2 Mar 87 10:26:17 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA19661; Mon, 2 Mar 87 10:26:10 MST Date: Mon, 2 Mar 87 10:26:10 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8703021726.AA19661@utah-orion.ARPA> Subject: Re: What does this bit of code do? To: Kent M Pitman Cc: gls@think.com, sandra%utah-orion@utah-cs.arpa, common-lisp@sail.stanford.edu In-Reply-To: Kent M Pitman , Fri, 27 Feb 87 13:14 EST It occurs to me that one of the strangenesses of exiting from the cleanup forms of an unwind-protect is that CLtL requires throw to find a matching catch before proceeding to do anything, even though the throw might never actually return control to that catch! Weird.... -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Feb 87 13:33:34 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 10:17:33 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80505; Fri 27-Feb-87 13:15:51 EST Date: Fri, 27 Feb 87 13:14 EST From: Kent M Pitman Subject: What does this bit of code do? To: gls@Think.COM cc: sandra%utah-orion@utah-cs.arpa, common-lisp@sail.stanford.edu In-Reply-To: <870227121710.5.GLS@BOETHIUS.THINK.COM> Message-ID: <870227131457.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I happen to agree with you, but it is a point more controversy than I would have expected. We had a lot of discussion about it internally at Symbolics a while back. In any case, nailing down the semantics of non-local exit from UNWIND-PROTECT is on my list of changes to submit to the cleanup committee in the very near future. (To those not on that committee, don't panic -- we don't actually make any decisions, we just package up the space of options into ballot items that can be voted upon by X3J13.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Feb 87 12:30:26 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Feb 87 09:16:04 PST Received: from boethius by Think.COM via CHAOS; Fri, 27 Feb 87 12:15:24 EST Date: Fri, 27 Feb 87 12:17 EST From: Guy Steele Subject: What does this bit of code do? To: sandra%utah-orion@utah-cs.arpa, common-lisp@sail.stanford.edu Cc: gls@think.com In-Reply-To: <8702271657.AA06791@utah-orion.ARPA> Message-Id: <870227121710.5.GLS@BOETHIUS.THINK.COM> Date: Fri, 27 Feb 87 09:57:38 MST From: sandra%utah-orion@UTAH-CS.ARPA (Sandra J Loosemore) Suppose I define function "foo" like so: (defun foo (unwind-protect (throw 'silly t) (return-from foo nil))) What does (catch 'silly (foo)) return? -Sandra ------- I say it should return nil. (I assume that you meant to have an empty argument list following "defun foo", as otherwise the function would have a null body, parameters named UNWIND-PROTECT, THROW, and RETURN-FROM, and supplied-p parameters named T and NIL.) --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Feb 87 12:10:33 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 08:55:33 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA23127; Fri, 27 Feb 87 09:57:41 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA06791; Fri, 27 Feb 87 09:57:38 MST Date: Fri, 27 Feb 87 09:57:38 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8702271657.AA06791@utah-orion.ARPA> Subject: What does this bit of code do? To: common-lisp@sail.stanford.edu Suppose I define function "foo" like so: (defun foo (unwind-protect (throw 'silly t) (return-from foo nil))) What does (catch 'silly (foo)) return? -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 87 01:18:51 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 22:06:58 PST Received: by navajo.stanford.edu; Mon, 23 Feb 87 22:05:53 PST Received: from gypsy-moth.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA01351; Mon, 23 Feb 87 17:53:32 pst Received: by gypsy-moth.edsel.com (3.2/SMI-3.2) id AA01060; Mon, 23 Feb 87 17:50:39 PST Date: Mon, 23 Feb 87 17:50:39 PST From: edsel!gypsy-moth!kdo@navajo.stanford.edu (Ken Olum) Message-Id: <8702240150.AA01060@gypsy-moth.edsel.com> To: navajo!common-lisp%sail@navajo.stanford.edu Subject: (READ-CHAR T) vs. (FORMAT T) READ-CHAR and WRITE-CHAR accept T to mean *TERMINAL-IO*, but FORMAT accepts T to mean *STANDARD-OUTPUT*. This leads easily to confusion, since a higher-level output-function is likely to take a stream and pass it on without examination to either FORMAT and to other output-functions, and thus get output distributed between different streams when *STANDARD-OUTPUT* is bound. This is pretty unpleasant. Ken  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Feb 87 23:05:33 EST Received: from ICST-ECF.ARPA by SAIL.STANFORD.EDU with TCP; 19 Feb 87 19:49:30 PST Date: 19 Feb 87 12:59:00 EST From: "CUGINI, JOHN" Subject: What does TYIPEEK mean? To: "common-lisp" Reply-To: "CUGINI, JOHN" I recently got Forgy's OPS5 interpreter, written in fairly Common Lisp, running on our VAX (under VMS). When I ran it thru the VAXLisp compiler, there were a few error messages, most of which I can handle (eg, spell GREATERP as ">"), but there were several references to an undefined TYIPEEK function, like 'frinstance: ;;; RHS Functions (defmacro accept (&rest z) `(prog (port arg) (cond ((> (length ',z) 1.) (%warn '|accept: wrong number of arguments| ',z) (return nil))) (setq port t) (cond (*accept-file* (setq port ($ifile *accept-file*)) (cond ((null port) (%warn '|accept: file has been closed| *accept-file*) (return nil))))) (cond ((= (length ',z) 1) (setq arg ($varbind (car ',z))) (cond ((not (symbolp arg)) (%warn '|accept: illegal file name| arg) (return nil))) (setq port ($ifile arg)) (cond ((null port) (%warn '|accept: file not open for input| arg) (return nil))))) ;; HERE'S ONE (cond ((= (tyipeek port) -1.) ($value 'end-of-file) (return nil))) (flat-value (read port)))) (defun span-chars (x prt) ;; HERE'S ANOTHER (do ((ch (tyipeek prt) (tyipeek prt))) ((not (member ch x #'char-equal))) (read-char prt))) I think this may be left over from MacLisp. Is the following an OK implementation? (defun tyipeek (port) (peek-char nil port nil -1.)) Thanks for any advice.... John Cugini ------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 87 20:27:58 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Feb 87 17:14:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 69836; Thu 12-Feb-87 20:13:10 EST Date: Thu, 12 Feb 87 20:13 EST From: David A. Moon Subject: *APPLYHOOK* Vagueness To: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8702122224.AA17872@utah-orion.ARPA> Message-ID: <870212201305.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 12 Feb 87 15:24:25 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Page 322 of CLtL is a little vague on exactly when *applyhook* is used. It says that the apply hook function is used only for "ordinary" functions, while funcalls and some related cases are not hookable. I would like to know what an "ordinary" function is - does it include named local functions created via flet? What about an anonymous lambda in the car of a form? "Ordinary function" isn't a term defined in CLtL as far as I can tell, but from context it means a genuine function, as opposed to a macro or a special form. Whether the function is defined globally, locally, or explicitly with a lambda-expression makes no difference. I hope that in the future some consistent terminology will be used for the various things that can appear in the car of a form, so that these problems of ambiguity don't keep arising. The business about funcall and mapcar is expanding on the "within eval" portion of the phrase "application of ordinary functions within eval". That is, applyhook controls only the application of the function designated by the car of a form to the arguments resulting from evaluating the forms in the cdr of the form.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 87 20:12:06 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Feb 87 16:55:57 PST Received: ID ; Thu 12 Feb 87 19:56:48-EST Date: Thu, 12 Feb 1987 19:56 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: Lexical globals In reply to: David Singer Common Lisp is currently missing this concept. There has been some discussion on how to remedy this, but no clear consensus as yet. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 87 19:48:42 EST Received: from [128.58.1.2] by SAIL.STANFORD.EDU with TCP; 12 Feb 87 16:31:51 PST Date: Thu 12 Feb 87 16:31:23-PST From: David Singer Subject: Lexical globals To: common-lisp@SAIL.STANFORD.EDU cc: singer@SPAR-20.ARPA Message-ID: <12278568528.12.SINGER@SPAR-20.ARPA> I am unable to work out how to declare LEXICAL, GLOBAL variables; DEFVAR makes special variables -- what I am looking for is a variable which will obscured by another declaration in say, a LET construct. Am I missing something obvious, or is common-lisp (which is I understand 'normally' lexical) missing this concept, which would equate to STATICS in other block-structured lexical languages such as BCPL and pascal-family languages? -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 87 17:54:29 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 12 Feb 87 14:22:52 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA29796; Thu, 12 Feb 87 15:24:29 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA17872; Thu, 12 Feb 87 15:24:25 MST Date: Thu, 12 Feb 87 15:24:25 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8702122224.AA17872@utah-orion.ARPA> To: common-lisp@sail.stanford.edu Subject: *APPLYHOOK* Vagueness Page 322 of CLtL is a little vague on exactly when *applyhook* is used. It says that the apply hook function is used only for "ordinary" functions, while funcalls and some related cases are not hookable. I would like to know what an "ordinary" function is - does it include named local functions created via flet? What about an anonymous lambda in the car of a form? stan