Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 18:00:05 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 14:49:13 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4116; Tue 11-Mar-86 17:48:49-EST Date: Tue, 11 Mar 86 17:48 EST From: Kent M Pitman Subject: Some notes about declarations To: Common-Lisp@SU-AI.ARPA Message-ID: <860311174837.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Do we provide a way to type-declare functions (ie, FTYPE) that have &optional or &rest specifications? It seems like (FTYPE (FUNCTION (INTEGER &OPTIONAL INTEGER) FLOAT)) would have been reasonable, but I can't find anything that suggests I can do this. &REST would be more complicated, but not prohibitively so. Am I missing something or do we not have a way to do this at all. Do we provide a way to declare that a function is n-ary (or not) at all? That is, the equivalent of the *EXPR and *LEXPR declarations in Maclisp? I guess I would be surprised if there was no CL implementation that could generate better code in cases where I declared this kind of thing ahead of time. And while we're on the subject, is there some reason that PROCLAIM was not made to be n-ary? It has bothered me on numerous occassions that I have to do: (PROCLAIM '(SPECIAL X)) (PROCLAIM '(FIXNUM X)) when we could just as well have allowed: (PROCLAIM '(SPECIAL X) '(FIXNUM X)) Allowing multiple arguments would be more consistent with DECLARE.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 17:09:14 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 13:57:31 PST Received: from LONG-TAILED-JAEGER.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4066; Tue 11-Mar-86 16:57:12-EST Date: Tue, 11 Mar 86 16:59 EST From: David A. Moon Subject: compiler-let and macrolet in macros To: Jeff Barnett cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 10 Mar 86 22:14-EST from Jeff Barnett Message-ID: <860311165932.5.MOON@LONG-TAILED-JAEGER.SCRC.Symbolics.COM> Date: Mon, 10 Mar 86 19:14:01 PST From: Jeff Barnett Consider the following hack. (defmacro with-car (&body body) `(compiler-let((operator 'car)) ,. body)) (defmacro with-cdr (&body body) `(compiler-let((operator 'cdr)) ,. body)) (defmacro right-side (exp) `(,operator ,exp)) What I want to know is will the following work (setf (with-car (right-side foo)) (with-cdr (right-side goo))) Probably not. Of course this can be transformed into (with-car (setf (right-side foo) (with-cdr (right-side goo)))) However, I think the latter is more obscure. (define-setf-method compiler-let (bindings single-body-form) (progv (mapcar #'first bindings) (mapcar #'eval (mapcar #'second bindings)) (get-setf-method-multiple-value single-body-form))) makes it work for me. Perhaps if I thought about it more I would come up with a subtle reason why this works for your example but cannot work in the most general case. Perhaps it should wrap the COMPILER-LET back around the fourth and fifth values before returning them. The reason define-setf-method is included in the language is precisely to provide a portable way to do hairy things like this. By the way, I don't believe that an implementation of this sort using macrolet will work either. I think it would if Common Lisp included a portable way to manipulate the function environment in the same way that progv provides a portable way to manipulate the special-variable environment.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 15:45:34 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 12:34:28 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3990; Tue 11-Mar-86 15:34:03-EST Date: Tue, 11 Mar 86 15:33 EST From: Daniel L. Weinreb Subject: :if-does-not-exist To: common-lisp@SU-AI.ARPA Message-ID: <860311153347.1.DLW@CHICOPEE.SCRC.Symbolics.COM> The description of the default value of the :if-does-not-exist argument to open, on page 422, confused our implementor. Strictly read, the manual is ambiguous about the default value, in the case where :direction is :probe and :if-exists is :overwrite or :append. The intention of the manual is probably that you realize that :if-exists is not defined for :probe, but this is not completely clear from the text. This should be clarified in the next edition.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 14:10:30 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 10:57:53 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3932; Tue 11-Mar-86 13:57:41-EST Date: Tue, 11 Mar 86 13:57 EST From: Daniel L. Weinreb Subject: TRUE, FALSE To: Fahlman@C.CS.CMU.EDU cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860311135722.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 11 Mar 1986 10:19 EST From: "Scott E. Fahlman" I'm not sure where the break-even point would be in this case, but it's a lot higher than two. I'd say the key question is whether we anticipate that this function generator might be used for other things besides these two things, in the future. If we think there would be many other things, that would support the proposal for the function generator. In turn, this depends partially on how much we think people will be using functional objects, closures, and function generators. That's what GLS's last message was about. Appropriate design of Common Lisp can only be done in the presence of a presumed programming style, to allow us to try to gague how useful certain proposed features will be in the future. It's a hard problem because we don't all use the same programming style, and because programming styles change with time. In developing Common Lisp, I don't think we were completely consistent in our treatment of these issues. (Controversial statement of the year...) Some things in Common Lisp, notably the sequence functions, were a little bit outside of what most of us considered the usual programming style, for example. This is presumably because we felt that the style of the sequence functions was in the direction that we felt modern Lisp was going. This is also one of the reasons that lexical scoping was adopted, although there were certainly others. I think that GLS's proposed function generator is also in the direction that model Lisp style is moving towards. However, we don't all have the same opinions about style. Also, it's not clear how far out Common Lisp, as a broad standard, should reach. While we don't want to be mired in the past, we also have a responsibility to be generally conservative in some ways, because of the large number of implementations and users. So I think it's a complex judgement call.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 13:14:24 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Mar 86 09:39:34 PST Date: 11 Mar 86 12:34:00 EST From: "BACH::GREEK" Subject: Having lots of packages with extensions. To: "common-lisp" Reply-To: "BACH::GREEK" In response to Mr. Weinreb: Yes, I was clearly being too general. I agree that there may be lots of packages provided by a company with their Common LISP. Not all of the public symbols in these packages want to be imported into some "extensions" package. We certainly have such packages in VAX LISP. I'm thinking more of general extensions that are used at top level for various random things. Those symbols that a person would expect to just have at top level in the USER package without having to use some special package or package prefix. Symbols which fall into the category of ED or DEBUG or the like. This is the reason Common LISP defined ED to invoke the editor rather than just saying that "there might be an editor." Perhaps this is simply too nebulous to define. I'd be happy, I guess, if we just said that the LISP package contains exactly Common LISP and lots of other packages might exist with various extra goodies. I sure feel uncomfortable, however, if we don't at least say that all those extra packages follow some naming convention, like SYSTEM-xxx. Otherwise a layered product simply does not know what names it can use for its packages. Furthermore, if we say that there can be arbitrary packages with extensions, then what the hell are we bothering to define the SYSTEM package for? - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 13:09:41 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Mar 86 09:39:10 PST Date: 11 Mar 86 12:23:00 EST From: "BACH::NELSON" Subject: package names To: "common-lisp" Reply-To: "BACH::NELSON" If it is clear that package names should be different between implementations, how do we assure that they are different? Have each implementation insert a vendor or system prefix (e.g. DEC-EDITOR::, SYMBOLICS-EDITOR::, PSL-VAX-UNIX-EDITOR::)? Ick. Or require, as Paul Anagnastopoulos has suggested, that package names be registered? It seems like this can easily become an intractable problem. There will be lots of editors and debuggers and other programs. I accept the arguments for encouraging that implementation-specific, accessible, functions be in packages uniquely named for each implementation, but the only naming conventions which come to mind are the two mentioned above. Does anyone have any other suggestions? Regarding the functions which Guy suggested for generating functions - they don't seem any more weird than the functions that they generate. Beryl Nelson ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 13:02:39 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 08:02:09 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3853; Tue 11-Mar-86 11:01:44-EST Date: Tue, 11 Mar 86 11:01 EST From: Daniel L. Weinreb Subject: Meta-issue To: common-lisp@SU-AI.ARPA Message-ID: <860311110129.5.DLW@CHICOPEE.SCRC.Symbolics.COM> I'd like to make a point at the meta-level, i.e., about how we go about evaluating Common Lisp clarification/redesign decisions. A major goal of Common Lisp was to allow portability of serious, large Lisp programs. After all these years, we are finally seeing a few efforts to do develop such portable software. In all my time as a computer engineer, I have found that experience from practical implementation efforts is irreplacable, and "packs more punch" than speculative opinion in general. We should pay close attention to the experiences of KMP, Gregor, and others if we seriously want to make Common Lisp useful for serious portable software.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 12:38:29 EST Date: 11 Mar 86 0918 PST From: Dick Gabriel Subject: TRUE, FALSE To: common-lisp@SU-AI.ARPA Rememeber, also, that Common Lisp designers have traditionally adopted the S-1 motto: Why use lead when gold will do? -rpg-  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 12:30:42 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 11 Mar 86 07:57:31 PST Received: from guido by GODOT.THINK.COM via CHAOS; Tue, 11 Mar 86 10:57:54 est Date: Tue, 11 Mar 86 10:59 EST From: Guy Steele Subject: TRUE, FALSE To: Fahlman@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <860311105957.5.GLS@GUIDO.THINK.COM> Date: Tue, 11 Mar 1986 10:19 EST From: "Scott E. Fahlman" The issue isn't generality, but minimizing the number of new functions. "Why take two when one will do?" --Guy In my view, the complexity of a language is not measured by counting the functions. One hairy function-building meta-function adds a lot more conceptual hair than two nearly identical simple functions that just do easily explained things: gobble down any number of arguments, ignore them, and return T or NIL. I'm not sure where the break-even point would be in this case, but it's a lot higher than two. -- Scott That's fair, of course, but I'll rpess my luck just one more time: we would be better off if we didn't automatically think of functions that return functions as "hairy". (I don't mean to accuse you of reacting automatically in this case, but I don't think my CONSTFN one-liner was any hairier than + or GCD.) We are all used to MAPC and MAPCAR; most of us are used to REMOVE-IF-NOT by now; and I have found REDUCE to be tremendously useful in unexpected ways, as I have already noted. There is great expressive power to be gained in a carefully selected set of function-producing functions.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 11:54:37 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 Mar 86 07:31:19 PST Received: ID ; Tue 11 Mar 86 10:19:58-EST Date: Tue, 11 Mar 1986 10:19 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: Common-Lisp@SU-AI.ARPA Subject: TRUE, FALSE In-reply-to: Msg of 11 Mar 1986 10:09-EST from Guy Steele The issue isn't generality, but minimizing the number of new functions. "Why take two when one will do?" --Guy In my view, the complexity of a language is not measured by counting the functions. One hairy function-building meta-function adds a lot more conceptual hair than two nearly identical simple functions that just do easily explained things: gobble down any number of arguments, ignore them, and return T or NIL. I'm not sure where the break-even point would be in this case, but it's a lot higher than two. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 11:48:11 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 11 Mar 86 08:39:18 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3877; Tue 11-Mar-86 11:39:02-EST Date: Tue, 11 Mar 86 11:38 EST From: Daniel L. Weinreb Subject: Where do extensions go? To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Mar 86 10:07-EST from "BACH::GREEK" Message-ID: <860311113844.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 11 Mar 86 10:07:00 EST From: "BACH::GREEK" I agree that different implementations might have lots of packages with different extensions in them (e.g., debugger, editor). It just seems a pain if you don't import all of these into one extensions package and then make them public from there. Otherwise the user has to use all sorts of packages or put package prefixes everywhere. What if there is more than one "extension", and two extensions use the same name for something? Think about why there are packages in the first place. In particular, Common LISP says that there will probably be a debugger (for example), but doesn't talk about the interface. So the user says "I want to use the debugger, where the hell is it? Which packages do I have to use so that any symbols that are part of the debugger will show up? Do I need to use more than one package?" It seems we could avoid some of this annoyance if we just said that all such public symbols are in some standard package. OK, so then you'd know what package the interface was in. But you still would not know what any of the functions did. So you need a specification (documentation). Since you need that anyway, it can tell you what package to use. Of course there might be confusion between two implementations. But that isn't any worse or better if we agree on the name of the extensions package. Also, by agreeing on one name, we only reserve that one name, and we don't potentially have a bunch of names that layered product developers have to avoid. This is particularly important if we refuse to register package names, which we probably will. I think the problem here is that you are assuming that each Common Lisp system comes with one single set of "extensions", produced by the same people that provide the base language, and that these sets of "extensions" are inherently different in some way from other packages of useful functions produced by other parties.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 10:27:46 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 11 Mar 86 07:19:05 PST Date: 11 Mar 86 10:07:00 EST From: "BACH::GREEK" Subject: Where do extensions go? To: "common-lisp" Reply-To: "BACH::GREEK" I agree that different implementations might have lots of packages with different extensions in them (e.g., debugger, editor). It just seems a pain if you don't import all of these into one extensions package and then make them public from there. Otherwise the user has to use all sorts of packages or put package prefixes everywhere. In particular, Common LISP says that there will probably be a debugger (for example), but doesn't talk about the interface. So the user says "I want to use the debugger, where the hell is it? Which packages do I have to use so that any symbols that are part of the debugger will show up? Do I need to use more than one package?" It seems we could avoid some of this annoyance if we just said that all such public symbols are in some standard package. Of course there might be confusion between two implementations. But that isn't any worse or better if we agree on the name of the extensions package. Also, by agreeing on one name, we only reserve that one name, and we don't potentially have a bunch of names that layered product developers have to avoid. This is particularly important if we refuse to register package names, which we probably will. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 11 Mar 86 10:17:49 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 11 Mar 86 07:07:21 PST Received: from guido by GODOT.THINK.COM via CHAOS; Tue, 11 Mar 86 10:07:22 est Date: Tue, 11 Mar 86 10:09 EST From: Guy Steele Subject: TRUE, FALSE To: Fahlman@C.CS.CMU.EDU, gls@THINK-AQUINAS.ARPA Cc: Common-Lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: Message-Id: <860311100923.1.GLS@GUIDO.THINK.COM> Date: Mon, 10 Mar 1986 17:15 EST From: "Scott E. Fahlman" Why not just a function CONSTFN that takes a value and returns a function that will return that value? So far only two such functions have been asked for, one of which produces a null value and the other of which produces something non-null: T, for lack of any better thing. Do we really need a general function to build such things? I don't think so. Down with generality, and down with the generals! -- Scott The issue isn't generality, but minimizing the number of new functions. "Why take two when one will do?" --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 23:28:04 EST Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 20:20:15 PST Date: Mon, 10 Mar 86 19:14:01 PST From: Jeff Barnett To: common-lisp@SU-AI.ARPA Subject: compiler-let and macrolet in macros Via: Nrtc; 10 Mar 86 20:04:42 Consider the following hack. (defmacro with-car (&body body) `(compiler-let((operator 'car)) ,. body)) (defmacro with-cdr (&body body) `(compiler-let((operator 'cdr)) ,. body) (defmacro right-side (exp) `(,operator ,exp)) What I want to know is will the following work (setf (with-car (right-side foo)) (with-cdr (right-side goo))) Probably not. Of course this can be transformed into (with-car (setf (right-side foo) (with-cdr (right-side goo)))) However, I think the latter is more obscure. By the way, I don't believe that an implementation of this sort using macrolet will work either. The point of all of this is that macroexpand does not expand either compiler-let or macrolet. Thus, setf can't see its real arguments. There is a solution to this kind of problem but it would require much more sophisticated macro expansion than is done today or has been proposed. Before, I endeavor to write up a proposal for better macro expansion facilities, I want to know if anybody is interested in either the problem or its solution. Jeff  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 23:27:54 EST Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 20:19:59 PST Date: Mon, 10 Mar 86 19:01:24 PST From: Jeff Barnett To: common-lisp@SU-AI.ARPA Subject: Re Scope and declarations Via: Nrtc; 10 Mar 86 20:04:19 Sorry I wasn't specific enough in my last query. Therefore, I'll start from scratch. The point that bothers me is the one made on page 155 of CLtL. As I understand things, (setq x 5) (defun foo (x) (declare (unspecial x)) (let((x (1+ x))) (declare (special x)) x) (print (foo 0)) outputs 6, not 1. The declare in the let form prevades the preset expression so that the expression (1+ x) assumes the current global binding of x outside outside the let. I can understand that this will often be the right thing and require less writing. I also understand that if I want to grab the lexical x that I could change the let to start (let((x (let()(declare (unspecial x)) (1+ x)))) which I suppose works. (Does it?) However, if the let is produced by a macro, there is no way to achieve this effect unless the macro can enumerate the scope of the expression that it uses for the preset. Since the preset may be passed into the macro, I don't think it can recover in any graceful way unless you think that (let((g exp)) (let((x g)) (declare (special x)) etc)) where g is a gensym, is graceful. Another problem with declares prevading presets is that the following are not equivelent: (let((v1 e1) (v2 e2)) (declare (something-about v1 v2)) body...) ((lambda(v1 v2) (declare (something-about v1 v2)) body...) e1 e2) Further, I think the proposed standard is incompatible with virtually all other LISP implementations. I don't think that this is a good idea for CL. Any comments and clarifications as to all of this would be appreciated. Jeff  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 22:01:54 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 17:30:54 PST Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 434784; Mon 10-Mar-86 20:24:36-EST Date: Mon, 10 Mar 86 20:25 EST From: Kent M Pitman Subject: The LISP-EXTENSIONS Package. To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA In-Reply-To: The message from "BACH::GREEK" Message-ID: <860310202519.1.KMP@HUMMINGBIRD.SCRC.Symbolics.COM> From: "BACH::GREEK" Subject: The LISP-EXTENSIONS Package. I'm not saying that there any common extensions. I'm just saying that we should all agree to put our extensions in the same package, just like we agree to put our system hacks in the SYSTEM package. Then the CLtL could say "hey, any implementation-specific extensions are in the LISP-EXTENSIONS package. Look there to find all kinds of goodies." Are you arguing that people should do (APROPOS "" "SYSTEM") and try calling things that look fun? Each implementation will have to document its goodies, and in that documentation they can tell you any package you want. There is no reason for CL to standardize on that package name and a lot of reason for CL not to (read on)... I'm only suggesting we agree on the package name, not on the contents. The problem is that if one writes: (DEFUN FOO (X) (LISP-EXTENSIONS:FROB X)) they may find out that FROB is defined differently in two different systems. When a program is written for one implementation and later ported to another, you may get no compiler warnings since the compiler may not realize that the LISP-EXTENSIONS:FROB you're calling is not the one you meant. Consider the following awful situation, where two implementations have FROB1 and FROB2, but where the two have oppposite meanings... (DEFUN FOO (X) (COND (X #+SOMETHING (LISP-EXTENSIONS:FROB1 X) #-SOMETHING (LISP-EXTENSIONS:FROB2 X)) (T #+SOMETHING (LISP-EXTENSIONS:FROB2 X) #-SOMETHING (LISP-EXTENSIONS:FROB1 X)))) This program is very hard to look at. The following program is not much prettier, but is a least something which one can begin to fathom at a glance... (DEFUN FOO (X) (COND (X #+SOMETHING (MY:FROB1 X) #-SOMETHING (YOUR:FROB2 X)) (T #+SOMETHING (MY:FROB2 X) #-SOMETHING (YOUR:FROB1 X)))) This actually comes up in things like file manipulation tools, math (especially trig) functions, and other such things where the concepts have well defined names, but where the exact datatypes and ranges of inputs and outputs can vary widely. I agree with those at Symbolics who've said there are good reasons for our having picked SCL: for Symbolics extensions and not dumped all that in a standardly named package. At least if SCL:symbols are read into another Lisp, you'll know right away that you have a portability problem -- an effect which I have found to be an important -aid- to portability.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 21:48:32 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 10 Mar 86 15:11:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAR 86 14:21:31 PST Date: 10 Mar 86 13:28 PST From: Gregor.pa@Xerox.COM Subject: Re: A package to contain Common LISP extensions. In-reply-to: David C. Plummer 's message of Mon, 10 Mar 86 12:54 EST To: DCP@SCRC-QUABBIN.ARPA cc: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA Message-ID: <860310-142131-1093@Xerox> From my experience porting Portable CommonLoops I have the following opinions on this subject: * I feel VERY STRONGLY that the lisp package should have only those symbols defined in CLTL. Here are some examples of problems I have had with Common Lisps in which this wasn't true, (I do not mean to point fingers, I am just trying to use concrete examples): In an early version of Lucid Lisp memq was in the lisp package. It was also a special function so that when PCL redefined it as a macro the lisp got a bad headache. On the Explorer string-append is defined in the lisp package. When you load pcl is says "Warning... redefining string append, OK?" You say yes, but then the editor breaks because they have extended string-append to do some special stuff for the editor. I KCL there are so many extra symbols in the lisp package that its easy to use one of them without knowing it. * make-package should inherit from lisp. * I see no reason to specify the name of the package where people should put their extensions. Extensions go in lots of different packages based upon their nature, it would be cumbersome to have to decide if a particular function deserves to be a "common Lisp extension" and should be movce to the extensions package. Hmm should zwei:with-output-to-buffer be in the extensions package. In order for a programmer to make use of the extensions that a given implementation offers they are going to have to spend enough time reading about those extensions and interfacing them to their program that the time it will take them to type a few IMPORTs or use-packages will be insignificant. But someone who tries real hard to make a program that really is portable should have as much of a chance at wining as possible and extra symbols in the Lisp package get in the way.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 19:16:47 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 15:05:57 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 252084; Mon 10-Mar-86 18:03:40-EST Date: Mon, 10 Mar 86 18:06 EST From: David C. Plummer Subject: TRUE, FALSE To: Scott E. Fahlman , Guy Steele cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860310180600.0.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 10 Mar 1986 17:15 EST From: "Scott E. Fahlman" Why not just a function CONSTFN that takes a value and returns a function that will return that value? So far only two such functions have been asked for, one of which produces a null value and the other of which produces something non-null: T, for lack of any better thing. Do we really need a general function to build such things? I don't think so. Down with generality, and down with the generals! Another way to look at this is that common cliches should have a defined, common, abstraction.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 19:16:32 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 15:09:05 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 252085; Mon 10-Mar-86 18:03:51-EST Date: Mon, 10 Mar 86 18:06 EST From: David C. Plummer Subject: TRUE, FALSE To: Scott E. Fahlman , Guy Steele cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860310180613.1.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 10 Mar 1986 17:15 EST From: "Scott E. Fahlman" Why not just a function CONSTFN that takes a value and returns a function that will return that value? So far only two such functions have been asked for, one of which produces a null value and the other of which produces something non-null: T, for lack of any better thing. Do we really need a general function to build such things? I don't think so. Down with generality, and down with the generals! Another way to look at this is that standard cliches should have a defined, common, abstraction.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 19:14:56 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Mar 86 15:04:57 PST Date: Mon, 10 Mar 86 18:05:46 EST From: "George J. Carrette" Subject: "But that CONSES?" To: gls@AQUINAS.THINK.COM cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Mon 10 Mar 86 15:48 EST from Guy Steele Message-ID: <[MC.LCS.MIT.EDU].845835.860310.GJC> They could be very wrong. If CONSTFN is declared to be integrable then (CONSTFN T) could very well return the same thing, #'TRUE, every time. No need to cons.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 18:58:07 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 14:16:05 PST Received: ID ; Mon 10 Mar 86 17:15:38-EST Date: Mon, 10 Mar 1986 17:15 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: Common-Lisp@SU-AI.ARPA Subject: TRUE, FALSE In-reply-to: Msg of 10 Mar 1986 15:48-EST from Guy Steele Why not just a function CONSTFN that takes a value and returns a function that will return that value? So far only two such functions have been asked for, one of which produces a null value and the other of which produces something non-null: T, for lack of any better thing. Do we really need a general function to build such things? I don't think so. Down with generality, and down with the generals! -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 17:57:00 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 14:47:43 PST Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 434635; Mon 10-Mar-86 17:33:23-EST Date: Mon, 10 Mar 86 17:35 EST From: David C. Plummer Subject: The LISP-EXTENSIONS Package. To: "BACH::GREEK" , common-lisp In-Reply-To: The message from "BACH::GREEK" Message-ID: <860310173508.1.DCP@NEPONSET.SCRC.Symbolics.COM> From: "BACH::GREEK" I'm not saying that there any common extensions. I'm just saying that we should all agree to put our extensions in the same package, just like we agree to put our system hacks in the SYSTEM package. Then the CLtL could say "hey, any implementation-specific extensions are in the LISP-EXTENSIONS package. Look there to find all kinds of goodies." The manual says very little about what goes in the SYSTEM package. The Symbolics implementation has several other packages where 'system hacks' live, such as the network package, the TV package, the debugger package, etc. I'm flaming. Sorry. My first opinion was probably my best. It is in the archive, and I'll let that opinion stand. I'm only suggesting we agree on the package name, not on the contents.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 16:56:04 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Mar 86 12:46:29 PST Received: from yon by GODOT.THINK.COM via CHAOS; Mon, 10 Mar 86 15:46:57 est Date: Mon, 10 Mar 86 15:48 EST From: Guy Steele Subject: TRUE, FALSE To: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860309184010.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-Id: <860310154859.2.GLS@THINK-YON.ARPA> Date: Sun, 9 Mar 86 18:40 EST From: Kent M Pitman For the next edition, could we introduce functions TRUE and FALSE ... Why not just a function CONSTFN that takes a value and returns a function that will return that value? (DEFUN CONSTFN (X) #'(LAMBDA (&REST Z) (DECLARE (IGNORE Z)) X)) or, for more generality: (DEFUN CONSTFN (&REST X) #'(LAMBDA (&REST Z) (DECLARE (IGNORE Z)) (VALUES-LIST X))) Then instead of #'TRUE you just say (CONSTFN T). All very Schemish. (And I know at least thirty people out there will scream with horror, "But that CONSES!" and they will be right.) --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 16:24:33 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 10 Mar 86 11:54:55 PST Received: from christopher by GODOT.THINK.COM via CHAOS; Mon, 10 Mar 86 14:55:28 est Date: Mon, 10 Mar 86 14:57 EST From: Dan Aronson Subject: Package for exactly CLtL and nothing else To: Rem@IMSSS, common-lisp@SU-AI.ARPA In-Reply-To: <8603101937.AA02525@GODOT.THINK.COM> Message-Id: <860310145729.3.DAN@THINK-CHRISTOPHER.ARPA> From: Rem@IMSSS Subject: Package for exactly CLtL and nothing else ... , it would be possible for one implementation to provide several different years of standard at the same time, and portable code could use exactly the package it was written for without incompatible changes from year to year goofing it up, and there'd be a graceful period of overlap instead of a flag day when a given vendor's implementation switches years (or two incompatible LISP environments where the poor user can't mix usage of the two). ... Wait a minute. Are you suggesting that lisps should be required to have a whole bunch of almost identical implementations, each loaded up in a different package. Since most of the language probably will remain fairly constant this is a fairly large waste of space. (or a large effort for the implementor to figure out how to share common function, etc.) Since we are hoping for a standard I don't think that the language will change all that much so that the code really needs to use a completely different lisp system. I vote for having one standard package. --Dan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 14:50:31 EST Received: from IMSSS by SU-AI with PUP; 10-Mar-86 11:28 PST Date: 10 Mar 1986 1125-PST From: Rem@IMSSS Subject: Package for exactly CLtL and nothing else To: COMMON-LISP@SU-AI I agree with all the people who want some package with an agreed-upon name to be exactly CLtL and nothing else, because it makes benchmarking easier, you just map down the package to verify every function is there and nothing else there, and having done that gross count you then proceed with detailed testing of each and every function in that package. As to its name, that's unclear. SInce we're liable to have different versions of CLtL every so years as we improve the specification, either LISP or CLTL is probably a bad name, although CLTL86 would be a good name for this year's standard. If CLTL86 happened to be identical to LISP on some systems and not on other systems, I wouldn't mind. The documentation for that system should say what packages are available beyond CLTL86 and what is in them. If the exactly-CLTL package were year-numbered, it would be possible for one implementation to provide several different years of standard at the same time, and portable code could use exactly the package it was written for without incompatible changes from year to year goofing it up, and there'd be a graceful period of overlap instead of a flag day when a given vendor's implementation switches years (or two incompatible LISP environments where the poor user can't mix usage of the two). Therefore I propose that as soon as CLtL is absolutely firm, we stamp it with a yearmark and establish the package name to contain that version; debate on this proposal invited... -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 14:22:23 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 10 Mar 86 10:46:16 PST Date: Mon, 10 Mar 86 13:46:58 EST From: Jonathan A Rees Subject: A package to contain Common LISP extensions. To: greek%bach.decnet@HUDSON.DEC.COM cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 0 0 00:00:00 EST from BACH::GREEK Message-ID: <[MC.LCS.MIT.EDU].845405.860310.JAR> Date: 0 0 00:00:00 EST From: BACH::GREEK Of course DEC's EXTENDED-LISP package would contain different things than Symbolic's. That's the purpose of the EXTENDED-LISP package. Perhaps LISP-EXTENSIONS would be a better name. I just think that everyone should agree on the name of the package to contain their extensions. Then a user would at least have a place to start. I don't see why there should be agreement, as each implementation's extensions will be different. In fact, I would think each implementation would want its own package name for its extensions, in order to improve readability and reduce the potential for accidental name conflicts (which could otherwise be painful to track down). Also, one could imagine creating compatibility-mode implementations of one set of extensions to co-reside with another set, making it even more desirable to have disjoint packages. The only reason I can think of for having a standard name for a package of extensions is to give users a way to create "things like the USER package" which have local extensions. This seems of marginal utility in portable code, but perhaps a standard nickname would be in order if people think it's important. Of course all this begs the question of how to avoid package name conflicts, but that's not a new problem created by this situation. I think a package name registry would be a good idea, although not a complete solution; the only problem with it would be getting people to make use of it. --- Having attempted to write portable CL code, and having repeatedly tromped on implementation-dependent things in the LISP package which I would have preferred to not be there (not just symbols like QUIT and HELP, but definitions as well - e.g. Symbolics Common Lisp defines an IGNORE function), I want to put myself on record as opposed to putting non-CL things in the LISP package or in value (function, etc.) cells of symbols in the LISP package. As long as I'm flaming on this subject, I'll mention my idle desire that the HOME package of symbols in the LISP package be defined to be the LISP package. This would permit true read/print symmetry (e.g. across implementations or different versions of the same implementation) for shadowed LISP package symbols. Jonathan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 14:01:00 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 10:40:07 PST Received: ID ; Mon 10 Mar 86 13:13:40-EST Date: Mon, 10 Mar 1986 13:13 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: Lisp package In response to David Plummer: Wrong. The LISP package contains the Common Lisp language. Anything else, ANYTHING, is not Common Lisp, but rather an extension. Extensions belong in some other package or packages. Applications can use those other packages in addition to LISP. This is a matter of documentation by vendors for people writing such applications. It does not say anywhere that the Lisp package contains ONLY the Common Lisp language. That's certainly one way to handle this, but it is not obvious that this is the best way, regardless of how forcefully you choose to state this opinion. I agree that it would be useful to have separate packages for "pure" Common Lisp and for the richer default environment provided by a given implementation. It seems clear to me that the latter is what should be used by Make-Package unless the user specifies otherwise, since this is what the implementors of the system believe that the user will typically want to have around. The only remaining issue is which of these concepts gets to use the name Lisp, and which has to find a new name. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 13:45:12 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 10:26:32 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: The LISP-EXTENSIONS Package. To: "common-lisp" Reply-To: "BACH::GREEK" I'm not saying that there any common extensions. I'm just saying that we should all agree to put our extensions in the same package, just like we agree to put our system hacks in the SYSTEM package. Then the CLtL could say "hey, any implementation-specific extensions are in the LISP-EXTENSIONS package. Look there to find all kinds of goodies." I'm only suggesting we agree on the package name, not on the contents. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 13:09:32 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 09:54:07 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3619; Mon 10-Mar-86 12:54:25-EST Date: Mon, 10 Mar 86 12:54 EST From: David C. Plummer Subject: A package to contain Common LISP extensions. To: "BACH::GREEK" , common-lisp In-Reply-To: The message from "BACH::GREEK" Message-ID: <860310125443.8.DCP@NEPONSET.SCRC.Symbolics.COM> From: "BACH::GREEK" Of course DEC's EXTENDED-LISP package would contain different things than Symbolic's. That's the purpose of the EXTENDED-LISP package. Perhaps LISP-EXTENSIONS would be a better name. I just think that everyone should agree on the name of the package to contain their extensions. Then a user would at least have a place to start. To start what? I don't think there is such a thing as common extensions, so it doesn't make much sense to me to agree to put our uncommon extensions in a common package.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 13:05:54 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 09:39:12 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: One More Apology To: "common-lisp" Reply-To: "BACH::GREEK" Let me apologize once more for our mailer software, which is written by a company with an Australian-sounding name. Please don't ask us to fix it, because we didn't write it and we don't have the time or inclination to write a new mailer. So we wait until our vendor fixes it. Personally, I think any mail receiver that relies on a blank line to separate the header from the body of the mail is brain-damaged. But then again, I don't know anything about TCP/IP protocol or whatever. And I don't want to. Enough. Global apologies to all. I hope we get this fixed soon. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 12:50:02 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 09:39:38 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: A package to contain Common LISP extensions. To: "common-lisp" Reply-To: "BACH::GREEK" Of course DEC's EXTENDED-LISP package would contain different things than Symbolic's. That's the purpose of the EXTENDED-LISP package. Perhaps LISP-EXTENSIONS would be a better name. I just think that everyone should agree on the name of the package to contain their extensions. Then a user would at least have a place to start. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 12:21:46 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 09:01:53 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3578; Mon 10-Mar-86 12:02:13-EST Date: Mon, 10 Mar 86 12:02 EST From: David C. Plummer Subject: LISP package To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860310120230.1.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 10 Mar 1986 09:16 EST From: "Scott E. Fahlman" I disagree rather strongly with the view that the Lisp package should be exactly those symbols defined in the Common Lisp manual and no others. My understanding of what these packages are for is based in part on the Zetalisp package system, which was the starting point for the one in Common Lisp. Please don't confuse the Zetalisp package system with the Zetalisp GLOBAL package. The GLOBAL package is a crock of which at least half is garbage and shouldn't be there. I'll let KMP tell you how it is hard enough to write portable programs with extensions to functions in the CL package, which will be after he tells you how to get screwed by having non-CLtL symbols in the LISP package, which I thought he did in his original message. The Lisp package has special status, in that it is the package that is included by default in all others. It wants to contain those symbols that should be accessible to typical applications in a given system -- the default set of accessible names. Wrong. The LISP package contains the Common Lisp language. Anything else, ANYTHING, is not Common Lisp, but rather an extension. Extensions belong in some other package or packages. Applications can use those other packages in addition to LISP. This is a matter of documentation by vendors for people writing such applications. The System package is for system-interface stuff and dangerous implementation-dependent operations that do not want to be trivially accessible to the average application. I agree that it would occasionally be useful to have a package that is guaranteed not to have anything in it that is not part of the Common Lisp standard. We could create a new package, named "standard" or something like that, to do this job. Or, I suppose, we could say that the Lisp package does this job, and create a new package named "default" or something that contains Common Lisp plus the local extensions. In that case, "default" would replace "lisp" as the package used by default when a new package is created. That's a more incompatible change for most implementaitons. I certainly do not like the idea of "system" being used to hold the local stuff, and of folding it into the default. Then we would just have to create another package to hold the dangerous "system" stuff like (rewind-the-disk). -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 11:58:55 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 08:50:51 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3570; Mon 10-Mar-86 11:51:04-EST Date: Mon, 10 Mar 86 11:51 EST From: David C. Plummer Subject: What packages contain. To: "BACH::GREEK" , common-lisp In-Reply-To: The message from "BACH::GREEK" Message-ID: <860310115122.8.DCP@NEPONSET.SCRC.Symbolics.COM> From: "BACH::GREEK" Two thing: (1) Your mailer is specifying a completely out-to-lunch date of Date: 0 0 00:00:00 EST and (2) there is no newline between your header and the first paragraph of text, which implies the text is still part of the header. I agree with Dave Plummer. That sounds like the best organization. LISP has only standard Common LISP stuff, and EXTENDED-LISP (say) has all other public things. SYSTEM just has system hackery. I don't think it should be called EXTENDED-LISP. DEC's EXTENDED-LISP package would not contain the same as Symbolic's EXTENDED-LISP package. Now, what the USER package should use and what MAKE-PACKAGE should use by default is still not completely clear. I agree, as I stated in my last message. I think USER should get everything (i.e., use both LISP and EXTENDED-LISP). Ditto. Perhaps this is the right default for MAKE-PACKAGE just for consistency's sake. I disagree. My current reason is that MAKE-PACKAGE is a CL tool to make CL packages, and EXTENDED-LISP is not part of the default CL packages. A person writing a layered product can just say to use only LISP. Continuing... A person writing a layered product on CL need only use MAKE-PACKAGE, which, after all, is pure CL. A person writing a layered product based on the extended features of some other package must explicitly use that package, which, after all, is not pure CL.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 11:53:39 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 08:43:16 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3567; Mon 10-Mar-86 11:43:34-EST Date: Mon, 10 Mar 86 11:43 EST From: David C. Plummer Subject: True, False To: Scott E. Fahlman , Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860310114351.7.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 10 Mar 1986 09:48 EST From: "Scott E. Fahlman" I've got no problem with the True and False functions, I guess. I'm not 100% sure that I like those names -- if I saw these in code, I would tend to assume that they were predicates more or less equivalent to (not (null ...)) and (null...). But I have nothing better to propose right now. KMP may have picked TRUE and FALSE for historical reasons. I wouldn't mind more descriptive names, possibly which imply they take a set and map the set to either boolean truth or boolean false. {-: Maybe we can call these functions T and NIL :-} Probably the best thing to do for now is to tack them onto the end of the error proposal in a section labeled "Extensions to the Language" or something like that. I'm glad to hear that the error proposal is moving along. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 11:29:07 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 10 Mar 86 08:19:10 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: What packages contain. To: "common-lisp" Reply-To: "BACH::GREEK" I agree with Dave Plummer. That sounds like the best organization. LISP has only standard Common LISP stuff, and EXTENDED-LISP (say) has all other public things. SYSTEM just has system hackery. Now, what the USER package should use and what MAKE-PACKAGE should use by default is still not completely clear. I think USER should get everything (i.e., use both LISP and EXTENDED-LISP). Perhaps this is the right default for MAKE-PACKAGE just for consistency's sake. A person writing a layered product can just say to use only LISP. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 10:54:06 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 07:41:29 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA21692; Mon, 10 Mar 86 08:43:44 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA23001; Mon, 10 Mar 86 08:43:40 MST Date: Mon, 10 Mar 86 08:43:40 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8603101543.AA23001@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Re: LISP Package In PCLS we've been very careful to export only standard things from LISP, and use SYSTEM for anything that is PCLS dependent. The theory is that it only takes one unqualified PCLS-specific symbol to ruin a programmer's whole day - porting is hard enough when the necessary changes are obvious! Even assuming something that every implementation "should have" (like MULTIPLE-VALUE-SETF) is questionable. I like Scott's suggestion of another package that exports exactly those symbols defined in the standard. Existing user programs needn't change, and if a user wanted to test for portability, s/he could tweak the list of default use packages from (LISP ...) to (STANDARD), and see what happens to the program... stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 10:48:46 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 10 Mar 86 07:36:51 PST Received: from HP-HULK by hplabs.ARPA ; Mon, 10 Mar 86 07:36:46 pst Date: Mon 10 Mar 86 07:36:28-PST From: Martin Subject: Packages To: common-LISP%su-ai@HPLABS Cc: GRISS%HP-HULK@HPLABS It seems to me that we do need a new package, called EXTENSIONS (or some such) for new language features and reserve SYSTEM for those really subtle/dangerous (rewind-the-disk -:) sort of things. I am bothered by the notion that the LISP package should include all kinds of implementation dependent symbols so that "other things can work". To some degree, the LISP package lists the reserved words (functions, globals, etc) of the Portable dialect. I would like to see some examples of things in different implementations that "MUST" be in LISP, yet are system dependent, rather than being candidates for inclusion in the next CLtL? Martin -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 10:41:38 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 10 Mar 86 07:27:52 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3525; Mon 10-Mar-86 10:28:09-EST Date: Mon, 10 Mar 86 10:28 EST From: David C. Plummer Subject: Can, could, may, might, must, ... To: Kent M Pitman , "BACH::GREEK" , Rob MacLachlan , Common-Lisp@SU-AI.ARPA In-Reply-To: <860309184822.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, The message from "BACH::GREEK" , Message-ID: <860310102822.0.DCP@NEPONSET.SCRC.Symbolics.COM> I disagree with some people's opinions about what packages should contain what. LISP should contain only those things that are in the Silver Bible, or ECO'd extensions. It should not include user interface things like QUIT and SAVE-ALL-BUFFERs. There should be a package that is defined by the vendor which contains that vendor's EXTENSIONS. Symbolics has the Symbolics-Common-Lisp package (aka SCL). This package contains language extensions and external user interface items ONLY. It is NOT the system package and it does NOT contain the implementation details (at least as exported symbols) of LISP or the extensions. This package is the one to :USE when writing Common Lisp programs specific to the vendor's system. To write portable code, :USE the LISP package. The extended package either uses and reexports all symbols in LISP, or imports and reexports to get the same effect. (This allows a package to :use the extended package without having to :use both. Maybe that isn't such a good idea, but that's who Symbolics does it and it doesn't bother me.) As stated above, the SYSTEM package is yet another beast. In the Symbolics system (and probably the other derivitives from the MIT Lisp Machine project), there are two rather different classes of things that show up in here. One class is the external interface to the operating system, such as SYSTEM:DISK-READ to issue a disk read. The other class is the internal interface to the machine, such as instructions. This has bothered me for a while, but I haven't had time to think about it much. The USER package can either use CL or use the extended CL package. Symbolics makes it use the extended CL package since the extended package contains a lot of user interface and is generally more useful than the bare CL package. USER does NOT use SYSTEM. The USER package is for dealing with the language and user interface, NOT the internals of the implementation or the operating system. Personally, I always specify a default for MAKE-PACKAGE :USE. That's probably because our default is to :USE only LISP, which I think is the right thing. :USE'ing any other packages would lead to name conflicts KMP is trying to avoid. The most important thing that I agree with KMP about is that the LISP package contains only those symbols in CLtL.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 10:25:32 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 07:17:24 PST Received: ID ; Mon 10 Mar 86 09:51:03-EST Date: Mon, 10 Mar 1986 09:50 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: (LOAD ... :VERBOSE T) In Spice Lisp, the :verbose option to load prints just an introductory and completion message, while the :print option says something for each item loaded. I think that this is what page 426 is trying to tell us, though I admit that :verbose is described so loosely as to allow all sorts of stuff to be printed. I would suggest a clarification that says that :verbose is intended to print some useful information about the file itself, but should not print anything about individual items in the file. It's too bad we chose those names, because they are confusing. :verbose isn't very verbose and is not the most verbose of the available options. I think we followed Maclisp in this. If the world were young, I would suggest that :verbose print a comment for each item loaded, that the default be to print just the "Loading FOO ...done." message, and that there be a :silent keyword when you want to suppress all printout. But this is probably not important enough to be worht an incompatible change. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 10:23:28 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 07:14:54 PST Received: ID ; Mon 10 Mar 86 09:48:39-EST Date: Mon, 10 Mar 1986 09:48 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: True, False I've got no problem with the True and False functions, I guess. I'm not 100% sure that I like those names -- if I saw these in code, I would tend to assume that they were predicates more or less equivalent to (not (null ...)) and (null...). But I have nothing better to propose right now. Probably the best thing to do for now is to tack them onto the end of the error proposal in a section labeled "Extensions to the Language" or something like that. I'm glad to hear that the error proposal is moving along. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 10:07:21 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 06:43:20 PST Received: ID ; Mon 10 Mar 86 09:17:00-EST Date: Mon, 10 Mar 1986 09:16 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: LISP package I disagree rather strongly with the view that the Lisp package should be exactly those symbols defined in the Common Lisp manual and no others. My understanding of what these packages are for is based in part on the Zetalisp package system, which was the starting point for the one in Common Lisp. The Lisp package has special status, in that it is the package that is included by default in all others. It wants to contain those symbols that should be accessible to typical applications in a given system -- the default set of accessible names. The System package is for system-interface stuff and dangerous implementation-dependent operations that do not want to be trivially accessible to the average application. I agree that it would occasionally be useful to have a package that is guaranteed not to have anything in it that is not part of the Common Lisp standard. We could create a new package, named "standard" or something like that, to do this job. Or, I suppose, we could say that the Lisp package does this job, and create a new package named "default" or something that contains Common Lisp plus the local extensions. In that case, "default" would replace "lisp" as the package used by default when a new package is created. That's a more incompatible change for most implementaitons. I certainly do not like the idea of "system" being used to hold the local stuff, and of folding it into the default. Then we would just have to create another package to hold the dangerous "system" stuff like (rewind-the-disk). -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 10 Mar 86 04:04:48 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 Mar 86 00:54:10 PST Received: ID ; Mon 10 Mar 86 03:27:52-EST Date: Mon, 10 Mar 1986 03:27 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: which package... The Spice Lisp packaging rules are someething like this: LISP Anything which is: 1] Defined in the manual. 2] Needed to support something in the manual, e.g. debugger commands. 3] A potentially portable language extension, e.g. MULTIPLE-VALUE-SETF. 4] User interface commands which should always be availble, e.g. QUIT and SAVE-ALL-BUFFERS. SYSTEM Random implementation constants and system interface facilities. The idea is that all symbols which are needed for writing portable programs are available from the LISP package. Packages only use type SYSTEM package if they are doing system hacking. The only reservation I have about this scheme is with the "portable extensions" being exported from the LISP package. It would probably be a good idea to put them somewhere else. It seems that the big discrepancy between what we are doing and what other people advocate has to do with the SYSTEM package. There seem to be two interpretations of what the SYSTEM package is for: 1] The system package provides facilities needed for systems programming. (Spice Lisp) 2] The system package provides system dependent user interface facilities. (Greek, KMP) In the first case, random users clearly don't want to use the SYSTEM package. In the second case, they definitely do. I would argue that if the system package has facilities which you always want to be there, then it should be in the default use list. From: "BACH::GREEK" Subject: What's in the standard packages? 1. The LISP package should have external symbols which exactly are the Common LISP standard. Symbols not mentioned in the manual may need to be exported from LISP in order for things to work. This is because environment interface functions are incompletely defined in the manual. It would be silly to export a function from LISP and not be able to use it beacuse some magic frob it needs isn't available. 2. Either the SYSTEM package or some implementation-specific package should contain any implementation extensions to Common LISP. Might as well make this the SYSTEM package. I don't think extensions should come from the SYSTEM package. It seems to me that there is a difference between a language extension and a system dependent feature. 3. The USER package should use both the LISP and SYSTEM packages. 4. What should MAKE-PACKAGE use by default? Clearly the LISP package. Probably not the SYSTEM package, although this would result in an incompatible change for any implementation that currently puts all public symbols in the LISP package. Such is life. It is pretty wierd to say that USER should use the SYSTEM package yet the default shouldn't include SYSTEM. USER is nothing if not the default environment. Date: Sunday, 9 March 1986 18:48-EST From: Kent M Pitman Re: Can, could, may, might, must, ... The manual seems to take no stand on what should -not- be in the LISP package. It says that the things in the book should be, but it does not say, for example, whether it's appropriate to have the LISP package use the SYSTEM package. ... The main reason is that this makes porting between dialects a pain. Suppose that some implementation has a symbol SYSTEM:FOO which is a system constant. CLtL does not prohibit that symbol being placed on the LISP package. But if I build and application which builds a package on LISP, I have no assurance that doing (DEFVAR FOO 3) will not be trying to redefine a system constant. ... This seems confused. The packages which LISP uses has no effect on packages which use LISP, since inherited symbols become internal symbols. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 20:27:59 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 17:22:54 PST Received: from HP-HULK by hplabs.ARPA ; Sun, 9 Mar 86 17:23:03 pst Date: Sun 9 Mar 86 17:22:44-PST From: Martin Subject: TRUE and FALSE as n-ary functions To: common-lisp%su-ai@HPLABS Cc: GRISS%HP-HULK@HPLABS I am in favor of Kents proposal to add TRUE and FALSE as predefined n-ary functions. M -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 20:25:58 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 9 Mar 86 17:19:05 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Putting the company name in the *FEATURES* list. To: "common-lisp" Reply-To: "BACH::GREEK" We at Digital didn't put our name in the *FEATURES* list, although I'm not sure why. We did put VAX, COMMON, and VMS or ULTRIX in, I think. Hell, the community can't even agree that COMMON ought to go in for Common LISP. I guess I agree that it would be useful. However, some of the #+ and #- expressions are going to be frightening. I pity the poor developer who has to worry about all these differences. I also think this is all semi-useless without an official registrar for company names, dialect names, operating system names, machine names, etc. Different people are going to assume different spellings and abbreviations for the same entity. A few companies even have the same acronym. Shall we add DEC, DIGITAL, or DIGITAL-EQUIPMENT-CORPORATION to the *FEATURES* list? If you'll remember, I offered to be the Common LISP registrar about six months ago. That went over like a lead balloon. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 19:46:16 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 16:39:25 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433748; Sun 9-Mar-86 19:38:21-EST Date: Sun, 9 Mar 86 19:38 EST From: Kent M Pitman Subject: *FEATURES* To: Common-Lisp@SU-AI.ARPA Message-ID: <860309193858.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> It would be nice if every company which makes a Common-Lisp would be kind enough to put some symbol on *FEATURES* which is the trademarked name of its company. It would seem an obvious enough request, but I've discovered at least one company that didn't do this; it had features for things like operating system, machine type, Common Lisp, etc. but there could be instances of more than one dialect of CL running under the same machine type, operating system, etc if they were supplied by different vendors. For the sake of hacking non-portable sections of code, it would be nice if by convention all implementors could be convinced to do this -- and a later edition of CLtL would remind them of such. eg, #+SYMBOLICS works in any of our implementations. If other vendors each make sure their company's name is on their *FEATURES* list, it could save people the hassle of doing something silly, obscure, and unreliable like: (WHEN (FBOUNDP 'SYSTEM::FROB-SOMETHING-SOMEHOW) ;; Surely only the ACME computer company ever uses such a function name (PUSH 'ACME *FEATURES*)) I guess it should go without saying but since nothing seems to I'll say it anyway -- vendors who provide layered products should not, in general, add their names to the *FEATURES* list or the whole thing would end up meaningless. That is, if DEC decided to write an editor which ran on a 3600, they might add a feature to *FEATURES* on the 3600, but would not add the feature DEC. I say "in general" because in a few rare cases it might be useful to commit an outright lie (in a well-documented fashion, of course) -- cross compilation is one situation where that issue might come up. All suggestions above refer only to what should go in the CL implementor's guide (I forget the relevant page color), and not necessarily to what, if anything, should go in the CL language spec itself.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 19:45:18 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 9 Mar 86 16:39:05 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: What's in the standard packages? To: "common-lisp" Reply-To: "BACH::GREEK" Silly mailer software. I agree with Kent that we should specify more exactly what's in the standard packages. Here, I think, are the issues: 1. The LISP package should have external symbols which exactly are the Common LISP standard. 2. Either the SYSTEM package or some implementation-specific package should contain any implementation extensions to Common LISP. Might as well make this the SYSTEM package. 3. The USER package should use both the LISP and SYSTEM packages. 4. What should MAKE-PACKAGE use by default? Clearly the LISP package. Probably not the SYSTEM package, although this would result in an incompatible change for any implementation that currently puts all public symbols in the LISP package. Such is life. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 19:20:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 16:14:04 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433738; Sun 9-Mar-86 19:13:08-EST Date: Sun, 9 Mar 86 19:13 EST From: Kent M Pitman Subject: Not just ~C, but ~A To: Common-Lisp@SU-AI.ARPA Message-ID: <860309191344.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> This note is intended to amplify the remarks made by greek@hudson the other day about ~C. In VAXLISP, (FORMAT NIL "~C" #\Space) => "Space". In Zetalisp, (FORMAT NIL "~C" #\Space) => " ". Since the manual allows implementations to do what they want, neither of these can easily be claimed to be a simple bug. Worse, however, is that none of the description of ~A, PRINC, or *PRINT-ESCAPE* give me the sense of confidence that (FORMAT NIL "~A" #\Space) will come out with " " rather than "Space" or "#Space" since they all talk about doing like PRIN1 but without escape characters. Since neither ~C nor ~A seems to specify for sure that it will output #\Space as a space, the bottom line seems to be that CL does not specify a format op (other than ~Q) which can reliably do the job! This is a sad situation indeed. I hope we can promptly clarify the behaviors of ~A and ~C in this regard. At the same time, it would be good if any clarifications discussed what should happen for characters which are not STRING-CHAR-P. I'd be content to see a variety of things happen in this situation, but I'd like us to take some firmer stand if we could agree to. However, if we couldn't come to an agreement on that, it certainly shouldn't keep us from fixing the problem for the common case of things that are STRING-CHAR-P.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 19:04:59 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 15:57:55 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433729; Sun 9-Mar-86 18:56:49-EST Date: Sun, 9 Mar 86 18:57 EST From: Kent M Pitman Subject: (LOAD ... :VERBOSE T) To: Common-Lisp@SU-AI.ARPA Message-ID: <860309185727.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Can we get some clarification about what is meant by :VERBOSE T to LOAD? There is verbose and then there's VERBOSE. Without specifying exactly what is typed out, we should give guidelines about what kinds of things should or could be typed out. In particular, some implementations seem to do: (LOAD "foo" :VERBOSE T) Loading "foo" ... done. while others do: (LOAD "foo" :VERBOSE T) Started loading the file "foo" Variable *JOE* Variable *MARY* Variable *SPOT* Function RUN Function PLAY Function WORK Done loading the file "foo" I certainly don't mind an implementation providing a way to get the latter information, since it's sometimes quite useful. I do, however, mind having the :VERBOSE keyword be the way to turn that information on because it forces me to do the following: #-OVERLY-VERBOSE (LOAD FILE :VERBOSE T) #+OVERLY-VERBOSE (LET ((PATH (PROBEF FILE))) (FORMAT T "~&Loading ~A ..." PATH) (LOAD PATH :VERBOSE NIL) (FORMAT T " done.~%")) I presume the reason that we provided :VERBOSE in the first place was to be able to provide a portable way to get around writing standard idioms like this.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 18:55:03 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 15:48:44 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433720; Sun 9-Mar-86 18:47:45-EST Date: Sun, 9 Mar 86 18:48 EST From: Kent M Pitman Subject: Can, could, may, might, must, ... To: Common-Lisp@SU-AI.ARPA Message-ID: <860309184822.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> The manual seems to take no stand on what should -not- be in the LISP package. It says that the things in the book should be, but it does not say, for example, whether it's appropriate to have the LISP package use the SYSTEM package. Could we get people to agree that this should be discouraged, explicitly in the next edition of the manual and socially until then? The main reason is that this makes porting between dialects a pain. Suppose that some implementation has a symbol SYSTEM:FOO which is a system constant. CLtL does not prohibit that symbol being placed on the LISP package. But if I build and application which builds a package on LISP, I have no assurance that doing (DEFVAR FOO 3) will not be trying to redefine a system constant. It forces you to shadow a different set of symbols on in virtually every implementation that you want to port to, which seems counter to our goals in creating CL in the first place. I suggest that it be made explicitly appropriate that the USER package could inherit from the SYSTEM package, so that functions like SYSTEM:LOGIN, SYSTEM:HELP, SYSTEM:SUSPEND, and so on could be made available to users in the default start-up environment without infecting portable code modules that want to start out in a sterile environment.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 18:47:05 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 15:40:29 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 433716; Sun 9-Mar-86 18:39:32-EST Date: Sun, 9 Mar 86 18:40 EST From: Kent M Pitman Subject: TRUE, FALSE To: Common-Lisp@SU-AI.ARPA Message-ID: <860309184010.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> For the next edition, could we introduce functions TRUE and FALSE which have these definitions: TRUE &rest ignored-arguments [Function] Returns true (ie, the symbol T). FALSE &rest ignored-arguments [Function] Returns false (ie, the symbol NIL). There are places in the error proposal that I'm about to send out to CL-ERROR-HANDLING which have to use #'(LAMBDA (IGNORE) T) or similar silliness to get around the fact that #'TRUE and #'FALSE don't exist. Since these are not something that should go into the error handling chapter, I'm reluctant to include them directly in that proposal. By the way, I've observed these to be functions that people write a lot anyway. Unfortunately, some people/implementations write them with one argument and some with zero; in my experience, very few people have had the forethought to generalize their variants to be nary functions. So, when other applications come along later that want to use them with a different number of arguments, they can't always do so. Having them built into the language would help reduce this incident rate of this problem.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 17:40:07 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 9 Mar 86 14:33:45 PST Date: Sun, 9 Mar 86 17:34:31 EST From: Richard Mark Soley Subject: IGNORABLE. To: preece%ccvaxa@GSWD-VMS.ARPA cc: COMMON-LISP@SU-AI.ARPA In-reply-to: Msg of Fri 7 Mar 86 15:42:14 cst from preece%ccvaxa at gswd-vms (Scott E. Preece) Message-ID: <[MC.LCS.MIT.EDU].844192.860309.SOLEY> Date: Fri, 7 Mar 86 15:42:14 cst From: preece%ccvaxa at gswd-vms (Scott E. Preece) I vote for (declare (ignore-if-unsused ...)) as more specific than (declare (ignorable ...)). I agree we need some feature like this. However, this "declare ignore" stuff is really nonsense -- what we're talking about is *suppressing warning messages*, not something akin to "declare special." How about a general approach, like (supress-compiler-warnings (unused-variable x y z) (undefined-function glorp) . . .) Put it inside DECLARE, if you want. -- Richard  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 9 Mar 86 14:46:42 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 9 Mar 86 11:40:28 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA03193; Sun, 9 Mar 86 12:42:46 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA20539; Sun, 9 Mar 86 12:42:43 MST Date: Sun, 9 Mar 86 12:42:43 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8603091942.AA20539@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Re: ignorable I don't understand why everyone is getting so excited about a declaration of IGNORABLE for variables. So far as I can tell, its sole purpose in life is to suppress some compiler warnings - it has no effect on either the performance or correctness of code. But IGNORABLE opens up a whole can of worms - what about all the other kinds of warnings that people's compilers might want to issue? How about a (PROCLAIM 'CONSTANTS-MIGHT-BE-REBOUND)? Or (PROCLAIM 'TYPE-ERRORS-NO-PROBLEM)? Trying to ensure that your program will go on all compilers in the world without any warnings whatsoever is probably a lost cause. The only way I know of to get this degree of portability is to use exactly the same implementation code on all machines a la PSL... I'm not saying that IGNORABLE is bad - I just don't think it's worth writing into an already huge language standard, and if *that* gets in, everybody who has a desirable but sometimes annoying warning message in their implementation is going to want to include a control frob in the standard. (Remember UNSPECIAL, and the discussion about general undos that it precipitated? Does anybody still want to incorporate a general UNDO in CL?) For instance, PSL has a warning about strings that go over the end of the line, and it warns about users redefining "system" functions, and it puts out a message everytime a function is redefined, and it warns about attempts to redefine constants, and... Every one of these is ideally controlled by its very own declaration! stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Mar 86 17:45:30 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 8 Mar 86 14:39:02 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: IGNORE and friends. To: "common-lisp" Reply-To: "BACH::GREEK" I think "ignore" means "I, the programmer, am going to ignore this variable". Therefore the compiler has the right to complain if in fact you didn't ignore it, but used it. If you buy that, then "ignore-if-unused" isn't in the right person, since it means "please, compiler, ignore this if I don't use it." Note the inconsistency in person. Thus I propose "maybe-ignore", which means "I, the programmer, may ignore this variable, or I may not." Now if you think that "ignore" really means "please ignore this variable, Mr. compiler" then the compiler has no right to complain one way or the other about the variable, since you told it to ignore the variable. Critical stuff. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Mar 86 15:23:35 EST Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 8 Mar 86 12:16:26 PST Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA02896; Fri, 7 Mar 86 15:42:59 CST Message-Id: <8603072142.AA02896@gswd-vms.ARPA> Date: Fri, 7 Mar 86 15:42:14 cst From: preece%ccvaxa@gswd-vms (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: IGNORABLE. I vote for (declare (ignore-if-unsused ...)) as more specific than (declare (ignorable ...)). Please let's make one of them part of the standard.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 16:30:33 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 7 Mar 86 11:55:04 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3218; Fri 7-Mar-86 14:55:16-EST Date: Fri, 7 Mar 86 14:55 EST From: David C. Plummer Subject: Need for (declare (ignorable ...)) To: Skef Wholey , Jonathan A Rees cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860307145510.0.DCP@NEPONSET.SCRC.Symbolics.COM> Suppose a rather smart compiler that knows if things are being evaluated for effect or for value, and if functions are meant to be called for effect or for value. It would be rather natural for such a compiler to warn if you are using something for effect which has absolutely no side effects. A reference to a variable, as in (defun foo (x) x 'bar) could be considered 'an error in semantics' and the compiler might be justified in producing a warning. Likewise (defun foo (x) (cons x x) 'bar) could be considered an error. Granted, it side effects the consing system, the storage system, the paging system and the GC, but those are supposed to be invisible to Lisp. I'm not saying free references to variables should produce these warnings. Because we don't currently have an IGNORABLE declaration, it probably shouldn't. If and when we do, I personally would probably lean toward encouraging compilers to issue warnings under these circumstances.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 16:28:15 EST Received: from KIM.BERKELEY.EDU by SU-AI.ARPA with TCP; 7 Mar 86 11:52:51 PST Received: by kim.berkeley.edu (5.45/1.8) id AA02587; Fri, 7 Mar 86 11:51:53 PST Received: from fimass by franz (5.5/3.14) id AA08800; Fri, 7 Mar 86 11:26:23 PST Received: by fimass (5.5/3.14) id AA01640; Fri, 7 Mar 86 10:23:07 PST Date: Fri, 7 Mar 86 10:23:07 PST From: franz!fimass!jkf@kim.berkeley.edu (John Foderaro) Return-Path: Message-Id: <8603071823.AA01640@fimass> To: jar@mit.lcs.mit.edu Subject: Re: Need for (declare (ignorable ...)) Cc: common-lisp@su-ai.arpa In-Reply-To: Your message of Fri, 7 Mar 86 13:05:09 EST We also found such a declaration to be necessary and added it to our common lisp. However, the name is 'ignore-if-unused', not 'ignorable'. john foderaro  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 14:21:49 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 86 11:11:22 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 432906; Fri 7-Mar-86 13:57:04-EST Date: Fri, 7 Mar 86 13:57 EST From: Kent M Pitman Subject: IGNORABLE To: JAR@MIT-MC.ARPA cc: Common-Lisp@SU-AI.ARPA Message-ID: <860307135721.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 7 Mar 86 13:05:09 EST From: Jonathan A Rees Common Lisp (and in fact, every language that has variables) needs a (DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not be used, and I don't want the compiler to generate a warning in either case. There is no way to simulate this feature in Common Lisp. ... While I agree that (DECLARE (IGNORABLE ...)) would be nice. I dispute your contention that you can't simulate this feature. I always just write: (DEFMACRO WITH-FOO (&BODY BODY) `(LET ((FOO (COMPUTE-FOO))) FOO ;ignorable ,@(OR BODY '(NIL)))) I've never seen a reasonable Lisp compiler that didn't handle this correctly. I would even argue that it is indirectly implied by the language specification that this must work, and that it's a bug if a compiler warns either about no FOO in body or a FOO in body. -kmp ps Please no discussion about what happens if BODY begins with a DECLARE form. The example above is obviously oversimplified in that respect, but adequate discussion of that issue has already taken place and isn't relevant here.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 13:52:38 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 7 Mar 86 10:40:28 PST Received: ID ; Fri 7 Mar 86 13:40:51-EST Date: Fri, 7 Mar 1986 13:40 EST Message-ID: Sender: WHOLEY@C.CS.CMU.EDU From: Skef Wholey To: Jonathan A Rees Cc: common-lisp@SU-AI.ARPA Subject: Need for (declare (ignorable ...)) In-reply-to: Msg of 7 Mar 1986 13:05-EST from Jonathan A Rees Date: Friday, 7 March 1986 13:05-EST From: Jonathan A Rees Re: Need for (declare (ignorable ...)) Common Lisp (and in fact, every language that has variables) needs a (DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not be used, and I don't want the compiler to generate a warning in either case. ... Have other people suffered from this lack, or do I just write particularly perverse macros? I think the problem is widespread enough to warrant something with the effect of that declaration. A change like this will probably take years to become "real Common Lisp," but there are other ways around this. One writer of system code in the Spice Lisp system ran into this problem, and just added references to the "ignorable" variables right after their binding. When we switched to a new compiler, which was smarter in a number of ways, warnings were generated because the referenced-p slot of the variable's compiler data structure wasn't set when the variable reference could be optimized away. By lobbying hard, I was able to convince the compiler writer (Scott Fahlman), that the right thing to do IS to count that reference, since dummy references are the only way to supress warnings in such cases, AND since optimization is the compiler's business, references should be counted as they are written, not as they appear in code. For instance, generating a warning that an index variable is not referenced after the compiler has unrolled a loop would be truly asinine. So, I would suggest that Common Lisp compilers treat all references equally in this respect, even though some may be optimized away. Then writers of hairy macros can insert references to these variables and be sure of getting only valid warnings. Side note: Most "portable" Common Lisp code I've had to deal with generates all kinds of warnings when compiled. It's not clear if this is because different implementations warn about different things or if the code needs ignore declarations, or whatever, but it would be nice if people would try to make such code compile without warnings before inviting other people to use it. --Skef  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 13:48:56 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 7 Mar 86 10:33:23 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3184; Fri 7-Mar-86 13:33:39-EST Date: Fri, 7 Mar 86 13:33 EST From: David C. Plummer Subject: Need for (declare (ignorable ...)) To: Jonathan A Rees , common-lisp@SU-AI.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].842283.860307.JAR> Message-ID: <860307133328.6.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Fri, 7 Mar 86 13:05:09 EST From: Jonathan A Rees Common Lisp (and in fact, every language that has variables) needs a (DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not be used, and I don't want the compiler to generate a warning in either case. I agree. There is no way to simulate this feature in Common Lisp. If there is no such declaration, and X isn't used, then I get a warning message X bound but not used; if I use (DECLARE (IGNORE X)), and X is used, then I get a warning message saying that X was declared ignored but in fact was used. I wouldn't want to change either of these features of Common Lisp compilers. (defun foo (x) x 'bar) Is one possible workaround, but it doesn't make it obvious what the intent is. In Symbolics Common Lisp, you can do (defun foo (x) (ignore x) 'bar) which is a common cliche because the IGNORABLE declaration doesn't exist. The IGNORABLE declaration is needed for applications where code is automatically generated, say, by a macro or a compiler. A macro, especially, is not in a good position to know whether a variable is being referenced. A sledgehammer like a code traversal tool shouldn't be required for this simple application. It has been in T (Yale Scheme) since 1981, and has proved very useful. Have other people suffered from this lack, or do I just write particularly perverse macros? Jonathan Rees  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 13:29:19 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Mar 86 10:20:17 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: IGNORABLE. To: "common-lisp" Reply-To: "BACH::GREEK" Silly software! A DECLARE IGNORABLE would indeed be quite useful. I don't think Jonathan writes particularly perverse macros. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 13:11:39 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 Mar 86 10:04:25 PST Date: Fri, 7 Mar 86 13:05:09 EST From: Jonathan A Rees Subject: Need for (declare (ignorable ...)) To: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].842283.860307.JAR> Common Lisp (and in fact, every language that has variables) needs a (DECLARE (IGNORABLE ...)) in addition to (DECLARE (IGNORE ...)). The meaning of (DECLARE (IGNORABLE X)) is: the variable X might or might not be used, and I don't want the compiler to generate a warning in either case. There is no way to simulate this feature in Common Lisp. If there is no such declaration, and X isn't used, then I get a warning message X bound but not used; if I use (DECLARE (IGNORE X)), and X is used, then I get a warning message saying that X was declared ignored but in fact was used. I wouldn't want to change either of these features of Common Lisp compilers. The IGNORABLE declaration is needed for applications where code is automatically generated, say, by a macro or a compiler. A macro, especially, is not in a good position to know whether a variable is being referenced. A sledgehammer like a code traversal tool shouldn't be required for this simple application. It has been in T (Yale Scheme) since 1981, and has proved very useful. Have other people suffered from this lack, or do I just write particularly perverse macros? Jonathan Rees  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 10:50:29 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 7 Mar 86 07:42:05 PST Date: 7 Mar 1986 10:40-EST Sender: NGALL@G.BBN.COM Subject: Re: The ~C format directive From: NGALL@G.BBN.COM To: greek%bach.decnet@HUDSON.DEC.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM] 7-Mar-86 10:40:21.NGALL> In-Reply-To: The message of 0 0 00:00:00 EST from "BACH::GREEK" From: "BACH::GREEK" Subject: The ~C format directive Does anyone have a guess as to what the ~C format directive (without any modifiers) is supposed to do? CLtL says "prints the character in an implementation-dependent abbreviated format." At least one person has said they think it should just throw the character at the terminal, as with ~A. I agree. Currently, VAX LISP prints it like ~S would, abbreviating any control bits down to one letter. This seems right according to the rationale given under the description of ~C. But then one can't use any variant of ~C to just throw the character at the terminal. ~@C should be used to print a char. in a readable way (i.e. "like ~S would"). Any opinions? - Paul ------ -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 10:42:25 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 7 Mar 86 07:34:29 PST Date: 7 Mar 1986 10:32-EST Sender: NGALL@G.BBN.COM Subject: Re: initforms and implicit blocks From: NGALL@G.BBN.COM To: apollo!dfm@UW-BEAVER.ARPA Cc: COMMON-LISP@SU-AI.ARPA Message-ID: <[G.BBN.COM] 7-Mar-86 10:32:17.NGALL> In-Reply-To: <8603070500.AA16622@uw-beaver.arpa> Date: Thu, 6 Mar 86 17:18:28 EST From: apollo!dfm@uw-beaver.arpa To: COMMON-LISP@su-ai.arpa Subject: initforms and implicit blocks Message-ID: <8603070500.AA16622@uw-beaver.arpa> Apologies if this has been discussed before. Are initforms in &optional, &key, and &aux parameters evaluated inside or outside the implicit block provided by defun and friends? In particular, should the following return t or nil? (block f (labels ((f (&optional (x (return-from f nil))))) (f) t) ) As near as I can tell CLtL is silent on this. Perhaps it simply "is an error" to depend on either behavior? At first glance, it seems most tasteful to have them evaluated within the implicit block. - Don Morrison -------------------- On pg 67: "The FORMS constitute the body of the defined function..." "The body of the defined function is implicitly enclosed in a BLOCK construct..." I think this strongly implies that the init forms are not enclosed by the BLOCK, since they are not part of the body by this definition. Since this definition of body is somewhat at odds with the definition of body used in the DECL. chapter (pg 155), the fact that init forms are not enclosed in the block should be made explicit. Of course, I would prefer that init forms were considered part of the body in all contexts (hence one could do returns in them), but I think most implementations have already done it the easy way. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 10:38:04 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Mar 86 07:30:10 PST Received: from nymphodora by GODOT.THINK.COM via CHAOS; Fri, 7 Mar 86 10:30:42 est Date: Fri, 7 Mar 86 10:32 EST From: Guy Steele Subject: get-setf-method To: DCP@SCRC-QUABBIN.ARPA, hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860307092548.2.DCP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <860307103246.2.GLS@THINK-NYMPHODORA.ARPA> Date: Fri, 7 Mar 86 09:25 EST From: David C. Plummer FYI, I'm pretty sure we already convinced GLS that get-setf-methods MUST NOT be passed an already macro-expanded form, which implies it must get an environment so it can do its own macroexpansions, as you notice the SPICE code does. ... That is correct. I was wedged. GET-SETF-METHODS must take an environment argument. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 10:34:06 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 7 Mar 86 07:27:09 PST Received: from nymphodora by GODOT.THINK.COM via CHAOS; Fri, 7 Mar 86 10:27:41 est Date: Fri, 7 Mar 86 10:29 EST From: Guy Steele Subject: What is that -*- line for, anyway? To: DLW@SCRC-QUABBIN.ARPA, GJC@MC.LCS.MIT.EDU Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <860307002413.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <860307102943.1.GLS@THINK-NYMPHODORA.ARPA> Date: Fri, 7 Mar 86 00:24 EST From: Daniel L. Weinreb Date: Tue, 4 Mar 86 23:18:16 EST From: "George J. Carrette" Q: Who invented the file mode line in EMACS? I'm not sure whether it was Moon, Steele, or Stallman. Not me. Probably Stallman. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 10:09:14 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Mar 86 06:59:25 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: List of Changes To: "common-lisp" Reply-To: "BACH::GREEK" I second the motion for an up-to-date list of proposed changes. In fact, a complete list of every single proposed changed to CLtl, even typos and nits, would be great. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 10:07:48 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 7 Mar 86 06:59:09 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: The ~C format directive To: "common-lisp" Reply-To: "BACH::GREEK" Does anyone have a guess as to what the ~C format directive (without any modifiers) is supposed to do? CLtL says "prints the character in an implementation-dependent abbreviated format." At least one person has said they think it should just throw the character at the terminal, as with ~A. Currently, VAX LISP prints it like ~S would, abbreviating any control bits down to one letter. This seems right according to the rationale given under the description of ~C. But then one can't use any variant of ~C to just throw the character at the terminal. Any opinions? - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 09:32:31 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 7 Mar 86 06:25:36 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3109; Fri 7-Mar-86 09:25:57-EST Date: Fri, 7 Mar 86 09:25 EST From: David C. Plummer Subject: get-setf-method To: hpfclp!diamant@HPLABS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 6 Mar 86 20:54-EST from hpfclp!diamant@hplabs.ARPA Message-ID: <860307092548.2.DCP@NEPONSET.SCRC.Symbolics.COM> FYI, I'm pretty sure we already convinced GLS that get-setf-methods MUST NOT be passed an already macro-expanded form, which implies it must get an environment so it can do its own macroexpansions, as you notice the SPICE code does. Maybe we need an up-to-date list of proposed changes which incorporates the discussions generated by the last list?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 02:41:47 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 Mar 86 23:28:22 PST Received: ID ; Fri 7 Mar 86 01:59:11-EST Date: Fri, 7 Mar 1986 01:28 EST Message-ID: From: Rob MacLachlan To: apollo!dfm@UW-BEAVER.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: initforms and implicit blocks In-reply-to: Msg of Thu 6 Mar 86 17:18:28 EST from apollo!dfm at uw-beaver.arpa Date: Thu, 6 Mar 86 17:18:28 EST From: apollo!dfm at uw-beaver.arpa Re: initforms and implicit blocks Are initforms in &optional, &key, and &aux parameters evaluated inside or outside the implicit block provided by defun and friends? ... At first glance, it seems most tasteful to have them evaluated within the implicit block. What could DEFUN expand into which would place the arguments within the scope of the block? The obvious expansion of DEFUN is something like: (setf (symbol-function ') #'(lambda (block )) Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 02:32:46 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 6 Mar 86 21:18:29 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3054; Fri 7-Mar-86 00:18:43-EST Date: Fri, 7 Mar 86 00:24 EST From: Daniel L. Weinreb Subject: What is that -*- line for, anyway? To: GJC@MC.LCS.MIT.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].839063.860304.GJC> Message-ID: <860307002413.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 4 Mar 86 23:18:16 EST From: "George J. Carrette" Q: Who invented the file mode line in EMACS? I'm not sure whether it was Moon, Steele, or Stallman. Q: Who decided to extend this to the file attribute line syntax on the Lispm? I did. However, speaking as the definer of the file attribute line, I do not think that we should make any attempt to standardize on it. It's part of the programming environment, not the language, and it would be a big mistake to start slipping into the programming environment business. Yes, one does need some kind of facility to solve the problems that the file attribute line solves. But this should not be part of the CL standard. For one thing, as Miller points out, when you have make-system, you now have an alternative method of saying things about packages of files. The CL spec should not forbid this or interfere with it. For another, in our next generation of software development environment tools, the way to solve the problem will not be with a file attribute line at all. I don't want to be stuck with the file attribute line as part of a standard when I can already see a near future in which it is obsolete.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 02:32:23 EST Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 20:54:22 PST Received: by uw-beaver.arpa (4.42/4.2) id AA16622; Thu, 6 Mar 86 21:00:50 PST Return-Path: Message-Id: <8603070500.AA16622@uw-beaver.arpa> From: apollo!dfm@uw-beaver.arpa Date: Thu, 6 Mar 86 17:18:28 EST Subject: initforms and implicit blocks To: COMMON-LISP@su-ai.arpa Apologies if this has been discussed before. Are initforms in &optional, &key, and &aux parameters evaluated inside or outside the implicit block provided by defun and friends? In particular, should the following return t or nil? (block f (labels ((f (&optional (x (return-from f nil))))) (f) t) ) As near as I can tell CLtL is silent on this. Perhaps it simply "is an error" to depend on either behavior? At first glance, it seems most tasteful to have them evaluated within the implicit block. - Don Morrison  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 00:27:16 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 6 Mar 86 21:18:29 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 3054; Fri 7-Mar-86 00:18:43-EST Date: Fri, 7 Mar 86 00:24 EST From: Daniel L. Weinreb Subject: What is that -*- line for, anyway? To: GJC@MC.LCS.MIT.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].839063.860304.GJC> Message-ID: <860307002413.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 4 Mar 86 23:18:16 EST From: "George J. Carrette" Q: Who invented the file mode line in EMACS? I'm not sure whether it was Moon, Steele, or Stallman. Q: Who decided to extend this to the file attribute line syntax on the Lispm? I did. However, speaking as the definer of the file attribute line, I do not think that we should make any attempt to standardize on it. It's part of the programming environment, not the language, and it would be a big mistake to start slipping into the programming environment business. Yes, one does need some kind of facility to solve the problems that the file attribute line solves. But this should not be part of the CL standard. For one thing, as Miller points out, when you have make-system, you now have an alternative method of saying things about packages of files. The CL spec should not forbid this or interfere with it. For another, in our next generation of software development environment tools, the way to solve the problem will not be with a file attribute line at all. I don't want to be stuck with the file attribute line as part of a standard when I can already see a near future in which it is obsolete.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 7 Mar 86 00:07:39 EST Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 20:54:22 PST Received: by uw-beaver.arpa (4.42/4.2) id AA16622; Thu, 6 Mar 86 21:00:50 PST Return-Path: Message-Id: <8603070500.AA16622@uw-beaver.arpa> From: apollo!dfm@uw-beaver.arpa Date: Thu, 6 Mar 86 17:18:28 EST Subject: initforms and implicit blocks To: COMMON-LISP@su-ai.arpa Apologies if this has been discussed before. Are initforms in &optional, &key, and &aux parameters evaluated inside or outside the implicit block provided by defun and friends? In particular, should the following return t or nil? (block f (labels ((f (&optional (x (return-from f nil))))) (f) t) ) As near as I can tell CLtL is silent on this. Perhaps it simply "is an error" to depend on either behavior? At first glance, it seems most tasteful to have them evaluated within the implicit block. - Don Morrison  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 6 Mar 86 21:02:55 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 17:54:23 PST Received: by hplabs.ARPA ; Thu, 6 Mar 86 17:54:10 pst Date: Thu, 6 Mar 86 17:54:10 pst From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: get-setf-method In the proposed clarifications for CLtL, for page 107, GLS states that GET-SETF-METHOD should not do macroexpansion, and that it should be called with an already expanded form. The purpose of this change is to avoid having to make GET-SETF-METHOD take an &environment parameter, since MACROEXPAND needs it. He says "in most contexts the usage should be (GET-SETF-METHOD (MACROEXPAND form env))." This seems incorrect to me, as there may be a setf method defined on an intermediate expansion of the macro, which should take precedence over the macroexpansion. In order to correct this problem, each function which called GET-SETF-METHOD would have to repeatedly call it with MACROEXPAND-1 until there were no longer any macros to expand, or GET-SETF-METHOD found a setf method. What would GET-SETF-METHOD return if it didn't find a setf method? Here is an example of the problem: (defsetf foo boat) (defmacro foobar (x) `(foo ,x)) (defmacro foo (x) `(car ,x)) (setq x '(a . b)) (setf (foobar x) 3) ; this will expand to something equivalent to ; (setf (car x) 3) instead of calling boat as ; the update function. In other words, it missed the boat! In looking at the current SPICE sources, I see that GET-SETF-METHOD does take an environment, and MACROEXPAND-1 is called repeatedly, rather than MACROEXPAND. Due to the discrepency between the SPICE code and the clarifications list, I assume that either no consensus has been reached, or some decision has been made of which I am not aware. John Diamant Hewlett Packard Company diamant%hpfclp@hplabs.arpa  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 6 Mar 86 15:16:52 EST Received: from BRILLIG.UMD.EDU by SU-AI.ARPA with TCP; 6 Mar 86 12:07:01 PST Received: by brillig.umd.edu (5.9/4.7) id AA14513; Thu, 6 Mar 86 15:07:49 EST Message-Id: <8603062007.AA14513@brillig.umd.edu> To: rwk@scrc-yukon.ARPA Cc: common-lisp@su-ai.ARPA Subject: Re: loop macro In-Reply-To: Your message of Thu, 13 Feb 86 13:36 EST. <860213133639.3.RWK@CROW.SCRC.Symbolics.COM> Date: Thu, 06 Mar 86 15:07:47 -0500 From: Liz Allen From: Robert W. Kerns From: Liz Allen I don't really remember needing to use a DO* type binding of iteration variables. I guess I would use a LET to bind some common value and use it in the init part of the iteration values. I use the DO* type of binding far more often than not. And it isn't an issue for the init part of the iteration, it's for the stepping. I finally had a chance to look up DO vs DO* in CLtL -- and I was mistaken above. It turns out that the Franz DO that we use works exactly like the DO* in Common Lisp... So, we always use DO* type binding -- and have never seemed to need the other type of binding. -Liz  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 6 Mar 86 09:37:16 EST Received: from USC-ECL.ARPA by SU-AI.ARPA with TCP; 6 Mar 86 06:28:47 PST Date: Wed, 5 Mar 86 17:07:11 PST From: Jeff Barnett To: COMMON-LISP@SU-AI.ARPA Subject: Scope and declare Via: Nrtc; 06 Mar 86 05:47:20 In re CL book, page 155, example programm nonsense: why is the scope rule as stated? Is this a firm decision? If so, why? As I understand it, this is an inconpatible decision to virtually every other LISP that has been written. LET and PROG binding semantics can no longer be explained in terms of those associated with LAMBDA. Among other things, macro expansions can no longer use binding forms as they do now. In the rare case where the declaration should prevade the preset expression, that expression can be wrapped with a LET and a duplicate DECLARE. Since the inside of a macro can't tell or find out what the outside context is, it can't do the wrapping to regain it.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Mar 86 22:37:23 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 5 Mar 86 19:22:46 PST Received: ID ; Wed 5 Mar 86 22:22:47-EST Date: Wed, 5 Mar 1986 22:22 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jeff Dalton Cc: aarons%svga.susx.ac.uk@CS.UCL.AC.UK, common-lisp@SU-AI.ARPA, johnw%svga.susx.ac.uk@CS.UCL.AC.UK, rhr%aiva.edinburgh.ac.uk@CS.UCL.AC.UK Subject: Environment Committee In-reply-to: Msg of 1 Mar 1986 14:28-EST from Jeff Dalton Is it safe to assume that when Common Lisp is being compiled by Pop11, the system is operating as a Common Lisp superset? If not, how do you do macros? If so, one might still argue that nobody has implemented a Common Lisp compiler that is not in Common Lisp. The point of this is that we might want to specify more clearly what effect various compilation operations ahve on "the surrounding Lisp system". -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Mar 86 14:13:52 EST Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 5 Mar 86 11:03:20 PST Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA02590 (4.12w); Wed, 5 Mar 86 14:03:08 est Received: by ur-seneca.rochester.arpa id AA04390 (4.12w); Wed, 5 Mar 86 14:02:49 est Message-Id: <8603051902.4390@ur-seneca.rochester.arpa> Date: Wed, 5 Mar 86 14:02:49 est From: Lab Manager(Brad Miller) To: GJC@MC.LCS.MIT.EDU Cc: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA, fahlman@C.CS.CMU.EDU In-Reply-To: "George J. Carrette"'s message of Tue, 4 Mar 86 23:18:16 EST Subject: What is that -*- line for, anyway? Date: Tue, 4 Mar 86 23:18:16 EST From: "George J. Carrette" To add to what you have said historically speaking, orginally it was easier for an editor to understand "-*-" rather than some form such as (MODULE "name" :package "foo" :syntax "bar) presumably because the "-*-" first showed up in the TECO implemented EMACS editor on the PDP-10. Predating lispmachines of course (not by much, so an ITS historian should check me on this). Later the "-*-" syntax was extended to require/allow such things as #||-*- mode:lisp; package:(FOOBAR :USE (GLOBAL BAZ) :SHADOW (CAR CDR CONS)); base:10 -*- ||# >From this it is obvious that our Mr. Lab Managers comment about "-*-" being easier to parse "for your editor so that it need not actually 'read' lisp" is both ignorant and condescending. The stuff after the ":" must be parsed with READ. -gjc 1. Hardly ignorant nor condescending, as I was not talking about lisp FORMS. Your editor need not read the lisp IN THE FILE to determined the package of an expression, because an appropriate form is on the attribute line. Furthermore, that is all the editor is expected to know. If you change packages in the middle of the filed, the editor is not expected to follow the switch. Nor do I think we should expect it to, nor is this issue part of CLtL, hence my comment. 2. On the symbolics (at least) use of the make-system construct allows you to specify the package to compile or load a file into. It OVERRIDES anything on the attribute line. This makes a lot of sense: common subroutines can be loaded into my package this way, but if I were to edit the subroutines the attribute line would have to be overridden if I expected immediate effect on *my* programming environment (that is, the one I had loaded it into). Conclusion: the attribute line's idea of the package and the package a file is compiled or loaded into are independant entities and should remain that way. Both are environment issues, neither must be specified by CLtL, and my opinion is that neither should be. Brad Miller ARPA: lab@rochester.arpa UUCP:rochester!lab (also miller@rochester for grad student stuff) Title: CS Lab Manager Snail: University of Rochester Computer Science Department 617 Hylan Building Rochster, NY 14627 PS: sorry for the 'lab' signature, but my 'miller' account is on a lispm which currently does not forward to the arpa net.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Mar 86 10:17:10 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 5 Mar 86 07:05:21 PST Date: 5 Mar 1986 10:05-EST Sender: NGALL@G.BBN.COM Subject: Re: misc questions From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Cc: cfry%oz@MC.LCS.MIT.EDU Message-ID: <[G.BBN.COM] 5-Mar-86 10:05:17.NGALL> In-Reply-To: <860305034651.1.@MOSCOW-CENTRE.AI.MIT.EDU> Date: Wed, 5 Mar 86 03:46 EST From: Christopher Fry To: common-lisp@SU-AI.ARPA Subject: misc questions Message-ID: <860305034651.1.CFRY@MOSCOW-CENTRE.AI.MIT.EDU> What does WITH-OPEN-FILE return? I can't find it in CLtL. I'd prefer that it return the value of the last form in its body. I believe this is what most implementations do (since it is stated that the forms of the body are an implicit PROGN). This should be 'clarified' though. When SYMBOL-FUNCTION is passed a symbol which refers to a macro or special form, what does it return? There was a lot of discussion about this a few weeks ago. My impression of the result of that discussion was that SYMBOL-FUNCTION could return ANYTHING (including NIL) when passed a symbol that names a macro or special form. All you can count on is that it WON'T signal an error and it will return something. Of course, when passed a symbol that names an actual function, you can assume that what is returned is the function def. and that it can be applied, etc. If FUNCTION is passed a definition, does it simply return it? I assume by 'definition' you mean a lambda expression. When passed a lambda expression, FUNCTION may return a closure (an actual data type in some implementations, the original lambda (if no env. info. is needed), a compiled-code object (if you are using POPLOG LISP :-)), or any lisp object that is appliable or funcallable and that 'represents' the original lambda expression and its defining env. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Mar 86 09:40:52 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 5 Mar 86 06:32:32 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2500; Wed 5-Mar-86 09:32:51-EST Date: Wed, 5 Mar 86 09:32 EST From: David C. Plummer Subject: misc questions To: Christopher Fry , common-lisp@SU-AI.ARPA In-Reply-To: <860305034651.1.CFRY@MOSCOW-CENTRE.AI.MIT.EDU> Message-ID: <860305093230.2.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 5 Mar 86 03:46 EST From: Christopher Fry What does WITH-OPEN-FILE return? I can't find it in CLtL. I'd prefer that it return the value of the last form in its body. Funny it doesn't say. The 'obvious' way tocode it produces the expected result: it returns the valueS of the last form of the implicit progn. When SYMBOL-FUNCTION is passed a symbol which refers to a macro or special form, what does it return? The Silver bible says the definition 'may be an object representing a special form or macro' but it is illegal to funcall such a beast. If FUNCTION is passed a definition, does it simply return it? You probably should depend on this. The only way to get such a thing is by being constructed by a macro, which doesn't look pretty, e.g., `#',#'car You should only pass function specs or lambda expressions in. I will note that the Symbolics implementation is loose in this regard: #'#.#'car => # and (#.#'car '(3 4)) => 3  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 5 Mar 86 03:52:38 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 5 Mar 86 00:46:29 PST Received: from MOSCOW-CENTRE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 5 Mar 86 03:46-EST Date: Wed, 5 Mar 86 03:46 EST From: Christopher Fry Subject: misc questions To: common-lisp@SU-AI.ARPA Message-ID: <860305034651.1.CFRY@MOSCOW-CENTRE.AI.MIT.EDU> What does WITH-OPEN-FILE return? I can't find it in CLtL. I'd prefer that it return the value of the last form in its body. When SYMBOL-FUNCTION is passed a symbol which refers to a macro or special form, what does it return? If FUNCTION is passed a definition, does it simply return it?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Mar 86 23:32:12 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 4 Mar 86 20:17:39 PST Date: Tue, 4 Mar 86 23:18:16 EST From: "George J. Carrette" Subject: What is that -*- line for, anyway? To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, lab@ROCHESTER.ARPA, fahlman@C.CS.CMU.EDU In-reply-to: Msg of Tue 4 Mar 86 21:26 EST from David C. Plummer Message-ID: <[MC.LCS.MIT.EDU].839063.860304.GJC> To add to what you have said historically speaking, orginally it was easier for an editor to understand "-*-" rather than some form such as (MODULE "name" :package "foo" :syntax "bar) presumably because the "-*-" first showed up in the TECO implemented EMACS editor on the PDP-10. Predating lispmachines of course (not by much, so an ITS historian should check me on this). Q: Who invented the file mode line in EMACS? Q: Who decided to extend this to the file attribute line syntax on the Lispm? Later the "-*-" syntax was extended to require/allow such things as #||-*- mode:lisp; package:(FOOBAR :USE (GLOBAL BAZ) :SHADOW (CAR CDR CONS)); base:10 -*- ||# From this it is obvious that our Mr. Lab Managers comment about "-*-" being easier to parse "for your editor so that it need not actually 'read' lisp" is both ignorant and condescending. The stuff after the ":" must be parsed with READ. -gjc  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Mar 86 21:40:01 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 4 Mar 86 18:27:01 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2397; Tue 4-Mar-86 21:27:04-EST Date: Tue, 4 Mar 86 21:26 EST From: David C. Plummer Subject: What is that -*- line for, anyway? To: Lab Manager , fahlman@c.cs.cmu.edu cc: common-lisp@SU-AI.ARPA In-Reply-To: <8603041716.2181@ur-seneca.rochester.arpa> Message-ID: <860304212622.2.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Tue, 4 Mar 86 12:16:04 est From: Lab Manager(Brad Miller) Subject: What does LOAD use for read table & package? Date: Sun, 2 Mar 1986 00:31 EST Message-Id: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: common-lisp@SU-AI.ARPA Subject: What does LOAD use for read table & package? In-Reply-To: Msg of 1 Mar 1986 08:29-EST from George J. Carrette You should not be so quick to say that the "-*-" shouldnt be used. It may be ugly but experience has shown that it works very well. .... But all of that is irrelevant to the point I was making. Let me try again: There is no mention of "-*-" comments anywhere in the current definition of Common Lisp. As far as Common Lisp is concerned, everything in a comment is ignored. Any code that depends for its correct interpretation on the "-*-" not being ignored is not portable Common Lisp. Therefore, depending on this construct to set up packages and the like should be avoided in code that is intended to be portable. That's what In-Package is for. I concur. -*- is fine if you want frozzbozzy things for your editor so it need not actually 'read' lisp, but the lisp language certainly shouldn't define it, nor depend on it. I don't dissent, from a literal reading of CLtL, but I'll make the following observations. CLtL is a language specification. It does very little in the way of program development tools or programming environment aids. For those people that have non-Lisp-understanding text editors, they will parse neither the -*- 'attribute line' nor the possible in-package forms. As soon as you want your editor to be integrated into your environment (e.g., be able to ask the question "What's the arglist of the function the cursor is pointing at?" or "Macro expand the form after the cursor.") you need to know various things about the 'state' of the file/buffer. This includes things like *package*. Hystorically, (MIT derived) Lisp Machine files have code which is in the same package. Therefore, the -*- attribute list and an in-package form are equivalent, but the former is a lot easier for the editor to understand; either it is there at a known place or it isn't. The compiler and loader and other >tools< where made to know about the attribute list. In fact, binary files contain an attribute list which requires minimal parsing of the binary file. It is not 'certain' that a lisp language should not define it. If we really specify the least common denominator, of course it won't be part of the language, but the least common denominator isn't a powerful language. If we attempt to define some relatively simple standards for useful program development aids, then I think something should be defined.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Mar 86 12:23:59 EST Received: from ROCHESTER.ARPA by SU-AI.ARPA with TCP; 4 Mar 86 09:16:15 PST Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA18874 (4.12w); Tue, 4 Mar 86 12:16:15 est Received: by ur-seneca.rochester.arpa id AA02181 (4.12w); Tue, 4 Mar 86 12:16:04 est Message-Id: <8603041716.2181@ur-seneca.rochester.arpa> Date: Tue, 4 Mar 86 12:16:04 est From: Lab Manager(Brad Miller) To: fahlman@c.cs.cmu.edu Cc: common-lisp@su-ai.arpa Subject: What does LOAD use for read table & package? Date: Sun, 2 Mar 1986 00:31 EST Message-Id: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: common-lisp@SU-AI.ARPA Subject: What does LOAD use for read table & package? In-Reply-To: Msg of 1 Mar 1986 08:29-EST from George J. Carrette You should not be so quick to say that the "-*-" shouldnt be used. It may be ugly but experience has shown that it works very well. .... But all of that is irrelevant to the point I was making. Let me try again: There is no mention of "-*-" comments anywhere in the current definition of Common Lisp. As far as Common Lisp is concerned, everything in a comment is ignored. Any code that depends for its correct interpretation on the "-*-" not being ignored is not portable Common Lisp. Therefore, depending on this construct to set up packages and the like should be avoided in code that is intended to be portable. That's what In-Package is for. -- Scott I concur. -*- is fine if you want frozzbozzy things for your editor so it need not actually 'read' lisp, but the lisp language certainly shouldn't define it, nor depend on it. Brad Miller  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 4 Mar 86 08:31:30 EST Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 4 Mar 86 05:23:50 PST Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a005943; 4 Mar 86 10:27 GMT From: Jeff Dalton Date: Sat, 1 Mar 86 19:28:12 GMT Message-Id: <5586.8603011928@aiva.edinburgh.ac.uk> To: Fahlman@c.cs.cmu.edu, common-lisp@su-ai.arpa Subject: Re: Environment Committee Cc: aarons%svga.susx.ac.uk@cs.ucl.ac.uk, johnw%svga.susx.ac.uk@cs.ucl.ac.uk, rhr%aiva.edinburgh.ac.uk@cs.ucl.ac.uk > Date: Fri, 28 Feb 1986 09:37 EST > From: "Scott E. Fahlman" > Subject: Environment Committee > > Initially we even wanted to leave open the question of whether the > compiler was written in Lisp, though I don't think anyone has exercised > the option not to do this and we may want to put that particular freedom > to rest. The PopLog Common Lisp compiler is written in Pop11. Incidently, this system also exercises another of the more unusual implementation options: there is no interpreter per se: EVAL just compiles and calls the resulting code. PopLog, from the University of Sussex, is a mixed-language system which includes Pop11, Prolog, and (when it's finished) Common Lisp. For anyone who is interested, the best person to contact there is probably Aaron Sloman. An address that might work is: aarons%uk.ac.susx.svga@ucl-cs.arpa -- Jeff  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Mar 86 23:03:12 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Mar 86 19:55:45 PST Date: Mon, 3 Mar 86 22:56:30 EST From: "George J. Carrette" Subject: Things to consider for CLtL'97 To: gls@AQUINAS.THINK.COM, DCP@SCRC-QUABBIN.ARPA cc: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of Mon 3 Mar 86 10:43 EST from Guy Steele Message-ID: <[MC.LCS.MIT.EDU].837609.860303.GJC> Loop and efficiency? Please save us! I write using the mapping/sequence functional form and then add a compiler:optimizer that will turn it into a call to a hand-microcoded %SEQUENCE-FROB-CASE-XXX instruction. You cant get any more efficient than that.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Mar 86 19:03:24 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 3 Mar 86 15:52:54 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2091; Mon 3-Mar-86 18:37:06-EST Date: Mon, 3 Mar 86 18:36 EST From: David C. Plummer Subject: Things to consider for CLtL'97 To: Guy Steele , DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <860303104332.1.GLS@GUIDO.THINK.COM> Message-ID: <860303183633.9.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 3 Mar 86 10:43 EST From: Guy Steele Date: Fri, 28 Feb 86 17:06 EST From: David C. Plummer Date: Fri, 28 Feb 86 15:04 EST From: Guy Steele Date: Tue, 25 Feb 86 11:15 EST From: David C. Plummer reduce should have a :KEY keyword argument. For example, suppose you have a sequence of sequences, and you want to know the sum of the lengths of the inner sequences. Currently, I think you have to do (reduce #'(lambda (so-far subsequence) (+ so-far (length sub-sequence))) sequence) but I would prefer to do (reduce #'+ sequence :key #'length) (REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence)) Yours conses. Mine doesn't. Argh. If you're worried about conses, use LOOP. Seems like everyone else does. (This week I am of the opinion that all those :START and :END keywords were a mistake.) If I were worried about speed, I would use LOOP. Since I wasn't, I wanted to be pretty and still have some small spattering of efficiency. (This month I'm trying not to use LOOP when other CL constructs are cleanlier.) ... Did you mean: modify-seq item sequence modifier &key start end from-end test test-not modify-seq-if predicate sequence modifier &key start end from-end modify-seq-if-not predicate item sequence modifier &key start end from-end ? I see, I think. Yes, I want the -IF and -IF-NOT forms as well. And should they all also take a :KEY argument? I don't think so. Consider what :KEY does. It extracts a part of the datastructure. To put it back, the implementation would have to do something like (setf (funcall key sequence-element) (funcall modifier (funcall key sequence-element))) and SETF of FUNCALL isn't generally invertable. Sorry; I meant the :KEY part to be used only in conjunction with the test, not the modify part of the operation. See how tricky it is to specify these things? Glorp! I see, you meant (when (funcall predicate (funcall key seqeunce-element)) (setf (funcall modifier sequence-element))) Yeah, I guess that would be reasonable. Seems to me JONL once proposed an omnibus sequence function with a name such as MEMASSDELREMCONCQ-IF that simply took enough options to be able to do anything you desired with a sequence. :-{  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Mar 86 12:05:56 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 3 Mar 86 07:41:08 PST Received: from guido by GODOT.THINK.COM via CHAOS; Mon, 3 Mar 86 10:41:39 est Date: Mon, 3 Mar 86 10:43 EST From: Guy Steele Subject: Things to consider for CLtL'97 To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860228170643.0.DCP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <860303104332.1.GLS@GUIDO.THINK.COM> Date: Fri, 28 Feb 86 17:06 EST From: David C. Plummer Date: Fri, 28 Feb 86 15:04 EST From: Guy Steele Date: Tue, 25 Feb 86 11:15 EST From: David C. Plummer reduce should have a :KEY keyword argument. For example, suppose you have a sequence of sequences, and you want to know the sum of the lengths of the inner sequences. Currently, I think you have to do (reduce #'(lambda (so-far subsequence) (+ so-far (length sub-sequence))) sequence) but I would prefer to do (reduce #'+ sequence :key #'length) (REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence)) Yours conses. Mine doesn't. Argh. If you're worried about conses, use LOOP. Seems like everyone else does. (This week I am of the opinion that all those :START and :END keywords were a mistake.) ... Did you mean: modify-seq item sequence modifier &key start end from-end test test-not modify-seq-if predicate sequence modifier &key start end from-end modify-seq-if-not predicate item sequence modifier &key start end from-end ? I see, I think. Yes, I want the -IF and -IF-NOT forms as well. And should they all also take a :KEY argument? I don't think so. Consider what :KEY does. It extracts a part of the datastructure. To put it back, the implementation would have to do something like (setf (funcall key sequence-element) (funcall modifier (funcall key sequence-element))) and SETF of FUNCALL isn't generally invertable. Sorry; I meant the :KEY part to be used only in conjunction with the test, not the modify part of the operation. See how tricky it is to specify these things? Seems to me JONL once proposed an omnibus sequence function with a name such as MEMASSDELREMCONCQ-IF that simply took enough options to be able to do anything you desired with a sequence. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 3 Mar 86 07:47:18 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 3 Mar 86 04:40:42 PST Date: Mon, 3 Mar 86 07:41:29 EST From: "George J. Carrette" Subject: What does LOAD use for read table & package? To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Sun 2 Mar 1986 00:31 EST from Scott E. Fahlman Message-ID: <[MC.LCS.MIT.EDU].836491.860303.GJC> Looking back through the *anals* (sic) of BUG-LISPM at MIT you will find my objections to the the "-*-" crock too. But you dont get the point of my suggestion: "To be actually suggesting that users can use -*- without fear, and that it IS PORTABLE. This is because there are many machines that support it now in a consistent way, and since other machines IGNORE it then users are free to implement it themselves." Any of RWK's suggestions would be easy to implement and very servicable to the community, in my experience. -gjc  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Mar 86 02:33:46 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 1 Mar 86 23:25:46 PST Received: from CROW.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1745; Sun 2-Mar-86 02:26:01-EST Date: Sun, 2 Mar 86 02:20 EST From: Robert W. Kerns Subject: Loading into the current package. To: "BACH::GREEK" cc: common-lisp In-Reply-To: The message from "BACH::GREEK" Message-ID: <860302022030.2.RWK@CROW.SCRC.Symbolics.COM> From: "BACH::GREEK" There is something wrong with a file that doesn't mention packages. This is just the rim of the compilation environment wormcan. I think this is the key point. I wouldn't dream of creating a Lisp file without that -*- line at the top. Even my programs which write Lisp files put it on there. But I'd like to take a bite out of your wormcan. I think we're being silly, scaring ourselves with "compilation environments are a hard issue." The Europeans are tackling it, if I understand my mail rightly, and if we just address the specific problems, rather than throwing up our hands, I believe we can make forward progress. Surely we can come up with some standard syntax for specifying this information, in a way that isn't completely broken for systems with editors. I see three approaches: 1) restrict IN-PACKAGE, IMPORT, and friends to be at the start of the file, before any other forms. 2) combine this stuff into a single declarative form at the top of the file. (declarative = non-evaluating). 3) -*- or similar syntax. We could also argue forever, or we could ignore the problem. But that doesn't make IN-PACKAGE any less of a useless crock that fails to live up to its compatibility goals. Unless there is a language-specification change, "portable" CL files will only be portable in a very narrow sense, and the reader of the Steele Grey Book won't even know there's an issue.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 2 Mar 86 00:39:49 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 Mar 86 21:31:05 PST Received: ID ; Sun 2 Mar 86 00:31:37-EST Date: Sun, 2 Mar 1986 00:31 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "George J. Carrette" Cc: common-lisp@SU-AI.ARPA Subject: What does LOAD use for read table & package? In-reply-to: Msg of 1 Mar 1986 08:29-EST from George J. Carrette You should not be so quick to say that the "-*-" shouldnt be used. It may be ugly but experience has shown that it works very well. It is fine with me if people want to put funny-looking comments into their code and if certain implementation-specific tools such as editors want to pay attention to such comments. We can even discuss whether the "-*-" convention should be given some sort of official status within Common Lisp. I'm glad we agree that it is ugly. If we want to specify some Lisp-accessible attributes of a file, I would certainly hope that we could do better than retaining this ugly kludge that has, unfortunately, been around long enough that people have become used to it. But all of that is irrelevant to the point I was making. Let me try again: There is no mention of "-*-" comments anywhere in the current definition of Common Lisp. As far as Common Lisp is concerned, everything in a comment is ignored. Any code that depends for its correct interpretation on the "-*-" not being ignored is not portable Common Lisp. Therefore, depending on this construct to set up packages and the like should be avoided in code that is intended to be portable. That's what In-Package is for. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Mar 86 08:34:53 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 1 Mar 86 05:28:44 PST Date: Sat, 1 Mar 86 08:29:32 EST From: "George J. Carrette" Subject: What does LOAD use for read table & package? To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Wed 26 Feb 1986 20:36 EST from Scott E. Fahlman Message-ID: <[MC.LCS.MIT.EDU].834927.860301.GJC> You should not be so quick to say that the "-*-" shouldnt be used. It may be ugly but experience has shown that it works very well. I know of some common-lisp portable DEFSYSTEM/UNIX-MAKE-like programs that first open the file and parse the "-*-" line and then bind package,readtable, etc before calling the compiler and/or loader. (And, similarily I have had to put code in the (LMI) lispmachine "-*-" parser to scan the first part of a file to look for the idiomatic use of IN-PACKAGE). Already I have had my fill of seeing the most grossly ad-hoc and insufficient system-building programs in use by people that did at least part of their program development work in the immature non-Lispmachine environments and then have trouble dealing with the more formal tools on the lispmachines. Does any emacs editor with COMPILE-DEFUN really deal with multiple *package* SETQ's (In-Package) throughout a file? On the other hand, there are people with good portable system building tools, (that they have put a significant amount of work into) and these people wont be screwed by the lack of such things in the base CL.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 1 Mar 86 02:05:29 EST Received: from UW-BEAVER.ARPA by SU-AI.ARPA with TCP; 28 Feb 86 22:58:11 PST Received: by uw-beaver.arpa (4.42/4.2) id AA12446; Fri, 28 Feb 86 23:04:02 PST Return-Path: Message-Id: <8603010704.AA12446@uw-beaver.arpa> From: apollo!dfm@uw-beaver.arpa Date: Fri, 28 Feb 86 16:18:48 EST Subject: (satisfies predicate-name) To: common-lisp@su-ai.arpa Apologies if this has been discussed before. On page 43, discussing (satisfies predicate-name), CLtL says "A name is required; lambda-expressions are disallowed in order to avoid scoping problems." Am I correct in assuming that the global function definition is always to be used? For example, I assume the following should not signal an error: (defun f (x) t) (labels ((f (x) nil)) (type-check nil (satisfies f)) ) Is that correct? - Don Morrison  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 21:42:38 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Feb 86 18:33:42 PST Received: ID ; Fri 28 Feb 86 21:34:04-EST Date: Fri, 28 Feb 1986 21:34 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jonathan A Rees Cc: common-lisp@SU-AI.ARPA Subject: Collecting proposals for packages, readtables, etc. In-reply-to: Msg of 28 Feb 1986 13:07-EST from Jonathan A Rees I simply want to be able to set the readtable (and package) with which a *source* file will be *read* by COMPILE-FILE and LOAD. Pending a resolution of these heavy issues, I would say that in a Lisp where Compile-File and/or Load uses the current package and readtable, there's no problem in rebinding this before doing the call. Any Lisp in which Compile-File and/or Load insist on binding the package to some particular value should allow this to be over-ridden, presumably by a :package keyword argument. Moon says that Symbolics has this already. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 17:20:56 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 28 Feb 86 14:06:07 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1624; Fri 28-Feb-86 17:06:10-EST Date: Fri, 28 Feb 86 17:06 EST From: David C. Plummer Subject: Things to consider for CLtL'97 To: Guy Steele , DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <860228150412.8.GLS@GUIDO.THINK.COM> Message-ID: <860228170643.0.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Fri, 28 Feb 86 15:04 EST From: Guy Steele Date: Tue, 25 Feb 86 11:15 EST From: David C. Plummer reduce should have a :KEY keyword argument. For example, suppose you have a sequence of sequences, and you want to know the sum of the lengths of the inner sequences. Currently, I think you have to do (reduce #'(lambda (so-far subsequence) (+ so-far (length sub-sequence))) sequence) but I would prefer to do (reduce #'+ sequence :key #'length) (REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence)) Yours conses. Mine doesn't. There should be a modify-seq (or some name) that looks roughly like modify-seq sequence modifier &key start end from-end test test-not that modifies the elements of the sequence between start and end that past the TEST function. The element is replaced by the modifier applied to the old element. For example, if a sequence is a sequence of integers and you want to change it into a sequence of arrays whose lengths are based on those integers, one could do (modify-seq sequence #'(lambda (n) (make-array (round (* n 1.1))))) There should be a modify-hash function. This isn't consistent with the syntax of other functions that have a test. Did you mean: [I assume this is in response to modify-seq instead of modify-hash.] modify-seq item sequence modifier &key start end from-end test test-not modify-seq-if predicate sequence modifier &key start end from-end modify-seq-if-not predicate item sequence modifier &key start end from-end ? I see, I think. Yes, I want the -IF and -IF-NOT forms as well. And should they all also take a :KEY argument? I don't think so. Consider what :KEY does. It extracts a part of the datastructure. To put it back, the implementation would have to do something like (setf (funcall key sequence-element) (funcall modifier (funcall key sequence-element))) and SETF of FUNCALL isn't generally invertable.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 15:17:35 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 28 Feb 86 12:02:32 PST Received: from guido by GODOT.THINK.COM via CHAOS; Fri, 28 Feb 86 15:02:26 est Date: Fri, 28 Feb 86 15:04 EST From: Guy Steele Subject: Things to consider for CLtL'97 To: DCP@SCRC-QUABBIN.ARPA, Common-Lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860225111537.4.DCP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <860228150412.8.GLS@GUIDO.THINK.COM> Date: Tue, 25 Feb 86 11:15 EST From: David C. Plummer reduce should have a :KEY keyword argument. For example, suppose you have a sequence of sequences, and you want to know the sum of the lengths of the inner sequences. Currently, I think you have to do (reduce #'(lambda (so-far subsequence) (+ so-far (length sub-sequence))) sequence) but I would prefer to do (reduce #'+ sequence :key #'length) (REDUCE #'+ (MAP (TYPE-OF sequence) #'length sequence)) There should be a modify-seq (or some name) that looks roughly like modify-seq sequence modifier &key start end from-end test test-not that modifies the elements of the sequence between start and end that past the TEST function. The element is replaced by the modifier applied to the old element. For example, if a sequence is a sequence of integers and you want to change it into a sequence of arrays whose lengths are based on those integers, one could do (modify-seq sequence #'(lambda (n) (make-array (round (* n 1.1))))) There should be a modify-hash function. This isn't consistent with the syntax of other functions that have a test. Did you mean: modify-seq item sequence modifier &key start end from-end test test-not modify-seq-if predicate sequence modifier &key start end from-end modify-seq-if-not item sequence modifier &key start end from-end ? And should they all also take a :KEY argument? --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 14:58:30 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 28 Feb 86 11:42:46 PST Received: from guido by GODOT.THINK.COM via CHAOS; Fri, 28 Feb 86 14:42:30 est Date: Fri, 28 Feb 86 14:44 EST From: Guy Steele Subject: Re: Function Cell Follow-up To: shebs%utah-orion@UTAH-CS.ARPA, DCP@SCRC-QUABBIN.ARPA, JAR@mc.lcs.mit.edu Cc: common-lisp@SU-AI.ARPA, gls@THINK-AQUINAS.ARPA In-Reply-To: <8602250156.AA26504@utah-orion.ARPA> Message-Id: <860228144414.6.GLS@GUIDO.THINK.COM> Date: Mon, 24 Feb 86 18:56:14 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Date: Mon, 24 Feb 86 20:28:33 EST From: Jonathan A Rees Date: Mon, 24 Feb 86 15:56 EST From: David C. Plummer Is tail recursion REQUIRED of Scheme implementations, or is just in all the papers because it is easy to do in most Scheme implementations. It's absolutely as essential as garbage collection. [...] I recall reading some old Lisp Machine papers that suggested garbage collection should be avoided (DDI = Don't Do It!) :-) :-) stan Probably you are thinking of JONL White's paper in the 1980 Lisp Conference. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 14:40:03 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 28 Feb 86 11:27:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 249286; 28 Feb 86 14:24:31-EST Date: Fri, 28 Feb 86 14:24 EST From: David A. Moon Subject: What does LOAD use for read table & package? To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860228142427.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 27 Feb 1986 20:40 EST From: "Scott E. Fahlman" I believe that the only viable possibility for LOAD of a compiled file is to bind *PACKAGE* to the same value that it had when the file was compiled. This means that the compiler must transmit this information to the loader in some way. If there are SETQs of *PACKAGE* in the source file (perhaps disguised as IN-PACKAGE), then they should do the same thing at load time as they did at compile time. For those of us who want to learn from your experience, could you elaborate a bit on the above pronouncement? Why is it a good idea to bind *PACKAGE* to the compile-time value, rather than using what is current at load time? The READ operations that the compiler does lose information about what package prefixes were specified on symbols. The compiler has to put something in its output file that expresses the identity of those symbols, and the loader has to take that information in the file and reproduce the same symbols. (Perhaps I should stop here and ask if you agree that the desired semantics is for loading the compiled file to refer to the same symbols as loading the source file.) In my experience, the way that produces the least surprise for users is for the compiler to record symbols in its output file using the same algorithm as PRINT to decide when to put a package prefix, and for the loader to use the same algorithm as READ to interpret those prefixes, relative to the same package with respect to which they were printed. We have tried other techniques, such as always putting a package prefix in the compiler's output file, and found them deficient. The problem with always putting a package prefix is that almost any change to the package structure (what symbol is exported from where, or what is the home package of a symbol that is in multiple packages) will prevent the compiled file from loading correctly. We do have a way to force LOAD to load into a different package than the one the file was compiled in, using a :PACKAGE keyword argument, but in practice this is rarely used. What if the compile-time package doesn't exist at load time? Then the program doesn't load. I don't see this as any different from calling a function that doesn't exist at load time. I also don't see this as surprising, since in my view the compile-time package is very much part of the program, not an accidental detail of compilation, and it would be unusual for it not to exist at load time. Of course any mechanism, such as IN-PACKAGE or -*-, that tells the compiler to create the package if it does not already exist should be transmitted to the loader, which should also create the package if it does not already exist. ------- This is of course only a tiny part of the whole issue of compilation and environments. I think it very unlikely that we will be able to agree on full details of programming environments, since Common Lisp is being implemented on such a wide range of systems with different capabilities and different goals. In fact such agreement would be undesirable in my view, since it would either exclude a large sector of the Common Lisp community or would require a least-common-denominator programming environment that would be of little use to those among my users who are tackling extremely ambitious projects in Lisp. I agree with what you said in another message that the important thing is to focus on what is necessary to write portable programs.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 13:48:58 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 28 Feb 86 10:37:42 PST Received: from guido by GODOT.THINK.COM via CHAOS; Fri, 28 Feb 86 13:37:45 est Date: Fri, 28 Feb 86 13:39 EST From: Guy Steele Subject: Function cells To: DCP@SCRC-QUABBIN.ARPA, gls@THINK-AQUINAS.ARPA, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <860220182741.9.DCP@NEPONSET.SCRC.Symbolics.COM> Message-Id: <860228133929.1.GLS@GUIDO.THINK.COM> Date: Thu, 20 Feb 86 18:27 EST From: David C. Plummer Date: Wed, 19 Feb 86 15:40 EST From: Guy Steele ... I can report that much of the time I am very happy to have the two names spaces be distinct. I get very unhappy whenever I find myself inventing functionals (functions that take other functions as arguments or return other functions as values) for various purposes. For example, I have found it semantically convenient to do so in Connection Machine Lisp. In these situations I find the need for interpolated occurrences of "funcall" and "#'" extremely annoying. I read this last paragraph 3 times and am under the impression you change your mind on each sentence. I'm really curious what you meant! What I meant is: (a) much of the time I am happy; (b) the part of the time I am not happy, it is in the following circumstances (trying to use functionals). --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 13:18:09 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 28 Feb 86 10:06:25 PST Date: Fri, 28 Feb 86 13:07:08 EST From: Jonathan A Rees Subject: Collecting proposals for packages, readtables, etc. To: common-lisp@SU-AI.ARPA In-reply-to: Msg of 0 0 00:00:00 EST from BACH::GREEK Message-ID: <[MC.LCS.MIT.EDU].833953.860228.JAR> While the discussion about the relationship between compilation environment and load environment has been interesting, and the problem is important (and probably insoluble, given CL's compilation and modularity paradigms), I want to point out that my message of a couple days ago, which apparently started this, was asking something very different and much simpler. I simply want to be able to set the readtable (and package) with which a *source* file will be *read* by COMPILE-FILE and LOAD. Symbolics Common Lisp gives me no way to do this, and I wanted to know whether people felt that CL was defined in such a way that COMPILE-FILE and LOAD, in the absence of standard (IN-PACKAGE, EVAL-WHEN, etc.) and nonstandard (-*- Syntax: ... -*-) bindings of package and readtable, are required to respect the bindings in effect when they are invoked. If so, then I should report a bug in Symbolics Common Lisp. - Jonathan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 11:30:10 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Feb 86 08:19:01 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: LISP Environment. To: "common-lisp" Reply-To: "BACH::GREEK" First of all, an apology to anyone receiving butchered mail from us at DEC. We're using some software by an Australian-sounding company that seems to have some problems. Well, Scott, I certainly agree that specifying an entire environment is a tough problem. Perhaps then, as has been suggested, someone should write down all the individual questions that we need to answer. Then everyone would know what to think about. At least those questions which we do answer would be consistent and play together. If people want to send me their favorite compilation environment QUESTIONS, I'd be happy to compile a complete list and send it out to everyone. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 10:02:11 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 28 Feb 86 06:37:02 PST Received: ID ; Fri 28 Feb 86 09:37:34-EST Date: Fri, 28 Feb 1986 09:37 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Environment Committee [I can't respond to Paul the Greek directly. All the mail from DEC in the last couple of weeks has arrived with headers all screwed up and with the body smashed into the header. I'm surprised it arrived at all. OF course, the problem might be on our end, but only mail from DEC seems to be losing.] Paul, I agree that there are many things that need to be sorted out in the compilation area. We really let that slide the first time around. There is not currently an environmnet committee, and I don't think that one is likely to be fruitful. At best we could hope for N different classes of environment, each fairly well-defined. Things are totally different depending on whether your system supports multiple windows, whether you are in an Emacs or internal-editing culture, and so on. Initially we even wanted to leave open the question of whether the compiler was written in Lisp, though I don't think anyone has exercised the option not to do this and we may want to put that particular freedom to rest. What we do need to do is work on specifying those aspects of compilation that affect what goes into a portable code file (or set of files) and what the items in that file mean. We can and must nail down compiler issues of that sort before a standard is finished. It is interesting that the EuLisp people have decided to try to specify an environmnet along with their Lisp, using a multi-level spec ranging from very simple (appropriate for a Z-80 based machine) to very complex (presumably comparable in scope to what is in Zetalisp or Interlisp). They have fewer constraints in the way of existing groups who want to stick with their own environment conventions, but they are trying to do this for an awfully big spread of machines. It will be interesting to see what they come up with. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 09:06:44 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 28 Feb 86 05:58:59 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Collecting proposals for packages, readtables, etc. To: "common-lisp" Reply-To: "BACH::GREEK" I certainly can't argue that collecting all the proposals so that we can see them together is a bad idea. But this really is a big project. I think we are dancing around a lot of tough issues: o What exactly is the compilation environment. o How is the LISP environment affected by a compilation. o How are multiple files/modules built into a large system. o How does the compilation environment compare to the load environment. o Etc. These questions must be answered in concert, with thought given to the whole problem of the LISP environment. I'd be willing to bet that an answer to one or two simpler problems would seem reasonable, but when placed in the larger context might be totally wrong. I was struck by a simple comment someone made: The right thing for the compiler to do is to clone the LISP environment, do the compilation, and discard the clone; however, this is not what people expect or want. Is there an environment committee? If not, does it make sense to start one? - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 28 Feb 86 04:42:32 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 28 Feb 86 00:16:52 PST Received: from IMSSS by Score with Pup; Fri 28 Feb 86 00:17:26-PST Date: 28 Feb 1986 0015-PST From: Rem@IMSSS Subject: PACKAGE, READTABLE, etc. in compiled files vs. load uncompiled To: COMMON-LISP%SU-AI@SCORE It seems clear from the plethora of proposals that somebody should collect all the proposals, as strawmen, and see which can be knocked down and which look like they might be workable; perhaps compile a document summarizing each proposal succinctly and summarizing bugs in proposal succinctly. Then if we have all these proposals and rebuttals in one document somebody can figure out what really should be done and write one final strawman proposal for everyone to consider adopting. Otherwise we seem to be going in circles with all these random proposals and flat-out ultimatum statements about how it should work. -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Feb 86 20:54:08 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Feb 86 17:40:54 PST Received: ID ; Thu 27 Feb 86 20:41:00-EST Date: Thu, 27 Feb 1986 20:40 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: What does LOAD use for read table & package? In-reply-to: Msg of 27 Feb 1986 14:15-EST from David A. Moon I believe that the only viable possibility for LOAD of a compiled file is to bind *PACKAGE* to the same value that it had when the file was compiled. This means that the compiler must transmit this information to the loader in some way. If there are SETQs of *PACKAGE* in the source file (perhaps disguised as IN-PACKAGE), then they should do the same thing at load time as they did at compile time. For those of us who want to learn from your experience, could you elaborate a bit on the above pronouncement? Why is it a good idea to bind *PACKAGE* to the compile-time value, rather than using what is current at load time? What if the compile-time package doesn't exist at load time? -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Feb 86 19:53:37 EST Received: from IM4U.UTEXAS.EDU by SU-AI.ARPA with TCP; 27 Feb 86 15:29:25 PST Date: Thu, 27 Feb 86 17:22:32 cst From: kim@im4u.utexas.edu (Hyoung-Joo Kim, DB person) Posted-Date: Thu, 27 Feb 86 17:22:32 cst Message-Id: <8602272322.AA14338@im4u> Received: by im4u (4.22/4.22) id AA14338; Thu, 27 Feb 86 17:22:32 cst To: common-lisp@SU-AI.ARPA Subject: desperately seeking Lisp hackers Cc: kim@im4u.utexas.edu MCC CAD Database Group is loking for real Lisp hackers. I got the following advertisement last week. ------------------------------------------------- Summer Job Opportunities with MCC We have summer openings for students experienced in LISP programming. The project involves programming in Common LISP various modules of a reserach prototype database system that will run on a Symbolics LISP machine. LISP programming experiences are required. Experiences with Common-LISP, Symbolics LISP machine, or database system architecture are preferred, but not required. Enquires should be directed to: Dr. Won Kim MCC 9430 Research Blvd. Austin, Texas 78759 (512) 834-3439 -------------------------------------------------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Feb 86 14:32:35 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 27 Feb 86 11:18:16 PST Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 1302; Thu 27-Feb-86 14:18:22-EST Date: Thu, 27 Feb 86 14:15 EST From: David A. Moon Subject: What does LOAD use for read table & package? To: common-lisp@SU-AI.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].831718.860226.JAR> Message-ID: <860227141510.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I believe that the only viable possibility for LOAD of a compiled file is to bind *PACKAGE* to the same value that it had when the file was compiled. This means that the compiler must transmit this information to the loader in some way. If there are SETQs of *PACKAGE* in the source file (perhaps disguised as IN-PACKAGE), then they should do the same thing at load time as they did at compile time. This is obviously an area where the language definition could use a lot of tightening up. The issues are not simple, especially if one is unwilling to learn from experience.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Feb 86 12:38:58 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 27 Feb 86 09:28:49 PST Received: from hplsny by hplabs.ARPA ; Thu, 27 Feb 86 09:28:09 pst Received: by hplsny ; Thu, 27 Feb 86 09:28:01 pst From: Alan Snyder Message-Id: <8602271728.AA02879@hplsny> Date: Thursday, February 27, 1986 09:27:57 Subject: Re: What does LOAD use for read table & package? To: common-lisp@su-ai.ARPA In-Reply-To: Your message of 26-Feb-86 20:36:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 It seems to me that, insofar as it is possible, we want to set things up so that loading a compiled file has the same effect as loading the source file. If the source file does not explicitly specify a package, it should be loaded into whatever package is current when Load is called. I don't think that compiled/uncompiled code consistency can be used to resolve this issue. One could just as easily say that loading either a source file or a compiled file should start in some "standard" package (e.g. "USER"). My own bias is that all source files be self-descriptive in the sense of specifying the environment they need (package, readtable, required modules, etc.). Perhaps both alternatives should be supported. We could define LOAD to start in a known state (package, readtable) and define a new function INCLUDE that uses the current environment. If the model for INCLUDE is "behave as if the referenced text were directly included here" then it might also differ from LOAD by (1) not restoring *PACKAGE* when it is done and (2) being implicitly evaluated by the compiler like INCLUDE in other languages. -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Feb 86 11:25:59 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 27 Feb 86 08:16:35 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA11420; Thu, 27 Feb 86 09:18:42 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA02746; Thu, 27 Feb 86 09:18:40 MST Date: Thu, 27 Feb 86 09:18:40 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8602271618.AA02746@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Documentation Strings in Lambdas It is implied on p. 60 that documentation strings are allowed in anonymous lambdas. Is this just for simplicity/consistency, so that things like defun can macroexpand without having to grovel around excising documentation strings? stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 27 Feb 86 09:29:15 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 27 Feb 86 06:18:37 PST Date: 0 0 00:00:00 EST From: "BACH::GREEK" Subject: Loading into the current package. To: "common-lisp" Reply-To: "BACH::GREEK" I agree pretty much with what Scott has to say about packages and readtables when loading. However, I believe there is at least one important ambiguity. Take the following program: ; Absolutely no mention of packages . . foo P1::bar Now let's say that's compiled in package P1. Once the reader is done, both symbols will be in package P1. The compiler won't be able to tell that one was unqualified and one was explicitly qualified with P1, so they both look unqualified. And then the fastload file is loaded into package P2. Oops! Assuming the compiler causes unqualified symbols to end up in the current package, then both will end up in P2. Or, if it causes unqualified symbols to end up in the package in which the compilation was performed, then both will end up in P1 (which may not even be around). There is something wrong with a file that doesn't mention packages. This is just the rim of the compilation environment wormcan. - Paul ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 26 Feb 86 21:41:48 EST Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 26 Feb 86 18:13:56 PST Date: Wed 26 Feb 86 17:35:58-PST From: Andy Freeman Subject: Re: defmacro in let To: NGALL@BBNG.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]26-Feb-86 20:12:49.NGALL> Message-ID: <12186567743.9.ANDY@SU-SUSHI.ARPA> I've now read and understood page 145. My question should be answered RTFM; I have mailed myself 100 copies of this, saving those of you so inclined the effort. (If you do this my way, you'll avoid polluting the entire common-lisp mailing list.) -andy thinks the difference in the environments for defun and defmacro is silly but that the time for discussion has long passed -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 26 Feb 86 21:39:51 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Feb 86 18:28:00 PST Received: ID ; Wed 26 Feb 86 20:59:10-EST Date: Wed, 26 Feb 1986 20:36 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jonathan A Rees Cc: common-lisp@SU-AI.ARPA Subject: What does LOAD use for read table & package? In-reply-to: Msg of 26 Feb 1986 18:07-EST from Jonathan A Rees I think that the manual is silent on what readtable and package should be used by load. Let's think about what the right thing would be. It seems to me that, insofar as it is possible, we want to set things up so that loading a compiled file has the same effect as loading the source file. This says to me that if the source file uses In-Package to specify the package to be used, the compiler should emit something in the compiled-code file that makes this package current while the file is being loaded. If the source file does not explicitly specify a package, it should be loaded into whatever package is current when Load is called. (The "-*-" convention is not a part of Common Lisp and should not be used by itself to set up packages in portable code. It is significant to certain editors and other implementation-specific tools.) In the case of loading uncompiled code files, the same thing would be true: the in-package statement would govern, and if it is absent the current package would be used by LOAD. It would be nice to say the same thing for readtables -- use the current one unless the file specifies otherwise -- but this is impractical. Almost all of what a readtable does is done while the compiler is reading the source file, at a time when the compiler has no way of knowing what readtable will be current when the object file is loaded. The loading of compiled code has little, if anything, to do with the reader, so I think the question of whether to use the current or the defautl readtable during such loads is moot. So in the case of readtables, it comes down to a question of what Load should do when loading uncompiled files. I'm inclined to think that the current readtable should be used, even though this will have different effects when loading a source file or the corresponding fasl file. We should advise users that the readtable should be the way they want it at COMPILE time if it is to effect code being compiled, because load time is too late. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 26 Feb 86 21:32:37 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Feb 86 18:19:54 PST Date: 26 Feb 1986 20:12-EST Sender: NGALL@G.BBN.COM Subject: Re: defmacro in let From: NGALL@G.BBN.COM To: ANDY@SU-SUSHI.ARPA Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]26-Feb-86 20:12:49.NGALL> In-Reply-To: <12186489734.14.ANDY@SU-SUSHI.ARPA> Date: Wed 26 Feb 86 10:27:27-PST From: Andy Freeman To: common-lisp@SU-AI.ARPA Subject: defmacro in let Message-ID: <12186489734.14.ANDY@SU-SUSHI.ARPA> The following is legal Common Lisp. (let ((tag (gensym))) (defun foo () tag)) What about this? (Yes, this example is stupid, but there are uses of the idea that aren't.) (let ((tag (gensym))) (defmacro foo () tag)) It is legal, but TAG is considered a special (i.e., the enclosing lexical env. is ignored). See pg 145. What about defsetf's inside top-level lets? Unclear from the text how free references should be handled. Since it "resembles DEFMACRO" (pg. 103) I'd go with my answer above. Should be clarified though. -andy ------- -------------------- -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 26 Feb 86 18:32:04 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 26 Feb 86 15:20:39 PST Date: Wed, 26 Feb 86 18:07:59 EST From: Jonathan A Rees Subject: What does LOAD use for read table & package? To: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].831718.860226.JAR> I'm trying to write a portable program which wants to use LOAD and COMPILE-FILE with a particular read table and package not specified by eval-when's or other forms in the file. I'm not at liberty to edit the file, and I don't want to bother writing out an intermediate file (besides being slow, redundant, and impossible to do portably, that screws up whatever record the CL implementation might be keeping of the source file for definitions). But in the implementation I'm using, LOAD and COMPILE-FILE absoluetly insist on ignoring the binding of readtable and package, and defaulting them to I don't know what. (The files don't have attribute lists.) CLtL is not explicit on this point. Is LOAD required to pay attention to the bindings of *READTABLE* and *PACKAGE*? If so, I can report a bug and look forward to a fix N years hence. Many people will say "no" just because they want their LOAD to attend to the -*- attribute list, but what if there isn't any attribute list? Maybe there should be :readtable and :package keyword arguments to LOAD and COMPILE-FILE, to override defaults that the system might have? Or am I just going to have to lose completely here? Jonathan Rees.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 26 Feb 86 15:53:37 EST Received: from SU-SUSHI.ARPA by SU-AI.ARPA with TCP; 26 Feb 86 10:27:29 PST Date: Wed 26 Feb 86 10:27:27-PST From: Andy Freeman Subject: defmacro in let To: common-lisp@SU-AI.ARPA Message-ID: <12186489734.14.ANDY@SU-SUSHI.ARPA> The following is legal Common Lisp. (let ((tag (gensym))) (defun foo () tag)) What about this? (Yes, this example is stupid, but there are uses of the idea that aren't.) (let ((tag (gensym))) (defmacro foo () tag)) What about defsetf's inside top-level lets? -andy -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 25 Feb 86 11:23:51 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 25 Feb 86 08:15:15 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 860; Tue 25-Feb-86 11:15:32-EST Date: Tue, 25 Feb 86 11:15 EST From: David C. Plummer Subject: Things to consider for CLtL'97 To: Common-Lisp@SU-AI.ARPA Message-ID: <860225111537.4.DCP@NEPONSET.SCRC.Symbolics.COM> reduce should have a :KEY keyword argument. For example, suppose you have a sequence of sequences, and you want to know the sum of the lengths of the inner sequences. Currently, I think you have to do (reduce #'(lambda (so-far subsequence) (+ so-far (length sub-sequence))) sequence) but I would prefer to do (reduce #'+ sequence :key #'length) There should be a modify-seq (or some name) that looks roughly like modify-seq sequence modifier &key start end from-end test test-not that modifies the elements of the sequence between start and end that past the TEST function. The element is replaced by the modifier applied to the old element. For example, if a sequence is a sequence of integers and you want to change it into a sequence of arrays whose lengths are based on those integers, one could do (modify-seq sequence #'(lambda (n) (make-array (round (* n 1.1))))) There should be a modify-hash function.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 24 Feb 86 22:05:11 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Feb 86 18:58:17 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA20999; Mon, 24 Feb 86 18:56:18 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA26504; Mon, 24 Feb 86 18:56:14 MST Date: Mon, 24 Feb 86 18:56:14 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8602250156.AA26504@utah-orion.ARPA> To: DCP@scrc-quabbin.arpa, JAR@mc.lcs.mit.edu Subject: Re: Function Cell Follow-up Cc: common-lisp@su-ai.arpa Date: Mon, 24 Feb 86 20:28:33 EST From: Jonathan A Rees Date: Mon, 24 Feb 86 15:56 EST From: David C. Plummer Is tail recursion REQUIRED of Scheme implementations, or is just in all the papers because it is easy to do in most Scheme implementations. It's absolutely as essential as garbage collection. [...] I recall reading some old Lisp Machine papers that suggested garbage collection should be avoided (DDI = Don't Do It!) :-) :-) stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 24 Feb 86 21:27:20 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 24 Feb 86 18:20:10 PST Date: Mon, 24 Feb 86 20:28:33 EST From: Jonathan A Rees Subject: Function Cell Follow-up To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, shebs@UTAH-ORION.ARPA In-reply-to: Msg of Mon 24 Feb 86 15:56 EST from David C. Plummer Message-ID: <[MC.LCS.MIT.EDU].829401.860224.JAR> Date: Mon, 24 Feb 86 15:56 EST From: David C. Plummer Is tail recursion REQUIRED of Scheme implementations, or is just in all the papers because it is easy to do in most Scheme implementations. It's absolutely as essential as garbage collection. (If you argue against one you must argue against the other.) See page 8 of the MIT AI memo 848 (the "revised revised report") and the abstract of memo 452 (the "revised report"). Also note that no mechanism other than function call is supplied to implement iteration, and it would be absurd to limit the number of iterations of a loop to a function of the space available for stack. (It was no easier or harder to do in "most scheme implementations" than in implementations of any other language, except by virtue of having been designed for; I don't quite understand the remark.)  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 24 Feb 86 16:05:40 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 24 Feb 86 12:56:29 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 790; Mon 24-Feb-86 15:56:42-EST Date: Mon, 24 Feb 86 15:56 EST From: David C. Plummer Subject: Function Cell Follow-up To: Jonathan A Rees , shebs@UTAH-ORION.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].828912.860224.JAR> Message-ID: <860224155645.8.DCP@NEPONSET.SCRC.Symbolics.COM> Is tail recursion REQUIRED of Scheme implementations, or is just in all the papers because it is easy to do in most Scheme implementations.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 24 Feb 86 15:08:40 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 24 Feb 86 12:00:10 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 784; Mon 24-Feb-86 15:00:23-EST Date: Mon, 24 Feb 86 15:00 EST From: David C. Plummer Subject: Function Cell Follow-up To: Stanley Shebs , common-lisp@SU-AI.ARPA In-Reply-To: <8602241608.AA21481@utah-orion.ARPA> Message-ID: <860224150024.6.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 24 Feb 86 09:08:37 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) I found the discussion of rationales for function cells interesting. The idea that different kinds of things should be allowed to have separate name spaces seemed to be the strongest reason for function cells, aside from compatibility. Unfortunately, no one addressed my last two questions, which had to do with implementing functions and values in terms of each other. With the correct language walking tools, it is possible to transform Scheme code into Common Lisp code. Basically, if you see FOO in a 'variable' position, but the lexically apparent FOO is really a function, transform it into #'FOO. If there is no lexically apparent FOO, then look at the global definition of function and value and pick the one that is defined. (This has order of definition and compiler environment problems, of course.) Conversely, if you see FOO in functional position, e.g., as (FOO ...) and FOO's innermost lexical definition is as a 'variable' then transform this into (funcall foo ...). I wrote such a tool before, but I have recently learned the usage of our code walker was somewhat incorrect, so I sometimes might generate the wrong answers. As for implementing CL in Scheme, I don't have any experience, but I think it could be done. [I learned Scheme in the '78-'79 academic year and confess I haven't kept up on the language.] One way would be to put the funtion on a property (a la Maclisp). There are a lot of details, but I think function lookup is the hardest; all the rest are mostly source level transforms.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 24 Feb 86 14:21:01 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 24 Feb 86 11:09:40 PST Date: Mon, 24 Feb 86 14:10:24 EST From: Jonathan A Rees Subject: Function Cell Follow-up To: shebs@UTAH-ORION.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Mon 24 Feb 86 09:08:37 MST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs) Message-ID: <[MC.LCS.MIT.EDU].828912.860224.JAR> Date: Mon, 24 Feb 86 09:08:37 MST From: shebs%utah-orion at utah-cs.arpa (Stanley Shebs) Anyway, despite appearances :-), I'm more of an ideologist than an ideologue, and so I'm interested in just how incompatible Common Lisp and Scheme *really* are, and how difficult it would be to implement one in the other. It's certainly possible, but since I haven't actually tried hacking all this out, I'm not clear on the pitfalls. I think the namespace problems are relatively easily overcome by source-to-source translations, both going from Scheme to CL and from CL to Scheme. Going one way you throw in a lot of FUNCALL's, and going the other way you implement packages somehow and do some kludge to generate names for variables which can stand for function bindings. The hard problem in embedding Scheme in CL is tail recursion, which is impossible to simulate in a natural way in portable Common Lisp. It may be more or less easy in particular CL implementations (some are tail recursive already, others may have compilers or stack-overflow handlers that can be tweaked), but the only portable mechanism I know of is to do more or less what Sussman and Steele's 1975 scheme interpreter did, which is to use a driver loop of some kind, so that each procedure "returns" into the driver loop in order to call another procedure at the same stack level. This works but is quite unnatural and probably inefficient. The hard technical problem in embedding CL in Scheme is implementing multiple values smoothly. Various kludges are possible, such as the one used by Maclisp, namely maintaining a set of global value registers. Again, if you can hack the implementation directly, it can be pretty straightforward (some already have multiple value returns internally). A lesser problem is left-to-right argument evaluation, if CL ever decides that that's necessary, but that can be forced using LET*.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 24 Feb 86 11:14:53 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 24 Feb 86 08:06:40 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA02115; Mon, 24 Feb 86 09:08:40 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA21481; Mon, 24 Feb 86 09:08:37 MST Date: Mon, 24 Feb 86 09:08:37 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8602241608.AA21481@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Function Cell Follow-up I found the discussion of rationales for function cells interesting. The idea that different kinds of things should be allowed to have separate name spaces seemed to be the strongest reason for function cells, aside from compatibility. Unfortunately, no one addressed my last two questions, which had to do with implementing functions and values in terms of each other. Perhaps I should point out some motivation. Today, it looks as if Common Lisp and Scheme (in various dialects) are emerging as the two chief alternatives in the Lisp world (sort of like Interlisp and Maclisp once upon a time?). Those who discount Scheme as a competitor should be aware that there are some very good Scheme implementations out there now, and that it has a body of supporters many of whom are in influential positions, i.e. as instructors in classes. At Utah for instance, undergraduates get several courses using Scheme long before they see Lisp, and many other places are similar. Consider another "instructional" language - Pascal - and think about how many Pascal programs have been inflicted on the world... Anyway, despite appearances :-), I'm more of an ideologist than an ideologue, and so I'm interested in just how incompatible Common Lisp and Scheme *really* are, and how difficult it would be to implement one in the other. It's certainly possible, but since I haven't actually tried hacking all this out, I'm not clear on the pitfalls. stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 23 Feb 86 13:57:44 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Feb 86 10:43:42 PST Received: ID ; Sun 23 Feb 86 13:45:08-EST Date: Sun, 23 Feb 1986 13:45 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Steven Haflich Cc: common-lisp@SU-AI.ARPA Subject: readtable and # "syntax" In-reply-to: Msg of 23 Feb 1986 02:19-EST from Steven Haflich In readtable r the parens should now have exchanged their normal functions. When readtable r is in effect, which of the following is correct reader syntax? )defstruct foo a b( ;Ugh! #S(foo 1 2) or )defstruct foo a b( #S)foo 1 2( The issue is not clear from CLtL, which avoids calling the text after #S a "list" and just generally refers to "this syntax". I think that the stuff following the #S is a list, and in parsing it one would use the bindings in the current readtable. So your second example would be the correct one, in my opinion. That seems like the intuitively consistent interpretation to me, if the word "intuitive" can be used in the presence of so perverse an example. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 23 Feb 86 13:51:39 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Feb 86 10:37:44 PST Received: ID ; Sun 23 Feb 86 13:38:52-EST Date: Sun, 23 Feb 1986 13:38 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Steven Haflich Cc: common-lisp@SU-AI.ARPA Subject: reader # syntax and whitespace In-reply-to: Msg of 22 Feb 1986 17:35-EST from Steven Haflich I see nothing in the manual to suggest that whitespace is allowed between a sharp-dispatch sequence and the associated arguments. It seems needlessly confusing to specifically allow this in some cases, where it clearly cannot work for others. In my opinion, it "is an error" (or should be an error) to include such whitespace, and this should not be done in portable code. Some implementations may tolerate whitespace in some of these places, but they certainly sholdn't go out of their way to do so. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 23 Feb 86 02:26:15 EST Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 22 Feb 86 23:16:04 PST Received: by mit-ems.ARPA (4.12/4.8) id AA15642; Sun, 23 Feb 86 02:19:09 est Date: Sun, 23 Feb 86 02:19:09 est From: Steven Haflich Message-Id: <8602230719.AA15642@mit-ems.ARPA> To: common-lisp@su-ai Subject: readtable and # "syntax" There are other ways in which reader # syntax is underspecified in CLtL. Consider: (setq r (copy-readtable)) (set-syntax-from-char #\( #\) r) (set-syntax-from-char #\) #\( r) In readtable r the parens should now have exchanged their normal functions. When readtable r is in effect, which of the following is correct reader syntax? )defstruct foo a b( ;Ugh! #S(foo 1 2) or )defstruct foo a b( #S)foo 1 2( The issue is not clear from CLtL, which avoids calling the text after #S a "list" and just generally refers to "this syntax".  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 22 Feb 86 18:50:16 EST Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 22 Feb 86 15:40:16 PST Received: by mit-ems.ARPA (4.12/4.8) id AA14012; Sat, 22 Feb 86 17:35:46 est Date: Sat, 22 Feb 86 17:35:46 est From: Steven Haflich Message-Id: <8602222235.AA14012@mit-ems.ARPA> To: common-lisp@su-ai Subject: reader # syntax and whitespace Is the reader required to accept whitespace between sharp dispatch sequences and the "following arguments in some form" (CLtL p.351)? The answer obviously is no for #\x but not so clear for others: #s (foo a 1 b 2) #2a ((1 2 3) (4 5 6)) #' (lambda (x) (* x 2)) The strong similarity of each such "syntax" to a normal list suggests that the reader will recursively use normal read, which implies that whitespace will be skipped. But should one rely on it across all implementations? If so, what about these? #+ lisp1.5 #: foo #x f98e #B 01110110 #3R 121211 These violate my aesthetic sense that single atoms are delimited by whitespace. Even so, the last three are arguably more readable (to humans) with the space. I feel that for consistency leading whitespace ought explicitly be defined as legal after all sharp dispatches *except* sharp-backslash.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Feb 86 22:15:42 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 21 Feb 86 19:03:47 PST Date: Fri, 21 Feb 86 22:04:25 EST From: "George J. Carrette" Subject: Function cells To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, gls@AQUINAS.THINK.COM In-reply-to: Msg of Fri 21 Feb 86 10:27 EST from David C. Plummer Message-ID: <[MC.LCS.MIT.EDU].826494.860221.GJC> CAR is not a constant because it is microcoded. CAR is (can be legally) microcoded because it is a constant. Get the difference? The problem you pose could come up in the LMI software where a user can make a (DEFUN FOO ...) turn into a %MISC instruction opcode by using the microcompiler, but should be avoided by having redefined %MISC instructions trap back to macrocode. The hard part is that the actual number of arguments to the call is lost in the translation to order-code, and klugely recovered by groveling through the debugging info for the FEF being executed. The real problem is allocating the limited opcode space, which right now is on a first-come-first-served basis. (Microcompiled function need but turn into %MISC's but it is the most efficient thing to turn into). -gjc  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Feb 86 22:00:33 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Feb 86 18:51:24 PST Received: ID ; Fri 21 Feb 86 21:52:23-EST Date: Fri, 21 Feb 1986 21:52 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: buffered output and prompting In-reply-to: Msg of 21 Feb 1986 12:46-EST from NGALL at G.BBN.COM I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to implicitly cause a newline to be written. I agree. I don't think pg. 22 implicitly allows FORCE-OUTPUT or FINISH-OUTPUT to postpend a newline. I agree too. Therefore, I don't think that we need any new machinery in order to do prompting. You just squeeze out the prompt with a force-output, and wait for an answer. If some line-oriented systems are so wedged that they can't type something and then wait for input on the same line, then they will have to do the best they can and certain things will be ugly. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Feb 86 16:01:25 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Feb 86 12:52:19 PST Received: ID ; Fri 21 Feb 86 15:53:10-EST Date: Fri, 21 Feb 1986 15:53 EST Message-ID: From: Rob MacLachlan To: SANDRA Cc: common-lisp@SU-AI.ARPA, NGALL@BBNG.ARPA Subject: buffered output and prompting In-reply-to: Msg of 21 Feb 1986 14:27-EST from SANDRA At one point, there was a prompting function in the Common Lisp spec. This is another thing that was flushed due to controversiality. Most people won't dispute that some sort of prompting capability is useful; the problem is deciding what to provide and how. If you have a proposal, speak up. In my message, I was pointing out that it is possible to use OS prompting features without having a language prompt notion. Regardless of the desirability of a prompting function, you should probably support users printing their own prompts. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Feb 86 15:48:09 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 21 Feb 86 12:39:04 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 482; Fri 21-Feb-86 10:20:29-EST Date: Fri, 21 Feb 86 10:27 EST From: David C. Plummer Subject: Function cells To: George J. Carrette , gls@AQUINAS.THINK.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].825077.860220.GJC> Message-ID: <860221102725.1.DCP@NEPONSET.SCRC.Symbolics.COM> If CAR == #'CAR were a constant (because it was microcoded), posit a machine that 'compiles' function into microcode and assigns instructions opcodes for them which further compilations then use. [Of course this creates havoc to programming development.] Now I can't bind function cells at all unless I happen to use FUNCALL all the time, which might very well lose some advantages of calling the instruction directly. On more realistic machines, some 'functions' are constants and some are not. How can one write portable code that would bind function cells? MIT students are indeed exposed to these ISSUES which are demonstrated on CONVENTIONAL hardware (68Ks I believe) that does not run Lisp natively and therefore bypasses the issues for more Lisp-specific engines.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Feb 86 14:40:20 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 21 Feb 86 11:27:10 PST Date: Fri 21 Feb 86 12:27:13-MST From: SANDRA Subject: Re: buffered output and prompting To: NGALL@BBNG.ARPA cc: RAM@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]21-Feb-86 12:46:01.NGALL> Message-ID: <12185189893.6.LOOSEMORE@UTAH-20.ARPA> Somehow I think this discussion of whether FORCE-OUTPUT can or can't write a newline is missing the mark. Leaving aside the issue whether this business about continuation markers in output records could even be implemented with the primitives provided by your operating system, restricting a low-level detail of the implementation like this to support a high-level concept like reading with a prompt strikes me as being counterproductive. I think that prompting the user to type something on the keyboard is a common enough situation that it would be worthwhile to provide a standardized, high-level interface for doing so. After all, if functions to handle situations that don't even occur in CL (like get-setf-method-multiple-value!) were deemed important enough to include in the language specification, it ought to be worthwhile to provide a high-level hook for a situation that does occur quite often. Not only would this free the programmer from having to write a lot of grungy code, but implementors would have maximum freedom to present the prompt in whatever way is most compatible with the rest of the user interface. -Sandra -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 21 Feb 86 13:02:10 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Feb 86 09:49:02 PST Date: 21 Feb 1986 12:46-EST Sender: NGALL@G.BBN.COM Subject: Re: buffered output and prompting From: NGALL@G.BBN.COM To: RAM@C.CS.CMU.EDU Cc: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]21-Feb-86 12:46:01.NGALL> In-Reply-To: Date: Thu, 20 Feb 1986 18:41 EST From: Rob MacLachlan To: SANDRA Subject: buffered output and prompting Date: Wednesday, 19 February 1986 13:10-EST From: SANDRA To: common-lisp at SU-AI.ARPA Re: buffered output and prompting I'm having trouble coming up with a portable way for a CL application program to read with a prompt string. What I would like to do is something like, but more general than, the y-or-n-p and yes-or-no-p functions: specify a prompt string and then call read, read-line, or read-char. For a usual terminal-style interaction, I'd like to have the prompt message printed out without a newline so the cursor is left at the end of the same line, and then read. .... I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to implicitly cause a newline to be written. I agree. I don't think pg. 22 implicitly allows FORCE-OUTPUT or FINISH-OUTPUT to postpend a newline. All pg. 22 says (to me) is that in some implementations: 1. For output that contains a newline, the output medium may be such that a newline neither appears as a visible glyph nor causes some state-change in the carriage-control mechanism or linefeed mechanism of the output medium (since some output mediums have no such mechanisms, e.g., a card-punch.) But, the newline must be manifested in some way, e.g., ending the current card without punching a line-contiuation indicator (card-punches w/o such a mech. cannot be used as the output medium for CL, since you couldn't print tokens conatining more chars. than could be fit onto a single card.) 2. For input that contains a newline, the input medium may be such that the newline character is not represented as a distinct entity, e.g. a byte in memory; rather the newline is implicit in the structure of an input record, e.g., based on the length of the record. But, there is usually a way to overide such an implicit interpretation, in order to allow tokens and/or lines which might otherwise be input with an embedded newline to be input without a newline being implicitly embedded, e.g., on an input card there is a continuation indicator that allows lines longer than the number of chars. on a single card. (note that such an override would be required on card readers that read cards that could not contain enough chars. for the longest CL defined symbol (which one is the longest? :-)). It does not allow printing to or reading from such mediums to throw in extraneous newlines merely because of peculiarites in nature the medium, e.g., record-length limits and default interpretations of distinct records as distinct lines. For example, FORCE-OUTPUT may cause the current card to be flipped into the ouput bin, but if it does so, it had better punch the continuation indicator before doing so. I think it would be a good idea to clarify FORCE-OUTPUT and FINISH-OUTPUT so that it is clear that they cannot generate an implicit newline. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 20:06:07 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 20 Feb 86 16:53:11 PST Date: Thu, 20 Feb 86 19:53:37 EST From: "George J. Carrette" Subject: Function cells To: gls@AQUINAS.THINK.COM cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Thu 20 Feb 86 18:27 EST from David C. Plummer Message-ID: <[MC.LCS.MIT.EDU].825077.860220.GJC> I lied of course when I said I didnt understand the efficiency arguments for function cells and their irregular binding semantics. I do understand, and I think they are hogwash. First, the dynamic binding case might not really be the most important. It is true that in most code written *now* a form ( ) the is 98% evaluated "dynamic" (or at least it uses a shallow bound global cell, which is not the same thing really) and the rest of are 90% local or lexical. But one need not equate global cell with fluid binding. Also one need not equate multiprocessing fluid binding with DEAP BINDING. There are easy ways of implementing fluid binding in a multiprocessing or multiprocessor context without arbitrarily costly table lookups. (Example, a LMI-LAMBDA 2-processor model running ... to be published...) The argument DCP mentions that goes like "what if I BIND #'CAR" is also hogwash. What if I (defun car (x) ...)??? You have the same problem. A good answer starts off with, "well, when you compiled the function F you did it in a lexical scope where CAR was bound to a CONSTANT." Unfortunately to users of common-lisp that isnt a good answer because common-lisp does not admit of such a *model* of binding and evaluation. What you want is a model where fluid, local, lexical, all fall out as the same mechanism with slightly different parameters. I claim that even MIT freshman get exposed to such models.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 18:52:17 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Feb 86 15:39:57 PST Received: ID ; Thu 20 Feb 86 18:41:25-EST Date: Thu, 20 Feb 1986 18:41 EST Message-ID: From: Rob MacLachlan To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: buffered output and prompting In-reply-to: Msg of 19 Feb 1986 13:10-EST from SANDRA Date: Wednesday, 19 February 1986 13:10-EST From: SANDRA To: common-lisp at SU-AI.ARPA Re: buffered output and prompting I'm having trouble coming up with a portable way for a CL application program to read with a prompt string. What I would like to do is something like, but more general than, the y-or-n-p and yes-or-no-p functions: specify a prompt string and then call read, read-line, or read-char. For a usual terminal-style interaction, I'd like to have the prompt message printed out without a newline so the cursor is left at the end of the same line, and then read. I believe the solution in TOPS-20 Clisp is the have the terminal output stream remember the text on the current line. When a read is done on the stream, this text is passed to the OS prompting call as the prompt. I think it is definitely wrong for a FORCE-OUTPUT or FINISH-OUTPUT to implicitly cause a newline to be written. If it is impossible to write text without a newline, then these calls are probably no-ops in your OS. It isn't true that the Common Lisp I/O precludes the use of a pop-up window for prompting. All you have to do is define the stream so that it pops up when you use it. You can do quite a bit with the built-in stream I/O functions if you are willing to define new kinds of streams. Common Lisp doesn't specifiy how, but every implementation should provide some way to define new kinds of streams in Lisp. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 18:32:09 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 Feb 86 15:20:51 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424; Thu 20-Feb-86 18:20:57-EST Date: Thu, 20 Feb 86 18:27 EST From: David C. Plummer Subject: Function cells To: Guy Steele , common-lisp@SU-AI.ARPA In-Reply-To: <860219154017.1.GLS@KATHERINE.THINK.COM> Message-ID: <860220182741.9.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 19 Feb 86 15:40 EST From: Guy Steele My memory is that a question arose as to whether, given that function cells and value cells were to be distinct, they should have identical binding mechanisms or not. There was no compelling reason to allow special binding of function names, and the following argument was advanced against such special bindings: multiprocessing implementations of Lisp might well prefer to use deep special binding, and it was undesirable to have to deal with the deep binding mechanism for function lookups, given that most function-name references, unlike most variable-name references, occur free. I recall that this was the deciding argument that eliminated special binding of function names from Common Lisp, thereby making function names and variable names dissimilar in their semantics and further discouraging their merging. This is one reason I usually give people who ask me. Consider another reason: Suppose you allowed deep binding of function cells as 'part of the language'. What would happen if you bound #'CAR? Doesn't this effectively force every function to be a true function, even if the hardware happens to be able to do the operation 10+ times faster than it takes to do a function call? 'Well, you aren't allowed to (deep) bind inline functions or functions that compile into instructions.' isn't a good answer because then we have to agree on what these are, and we might as well not be a portable language any more. I can report that much of the time I am very happy to have the two names spaces be distinct. I get very unhappy whenever I find myself inventing functionals (functions that take other functions as arguments or return other functions as values) for various purposes. For example, I have found it semantically convenient to do so in Connection Machine Lisp. In these situations I find the need for interpolated occurrences of "funcall" and "#'" extremely annoying. I read this last paragraph 3 times and am under the impression you change your mind on each sentence. I'm really curious what you meant!  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 18:17:24 EST Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 Feb 86 15:03:18 PST Received: from NEPONSET.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423; Thu 20-Feb-86 18:03:22-EST Date: Thu, 20 Feb 86 18:10 EST From: David C. Plummer Subject: loop macro To: DDYER@SCRC-RIVERSIDE.ARPA, David A. Moon , common-lisp@SU-AI.ARPA In-Reply-To: <860207151100.8.DDYER@PURPLE.SWW.Symbolics.COM> Message-ID: <860220181007.8.DCP@NEPONSET.SCRC.Symbolics.COM> Date: Fri, 7 Feb 86 15:11 PST From: DDYER@SCRC-RIVERSIDE.ARPA Date: Fri, 7 Feb 86 16:11 EST From: David A. Moon Just to set the record straight: Date: Wed, 5 Feb 86 10:49 EST From: Daniel L. Weinreb .... Since I'm getting into details, I should make quite clear that I do not speak for Moon in the matter of LOOP. Our opinions on this topic diverge much more than they do on most other topics. True. One of my own strong feelings about LOOP that Moon does not share is that we should get rid of the conditionals. False. Dan misremembered my position here. Actually, I've believed for several years that the conditionals in LOOP were the principal mistake in the current design. If I were doing it over today, I would certainly use the regular Lisp conditionals, which of course implies changes to the theory of collection. In the real world, one might consider keeping the conditionals just for compatibility, but frowning on their use in new code. The conditionals wouldn't be so bad if there were BEGIN and END markers for the scope of the body. Adding BEGIN and END as loop keywords would solve eliminate my objections to the loop conditionals. Oh, barf. What Moon meant was (case x (y (unless (or a b) (collect xyzzy))) (z (collect pray)) (otherwise (error "Loser!"))) Just adding block-construct keywords to LOOP is continuing a beyond-its-time idea.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 16:47:42 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Feb 86 13:29:40 PST Received: ID ; Thu 20 Feb 86 16:30:18-EST Date: Thu, 20 Feb 1986 16:30 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Eric J. Swenson" Cc: common-lisp@SU-AI.ARPA Subject: Basic Design Questions: function cells In-reply-to: Msg of 20 Feb 1986 09:46-EST from Eric J. Swenson I've gotten several responses (off the record, it appears since they were not cc'ed to the common-lisp mailing list) which appear to confirm my feeling that the two-cell approach in considered to be very ugly and that this decision must have been based on maintaining compatibility with existing renditions of Lisp. I can't very well argue with your anonymous friends, but in my opinion a Lisp that stores function definitions in value cells is not as good for serious programming as one that has two distinct name spaces. As I said before, this was not just a compatibility issue, at least for some of us. Another topic, which along similar veins, appears to hold a consensus is that the multitude of functions within CL which "only work for global (special) variables and not for lexically bound variables" and vice-versa is also clumsy in appearance. Would someone care to explain why it was necessary to devise two-sets of functions for what (being rather naive, I would think) could have been combined into one more consistent set? I have no idea what you're talking about. The only such function I can think of is PROGV, and that couldn't work for lexical variables. Gee, I'm sounding almost as grumpy as Moon today... -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 16:27:20 EST Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 13:15:47 PST Acknowledge-To: "Eric J. Swenson" Date: Thu, 20 Feb 86 09:46 EST From: "Eric J. Swenson" Subject: Re: Basic Design Questions: function cells To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 19 Feb 86 18:22 EST from "Fischer.pa at XEROX.COM" Message-ID: <860220144626.703757@CISL-SERVICE-MULTICS.ARPA> I've gotten several responses (off the record, it appears since they were not cc'ed to the common-lisp mailing list) which appear to confirm my feeling that the two-cell approach in considered to be very ugly and that this decision must have been based on maintaining compatibility with existing renditions of Lisp. Another topic, which along similar veins, appears to hold a consensus is that the multitude of functions within CL which "only work for global (special) variables and not for lexically bound variables" and vice-versa is also clumsy in appearance. Would someone care to explain why it was necessary to devise two-sets of functions for what (being rather naive, I would think) could have been combined into one more consistent set?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 14:42:00 EST Received: from MCC.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:45:52 PST Received: from mcc-pp by MCC.ARPA with TCP; Thu 20 Feb 86 12:45:09-CST Posted-Date: Thu, 20 Feb 86 12:43:59 cst Received: from dopey.MCC.ARPA (dopey) by mcc-pp (4.12/RKA.851124) id AA20952; Thu, 20 Feb 86 12:44:29 cst Return-Path: Received: by dopey.MCC.ARPA (2.0/RKA.851124) id AA05443; Thu, 20 Feb 86 12:43:59 cst Date: Thu, 20 Feb 86 12:43:59 cst From: ables%dopey%mcc-pp@mcc.arpa (King Ables) Message-Id: <8602201843.AA05443@dopey.MCC.ARPA> To: clisp%mcc-pp@mcc.arpa Subject: apology I'm sorry about that big message for those of you who got it (apparently not EVERYBODY did, thank goodness). I was setting up an alias on my local machine and got confused for about a minute and a half and that was all it took. 1000 pardons. -king  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 13:23:37 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:09:00 PST Received: from CUYAHOGA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 421289; Thu 20-Feb-86 13:05:07-EST Date: Thu, 20 Feb 86 13:07 EST From: Robert A. Cassels Subject: reading floats.. To: pyramid!bein@SRI-UNIX.ARPA, common-lisp@SU-AI.ARPA cc: bein@SRI-UNIX.ARPA In-Reply-To: <509261796/bein@pyramid> Message-ID: <860220130725.5.CASSELS@CUYAHOGA.SCRC.Symbolics.COM> Reply-To: Robert A. Cassels Date: 19 Feb 1986 21:36-PST From: David Bein What do others think the reader for floating point numbers should do when it calculates a 0 mantissa (for float-digits equal to 53 this would be 4503599627370496 in terms of a 53 bit 1.F value) and the smallest exponent which would be 0.0 if given to scale-float? (Assume the digits are non-zero).. I can see one of the following possibilities: (1) Could be quiet and produce the smallest possible non-zero float of the desired type. (2) Could be quiet and return 0.0. Either (1) or (2) could be construed as producing "the closest representable value to the input", but they both seem wrong. Mostly they are both misleading in that the floating-point result bears little resemblance to the input. (3) Could complain about non-zero digits turning into 0.0. (read-from-string "1e-50") on the Symbolics system currently blows out with the following error message: "The number 1E-50 is too small in magnitude for single-precision floating-point format." Underflow which leaves a denormalized nonzero result is accepted quietly, since the value is as accurate as possible given the format. (4) Compute it in a higher format if possible and let it die when converting that to the desired format. I don't see how this differs from (3) except that the message the user gets is more obscure. Note that this question also covers what would be described as exponent underflow since the mantissa for that would be too small if we shift the exponent to be in range. I vote for #3. Note that a proper printer based upon Guy Steele's "How To Print Floating Point Numbers.." will not produce digits which fall into this class, so this is only a question for "virgin" input. --David  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 13:16:50 EST Received: from MCC.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:03:09 PST Received: from mcc-pp by MCC.ARPA with TCP; Thu 20 Feb 86 12:02:26-CST Date: Thu, 20 Feb 86 12:01:40 cst From: ables%mcc-pp@mcc.arpa (King Ables) Posted-Date: Thu, 20 Feb 86 12:01:40 cst Message-Id: <8602201801.AA20732@mcc-pp> Received: by mcc-pp (4.12/RKA.851124) id AA20732; Thu, 20 Feb 86 12:01:40 cst To: clisp%mcc-pp@mcc.arpa Subject: back messages Wed 19 Feb 86 11:10:35-MST SANDRA buffered output and prompting I'm having trouble coming up with a portable way for a CL application program to read with a prompt string. What I would like to do is something like, but more general than, the y-or-n-p and yes-or-no-p functions: specify a prompt string and then call read, read-line, or read-char. For a usual terminal-style interaction, I'd like to have the prompt message printed out without a newline so the cursor is left at the end of the same line, and then read. Aside from the fact that writing out the prompt string directly prevents you from using alternative interaction styles (like a pop-up dialog box or whatever), it's unclear that you could guarantee the same behavior, or even reasonable behavior, in all CL implementations. CLtL implies that buffered i/o is perfectly acceptable, so I assume one would have to do a (finish-output) after printing the prompt message to ensure that it really does get printed. However, emptying the internal buffer may mean that the prompt message shows up with a newline on the end, particularly if the output stream is organized into records with an implicit newline at the end of each record. (This is also acceptable, according to page 22.) Furthermore, the terminal driver provided by the operating system may include some fancy input editing capabilities that are confused by printing out random prompt strings; to get the prompt to interact properly with the editor, you have to pass it to the read function provided by the operating system. (In fact, all three of these conditions are true under VMS.) PSL has a variable that holds the current prompt string, and it's used whenever you read from the terminal. Different PSL implementations use whatever hooks the OS provides to get the right effect. I also seem to remember that the NMODE editor does special things with the prompt string that are more appropriate for its style of interaction. The point is, the same code will produce reasonable behavior in all situations. How can I get similar portability in CL code? Do we need to define additional functions (or additional arguments to existing functions) to support user interaction? -Sandra ------- Wed, 19 Feb 86 14:10 EST Re: Basic Design Questions: function cells Date: Wed, 19 Feb 86 11:24 EST From: "Eric J. Swenson" I too don't understand the arguments of the efficiency of the function cell concept, I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. I could be wrong; people will argue for almost anything. however, from the standpoint of looking at CL as a NEW language (as opposed to a pot-pouri of all the existing Lisp dialects) it certainly seems that CL is clutterred with pairs of functions/macros to deal with functional and non-functional objects and that elegance has been sacrificed in order to maintain compatibility with the various older Lisp dialects. I take it that the overriding factor in CL development has been compatilibity with the major Lisp dialects as opposed to designing a new language which was more internally consistent and conceptually elegant? That's certainly true. At the same time, it is a matter of opinion whether having all of the dozens of possible classes of named objects in the same space, or each in a separate space, is more elegant. The issue is not only variables and functions. Without going into extensions to Common Lisp, you can also think about package names, type names, and module names. There are powerful arguments on both sides of this issue. All a language designer can do is pick one philosophy and then be consistent about it. ---- Wednesday, February 19, 1986 12:02:30 Alan Snyder Re: Basic Design Questions: function cells I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. My impression was that having a separate function cell can be more efficient because it allows function invocation to be compiled into a direct jsr (or jump) through the function cell, with no explicit check that the function is defined (undefined functions are represented by a special undefined-function function). Using the same cell for functions and other variables would require checking that the cell contains a function before calling it (otherwise you might transfer control to a random location). ------- 19 Feb 1986 1243-PST (Wednesday) berman@isi-vaxa.ARPA (Richard Berman) Re: Basic Design Questions: function cells I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. My impression was that having a separate function cell can be more efficient because it allows function invocation to be compiled into a direct jsr (or jump) through the function cell, with no explicit check that the function is defined (undefined functions are represented by a special undefined-function function). Using the same cell for functions and other variables would require checking that the cell contains a function before calling it (otherwise you might transfer control to a random location). ------- The function cell can also hold the lambda expression for an interpreted function, so you can't do a blind JSR anyway. RB ------ 19 Feb 1986 12:39-PST MATHIS@USC-ISIF.ARPA Standardization proposal Today I sent a proposal to X3 for the establishment of a technical committee for the development of an American National Standard for Common Lisp. This committee will probably have the designation X3J13. Following their normal time-table, the committee will probably be approved in early summer and the first official meeting will be in Washington, DC in September 1986. Membership will be open according to X3 rules (basically attendance, participation, and payment of fees). The proposals are available as net mail, but I would rather only send them to interested people. If you are interested in seeing the proposals or participating on the X3J13 committee, please respond and give me your non-arpa-net addresses as well. Bob Mathis 9712 Ceralene Dr Fairfax, VA 22032-1704 (703)425-5923 ------ Wed, 19 Feb 86 15:40 EST Guy Steele Function cells My memory is that a question arose as to whether, given that function cells and value cells were to be distinct, they should have identical binding mechanisms or not. There was no compelling reason to allow special binding of function names, and the following argument was advanced against such special bindings: multiprocessing implementations of Lisp might well prefer to use deep special binding, and it was undesirable to have to deal with the deep binding mechanism for function lookups, given that most function-name references, unlike most variable-name references, occur free. I recall that this was the deciding argument that eliminated special binding of function names from Common Lisp, thereby making function names and variable names dissimilar in their semantics and further discouraging their merging. I can report that much of the time I am very happy to have the two names spaces be distinct. I get very unhappy whenever I find myself inventing functionals (functions that take other functions as arguments or return other functions as values) for various purposes. For example, I have found it semantically convenient to do so in Connection Machine Lisp. In these situations I find the need for interpolated occurrences of "funcall" and "#'" extremely annoying. --Guy ------ Wed, 19 Feb 86 14:29:56 MST kessler%utah-orion@utah-cs.arpa (Robert Kessler) re: Function Cells > The function cell can also hold the lambda expression for an interpreted > function, so you can't do a blind JSR anyway. That is not true. One simply stores the lambda expression on the property list and stores a call to "CompiledCallingInterpreted" compiled function in the function cell. "CompiledCallingInterpreted" picks up the lambda expression from the property list and performs normal interpreted evaluation. PSL also stores a reference to "UndefinedFunction" in newly made symbols which causes the undefined function processing to be handled. Thus you can guarentee that the function cell always contains an executable function address and never need to check. Bob. ------ Wednesday, February 19, 1986 14:21:00 Alan Snyder Re: Basic Design Questions: function cells The function cell can also hold the lambda expression for an interpreted function, so you can't do a blind JSR anyway. Your assumption that the lambda expression for an interpreted function must be stored in the function cell is incorrect. PSL used the implementation technique that I described, with good results. ------- 19 Feb 86 15:42 PST Fischer.pa@Xerox.COM Re: transfer control to a random location Why should Common Lisp worry about this efficiency? It "would be an error" just like so many other things that can destroy a "fast" Common Lisp. Now if you mean this is one small case where the language favors a conventional machine... (ron) ------ Wed 19 Feb 86 18:00:48-PST Martin Re: Basic Design Questions: function cells Return-Path: <@SU-AI.ARPA:berman@isi-vaxa.ARPA> Received: from hplabs.ARPA by HP-HULK with TCP; Wed 19 Feb 86 13:15:15-PST Received: from SU-AI.ARPA by hplabs.ARPA ; Wed, 19 Feb 86 13:16:12 pst Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST Received: by isi-vaxa.ARPA (4.12/4.7) id AA04673; Wed, 19 Feb 86 12:43:16 pst From: berman@isi-vaxa.ARPA (Richard Berman) Message-Id: <8602192043.AA04673@isi-vaxa.ARPA> Date: 19 Feb 1986 1243-PST (Wednesday) Cc: Alan Snyder Subject: Re: Basic Design Questions: function cells To: common-lisp@su-ai.ARPA I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. My impression was that having a separate function cell can be more efficient because it allows function invocation to be compiled into a direct jsr (or jump) through the function cell, with no explicit check that the function is defined (undefined functions are represented by a special undefined-function function). Using the same cell for functions and other variables would require checking that the cell contains a function before calling it (otherwise you might transfer control to a random location). ------- The function cell can also hold the lambda expression for an interpreted function, so you can't do a blind JSR anyway. RB Actually, in our CL implementation, and in PSL before it, there is a compiled LAMBDA handler function (or "thunk") to which you JSR; it finds the associated S-expression wherever it is (or reconstructs, or whatever). Martin Griss ------- 19 Feb 1986 21:36-PST David Bein reading floats.. What do others think the reader for floating point numbers should do when it calculates a 0 mantissa (for float-digits equal to 53 this would be 4503599627370496 in terms of a 53 bit 1.F value) and the smallest exponent which would be 0.0 if given to scale-float? (Assume the digits are non-zero).. I can see one of the following possibilities: (1) Could be quiet and produce the smallest possible non-zero float of the desired type. (2) Could be quiet and return 0.0. (3) Could complain about non-zero digits turning into 0.0. (4) Compute it in a higher format if possible and let it die when converting that to the desired format. Note that this question also covers what would be described as exponent underflow since the mantissa for that would be too small if we shift the exponent to be in range. I vote for #3. Note that a proper printer based upon Guy Steele's "How To Print Floating Point Numbers.." will not produce digits which fall into this class, so this is only a question for "virgin" input. --David  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 13:12:15 EST Received: from MCC.ARPA by SU-AI.ARPA with TCP; 20 Feb 86 10:02:37 PST Received: from mcc-pp by MCC.ARPA with TCP; Thu 20 Feb 86 12:01:58-CST Date: Thu, 20 Feb 86 12:01:15 cst From: ables%mcc-pp@mcc.arpa (King Ables) Posted-Date: Thu, 20 Feb 86 12:01:15 cst Message-Id: <8602201801.AA20728@mcc-pp> Received: by mcc-pp (4.12/RKA.851124) id AA20728; Thu, 20 Feb 86 12:01:15 cst To: clisp%mcc-pp@mcc.arpa Subject: a note on back messages Ed or Pat have a line-printer copy of the old messages from CLISP dating back to November 85 if anyone is interested. It is also available by logging in on the Dec-20 and typing "bboard clisp". I will manually forward messages that come to the group until the necessary aliases are added to the Dec-20 to put us on the list. They will not be individual messages but in groups (of however many have come in since the last time I checked). When the "real" distribution begins, each message will be a separate news article.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 20 Feb 86 00:53:52 EST Received: from SRI-UNIX.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 21:45:52 PST Received: by sri-unix.ARPA (4.12/4.16) id AA14531; Wed, 19 Feb 86 21:44:44 pst Received: by pyramid (4.12/3.14) id AA07331; Wed, 19 Feb 86 21:39:36 pst Date: 19 Feb 1986 21:36-PST From: David Bein Subject: reading floats.. To: common-lisp@SU-AI.ARPA Cc: bein@sri-unix Message-Id: <509261796/bein@pyramid> What do others think the reader for floating point numbers should do when it calculates a 0 mantissa (for float-digits equal to 53 this would be 4503599627370496 in terms of a 53 bit 1.F value) and the smallest exponent which would be 0.0 if given to scale-float? (Assume the digits are non-zero).. I can see one of the following possibilities: (1) Could be quiet and produce the smallest possible non-zero float of the desired type. (2) Could be quiet and return 0.0. (3) Could complain about non-zero digits turning into 0.0. (4) Compute it in a higher format if possible and let it die when converting that to the desired format. Note that this question also covers what would be described as exponent underflow since the mantissa for that would be too small if we shift the exponent to be in range. I vote for #3. Note that a proper printer based upon Guy Steele's "How To Print Floating Point Numbers.." will not produce digits which fall into this class, so this is only a question for "virgin" input. --David  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 21:18:51 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 18:03:37 PST Received: from HP-HULK by hplabs.ARPA ; Wed, 19 Feb 86 18:02:24 pst Date: Wed 19 Feb 86 18:00:48-PST From: Martin Subject: Re: Basic Design Questions: function cells To: berman@isi-vaxa.ARPA Cc: GRISS%HP-HULK@HPLABS, common-lisp%su-ai@HPLABS In-Reply-To: Message from "berman@isi-vaxa.ARPA (Richard Berman)" of Wed 19 Feb 86 12:43:00-PST Return-Path: <@SU-AI.ARPA:berman@isi-vaxa.ARPA> Received: from hplabs.ARPA by HP-HULK with TCP; Wed 19 Feb 86 13:15:15-PST Received: from SU-AI.ARPA by hplabs.ARPA ; Wed, 19 Feb 86 13:16:12 pst Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST Received: by isi-vaxa.ARPA (4.12/4.7) id AA04673; Wed, 19 Feb 86 12:43:16 pst From: berman@isi-vaxa.ARPA (Richard Berman) Message-Id: <8602192043.AA04673@isi-vaxa.ARPA> Date: 19 Feb 1986 1243-PST (Wednesday) Cc: Alan Snyder Subject: Re: Basic Design Questions: function cells To: common-lisp@su-ai.ARPA I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. My impression was that having a separate function cell can be more efficient because it allows function invocation to be compiled into a direct jsr (or jump) through the function cell, with no explicit check that the function is defined (undefined functions are represented by a special undefined-function function). Using the same cell for functions and other variables would require checking that the cell contains a function before calling it (otherwise you might transfer control to a random location). ------- The function cell can also hold the lambda expression for an interpreted function, so you can't do a blind JSR anyway. RB Actually, in our CL implementation, and in PSL before it, there is a compiled LAMBDA handler function (or "thunk") to which you JSR; it finds the associated S-expression wherever it is (or reconstructs, or whatever). Martin Griss -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 19:28:32 EST Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Feb 86 15:55:25 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 86 15:43:08 PST Date: 19 Feb 86 15:42 PST From: Fischer.pa@Xerox.COM Subject: Re: transfer control to a random location In-reply-to: Alan Snyder 's message of Wednesday, February 19, 1986 12:02:30 To: snyder@hplsny.ARPA cc: MOON@SCRC-QUABBIN.ARPA, common-lisp@su-ai.ARPA Message-ID: <860219-154308-3347@Xerox> Why should Common Lisp worry about this efficiency? It "would be an error" just like so many other things that can destroy a "fast" Common Lisp. Now if you mean this is one small case where the language favors a conventional machine... (ron)  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 17:42:37 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 14:23:00 PST Received: from hplsny by hplabs.ARPA ; Wed, 19 Feb 86 14:21:54 pst Received: by hplsny ; Wed, 19 Feb 86 14:21:05 pst From: Alan Snyder Message-Id: <8602192221.AA07885@hplsny> Date: Wednesday, February 19, 1986 14:21:00 Subject: Re: Basic Design Questions: function cells To: berman@isi-vaxa.ARPA Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 19-Feb-86 12:43:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 The function cell can also hold the lambda expression for an interpreted function, so you can't do a blind JSR anyway. Your assumption that the lambda expression for an interpreted function must be stored in the function cell is incorrect. PSL used the implementation technique that I described, with good results. -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 16:39:22 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 13:28:01 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA01272; Wed, 19 Feb 86 14:29:59 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA00286; Wed, 19 Feb 86 14:29:56 MST Date: Wed, 19 Feb 86 14:29:56 MST From: kessler%utah-orion@utah-cs.arpa (Robert Kessler) Message-Id: <8602192129.AA00286@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: re: Function Cells > The function cell can also hold the lambda expression for an interpreted > function, so you can't do a blind JSR anyway. That is not true. One simply stores the lambda expression on the property list and stores a call to "CompiledCallingInterpreted" compiled function in the function cell. "CompiledCallingInterpreted" picks up the lambda expression from the property list and performs normal interpreted evaluation. PSL also stores a reference to "UndefinedFunction" in newly made symbols which causes the undefined function processing to be handled. Thus you can guarentee that the function cell always contains an executable function address and never need to check. Bob.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 15:49:24 EST Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:41:30 PST Received: by isi-vaxa.ARPA (4.12/4.7) id AA04673; Wed, 19 Feb 86 12:43:16 pst From: berman@isi-vaxa.ARPA (Richard Berman) Message-Id: <8602192043.AA04673@isi-vaxa.ARPA> Date: 19 Feb 1986 1243-PST (Wednesday) Cc: Alan Snyder Subject: Re: Basic Design Questions: function cells To: common-lisp@su-ai.ARPA I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. My impression was that having a separate function cell can be more efficient because it allows function invocation to be compiled into a direct jsr (or jump) through the function cell, with no explicit check that the function is defined (undefined functions are represented by a special undefined-function function). Using the same cell for functions and other variables would require checking that the cell contains a function before calling it (otherwise you might transfer control to a random location). ------- The function cell can also hold the lambda expression for an interpreted function, so you can't do a blind JSR anyway. RB  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 15:48:37 EST Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:39:20 PST Date: 19 Feb 1986 12:39-PST Sender: MATHIS@USC-ISIF.ARPA Subject: Standardization proposal From: MATHIS@USC-ISIF.ARPA To: common-lisp@SU-AI.ARPA Cc: Mathis@USC-ISIF.ARPA Message-ID: <[USC-ISIF.ARPA]19-Feb-86 12:39:34.MATHIS> Today I sent a proposal to X3 for the establishment of a technical committee for the development of an American National Standard for Common Lisp. This committee will probably have the designation X3J13. Following their normal time-table, the committee will probably be approved in early summer and the first official meeting will be in Washington, DC in September 1986. Membership will be open according to X3 rules (basically attendance, participation, and payment of fees). The proposals are available as net mail, but I would rather only send them to interested people. If you are interested in seeing the proposals or participating on the X3J13 committee, please respond and give me your non-arpa-net addresses as well. Bob Mathis 9712 Ceralene Dr Fairfax, VA 22032-1704 (703)425-5923  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 15:47:58 EST Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 Feb 86 12:38:27 PST Received: from katherine by GODOT.THINK.COM via CHAOS; Wed, 19 Feb 86 15:38:49 est Date: Wed, 19 Feb 86 15:40 EST From: Guy Steele Subject: Function cells To: common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA Message-Id: <860219154017.1.GLS@KATHERINE.THINK.COM> My memory is that a question arose as to whether, given that function cells and value cells were to be distinct, they should have identical binding mechanisms or not. There was no compelling reason to allow special binding of function names, and the following argument was advanced against such special bindings: multiprocessing implementations of Lisp might well prefer to use deep special binding, and it was undesirable to have to deal with the deep binding mechanism for function lookups, given that most function-name references, unlike most variable-name references, occur free. I recall that this was the deciding argument that eliminated special binding of function names from Common Lisp, thereby making function names and variable names dissimilar in their semantics and further discouraging their merging. I can report that much of the time I am very happy to have the two names spaces be distinct. I get very unhappy whenever I find myself inventing functionals (functions that take other functions as arguments or return other functions as values) for various purposes. For example, I have found it semantically convenient to do so in Connection Machine Lisp. In these situations I find the need for interpolated occurrences of "funcall" and "#'" extremely annoying. --Guy  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 15:12:03 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 12:03:41 PST Received: from hplsny by hplabs.ARPA ; Wed, 19 Feb 86 12:03:24 pst Received: by hplsny ; Wed, 19 Feb 86 12:02:35 pst From: Alan Snyder Message-Id: <8602192002.AA07562@hplsny> Date: Wednesday, February 19, 1986 12:02:30 Subject: Re: Basic Design Questions: function cells To: MOON@SCRC-QUABBIN.ARPA Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 19-Feb-86 14:10:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. My impression was that having a separate function cell can be more efficient because it allows function invocation to be compiled into a direct jsr (or jump) through the function cell, with no explicit check that the function is defined (undefined functions are represented by a special undefined-function function). Using the same cell for functions and other variables would require checking that the cell contains a function before calling it (otherwise you might transfer control to a random location). -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 14:41:31 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 11:12:41 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 200616; Wed 19-Feb-86 14:10:24-EST Date: Wed, 19 Feb 86 14:10 EST From: Subject: Re: Basic Design Questions: function cells To: common-lisp@SU-AI.ARPA In-Reply-To: <860219162459.161471@CISL-SERVICE-MULTICS.ARPA> Message-ID: <"860219141034.3.MOON@QUABBIN"@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 19 Feb 86 11:24 EST From: "Eric J. Swenson" I too don't understand the arguments of the efficiency of the function cell concept, I believe these arguments were comparing storing function definitions in dedicated cells to storing them in property lists. As far as I know no one has argued that having functions and variables in separate name spaces leads to a more or less efficient implementation than having them in the same name space. I could be wrong; people will argue for almost anything. however, from the standpoint of looking at CL as a NEW language (as opposed to a pot-pouri of all the existing Lisp dialects) it certainly seems that CL is clutterred with pairs of functions/macros to deal with functional and non-functional objects and that elegance has been sacrificed in order to maintain compatibility with the various older Lisp dialects. I take it that the overriding factor in CL development has been compatilibity with the major Lisp dialects as opposed to designing a new language which was more internally consistent and conceptually elegant? That's certainly true. At the same time, it is a matter of opinion whether having all of the dozens of possible classes of named objects in the same space, or each in a separate space, is more elegant. The issue is not only variables and functions. Without going into extensions to Common Lisp, you can also think about package names, type names, and module names. There are powerful arguments on both sides of this issue. All a language designer can do is pick one philosophy and then be consistent about it.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 13:59:41 EST Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 19 Feb 86 10:48:10 PST Date: 0 0 00:00:00 EST From: "BIZET::NELSON" Subject: prompting To: "common-lisp" Reply-To: "BIZET::NELSON" Our users have requested a "read-with-prompt" function for IO streams. Beryl ------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 13:21:20 EST Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 10:11:17 PST Date: Wed 19 Feb 86 11:10:35-MST From: SANDRA Subject: buffered output and prompting To: common-lisp@SU-AI.ARPA Message-ID: <12184651656.29.LOOSEMORE@UTAH-20.ARPA> I'm having trouble coming up with a portable way for a CL application program to read with a prompt string. What I would like to do is something like, but more general than, the y-or-n-p and yes-or-no-p functions: specify a prompt string and then call read, read-line, or read-char. For a usual terminal-style interaction, I'd like to have the prompt message printed out without a newline so the cursor is left at the end of the same line, and then read. Aside from the fact that writing out the prompt string directly prevents you from using alternative interaction styles (like a pop-up dialog box or whatever), it's unclear that you could guarantee the same behavior, or even reasonable behavior, in all CL implementations. CLtL implies that buffered i/o is perfectly acceptable, so I assume one would have to do a (finish-output) after printing the prompt message to ensure that it really does get printed. However, emptying the internal buffer may mean that the prompt message shows up with a newline on the end, particularly if the output stream is organized into records with an implicit newline at the end of each record. (This is also acceptable, according to page 22.) Furthermore, the terminal driver provided by the operating system may include some fancy input editing capabilities that are confused by printing out random prompt strings; to get the prompt to interact properly with the editor, you have to pass it to the read function provided by the operating system. (In fact, all three of these conditions are true under VMS.) PSL has a variable that holds the current prompt string, and it's used whenever you read from the terminal. Different PSL implementations use whatever hooks the OS provides to get the right effect. I also seem to remember that the NMODE editor does special things with the prompt string that are more appropriate for its style of interaction. The point is, the same code will produce reasonable behavior in all situations. How can I get similar portability in CL code? Do we need to define additional functions (or additional arguments to existing functions) to support user interaction? -Sandra -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 11:52:51 EST Received: from CISL-SERVICE-MULTICS.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 08:44:54 PST Posted-Date: 19 Feb 86 11:45 EST Acknowledge-To: "Eric J. Swenson" Date: Wed, 19 Feb 86 11:24 EST From: "Eric J. Swenson" Subject: Re: Basic Design Questions: function cells To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 18 Feb 86 22:40 EST from "George J. Carrette" Message-ID: <860219162459.161471@CISL-SERVICE-MULTICS.ARPA> I too don't understand the arguments of the efficiency of the function cell concept, however, from the standpoint of looking at CL as a NEW language (as opposed to a pot-pouri of all the existing Lisp dialects) it certainly seems that CL is clutterred with pairs of functions/macros to deal with functional and non-functional objects and that elegance has been sacrificed in order to maintain compatibility with the various older Lisp dialects. I take it that the overriding factor in CL development has been compatilibity with the major Lisp dialects as opposed to designing a new language which was more internally consistent and conceptually elegant?  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 19 Feb 86 10:24:03 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 19 Feb 86 07:09:06 PST Date: 19 Feb 1986 10:05-EST Sender: NGALL@G.BBN.COM Subject: Re: intern From: NGALL@G.BBN.COM To: hpfclp!diamant@HPLABS.ARPA Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]19-Feb-86 10:05:02.NGALL> In-Reply-To: The message of Mon, 17 Feb 86 12:47:35 pst from hpfclp!diamant@hplabs.ARPA Date: Mon, 17 Feb 86 12:47:35 pst From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: intern .... Since UNINTERN is the only other function that is allowed to modify the package cell, perhaps CLtL should state either that: 1. It is an error to UNINTERN a symbol from its home package if it is present in some other package; or, 2. An error is signaled in case 1 [I prefer this case.] Saying (1) would at least warn people that "all bets are off" if they create an accessible but unowned symbol and would allow implementations that were concerned about it to signal an error. Requiring (2) would be a bit more overhead, but since UNINTERN is rarely used (right?), I think it would be acceptable. I'm not convinced that this is a good idea. What if I want to move symbols from one package to another, but I want all of the references from any other location to point to the new place. I just had to do something like this recently to handle a bootstrap. Because of the nature of packages and macros, I had a case where I had to compile a system in which code may reference either old or new locations during the compile. I performed this move by doing the following: (defun move-symbol (sym pkg) (let ((old-pkg (symbol-package sym))) (unintern sym old-pkg) ; make sym have no home (a bastard?) (import sym pkg) ; give sym a new home package (import sym old-pkg) (export sym pkg) ; assumes sym was originally exported from old-pkg (export sym old-pkg))) If you restrict UNINTERN to only work if the symbol has not been imported into any other package, then move-symbol would probably not work (it is likely that some of the symbols that were moving had been imported elsewhere). It seems to me that the operation I performed was perfectly valid (though not for the weak of heart), and your restriction would limit it. I think the My restrictiction would disallow your def. of MOVE-SYMBOL, but you could easily unintern the symbol from all the packages it is present in (except of course the old home package) (and of course keeping a list of those packages, and info. as to whether or not the symbol was external) BEFORE uninterning the symbol from its home package. THEN, you import it into it's new home package, and import/export it back into the other packages it was present in. [Note: Your def. of move symbol did not deal with the problem of using SHADOWING-IMPORT where necessary, so neither does my alternative.] Other than changing a symbol's home package, I doubt that my restriction would ever get in anyone's way. current approach of warning users that this situation may arise is better than restricting its use. I'd rather warn the user when it happens, since that's when they need the warning. :-) -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Feb 86 22:49:17 EST Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 18 Feb 86 19:40:05 PST Date: Tue, 18 Feb 86 22:40:41 EST From: "George J. Carrette" Subject: Basic Design Questions: function cells To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of Mon 17 Feb 1986 22:14 EST from Scott E. Fahlman Message-ID: <[MC.LCS.MIT.EDU].822188.860218.GJC> You forgot that people have made various efficiency-based arguments for function cells. These arguments may be found in the archives. (I cannot understand them so I wont try to explain it). Having a function cell also gives the language designer another way to add more inconsistency to the language, in the way of breaking down possible analogies, for example LET=>SETQ as FLET=>{nothing-in-CL}. Also, if in the form ( ) all of and were evaluated in the same namespace, and if you said "left-to-right" evaluation order is preserved then users would imply that to mean evaluate then then . However, if is evaluated differently then it might not bother anyone than in some CL implementations the order of evaluation is , and in some it is . -gjc {You have to know the rules before you can break them.}  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Feb 86 20:07:37 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Feb 86 16:56:33 PST Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 419926; Tue 18-Feb-86 19:54:51-EST Date: Tue, 18 Feb 86 19:54 EST From: Subject: value of * To: Richard Fateman cc: common-lisp@SU-AI.ARPA In-Reply-To: <8602181722.AA16600@dali.berkeley.edu> Message-ID: <"860218195413.2.MOON@QUABBIN"@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 18 Feb 86 09:22:59 PST From: fateman@dali.berkeley.edu (Richard Fateman) While I can understand the efficiency motivation for the spec on p 325, I would find it much handier to have "*" refer to multiple-values returns to the top level. That is, => (values 1 2) 1 ; 2 => (multiple-value-list *) (1 2) ;;; the behavior now is (1) . Read the rest of the page.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Feb 86 20:07:29 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Feb 86 16:57:51 PST Received: ID ; Tue 18 Feb 86 19:58:59-EST Date: Tue, 18 Feb 1986 19:58 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: fateman@dali.berkeley.edu (Richard Fateman) Cc: common-lisp@SU-AI.ARPA Subject: value of * In-reply-to: Msg of 18 Feb 1986 12:22-EST from fateman at dali.berkeley.edu (Richard Fateman) The variable "/" already has a list of the multiple values, if that's what you want. Is there some need that this doesn't satisfy? -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 18 Feb 86 18:50:29 EST Received: from UCBVAX.BERKELEY.EDU by SU-AI.ARPA with TCP; 18 Feb 86 15:39:43 PST Received: by ucbvax.berkeley.edu (5.45/1.9) id AA06539; Tue, 18 Feb 86 15:38:29 PST Received: by dali.berkeley.edu (5.44/5.16) id AA16600; Tue, 18 Feb 86 09:22:59 PST Date: Tue, 18 Feb 86 09:22:59 PST From: fateman@dali.berkeley.edu (Richard Fateman) Message-Id: <8602181722.AA16600@dali.berkeley.edu> To: common-lisp@su-ai.arpa Subject: value of * While I can understand the efficiency motivation for the spec on p 325, I would find it much handier to have "*" refer to multiple-values returns to the top level. That is, => (values 1 2) 1 ; 2 => (multiple-value-list *) (1 2) ;;; the behavior now is (1) .  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 22:24:27 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Feb 86 19:12:40 PST Received: ID ; Mon 17 Feb 86 22:14:21-EST Date: Mon, 17 Feb 1986 22:14 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Cc: common-lisp@SU-AI.ARPA Subject: Basic Design Questions In-reply-to: Msg of 17 Feb 1986 11:13-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs) The existence of distinct function and value cells in Common Lisp is in part because a lot of existing code expects these cells to be distinct, and that is the sort of expectation that is very hard to undo. In addition to the question of historical compatibility, many people felt that using a single name space leads to a lot of extra bugs when some program rebinds a variable that happens to hold a function that is called within the scope of the new binding. This bug is much less likely in a lexically bound lisp than in a dynamic one, but it still is a danger. Reasonable people can disagree about whether the elegance of a single namespace is worth the danger of accidentally clobbering function definitions, but that's what the reasoning was. -- Scott  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 15:58:39 EST Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 12:47:49 PST Received: by hplabs.ARPA ; Mon, 17 Feb 86 12:47:35 pst Date: Mon, 17 Feb 86 12:47:35 pst From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: intern From: Rob MacLachlan ... First of all, I'm satisfied with what was apparently concluded several months ago. Unfortunately, I wasn't aware of the original discussion until I was already deeply involved in the current one. As long as the definition of the verb "intern" is either cleaned up or separated from the function INTERN, I would be satisfied, especially now that IMPORT has been defined to set the package cell if necessary. There is a point against INTERN setting the home package which I believe was not discussed. It is not obvious what package INTERN should choose at the home. It is a bad idea to set the package to the one being interned in, since the symbol may not be present in that package; it may be inherited. If the symbol was subsequently unexported, it would have a home package yet not be available in that package. This could be fixed up by choosing some package which the symbol is present in, but the choice would have to be fairly arbitrary, since the symbol might be inherited from more than one package. Rob That is exactly the point I made in my last message. The reason I created a print-read inconsitency is that I assumed INTERN would set the package cell to the package in which the symbol was being interned. We agree that this is a good reason to prevent INTERN from setting the package cell. From: hplabs!NGALL@G.BBN.COM Since UNINTERN is the only other function that is allowed to modify the package cell, perhaps CLtL should state either that: 1. It is an error to UNINTERN a symbol from its home package if it is present in some other package; or, 2. An error is signaled in case 1 [I prefer this case.] Saying (1) would at least warn people that "all bets are off" if they create an accessible but unowned symbol and would allow implementations that were concerned about it to signal an error. Requiring (2) would be a bit more overhead, but since UNINTERN is rarely used (right?), I think it would be acceptable. I'm not convinced that this is a good idea. What if I want to move symbols from one package to another, but I want all of the references from any other location to point to the new place. I just had to do something like this recently to handle a bootstrap. Because of the nature of packages and macros, I had a case where I had to compile a system in which code may reference either old or new locations during the compile. I performed this move by doing the following: (defun move-symbol (sym pkg) (let ((old-pkg (symbol-package sym))) (unintern sym old-pkg) ; make sym have no home (a bastard?) (import sym pkg) ; give sym a new home package (import sym old-pkg) (export sym pkg) ; assumes sym was originally exported from old-pkg (export sym old-pkg))) If you restrict UNINTERN to only work if the symbol has not been imported into any other package, then move-symbol would probably not work (it is likely that some of the symbols that were moving had been imported elsewhere). It seems to me that the operation I performed was perfectly valid (though not for the weak of heart), and your restriction would limit it. I think the current approach of warning users that this situation may arise is better than restricting its use. John  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 15:13:55 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 10:45:15 PST Date: 17 Feb 1986 13:42-EST Sender: NGALL@G.BBN.COM Subject: Re: intern From: NGALL@G.BBN.COM To: RAM@C.CS.CMU.EDU Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Cc: hpfclp!diamant@HPLABS.ARPA Message-ID: <[G.BBN.COM]17-Feb-86 13:42:30.NGALL> In-Reply-To: Date: Sun, 16 Feb 1986 20:54 EST From: Rob MacLachlan To: "Scott E. Fahlman" Subject: intern In-Reply-To: Msg of 16 Feb 1986 20:12-EST from Scott E. Fahlman Message-ID: I believe that it was decided that the correct interpretation of the manual did not support INTERN setting the package cell. Contradictory passages were considered to be dated, and inconsistent with the current notion of package semantics. It was thought that having INTERN do anything to package cells was a rather random side-effect, and was better left out since no very convincing arguments were presented in its favor. It was pointed out that IMPORT is a function which causes a symbol to be present in a package. This seems to correspond fairly well to the notion of intering a symbol. It was decided that having IMPORT home the symbol made some sense, so the change to IMPORT was put in. There is a point against INTERN setting the home package which I believe was not discussed. It is not obvious what package INTERN should choose at the home. It is a bad idea to set the package to the one being interned in, since the symbol may not be present in that package; it may be inherited. If the symbol was subsequently unexported, it would have a home package yet not be available in that package. This could be fixed up by choosing some package which the symbol is present in, but the choice would have to be fairly arbitrary, since the symbol might be inherited from more than one package. Rob -------------------- This is pretty much how I remember the discussion. -- Nick  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 13:54:07 EST Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 10:35:32 PST Date: 17 Feb 1986 13:33-EST Sender: NGALL@G.BBN.COM Subject: Re: intern From: NGALL@G.BBN.COM To: hpfclp!diamant@HPLABS.ARPA Cc: common-lisp@SU-AI.ARPA, diamant@HPLABS.ARPA Message-ID: <[G.BBN.COM]17-Feb-86 13:33:11.NGALL> In-Reply-To: The message of Fri, 14 Feb 86 16:07:53 pst from hpfclp!diamant@hplabs.ARPA From: hpfclp!diamant@hplabs.ARPA Subject: Re: intern From: hplabs!NGALL@G.BBN.COM Subject: Re: intern What I would like to see is the following: 1. Leave the stipulation on page 172 that INTERN fix-up the package slot of an interned symbol. It may be better to remove the definition of the verb "intern" on pg. 172 since the verb is not used elsewhere in the chapter. See my comments below. But the verb is used by Common Lispers, and many times incorrectly (e.g., the current definition of the verb is incorrectly applied to symbols instead of names). So I would like to see the use of INTERN as a verb and adjective defined about where it is now. 2. Refer to pg. 172 in the def. of INTERN. I think it would be a better idea to completely define the functionality of INTERN in one place (preferably on page 184). Agreed. 3. Make IMPORT also fix up the package slot. I agree. 4. In UNITERN, after warning about homeless interned symbols, cf. IMPORT for fixing things up. 5. Make clear that FIND-SYMBOL has NO SIDE EFFECTS. And point out that it is the only way of mapping a name to a homeless interned symbol. For the reasons described below, I would suggest stating that INTERN also does not modify already-existing symbols. Agreed. This appears O.K. at first, but consider the following example: (in-package "FOO") (intern "X") (export 'x) (in-package "BAR" :use '("FOO")) (export 'foo:x) (unintern 'foo:x (find-package "FOO")) (in-package "BAZ" :use '("BAR")) (intern "X") If we follow the proposed definition of intern, x is now internally available in BAR, available by inheritance in BAZ, but its package cell is BAZ. Now, if we (unintern 'bar:x (find-package "BAR")), then the symbol will disappear even though its home package was not BAR. Alternately, if we (unuse-package "BAR" (find-package "BAZ")), then bar:x has a home package of BAZ, but is not available in BAZ. This seems to violate print-read consinstency. (in-package "FOOBAR") (eq (read-from-string (with-output-to-string (*standard-output*) (print 'bar:x))) 'bar:x)) This will return nil, instead of t. An alternative is to have intern not set the home package, but be functionally equivalent to: (defun intern (name &optional (package *package*)) (or (find-symbol name package) (import (make-symbol name) package)))) This has the unfortunate property of having intern return uninterned symbols in some cases. See the above example. And of always importing NIL :-). It seems that we are back to the original statement you made that IMPORT is the only function permitted to change the package cell (however, the reasons are more complicated than first suspected). Would anyone care to comment on this? Since UNINTERN is the only other function that is allowed to modify the package cell, perhaps CLtL should state either that: 1. It is an error to UNINTERN a symbol from its home package if it is present in some other package; or, 2. An error is signaled in case 1 [I prefer this case.] Saying (1) would at least warn people that "all bets are off" if they create an accessible but unowned symbol and would allow implementations that were concerned about it to signal an error. Requiring (2) would be a bit more overhead, but since UNINTERN is rarely used (right?), I think it would be acceptable. By the way, it may be a good idea to make the shadowing-import explicitly state the same clarification. Agreed.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 13:52:43 EST Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 Feb 86 10:35:37 PST Received: ID ; Mon 17 Feb 86 13:10:12-EST Date: Mon, 17 Feb 1986 13:09 EST Message-ID: From: Rob MacLachlan To: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Cc: common-lisp@SU-AI.ARPA Subject: Basic Design Questions In-reply-to: Msg of 17 Feb 1986 11:13-EST from shebs%utah-orion at utah-cs.arpa (Stanley Shebs) If you have a lexical Lisp without closures, how do you deal with upward funargs? Dump core? Pascal gets away without closures by not having first-class functional values; this doesn't seem to work very well in Lisp. Alternatively, the compiler could signal an error whenever it couldn't prove you weren't creating a closure. That would be even sillier, since the compiler would be doing all the work of implementing closures without getting any of the benefit. You certainly wouldn't want warts like these in an "educational subset." An interesting point in favor of the function/variable split is that it makes macros work better. Most bindings in programs are variable bindings, while most global references are function references. If the program binds something that the macroexpansion references then the macro won't work. This is because macros aren't referentially transparent. If the bindings that a program makes don't intersect with the functions that the macroexpansion is trying to reference, then the macro works. If the set of global references is mostly disjoint from the set of local bindings, then more macros will work the first time. Separating the functional and normal values tends to have this effect. Yes this is an ad-hoc kludge, but that's what Lisp is all about. Lisp is getting things done that we don't yet know how to do right. Rob  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 13:50:37 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 10:33:28 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA18832; Mon, 17 Feb 86 11:35:17 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA18028; Mon, 17 Feb 86 11:35:14 MST Date: Mon, 17 Feb 86 11:35:14 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8602171835.AA18028@utah-orion.ARPA> To: RAM@c.cs.cmu.edu Subject: Re: Basic Design Questions Cc: common-lisp@su-ai.arpa The problem of upward funargs is neatly solved by excluding functional objects from the language. It may be that this is too drastic for the EuLispers; it was just a suggestion! Making Common Lisp subsets is like trimming the federal budget; almost everybody favors it, but when anyone makes specific suggestions, the howls of outrage can be heard all the way to the moon... Your comment about macros reminds me of the little hole that a great many macro setups have: it's called **macroarg** in Spice, and woe to they who refer to it indiscriminately in user code! Actually, I can't get upset about anything that discourages macro writing - I've seen whole systems whose validity hung on the convolutions of a single ill-advised macro... stan  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 17 Feb 86 11:24:48 EST Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 17 Feb 86 08:11:24 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA16387; Mon, 17 Feb 86 09:13:17 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA17264; Mon, 17 Feb 86 09:13:14 MST Date: Mon, 17 Feb 86 09:13:14 MST From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8602171613.AA17264@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Basic Design Questions About a month ago, I had some discussions with Julian Padget concerning EuLisp vs Common Lisp. One suggestion I found interesting was that the very lowest level of Eulisp, while lexically scoped, would not necessarily have lexical closures. In fact, it might be the moral equivalent of Pascal (yech), in terms of functionality, and in terms of how much reinvention of the wheel would be necessary to use the subset for real programs. This doesn't bother me a lot, since people wouldn't use this subset except for very special purposes (education, and maybe as machine-independent object code). The real reason for this posting has to do with the issue of single value cell vs value cell/function cell. Now I don't want to start a session with flamethrowers - here are some specific questions: 1. I've always assumed that the double cell arrangement in Common Lisp was for backwards compatibility. Is this true? Are there any other strong reasons for retaining the duality? Does anyone believe that efficiency is an issue? 2. (for diehard Schemers only) The strongest reason I've heard for the single cell arrangement is simplicity. Semantic "purity" or "rationality" is frequently claimed, but that's incredibly subjective, so it seems less strong to me. Are there any other reasons? 3. How hard is it really to embed a double cell Lisp in a single cell one, taking into account compiler effects, changes to existing user programs, and so forth? Can it be done without destroying performance? 4. How hard is it to embed a single cell Lisp in a double cell one? One of the problems with doing this is handling user programs that try to do things like mentioning "#'" and using a variable called "function" in the same lexical scope. Are there good ways of handling this without transforming the program? How about efficiency? My superficial analysis is that implementing double cell Lisp in single cell Lisp is easier than the reverse, since one can use the ancient expedient of the property list, and do tricky things in the compiler. Implementing single cell behavior in a double cell Lisp seems harder, without completely replacing the interpreter. I have no idea about relative efficiencies of these schemes (no pun intended!). stan