Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Mar 88 02:13:19 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 88 22:53:25 PST Received: from relay2.cs.net by RELAY.CS.NET id aa06767; 15 Mar 88 1:37 EST Received: from cs.umass.edu by RELAY.CS.NET id cb01442; 15 Mar 88 1:26 EST Date: Mon, 14 Mar 88 14:38 EDT From: ELIOT@cs.umass.edu Subject: &Rest Lists To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"common-lisp@sail.stanford.EDU" Ideally &Rest arguments should be the exclusive property of the function which defines them. Two funny restrictions have sometimes been imposed on &Rest lists to enable certain optimizations. The question is whether the value of the optimization exceeds the cost of documenting and not violating the restrictions. The first optimization/restriction primarilly allows stack-consing at the expense of making &Rest lists become undefined when the function returns. This is a fairly large optimization but it has already been prohibited (in the general case) by CLtL. The second optimization/restriction primarilly allows constant lists to be used as &Rest lists at the expense of prohibiting functions from modifying their &rest lists. However, since CLtL already requires &Rest lists to exist after the function returns they will almost always have to be CONSed as the function is called, unless fancy optimizations have occured. The primary case where this optimization still could matter is when Apply is used with a constant list to call a function with an &Rest list that does not have to be modified. I think that this optimization is rather minor, except in situations where a programmer has intentionally set up the code to take advantag of this. However, it is a simple matter to rework this kind of function call to get the optimized behavior in a fully portable way. Instead of: (defun bar (x) (apply #'foo x)) (defun foo (&rest theList) ...) Use: (defun bar (x) (foo x)) (defun foo (theList) ...) This new code is guaranteed to be portable and efficient, and it is also easier to read. Admittedly this rewrite isn't good for 100% of the cases, but it does make the optimized behavior of &Rest lists less important. Sufficiently so that I think &Rest lists should be implemented so that they behave as if: (defun foo (&rest x) ...) Should behave as if it were defined: (defun foo (&rest G0047) ;Gensym really (let ((x (copy-list G0047))) ...)) I think this fully and precisely specifies the semantics of &Rest. Chris Eliot  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Mar 88 12:00:12 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 88 08:46:59 PST Received: from en-c06.prime.com by RELAY.CS.NET id aa25561; 14 Mar 88 10:39 EST Received: from S51.Prime.COM by EN-C06.Prime.COM; 14 Mar 88 10:23:20 EST Received: from ENX.Prime.COM by S51.Prime.COM; 14 Mar 88 10:23:42 EST Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail) id AA28064; Mon, 14 Mar 88 10:12:26 EST Received: by zaphod.prime.com (3.2/SMI-3.2) id AA03232; Mon, 14 Mar 88 10:17:38 EST Date: Mon, 14 Mar 88 10:17:38 EST From: Douglas Rand Message-Id: <8803141517.AA03232@zaphod.prime.com> To: common-lisp@SAIL.STANFORD.EDU Subject: New defsys available for public anonymous ftp Jim Larus has been kind enough to provide a new home for defsys on ucbarpa. Use anonymous login to retrieve defsys.doc and defsys.lisp from pub/ on ucbarpa. Cheers, Doug  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Mar 88 08:00:41 EST Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 13 Mar 88 04:49:01 PST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA27626; Sun, 13 Mar 88 07:49:36 EST From: mcvax!pilatus!ceb@uunet.UU.NET Received: by mcvax.cwi.nl; Sun, 13 Mar 88 13:47:31 +0100 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA20860; Sun, 13 Mar 88 13:22:44 +0100 Date: Sun, 13 Mar 88 13:22:44 +0100 Message-Id: <8803131222.AA20860@cernvax.uucp> To: common-lisp@sail.stanford.edu Subject: &rest lists and other things ground through function application With regards the current (or, by the time this message makes it back, probably two week old) debate on this topic, I have yet to see the following point mentioned: If you want to be able to freely modify the structures which are used to implement these features, something imbedded in the kernel of the language is going to have to *copy* them. You could do a top-level copy, but then you are still not protected if someone does a (setf (cadr passed-argument-structure 'truc). In order to beat this, you have to do an arbitrary depth copy, and then, when you pass tangled, circular, non-ending horrible things which make print go bananas (I do this often), you have to do circular list detection, etc. . . . and you very quickly get into a game which can't be won. This is a problem which defies mechanical solution, and should be kept out of the language definition, except, as someone has already pointed out, for a clear staking of position in the standard. ceb  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Mar 88 08:00:22 EST Received: from uunet.UU.NET by SAIL.Stanford.EDU with TCP; 13 Mar 88 04:48:57 PST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA27623; Sun, 13 Mar 88 07:49:30 EST From: mcvax!pilatus!ceb@uunet.UU.NET Received: by mcvax.cwi.nl; Sun, 13 Mar 88 13:47:10 +0100 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA20851; Sun, 13 Mar 88 13:22:41 +0100 Date: Sun, 13 Mar 88 13:22:41 +0100 Message-Id: <8803131222.AA20851@cernvax.uucp> To: common-lisp@sail.stanford.edu Subject: &rest lists - correction In my previous posting, the counter example should have read (setf (cdar ..) .), since (setf (cadr ..) .) *would* be covered by backbone copying. Hope this didn't cloud things. I grow rusty on "under-the-hood tinkering", since I now use mainly semantically cleaner defstructs.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 23:38:16 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 20:22:24 PST Received: by labrea.Stanford.EDU; Fri, 11 Mar 88 20:23:06 PST Received: from bhopal.lucid.com by edsel id AA02102g; Fri, 11 Mar 88 20:03:14 PST Received: by bhopal id AA13617g; Fri, 11 Mar 88 20:10:04 PST Date: Fri, 11 Mar 88 20:10:04 PST From: Jon L White Message-Id: <8803120410.AA13617@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: Ram@c.cs.cmu.edu, common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu In-Reply-To: David A. Moon's message of Fri, 11 Mar 88 16:02 EST <19880311210247.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: the array type mess.... re: To say the same thing in Lisp: . . . (DEFUN IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE (TYPE) (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)) . . . Should the IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE function I have postulated as hidden inside TYPEP be made available as a standard function? Your summary here is essentially the same as the proposal I sent to CL-CLEANUP on March 1, except I named it UPGRADE-ARRAY-ELEMENT-TYPE to suggest that a possibly-non-trival super-type would be returned. Also, I think the functionality underlying UPGRADE-ARRAY-ELEMENT-TYPE is already in everyone's arrays implementation, regardless of how they handle the TYPEP mess. For those not on the cl-cleanup list, I've excerpted the relevant message below. Date: Tue, 1 Mar 88 13:09:10 PST From: Jon L White To: Moon@stony-brook.scrc.symbolics.com Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu Subject: UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem . . . a function (which would be "implementation revealing") named UPGRADE-ARRAY-ELEMENT-TYPE whose purpose would be to tell you what the canonical representation for a type name is (when used as an :element-type specifier). . . . [why not toss out "upgrading" altogether? because ...] to make types absolutely portable this way is a very pyrrhic success. Sure, your program will port to the Y machine -- it will just run two orders of magnitude slower [because you started out on, say, a Multics machine with (MOD 512) arrays optimized, and ported to an implementation for an engineering workstation that prefers (UNSIGNED-BYTE 8) arrays ...]. Finally, as I've said before, I don't think it's an acceptable solution for Lisp to take the same route as C (and others) to achieve portability. The kinds of array types in such languages are limited to a small (albeit very useful) set that seems inspired by one particular hardware architecture. -- JonL -- P.S. Of course UPGRADE-ARRAY-ELEMENT-TYPE can currently be implemented in a "consy" way doing something like: (array-element-type (make-array 0 :element-type 'foo)) But the presence of a "first class" function UPGRADE-ARRAY-ELEMENT-TYPE would be more for the purpose of encouraging cognizance of these problems than for avoiding the consing. Implicitly, such a function lies underneath any implementation of MAKE-ARRAY already. Date: Tue, 1 Mar 88 14:05:25 PST From: Jon L White To: Ram@c.cs.cmu.edu Cc: cl-cleanup@sail.stanford.edu, Moon@scrc-stony-brook.arpa, vanroggen%aitg.decnet@hudson.dec.com Subject: function-type-rest-list-element (really array types) ... This may be another way of trying to say that `(ARRAY FOO) is type equivalent to `(ARRAY ,(upgrade array-element-type 'foo)) -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 19:52:08 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Mar 88 16:38:28 PST Return-Path: Received: from sauron.think.com by Think.COM; Fri, 11 Mar 88 17:39:02 EST Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 11 Mar 88 17:38:58 EST Date: Fri, 11 Mar 88 17:40 EST From: Barry Margolin Subject: Re: &REST lists To: NGALL@g.bbn.com Cc: Moon@stony-brook.scrc.symbolics.com, Fahlman@c.cs.cmu.edu, common-lisp@sail.stanford.edu In-Reply-To: <[G.BBN.COM]11-Mar-88 16:42:56.NGALL> Message-Id: <19880311224022.7.BARMAR@OCCAM.THINK.COM> Date: 11 Mar 1988 16:42-EST From: NGALL@g.bbn.com 2) (This is the one that bothers me.) Some other part of the system may modifiy a shared CONS at any time. This means that although the list (chain of CONSes) that is the value of the &REST parameter has indefinite extent, some part of the system (e.g., some internal part of the function calling mechanism) could modify the CAR or CDR cell of any of the CONSes. For example, I could assign the value of the &REST parameter (e.g., the list (1 2 3)) to the special variable *FOO*, return from the function, and discover that the value of *FOO* is now (1 . !!!END!!!). The CONS is still there, but someone else (e.g., the function-return mechanism) modified its CDR cell. I don't think that he was suggesting that the conses could be smashed behind your back by some automatic mechanism like returning from a function call. I think the following is an example of the sharing of &REST lists that may be possible. (defparameter *shared-list* '(1 2 3)) (defun function-1 (&rest args) (function-2) (print args)) (defun function-2 () (setf (car *shared-list*) 6)) (defun caller () (apply #'function-1 *shared-list*)) OK, what does (caller) print, (1 2 3) or (6 2 3)? In Genera it prints the latter. Thus, one must be careful when passing argument lists that can be accessed by other functions. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 19:22:08 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Mar 88 16:00:07 PST Return-Path: Received: from sauron.think.com by Think.COM; Fri, 11 Mar 88 17:39:02 EST Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 11 Mar 88 17:38:58 EST Date: Fri, 11 Mar 88 17:40 EST From: Barry Margolin Subject: Re: &REST lists To: NGALL@g.bbn.com Cc: Moon@stony-brook.scrc.symbolics.com, Fahlman@c.cs.cmu.edu, common-lisp@sail.stanford.edu In-Reply-To: <[G.BBN.COM]11-Mar-88 16:42:56.NGALL> Message-Id: <19880311224022.7.BARMAR@OCCAM.THINK.COM> Date: 11 Mar 1988 16:42-EST From: NGALL@g.bbn.com 2) (This is the one that bothers me.) Some other part of the system may modifiy a shared CONS at any time. This means that although the list (chain of CONSes) that is the value of the &REST parameter has indefinite extent, some part of the system (e.g., some internal part of the function calling mechanism) could modify the CAR or CDR cell of any of the CONSes. For example, I could assign the value of the &REST parameter (e.g., the list (1 2 3)) to the special variable *FOO*, return from the function, and discover that the value of *FOO* is now (1 . !!!END!!!). The CONS is still there, but someone else (e.g., the function-return mechanism) modified its CDR cell. I don't think that he was suggesting that the conses could be smashed behind your back by some automatic mechanism like returning from a function call. I think the following is an example of the sharing of &REST lists that may be possible. (defparameter *shared-list* '(1 2 3)) (defun function-1 (&rest args) (function-2) (print args)) (defun function-2 () (setf (car *shared-list*) 6)) (defun caller () (apply #'function-1 *shared-list*)) OK, what does (caller) print, (1 2 3) or (6 2 3)? In Genera it prints the latter. Thus, one must be careful when passing argument lists that can be accessed by other functions. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 18:14:39 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:56:58 PST Received: by labrea.Stanford.EDU; Fri, 11 Mar 88 14:57:41 PST Received: from kent-state.lucid.com by edsel id AA21370g; Fri, 11 Mar 88 14:37:24 PST Received: by kent-state id AA04701g; Fri, 11 Mar 88 14:45:59 PST Date: Fri, 11 Mar 88 14:45:59 PST From: Eric Benson Message-Id: <8803112245.AA04701@kent-state.lucid.com> To: Fahlman@c.cs.cmu.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: "Scott E. Fahlman"'s message of Fri, 11 Mar 1988 17:03 EST Subject: &REST lists It's not only smashing a &rest argument that's a problem, it's smashing any list that has been given as the last argument to APPLY as well. Consider the following in an implementation that doesn't copy the last argument to APPLY when it is passed as a &rest argument: > (defvar *message*) *MESSAGE* > (defun set-message (&rest mess) (setq *message* mess)) SET-MESSAGE > (let ((winner (list 'a 'winner))) (apply #'set-message winner) (setf (cdr winner) (list 'loser)) winner) (A LOSER) Is *message* (A WINNER) or (A LOSER)? (It might be (# # ...) but that's a different problem.) This suggests that once a list has been given as the last argument to APPLY it is no longer OK to modify it.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 17:48:18 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:34:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361398; Fri 11-Mar-88 17:33:32 EST Date: Fri, 11 Mar 88 17:33 EST From: David A. Moon Subject: Re: &REST lists To: NGALL@G.BBN.COM cc: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <[G.BBN.COM]11-Mar-88 16:42:56.NGALL> Message-ID: <19880311223331.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 11 Mar 1988 16:42-EST From: NGALL@G.BBN.COM Hmm... I'm getting a little confused by the issue of structure-sharing the CONS object (and the CONSes linked to it) that is the value of an &REST parameter. In general, there are two consequences of structure sharing: 1) (The one alluded to in your message.) If one modifies the CAR or CDR cell of a shared CONS, other parts of the system may be affected (e.g., a calling function call form could be modified). 2) (This is the one that bothers me.) Some other part of the system may modifiy a shared CONS at any time. It's not considered kosher to modify shared data structure without documenting that you do so. This means that although the list (chain of CONSes) that is the value of the &REST parameter has indefinite extent, some part of the system (e.g., some internal part of the function calling mechanism) could modify the CAR or CDR cell of any of the CONSes. I don't see anything in CLtL that says the function calling mechanism is allowed to modify things. For example, I could assign the value of the &REST parameter (e.g., the list (1 2 3)) to the special variable *FOO*, return from the function, and discover that the value of *FOO* is now (1 . !!!END!!!). The CONS is still there, but someone else (e.g., the function-return mechanism) modified its CDR cell. If you are suggesting that (2) would be possible under the clarification of &REST, then saving the value of the &REST parameter is fairly useless. One would have to COPY it to prevent it from being smashed. I'm not suggesting this. If on the other hand, you are promising that a CL implementation will never (internally) modify any CONS comprising the list that is the value of an &REST parameter, then this should be stated explicitly in the clarification to &REST. You're right. It would be good to state explicitly that the function call mechanism will not bash lists received as values of &REST parameters, that users should not bash lists received as values of &REST parameters, and that users should not bash lists passed to APPLY as its last argument. Of course the same thing could be said about every other place in the language where potentially shareable structure exists.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 17:44:15 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:30:44 PST Received: ID ; Fri 11 Mar 88 17:30:50-EST Date: Fri, 11 Mar 1988 17:30 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: &REST lists In-reply-to: Msg of 11 Mar 1988 16:42-EST from NGALL at G.BBN.COM To further clarify, I don't think that anyone is proposing that &rest lists should be mysteriously modified by the system itself in a Common Lisp that adheres to the standard. -- Scott  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 17:25:23 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 14:10:36 PST Received: ID ; Fri 11 Mar 88 17:03:43-EST Date: Fri, 11 Mar 1988 17:03 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: &REST lists In-reply-to: Msg of 11 Mar 1988 16:42-EST from NGALL at G.BBN.COM In reply to NGALL at G.BBN.COM ... I believe that there is only one way in which the backbone of an &rest list might end up being shared, and that is if the list was passed in as the last arg to APPLY. In all other cases, the &rest list is built up from distinct arguments, and couldn't possibly be anything that the user has his hands on. We had a lengthy debate at one time about the APPLY case: should we guarantee the user that the &rest list is a fresh copy, guarantee that the APPLY list is incorporated into the &rest list, or not guarantee anything. I believe that we never reached a firm decision on this, which means that the "not guarantee anything" case wins by default. So smashing a &rest arg list is not a good idea unless you know where it came from and who else might have hold of it. As Steele pointed out, smashing anything is not a good idea unless you know its pedigree. If you want to be safe, copy it before smashing. -- Scott  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 17:02:00 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 11 Mar 88 13:44:09 PST Date: 11 Mar 1988 16:42-EST Sender: NGALL@G.BBN.COM Subject: Re: &REST lists From: NGALL@G.BBN.COM To: Moon@SCRC-STONY-BROOK.ARPA Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]11-Mar-88 16:42:56.NGALL> In-Reply-To: <19880311190404.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Hmm... I'm getting a little confused by the issue of structure-sharing the CONS object (and the CONSes linked to it) that is the value of an &REST parameter. In general, there are two consequences of structure sharing: 1) (The one alluded to in your message.) If one modifies the CAR or CDR cell of a shared CONS, other parts of the system may be affected (e.g., a calling function call form could be modified). 2) (This is the one that bothers me.) Some other part of the system may modifiy a shared CONS at any time. This means that although the list (chain of CONSes) that is the value of the &REST parameter has indefinite extent, some part of the system (e.g., some internal part of the function calling mechanism) could modify the CAR or CDR cell of any of the CONSes. For example, I could assign the value of the &REST parameter (e.g., the list (1 2 3)) to the special variable *FOO*, return from the function, and discover that the value of *FOO* is now (1 . !!!END!!!). The CONS is still there, but someone else (e.g., the function-return mechanism) modified its CDR cell. If you are suggesting that (2) would be possible under the clarification of &REST, then saving the value of the &REST parameter is fairly useless. One would have to COPY it to prevent it from being smashed. If on the other hand, you are promising that a CL implementation will never (internally) modify any CONS comprising the list that is the value of an &REST parameter, then this should be stated explicitly in the clarification to &REST. In summary, stating that "the CONSes of the &REST list have indefinite extent, but may be shared by other parts of the system", implicitly allows the behavior mentioned in (2), and this makes saving the CONSes relatively useless. -- Nick ... Date: Fri, 11 Mar 88 14:04 EST From: David A. Moon ... The premise that values of &rest parameters have indefinite extent does not imply the conclusion that each value of an &rest parameter is an independent object that does not share structure with any other object. There is general agreement on the premise, but certainly not on the conclusion. Please don't confuse the issue of extent, on which Symbolics still deliberately violates the standard (this is a well-known, documented violation, which will go away when we get the resources to make it go away) with the issue of structure sharing.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 16:27:55 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 13:04:43 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361275; Fri 11-Mar-88 16:02:53 EST Date: Fri, 11 Mar 88 16:02 EST From: David A. Moon Subject: the array type mess.... To: Ram@C.CS.CMU.EDU cc: Jon L White , common-lisp@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU In-Reply-To: Message-ID: <19880311210247.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I agree with your points about definitional versus implementation types. Is it a correct summary of your comments that you want the distinction (CLtL p.45) between declaration and discrimination to be eliminated, with TYPEP being changed to treat array type specifiers in precisely the way that CLtL calls "for declaration"? To say the same thing in Lisp: (TYPEP array '(ARRAY type *)) is currently defined to be equivalent to: (AND (TYPEP array '(ARRAY * *)) (SUBTYPEP (ARRAY-ELEMENT-TYPE array) 'type) (SUBTYPEP 'type (ARRAY-ELEMENT-TYPE array))) I don't think you're proposing to make it equivalent to: (AND (TYPEP array '(ARRAY * *)) (SUBTYPEP 'type (ARRAY-ELEMENT-TYPE array))) but rather to make it equivalent to: (LET ((TYPE1 (IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE 'type))) (AND (TYPEP array '(ARRAY * *)) (SUBTYPEP (ARRAY-ELEMENT-TYPE array) TYPE1) (SUBTYPEP TYPE1 (ARRAY-ELEMENT-TYPE array)))) where an inefficient but portable definition is: (DEFUN IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE (TYPE) (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)) Is this accurate? Let's look at the various things (TYPEP array '(ARRAY TYPE *)) => T might mean, and what they mean with that proposal: (TYPEP x TYPE) means x can safely be stored into the array: yes (TYPEP x TYPE) is true for all current elements of the array: no (TYPEP x TYPE) is true for all future elements of the array: no (NOT (TYPEP x TYPE)) means x cannot be safely stored into the array: no with CLtL's current definition of TYPEP: (TYPEP x TYPE) means x can safely be stored into the array: yes (TYPEP x TYPE) is true for all current elements of the array: yes (TYPEP x TYPE) is true for all future elements of the array: yes (NOT (TYPEP x TYPE)) means x cannot be safely stored into the array: yes So what we're saying is that for the latter two tests you must use ARRAY-ELEMENT-TYPE, and for the second test you must look at the actual contents of the array. That's probably okay, especially when one considers that in CLtL (TYPEP array '(ARRAY TYPE *)) very rarely returns T, and for most values of TYPE it is implementation dependent. (ARRAY T) remains a proper subset of (ARRAY *), and (STRING size) remains an abbreviation for (ARRAY STRING-CHAR (size)), for the simple reason that CLtL requires (IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE 'STRING-CHAR) => STRING-CHAR (or a type specifier equivalent to STRING-CHAR). Should the IMPLEMENTATION-DEPENDENT-ARRAY-ELEMENT-TYPE function I have postulated as hidden inside TYPEP be made available as a standard function? An interesting comment on all this is that we are implicitly assuming that an implementation's spectrum of specialized array types is independent of the size, number of dimensions, indirectness, or adjustability of the array. This seems unlikely to be true of all implementations. I don't know how to fix this deficiency. Someone should write this up in Cleanup form and thus give us all a chance to think about it more deeply.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 15:52:48 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 88 11:47:31 PST Received: ID ; Fri 11 Mar 88 14:47:20-EST Date: Fri, 11 Mar 1988 14:47 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: &REST lists In-reply-to: Msg of 11 Mar 1988 14:04-EST from David A. Moon In response to David A. Moon ... Yes, I misunderstood the question about RPLACA and &rest args. Since whoever asked the question did not mention the case of APPLY, I didn't realize that shared lists were the issue. I thought it was a question about whether the &rest list could be treated as a real list. -- Scott  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Mar 88 14:25:13 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 11:05:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361155; Fri 11-Mar-88 14:04:03 EST Date: Fri, 11 Mar 88 14:04 EST From: David A. Moon Subject: &REST lists To: Scott E. Fahlman cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <19880311190404.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 4 Jan 1988 20:27 EST From: "Scott E. Fahlman" Is there general agreement on whether it is valid Common Lisp to destructively modify (RPLACA, RPLACD) the list to which a &REST parameter is bound? I can't find a reference in CLtL for this. I think there's general agreement that &rest args are supposed to be righteous lists with indefinite extent, so RPLAC'ing them ought to be legal. I don't think I ever remembered to answer this. This is specious reasoning. The premise that values of &rest parameters have indefinite extent does not imply the conclusion that each value of an &rest parameter is an independent object that does not share structure with any other object. There is general agreement on the premise, but certainly not on the conclusion. Please don't confuse the issue of extent, on which Symbolics still deliberately violates the standard (this is a well-known, documented violation, which will go away when we get the resources to make it go away) with the issue of structure sharing.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Mar 88 19:56:31 EST Received: from ICS.UCI.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 88 16:41:13 PST Received: by ICS.UCI.EDU id ab24419; 10 Mar 88 16:40 PST Received: from pasteur.uci.edu by ICS.UCI.EDU id aa24388; 10 Mar 88 16:38 PST To: Barry Margolin cc: "mike@gold-hill.com after 1-April-88" , common-lisp%sail.stanford.edu@ICS.UCI.EDU Subject: Re: A keyword data type In-reply-to: Your message of Tue, 08 Mar 88 14:35:00 -0500. <19880308193551.6.BARMAR@OCCAM.THINK.COM> Date: Thu, 10 Mar 88 16:35:09 -0800 From: kipps%etoile.uci.edu@ICS.UCI.EDU Message-ID: <8803101638.aa24388@ICS.UCI.EDU> My purpose in suggesting a keyword data type was to make a definite distinction between symbols and keywords. Making one a subtype of the other does not do this. A type/subtype relation does not merely depend on commonality of operations, but of purpose and use. Keywords and symbols do not serve the same purpose. Keywords are used as symbolic literals, while symbols are used as identifiers (i.e., indirect references to values, functions, etc.). Thus, it does not seem right to make one the subtype of the other. My own suggestion would be to call symbols identifiers and create a new type called symbols which is a super of both identifier and keyword, e.g., symbol / \ identifier keyword Unfortunately, this suggestion would introduce even more terminology changes; so it goes. -Kipps  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Mar 88 21:58:24 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 18:43:03 PST Received: by labrea.Stanford.EDU; Wed, 9 Mar 88 18:43:49 PST Received: from bhopal.lucid.com by edsel id AA14794g; Wed, 9 Mar 88 18:28:38 PST Received: by bhopal id AA09672g; Wed, 9 Mar 88 18:35:03 PST Date: Wed, 9 Mar 88 18:35:03 PST From: Linda G. DeMichiel Message-Id: <8803100235.AA09672@bhopal.lucid.com> To: common-lisp-object-system@sail.Stanford.EDU, common-lisp@sail.Stanford.EDU Subject: CLOS Consortium Cc: gregor@xerox.com, lgd@sail.Stanford.EDU, rpg@sail.Stanford.EDU CLOS Consortium Lucid is currently pursuing the establishment of a consortium to do a high-performance implementation of the Common Lisp Object System. The suggested organization for this consortium is the following: Each member company is to supply either programmers or money, and the consortium will select a group of individuals to do the implementation (in the case that more programmers are offered than needed). It is likely that the current PCL will become the seed for this implementation. No restrictions will exist as to which companies may become members of the consortium, and we expect that the implementors would be from various companies. The result will be a set of sources either in the public domain or owned by the member companies. Lucid offers to contribute at least one highly-talented programmer and the organization for the program. A mechanism should also be established to handle companies who want to join the consortium at a later date. We will be holding an organizational meeting during X3J13 next week for anyone who may be interested in participating. This meeting is scheduled for Tuesday, March 15, 8:00p.m., at Hyatt Rickeys, 4219 El Camino Real, Palo Alto. If you are interested in joining and cannot make the meeting, please let me know. Linda DeMichiel Lucid, Inc. 415-329-8400  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Mar 88 16:29:33 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Mar 88 13:13:08 PST Received: from en-c06.prime.com by RELAY.CS.NET id aa09218; 9 Mar 88 15:09 EST Received: from S51.Prime.COM by EN-C06.Prime.COM; 09 Mar 88 14:42:51 EST Received: from ENX.Prime.COM by S51.Prime.COM; 09 Mar 88 14:43:28 EST Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail) id AA21223; Wed, 9 Mar 88 14:30:51 EST Received: by zaphod.prime.com (3.2/SMI-3.2) id AA01446; Wed, 9 Mar 88 14:35:59 EST Date: Wed, 9 Mar 88 14:35:59 EST From: Douglas Rand Message-Id: <8803091935.AA01446@zaphod.prime.com> To: common-lisp@SAIL.STANFORD.EDU Subject: defsys Folks, I have a new version of the public domain defsys available but I need someone with either access to sail or who is willing to provide it a good home. My usual contact seems to have failed me. Send responses to doug@zaphod.prime.com, I appologize for sending this to the whole list but my options seem limited. Cheers, Doug  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Mar 88 15:06:31 EST Received: from ICS.UCI.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:41:57 PST Received: from think.com by ICS.UCI.EDU id aa14829; 8 Mar 88 11:36 PST Return-Path: Received: from sauron.think.com by Think.COM; Tue, 8 Mar 88 14:34:31 EST Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 8 Mar 88 14:34:25 EST Date: Tue, 8 Mar 88 14:35 EST From: Barry Margolin Subject: A keyword data type To: "mike@gold-hill.com after 1-April-88" Cc: kipps%etoile.uci.edu@ICS.UCI.EDU, common-lisp%sail.stanford.edu@ICS.UCI.EDU In-Reply-To: <8803080829.aa08538@ICS.UCI.EDU> Message-Id: <19880308193551.6.BARMAR@OCCAM.THINK.COM> Date: Tue, 8 Mar 88 11:06 est From: "mike@gold-hill.com after 1-April-88" Date: Sun, 06 Mar 88 12:08:16 -0800 From: kipps%etoile.uci.edu@ICS.UCI.EDU The comments I've heard so far about keywords lead me to believe that there shouldn't be a keyword package at all; instead, there should be a keyword data type, i.e., a data type of symbolic literals. A keyword data object always evaluates to itself and has only one user-visible component, its print name. Frankly, I think this is a great idea. However, there are interactions with various features. E.G., &key parameters. For the sake of language extensions like CLOS, the identifiers for &key parameters are not really going to be required to be "keywords" at all; rather, they can be any symbol in any package. Use of real "keywords" for this just saves making an extra symbol. We would need to change terminology so that &key would become &name or &sym or something to avoid confusion. Such a terminology change might be necessary whether or not keywords were a distinct data type. Even without the new data type, the "keywords" corresponding to &KEY parameters will not be required to be keywords under the old definition (a symbol in the KEYWORD package). A variation of your idea which might capture its value and yet avoid turmoil in the CL world would be to make KEYWORD officially a subtype of SYMBOL, and to exactly define which symbol operations work on this subtype. My suggestion is that SYMBOL-NAME work, but not SYMBOL-PLIST, SYMBOL-FUNCTION, SYMBOL-VALUE, etc. Currently, keywords are real symbols, not a subtype, and therefore the issue arises of whether you can IMPORT a keyword, etc. Actually, I think that SYMBOL should be a subtype of KEYWORD! Anything you can do to a keyword you can also do to a symbol, but not vice versa. Using CLOS syntax (we'll need to get used to this soon): (defclass keyword () ((name :initarg name :reader symbol-name))) ;;; This should actually be a shared slot, but I'm not sure how to ;;; access it in the allocate-instance meta-method, because I don't ;;; have Part 3 of the CLOS spec. (defvar *keyword-table* nil) (defmethod eval ((object keyword)) (symbol-value object)) (defmethod symbol-value ((object keyword)) object) (defmethod initialize-instance :after ((object keyword) &rest ignore) (unless (slot-boundp object 'name) (error "A name must be specified."))) (defmethod allocate-instance :around ((class (eql (symbol-class 'keyword))) &key name &allow-other-keys) (or (and (stringp name) (find name *keyword-table* :key #'symbol-name :test #'string-equal)) (let ((object (call-next-method))) (push object *keyword-table*) object))) (defun intern (string &optional package) (if (or (eql package 'keyword) ; back-compatibility (string-equal package "keyword")) (make-instance 'keyword :name string) (intern-in-package string package))) (defclass symbol (keyword) ((value :accessor symbol-value :writer set) (function :accessor symbol-function) (plist :initform nil :accessor symbol-plist) (package :initform nil :reader symbol-package))) (defun symbolp (object) (typep object 'symbol)) (defun keywordp (object) (and (typep object 'keyword) (not (typep object 'symbol)))) I suspect the last function was the reason Mike said keywords should be subtypes of symbols. I think the ultimate reason for this backwardness is that the data types we really need are NAMED-OBJECT, with two subtypes KEYWORD and SYMBOL. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Mar 88 11:50:02 EST Received: from ICS.UCI.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 08:31:18 PST Received: from xx.lcs.mit.edu by ICS.UCI.EDU id aa08538; 8 Mar 88 8:29 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Mar 88 11:27-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 83524; 8 Mar 88 11:27:08-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 96121; Tue 8-Mar-88 11:07:07-EST Date: Tue, 8 Mar 88 11:06 est From: "mike@gold-hill.com after 1-April-88" COMMENTS: NOTE %acorn@oak... CHANGES TO @GOLD-HILL.COM ON 1-April-88 To: kipps%etoile.uci.edu@ICS.UCI.EDU Subject: A keyword data type Cc: common-lisp%sail.stanford.edu@ICS.UCI.EDU Message-ID: <8803080829.aa08538@ICS.UCI.EDU> Date: Sun, 06 Mar 88 12:08:16 -0800 From: kipps%etoile.uci.edu@ICS.UCI.EDU The comments I've heard so far about keywords lead me to believe that there shouldn't be a keyword package at all; instead, there should be a keyword data type, i.e., a data type of symbolic literals. A keyword data object always evaluates to itself and has only one user-visible component, its print name. Frankly, I think this is a great idea. However, there are interactions with various features. E.G., &key parameters. For the sake of language extensions like CLOS, the identifiers for &key parameters are not really going to be required to be "keywords" at all; rather, they can be any symbol in any package. Use of real "keywords" for this just saves making an extra symbol. We would need to change terminology so that &key would become &name or &sym or something to avoid confusion. A variation of your idea which might capture its value and yet avoid turmoil in the CL world would be to make KEYWORD officially a subtype of SYMBOL, and to exactly define which symbol operations work on this subtype. My suggestion is that SYMBOL-NAME work, but not SYMBOL-PLIST, SYMBOL-FUNCTION, SYMBOL-VALUE, etc. Currently, keywords are real symbols, not a subtype, and therefore the issue arises of whether you can IMPORT a keyword, etc. ....mike beckerle Gold Hill  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Mar 88 15:28:45 EST Received: from ICS.UCI.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:11:27 PST Received: from pasteur.uci.edu by ICS.UCI.EDU id aa06021; 6 Mar 88 12:11 PST To: common-lisp%sail.stanford.edu@ICS.UCI.EDU cc: kipps%etoile.uci.edu@ICS.UCI.EDU Subject: A keyword data type Date: Sun, 06 Mar 88 12:08:16 -0800 From: kipps%etoile.uci.edu@ICS.UCI.EDU Message-ID: <8803061211.aa06021@ICS.UCI.EDU> The comments I've heard so far about keywords lead me to believe that there shouldn't be a keyword package at all; instead, there should be a keyword data type, i.e., a data type of symbolic literals. A keyword data object always evaluates to itself and has only one user-visible component, its print name. Because of their simplicity, keywords can be implemented more efficiently than symbols (although this is probably of negligible consequence). What's more important is that the integrity of keywords can no longer be compromised as it is now. I find this approach to be cleaner than making the keyword package "special" and more in line with the use of keywords in CLtL. (Additional aspects of keywords should probably include the notion of an uninterned keyword and a set of generic operations that can be applied to keywords and symbols.) Is there any reason that keywords must be symbols? -Kipps  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 88 15:22:10 EST Received: from potomac.ads.com by SAIL.Stanford.EDU with TCP; 2 Mar 88 12:03:39 PST Received: by potomac.ads.com (5.58/1.7) id AA11771; Wed, 2 Mar 88 15:04:38 EST Date: Wed, 2 Mar 88 15:04:38 EST From: John T. Nelson Message-Id: <8803022004.AA11771@potomac.ads.com> To: ansi-common-request@potomac.ads.com, common-loops-request@potomac.ads.com, common-windows-request@potomac.ads.com Subject: Request to be added to mailing list... We would like to be added to your mailing list. Sorry if I'm repeating myself but we've had a few problems with ARPAnet. Please send the common-windows, common-loops and ansi-common lists to their respective addresses at our machine: post-common-loops@potomac.ads.com post-ansi-common@potomac.ads.com post-common-windows@potomac.ads.com Thanks. John T. Nelson UUCP: sun!sundc!potomac!jtn Advanced Decision Systems Internet: jtn@potomac.ads.com 1500 Wilson Blvd #512; Arlington, VA 22209-2401 (703) 243-1611 Strange... and beautiful music  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 88 03:07:44 EST Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 23:51:20 PST Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Tue 1 Mar 88 23:46:53-PST Received: by hplabs.HP.COM ; Tue, 1 Mar 88 23:49:56 PST Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424) id AA05037; Tue, 1 Mar 88 23:35:39 PST Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424) id AA17261; Tue, 1 Mar 88 23:38:55 PST Date: 1 Mar 1988 23:29-PST From: David Bein Subject: keywords revisited To: hplabs!common-lisp@sail.stanford.edu Message-Id: <573290979/bein@pyrnova> Nick, My idea of how all this ought to work is based on the idea that any symbol accessible in the keyword package is in fact a keyword, so that reading :FOOBAZ is always synonymous with (INTERN "FOOBAZ" keyword-package) If we allow any symbol to be accessible via using other packages or having a symbol imported into the keyword package without "keywordizing" it, then we violate the accessibility issues I have raised. If we define keywordize in the brutal fashion described in: (defun keywordize-symbol (symbol) (let ((home (symbol-package symbol)) (key-package (find-package "KEYWORD"))) (unless (eq home key-package) (if home (unintern symbol home)) (setf (symbol-value symbol) symbol) (import symbol key-package)))) then allowing other interned symbols into the keyword package does not violate my accessibility requirement. I think bashing an interned symbol's home package and its value is somewhat drastic. I dont feel as bad bashing a gensym or the result of make-symbol. To summarize, I think we should have done things this way: (1) The keyword package is isolated, i.e. it never uses (or is used by) other packages. (2) Any symbol accessible in the keyword package is a keyword, i.e. its home package is the keyword package and its value is itself. (3) Symbols only become accessible in the keyword package via INTERN. It is unclear to me why anyone would want to import a symbol which is homed someplace else into the keyword package. My only concern is that any symbols accessible in the keyword package be keywords. I really dont like the problems which come up with reading/printing given that reading :KEYWORD should produce a keyword. If a symbol is accessible in the keyword package but not homed in the keyword package, then it wont print as a keyword making one more subtle case of read/print inconsistency. I guess I could have the reader do a bunch of tricky things like shadow :-) .... --David p.s. Apologies if this came twice. Mailers are out to the beach these days.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 18:52:11 EST Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:09:14 PST Received: from THOTH.ACA.MCC.COM by MCC.COM with TCP; Tue 1 Mar 88 16:09:25-CST Date: Tue, 1 Mar 88 16:06 CST From: David Vinayak Wallace Subject: the KEYWORD package USEing another package To: NGALL@G.BBN.COM cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <[G.BBN.COM] 1-Mar-88 11:54:50.NGALL> Message-ID: <880301160628.2.GUMBY@THOTH.ACA.MCC.COM> Date: 1 Mar 1988 11:54-EST From: NGALL@G.BBN.COM Date: Mon, 29 Feb 88 23:08 CST From: David Vinayak Wallace ... Yes there is a problem: you could cause a symbol to be available as a keyword whose value was not the keyword. E.g: 1 (setf user::keyword-example nil) ==> nil 2 (export 'user::keyword-example) ==> t 3 user:keyword-example ==> nil 4 (use-package '(user) (find-package 'keyword)) ==> t 5 :keyword-example ==> nil What makes you think that reading and evaluating :keyword-example results in NIL? Pg 175: "Any symbol preceded by a colon but no package name ... is added to (or looked up in) the KEYWORD package as an EXTERNAL symbol." After form 4, user:keyword-example is accessible only as an INTERNAL symbol in the KEYWORD package. Therefore, according to my interpretation of the preceding quote, whatever mechanism "looks up" keyword::keyword-example (aka user:keyword-example) would EXPORT it from the KEYWORD package, thereby making it PRESENT in the KEYWORD package, and thereby causing it to become a constant whose value is itself (all on pg 175). Thus the value of form 5 would be printed as :keyword-example. Should user::keyword-example now be nil or :keyword-example? I actually tried the forms above in Symbolics Common Lisp and they behave the way my example does. It's apparently a "bug" in that if you poke around with FIND-SYMBOL you discover that the user:keyword-example symbol is NOT exported from the keyword package. I say "bug" because this behaviour should not really be defined. Should making KEYWORD USE another package really change the value cells of the inherited symbols? Or worse yet, according to your explanation above, it shouldn't change the value until the symbol was read through the KEYWORD package!? Plus you can end up with keywords with something in their function cells, which always makes me queasy. david  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 12:28:37 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 09:10:04 PST Date: 1 Mar 1988 12:10-EST Sender: NGALL@G.BBN.COM Subject: Re: the KEYWORD package USEing another package From: NGALL@G.BBN.COM To: barmar@THINK.COM Cc: Gumby@MCC.COM, common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM] 1-Mar-88 12:10:14.NGALL> In-Reply-To: <19880301160642.3.BARMAR@OCCAM.THINK.COM> Date: Tue, 1 Mar 88 11:06 EST From: Barry Margolin Date: Mon, 29 Feb 88 23:08 CST From: David Vinayak Wallace ... (setf user::keyword-example nil) ==> nil (export 'user::keyword-example) ==> t user:keyword-example ==> nil (use-package '(user) (find-package 'keyword)) ==> t :keyword-example ==> nil Actually, this should result in an error due to an attempt to reference an internal symbol as an external, because when a package uses another package the symbols in the used package are internal to the using package until it exports them. CLtL only says that symbols in the keyword package are made external when they are added to the package, not when they are accessed through indirection. barmar Yes. I retract my previous position (that symbols accessible in the KEYWORD package are made external when they are ACCESSED) and agree with Barry: a correctable error is signalled (pg. 174) when a symbol that is internal to the KEYWORD package is referenced with the `:' (or `keyword:') prefix. Note that the only possible internal symbols in the KEYWORD package are those that are inherited. Thus, one could `block' the addition of certain symbols to the KEYWORD package by having the KEYWORD package inherit them. This might be a useful way to `reserve' some set of keywords. -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 12:10:46 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 08:53:53 PST Date: 1 Mar 1988 11:54-EST Sender: NGALL@G.BBN.COM Subject: Re: the KEYWORD package USEing another package From: NGALL@G.BBN.COM To: Gumby@MCC.COM Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM] 1-Mar-88 11:54:50.NGALL> In-Reply-To: <880229230848.2.GUMBY@THOTH.ACA.MCC.COM> Date: Mon, 29 Feb 88 23:08 CST From: David Vinayak Wallace ... Yes there is a problem: you could cause a symbol to be available as a keyword whose value was not the keyword. E.g: 1 (setf user::keyword-example nil) ==> nil 2 (export 'user::keyword-example) ==> t 3 user:keyword-example ==> nil 4 (use-package '(user) (find-package 'keyword)) ==> t 5 :keyword-example ==> nil What makes you think that reading and evaluating :keyword-example results in NIL? Pg 175: "Any symbol preceded by a colon but no package name ... is added to (or looked up in) the KEYWORD package as an EXTERNAL symbol." After form 4, user:keyword-example is accessible only as an INTERNAL symbol in the KEYWORD package. Therefore, according to my interpretation of the preceding quote, whatever mechanism "looks up" keyword::keyword-example (aka user:keyword-example) would EXPORT it from the KEYWORD package, thereby making it PRESENT in the KEYWORD package, and thereby causing it to become a constant whose value is itself (all on pg 175). Thus the value of form 5 would be printed as :keyword-example. ... -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 11:29:42 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 08:07:23 PST Return-Path: Received: from sauron.think.com by Think.COM; Tue, 1 Mar 88 11:07:00 EST Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 1 Mar 88 11:06:54 EST Date: Tue, 1 Mar 88 11:06 EST From: Barry Margolin Subject: the KEYWORD package USEing another package To: David Vinayak Wallace Cc: NGALL@g.bbn.com, common-lisp@sail.stanford.edu In-Reply-To: <880229230848.2.GUMBY@THOTH.ACA.MCC.COM> Message-Id: <19880301160642.3.BARMAR@OCCAM.THINK.COM> Date: Mon, 29 Feb 88 23:08 CST From: David Vinayak Wallace Date: 29 Feb 1988 14:15-EST From: NGALL@G.BBN.COM Date: 24 Feb 1988 19:20-PST From: David Bein Cf. pg 187: "It is an error to try to use the KEYWORD package." I don't see any problem with having the KEYWORD package use another package (I don't see much point to it either). Do you? Yes there is a problem: you could cause a symbol to be available as a keyword whose value was not the keyword. E.g: (setf user::keyword-example nil) ==> nil (export 'user::keyword-example) ==> t user:keyword-example ==> nil (use-package '(user) (find-package 'keyword)) ==> t :keyword-example ==> nil Actually, this should result in an error due to an attempt to reference an internal symbol as an external, because when a package uses another package the symbols in the used package are internal to the using package until it exports them. CLtL only says that symbols in the keyword package are made external when they are added to the package, not when they are accessed through indirection. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 88 00:23:48 EST Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 21:11:18 PST Received: from THOTH.ACA.MCC.COM by MCC.COM with TCP; Mon 29 Feb 88 23:11:33-CST Date: Mon, 29 Feb 88 23:08 CST From: David Vinayak Wallace Subject: the KEYWORD package USEing another package To: NGALL@G.BBN.COM cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <[G.BBN.COM]29-Feb-88 14:15:37.NGALL> Message-ID: <880229230848.2.GUMBY@THOTH.ACA.MCC.COM> Date: 29 Feb 1988 14:15-EST From: NGALL@G.BBN.COM Date: 24 Feb 1988 19:20-PST From: David Bein Cf. pg 187: "It is an error to try to use the KEYWORD package." I don't see any problem with having the KEYWORD package use another package (I don't see much point to it either). Do you? Yes there is a problem: you could cause a symbol to be available as a keyword whose value was not the keyword. E.g: (setf user::keyword-example nil) ==> nil (export 'user::keyword-example) ==> t user:keyword-example ==> nil (use-package '(user) (find-package 'keyword)) ==> t :keyword-example ==> nil :some-other-keyword ==> :some-other-keyword This would break a lot of programs. Don't think of keywords as symbols. They are a specialisation of symbols; they don't have all the attributes (really only the PR and the plist should be used) of symbols. I think common-lisp should be explicit that you shouldn't think of them as having all the attributes of symbols. Perhaps cl should specify that "it is an error to use the function cell of a keyword," to discourage people from using them as normal symbols.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 22:08:44 EST Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 18:53:45 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Feb 88 21:54-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 82668; 29 Feb 88 21:50:52-EST Received: from LEIPZIG.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 95277; Mon 29-Feb-88 21:31:24-EST Date: Mon, 29 Feb 1988 21:32 EST From: RpK%acorn@oak.lcs.mit.edu Subject: [Order of arguments to sequence :TEST functions] Cc: common-lisp@sail.stanford.edu > Date: Mon, 29 Feb 88 09:34 EST > From: David C. Plummer > Subject: Order of arguments to sequence :TEST functions > To: common-lisp@sail.stanford.edu > > CLtL page 247 says > ... (funcall testfn item (keyfn x)) ... > I'm curious to know why this order was chosen instead of > ... (funcall testfn (keyfn x) item) ... Well, one nice property about this is that (find-if pred seq ...) is equivalent to (find pred seq :test #'funcall ...)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 20:00:55 EST Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 16:46:00 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Feb 88 19:46-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 82653; 29 Feb 88 19:44:49-EST Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 95271; Mon 29-Feb-88 17:56:40-EST Date: Mon, 29 Feb 1988 17:52 EST From: Randy%acorn@oak.lcs.mit.edu To: gls@Think.COM Subject: [Order of arguments to sequence :TEST functions] Cc: Randy, DCP@quabbin.scrc.symbolics.com, common-lisp@sail.stanford.edu, Moon@stony-brook.scrc.symbolics.com > Return-Path: > Date: Mon, 29 Feb 88 15:04:44 EST > From: gls@Think.COM > To: Moon@stony-brook.scrc.symbolics.com > Cc: DCP@quabbin.scrc.symbolics.com, common-lisp@sail.stanford.edu > In-Reply-To: David A. Moon's message of Mon, 29 Feb 88 13:55 EST <19880229185550.0.MOON@EUPHRATES.SCRC.Symbolics.COM> > Subject: Order of arguments to sequence :TEST functions > ..... > (find 3 numlist :text (C #'<)) ;find something less than 3 Is that the recently proposed :TEXT keyword, which tells the system what to print if it doesn't find anything? How about a new keyword for all the generix which take :TEST, called :REVERSE-TEST. On certain machines, this could be implemented more efficiently that using LAMBDA ;-) Random  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 17:14:36 EST Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by SAIL.Stanford.EDU with TCP; 29 Feb 88 13:59:37 PST Received: by cayuga.cs.rochester.edu (5.52/h) id AA01879; Mon, 29 Feb 88 16:58:57 EST Received: from loopback by lesath.cs.rochester.edu (3.2/h) id AA06946; Mon, 29 Feb 88 16:58:45 EST Message-Id: <8802292158.AA06946@lesath.cs.rochester.edu> To: David C. Plummer Cc: common-lisp@SAIL.STANFORD.EDU Subject: Re: Order of arguments to sequence :TEST functions In-Reply-To: Your message of Mon, 29 Feb 88 13:50:00 -0500. <19880229185047.6.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 29 Feb 88 16:58:40 -0500 From: quiroz@cs.rochester.edu | Here's a quick test/poll. Without using the -IF or -IF-NOT functions, | - Remove all elements of a sequence which are less than 3. | - Find the first element of a sequence which is more than 3. | My "intuition" for coding this gives the wrong answers. | I know this doesn't show anything about language design. Counterquestion: Why is it so important to do this `[w]ithout using the -IF or -IF-NOT functions'? My first reaction is (remove-if #'(lambda (elt) (< elt 3)) seq) Cesar Quiroz PS. "`Straightedge and Compass' is no more powerful than `Compass alone'" [Mascheroni? Steiner? Both? Sigh, I don't remember anymore]. Interesting, but both alternatives are much less useful than a decent plotter. :-)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 15:24:50 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 12:05:50 PST Return-Path: Received: from kali.think.com by Think.COM; Mon, 29 Feb 88 15:04:48 EST Received: by kali.think.com; Mon, 29 Feb 88 15:04:44 EST Date: Mon, 29 Feb 88 15:04:44 EST From: gls@Think.COM Message-Id: <8802292004.AA10886@kali.think.com> To: Moon@stony-brook.scrc.symbolics.com Cc: DCP@quabbin.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: David A. Moon's message of Mon, 29 Feb 88 13:55 EST <19880229185550.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Order of arguments to sequence :TEST functions Date: Mon, 29 Feb 88 13:55 EST From: David A. Moon Date: Mon, 29 Feb 88 09:34 EST From: David C. Plummer CLtL page 247 says ... (funcall testfn item (keyfn x)) ... I'm curious to know why this order was chosen instead of ... (funcall testfn (keyfn x) item) ... The design rationale is given just a few lines lower on the same page. The order of arguments to the testfn is kept consistent with the order of arguments to the sequence function in question. The moral is: When in doubt... ... What I was trying to do was use FIND to find an item of a certain type, as in (find type sequence :test #'typep) but the order of the arguments as defined in CLtL is backwards. Looks like a job for LAMBDA. Or, for a general solution, try the C combinator: (defun C (fn) #'(lambda (x y) (funcall fn y x))) (find type sequence :test (C #'typep)) (find 3 numlist :text (C #'<)) ;find something less than 3 --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 14:51:32 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 11:20:45 PST Date: 29 Feb 1988 14:15-EST Sender: NGALL@G.BBN.COM Subject: Re: the KEYWORD package ... From: NGALL@G.BBN.COM To: pyrnj!pyramid!bein@RUTGERS.EDU Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]29-Feb-88 14:15:37.NGALL> In-Reply-To: <572757648/bein@pyrnova> Date: 24 Feb 1988 19:20-PST From: David Bein Suppose we have a symbol which has no home package which is going to be imported into the keyword package using one of IMPORT,SHADOW, or SHADOWING-IMPORT. Should those functions "keyword-ize" the symbol ala INTERN, i.e. should the value of the symbol be set to itself? Cf. pg 175: "The KEYWORD package is treated specially in that whenever a symbol is added to the KEYWORD package the symbol is always made external; the symbol is also automatically declared to be a constant (see DEFCONSTANT) and made to have itself as its value." I interpret the word `added' as encompassing INTERN, IMPORT, etc., so I would say that the answer to your question is `yes'. While on the subject, should the keyword package be allowed to use (or be used by) other packages? Cf. pg 187: "It is an error to try to use the KEYWORD package." I don't see any problem with having the KEYWORD package use another package (I don't see much point to it either). Do you? I am leaning in favor of: (1) Anytime a symbol's home package is set to the keyword package, the symbol is keywordized destroying any previous value. Since one can never directly `set' the home package of a symbol, I don't think it is clear to couch a rule in that way. How about, "Anytime a symbol is made present in the KEYWORD package, the symbol is `keywordized'..." This basically rephrases pg 175. (2) It should be an error for the keyword package to use (or be used by) another package. Why should it be an error for the keyword package to use another package? (3) It should be an error to import a symbol into the keyword package which already has another home package. Why? -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 14:11:49 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:55:56 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 352865; Mon 29-Feb-88 13:56:05 EST Date: Mon, 29 Feb 88 13:55 EST From: David A. Moon Subject: Order of arguments to sequence :TEST functions To: David C. Plummer cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <19880229143424.3.DCP@SWAN.SCRC.Symbolics.COM> Message-ID: <19880229185550.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 29 Feb 88 09:34 EST From: David C. Plummer CLtL page 247 says ... (funcall testfn item (keyfn x)) ... I'm curious to know why this order was chosen instead of ... (funcall testfn (keyfn x) item) ... The design rationale is given just a few lines lower on the same page. The order of arguments to the testfn is kept consistent with the order of arguments to the sequence function in question. Was there a reason for the ordering choice? Does anybody depend on it, or know of somebody that does? Is there any chance of CLtL'89 reversing it (and documenting the reason in the text)? Yes. Yes. I hope not. Changing the order of arguments to something, in a way so that the incompatibility cannot be mechanically detected and warned about or assisted with, is the worst kind of incompatible change from a user point of view. What I was trying to do was use FIND to find an item of a certain type, as in (find type sequence :test #'typep) but the order of the arguments as defined in CLtL is backwards. Looks like a job for LAMBDA.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 14:06:48 EST Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:51:16 PST Received: from SWAN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 208100; Mon 29-Feb-88 13:52:22 EST Date: Mon, 29 Feb 88 13:50 EST From: David C. Plummer Subject: Order of arguments to sequence :TEST functions To: Scott E. Fahlman , common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <19880229185047.6.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 29 Feb 1988 10:57 EST From: "Scott E. Fahlman" Yes, lots of code would have to be changed (in a trivial way) if we switched this around now. I can believe you are right, but here's my reason why I think the amount of change could be small: The change only affects non-commutative predicates. Most of the predicates I have used and that I have seen are commutative, basically EQ, EQL, EQUAL and /=. I think that an incompatible change like this has no chance of passing if the reason is just someone's view that the order of arguments would be more intuitive if switched around. Here's a quick test/poll. Without using the -IF or -IF-NOT functions, - Remove all elements of a sequence which are less than 3. - Find the first element of a sequence which is more than 3. My "intuition" for coding this gives the wrong answers. I know this doesn't show anything about language design.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 14:06:33 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:50:27 PST Date: 29 Feb 1988 13:49-EST Sender: NGALL@G.BBN.COM Subject: Re: Order of arguments to sequence :TEST functions From: NGALL@G.BBN.COM To: DCP@SCRC-QUABBIN.ARPA Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]29-Feb-88 13:49:03.NGALL> In-Reply-To: <19880229143424.3.DCP@SWAN.SCRC.Symbolics.COM> Date: Mon, 29 Feb 88 09:34 EST From: David C. Plummer CLtL page 247 says ... (funcall testfn item (keyfn x)) ... I'm curious to know why this order was chosen instead of ... (funcall testfn (keyfn x) item) ... My personal theory is that the order of the arguments to the TESTFN is the same as their order in the `surface' call, i.e., in most (all?) of the sequence functions, the ITEM appears before the sequence (and therefore before each element X of the sequence). This theory makes it easy for me to remember the order of arguments to the TESTFN (so I would hate to see the order changed). -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 14:02:23 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:47:13 PST Return-Path: Received: from sauron.think.com by Think.COM; Mon, 29 Feb 88 13:45:54 EST Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 29 Feb 88 13:45:49 EST Date: Mon, 29 Feb 88 13:45 EST From: Barry Margolin Subject: [Order of arguments to sequence :TEST functions] To: Randy%acorn@live-oak.lcs.mit.edu Cc: David C. Plummer , Randy@sail.stanford.edu, common-lisp@sail.stanford.edu In-Reply-To: <8802291736.AA16958@Think.COM> Message-Id: <19880229184541.0.BARMAR@OCCAM.THINK.COM> Date: Mon, 29 Feb 1988 11:27 EST From: Randy%acorn@LIVE-OAK.LCS.MIT.EDU It seems that anyone who does (FIND number list-of-number :test #'<) is depending on the order of the arguments to the test. I don't know for sure if anyone depends on this, but it doesn't seem like a particularly contorted example. There are a fair number of non-commutative predicates. This example reminds me of what I think is the reason for the particular order chosen. I think the order of arguments to the test function is always supposed to be the same as the order of arguments to the sequence function, for ease of remembering. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 13:40:38 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:03:11 PST Date: 29 Feb 1988 12:58-EST Sender: NGALL@G.BBN.COM Subject: Re: package question From: NGALL@G.BBN.COM To: barmar@THINK.COM Cc: pyrnj!pyramid!bein@RUTGERS.EDU Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]29-Feb-88 12:58:14.NGALL> In-Reply-To: <19880226224604.9.BARMAR@OCCAM.THINK.COM> Date: Fri, 26 Feb 88 17:46 EST From: Barry Margolin ... And on p.176, CLtL says that #:BAR syntax is used "when the symbol BAR is uninterned (has no home package), even in the pathological case that BAR is uninterned but nevertheless somehow accessible in the current package." The statement on pg. 176 should be repeated on pg. 367 where it talks about how to print a symbol. Currently, in reading pg. 367 in isolation, one is left confused as to how to print an uninterned symbol that is accesible in the current package. -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 13:18:34 EST Received: from G.BBN.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 10:03:11 PST Date: 29 Feb 1988 12:58-EST Sender: NGALL@G.BBN.COM Subject: Re: package question From: NGALL@G.BBN.COM To: barmar@THINK.COM Cc: pyrnj!pyramid!bein@RUTGERS.EDU Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]29-Feb-88 12:58:14.NGALL> In-Reply-To: <19880226224604.9.BARMAR@OCCAM.THINK.COM> Date: Fri, 26 Feb 88 17:46 EST From: Barry Margolin ... And on p.176, CLtL says that #:BAR syntax is used "when the symbol BAR is uninterned (has no home package), even in the pathological case that BAR is uninterned but nevertheless somehow accessible in the current package." The statement on pg. 176 should be repeated on pg. 367 where it talks about how to print a symbol. Currently, in reading pg. 367 in isolation, one is left confused as to how to print an uninterned symbol that is accesible in the current package. -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 12:50:39 EST Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 09:35:17 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Feb 88 12:35-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 82575; 29 Feb 88 12:31:53-EST Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 95234; Mon 29-Feb-88 11:31:43-EST Date: Mon, 29 Feb 1988 11:27 EST From: Randy%acorn@oak.lcs.mit.edu To: David C. Plummer Subject: [Order of arguments to sequence :TEST functions] Cc: Randy, common-lisp@sail.stanford.edu > Date: Mon, 29 Feb 88 09:34 EST > From: David C. Plummer > Subject: Order of arguments to sequence :TEST functions > To: common-lisp@sail.stanford.edu > > CLtL page 247 says > ... (funcall testfn item (keyfn x)) ... > I'm curious to know why this order was chosen instead of > ... (funcall testfn (keyfn x) item) ... > ... > Yes, I know I can use find-if, and that's what I'm really doing. Was > there a reason for the ordering choice? Does anybody depend on it, or > know of somebody that does? Is there any chance of CLtL'89 reversing > it (and documenting the reason in the text)? It seems that anyone who does (FIND number list-of-number :test #'<) is depending on the order of the arguments to the test. I don't know for sure if anyone depends on this, but it doesn't seem like a particularly contorted example. There are a fair number of non-commutative predicates. Random  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 11:13:24 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 07:57:00 PST Received: ID ; Mon 29 Feb 88 10:57:07-EST Date: Mon, 29 Feb 1988 10:57 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: Order of arguments to sequence :TEST functions In-reply-to: Msg of 29 Feb 1988 09:34-EST from David C. Plummer I think that the definition on page 247 is what seemed intuitive to the designers at the time, probably reflecting some pre-existing practice in some system or other. Your view of the proper order is an interesting one, but doesn't seem to be universal, and nobody argued this point of view at the time. My intuition tends to go in the opposite direction: typep seems backwards to me, because I view the function and type argument as being a sort of composite function that is then applied to the thing being investigated. I agree that it is unfortunate that typep and the :test keyword don't match, but as you point out there are ways around this. Yes, lots of code would have to be changed (in a trivial way) if we switched this around now. I think that an incompatible change like this has no chance of passing if the reason is just someone's view that the order of arguments would be more intuitive if switched around. -- Scott  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 09:51:54 EST Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 29 Feb 88 06:34:50 PST Received: from SWAN.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 232161; Mon 29-Feb-88 09:34:48 EST Date: Mon, 29 Feb 88 09:34 EST From: David C. Plummer Subject: Order of arguments to sequence :TEST functions To: common-lisp@sail.stanford.edu Message-ID: <19880229143424.3.DCP@SWAN.SCRC.Symbolics.COM> CLtL page 247 says ... (funcall testfn item (keyfn x)) ... I'm curious to know why this order was chosen instead of ... (funcall testfn (keyfn x) item) ... When I hand code predicates, I usually put the more variable thing first and the more constant thing second, as in (defun poor-mans-position (array frob) (dotimes (index (length array)) (when (eql (aref array index) frob) (return index)))) The (Symbolics implementation) of xCASE macros are similar, in that the keyform is the more variable and the clauses are the more constant, and it is roughly (eql keyform clause) or (member keyform clause) as appropriate. Since EQL is commutative, this doesn't matter much. The xTYPECASE macros are somewhat similar: they keyform is the more variable and the type is more contant. Of course, this is largely based on the order of arguments to TYPEP. Still, there is a potential analogy. Generally, I view "is it XYZ" to be (test it XYZ). This generally holds except for the sequence functions, such as FIND, where I view XYZ being the item and "it" being the element of the sequence. What I was trying to do was use FIND to find an item of a certain type, as in (find type sequence :test #'typep) but the order of the arguments as defined in CLtL is backwards. The closest I could get was (find type sequence :key #'type-of :test-not #'subtypep) with the knowledge that there was no exact match (it was a flavor mixin). Yes, I know I can use find-if, and that's what I'm really doing. Was there a reason for the ordering choice? Does anybody depend on it, or know of somebody that does? Is there any chance of CLtL'89 reversing it (and documenting the reason in the text)?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Feb 88 07:25:58 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Feb 88 04:08:43 PST Received: from Burger.ms by ArpaGateway.ms ; 29 FEB 88 04:07:49 PST Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 29 Feb 88 04:06:59 PST (Monday) Subject: Re: Lisp Innards Wanted! From: MASINTER.PARC@Xerox.COM To: shebs@cs.utah.EDU cc: common-lisp@sail.stanford.EDU In-Reply-to: shebs%cs.utah:EDU's message of Saturday, February 27, 1988 11:09 am Reply-to: MASINTER.PARC@Xerox.COM Message-ID: <880229-040749-1061@Xerox> I'm willing to review your dissertation for technical accuracy, at least about the Lisp implementations that I'm familiar with. Larry Masinter Xerox PARC 3333 Coyote Hill Road Palo Alto, cA 94304  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Feb 88 09:31:58 EST Received: from rutgers.edu by SAIL.Stanford.EDU with TCP; 28 Feb 88 06:18:12 PST Received: by rutgers.edu (5.54/1.15) id AA17994; Sun, 28 Feb 88 08:33:48 EST Received: ID ; Sun 28 Feb 88 08:02:51-EST Date: Sat, 27 Feb 1988 20:55 EST Message-Id: Sender: RAM@ From: Ram@c.cs.cmu.edu To: David Bein Cc: common-lisp@sail.stanford.edu Subject: package question In-Reply-To: Msg of 24 Feb 1988 22:19-EST from David Bein Date: Wednesday, 24 February 1988 22:19-EST From: David Bein Re: package question [...] Is IMPORT doing the right thing by giving the symbol a home package if it does not have one? I believe there is nothing in CLTL that suggests this, but at one point a while back there was a discussion of this, and the consensus seemed to be that IMPORT should set the home package when it was null. This was way before the ANSII standardization processes started. (CMU Lisp also has this behavior.) Rob  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Feb 88 04:31:15 EST Received: from rutgers.edu by SAIL.Stanford.EDU with TCP; 28 Feb 88 01:16:11 PST Received: by rutgers.edu (5.54/1.15) id AA12121; Sun, 28 Feb 88 03:58:00 EST Received: ID ; Sun 28 Feb 88 03:21:41-EST Date: Sat, 27 Feb 1988 20:39 EST Message-Id: Sender: RAM@ From: Ram@c.cs.cmu.edu To: David Bein Cc: common-lisp@sail.stanford.edu Subject: package question In-Reply-To: Msg of 24 Feb 1988 22:19-EST from David Bein Print-read consistency isn't maintained when you use "dangerous" functions such as IMPORT and UNINTERN. See page 173. I understand that it is non-intuitive that an "uninterned" symbol can be accessible, but this is consistent with the other generally non-intuitive behavior of the package system. One of the most important things you must realize before you can understand what the package system really does (as opposed to what you want it to do) is to realize that symbols don't "belong" to any package, and that the home package means nothing except when printing, and not much even then. Rob  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Feb 88 13:52:07 EST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 27 Feb 88 10:36:42 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA02452; Sat, 27 Feb 88 11:37:17 MST Date: Sat, 27 Feb 88 11:37:17 MST From: shebs@cs.utah.edu (Stanley Shebs) Message-Id: <8802271837.AA02452@cs.utah.edu> To: common-lisp@sail.stanford.edu Subject: Lisp Innards Wanted! [Apologies to those who have seen this already, how could I have forgotten the COMMON-LISP list!] As part of my dissertation, I've been collecting info on the internal data representations of various Lisp systems. Lisp here is broadly defined as any language ultimately based on Lisp 1.5, and includes Scheme. What I'm looking for is the grungiest of machine-level details on the layout of cons cells, type discrimination schemes, memory organization, and storage recovery. Moon's description of the Symbolics architecture in the January 87 Computer is an excellent example, especially the pictures. Not every single detail is needed; just those that required conscious decisions by an implementor. (For instance, if arrays are tagged with a 0 to avoid masking, that is interesting, but if it was only because "array" is the first type name in the dictionary, that is not interesting.) Implementations embedded in other Lisps (Scheme 84, PCLS) are not of interest, but this does not exclude those written in other high-level languages (as can be seen from the list below). At present I have reasonably complete descriptions of the following systems, mostly derived from published material, manuals, or source code: 7090 Lisp 1.5 M-460 Lisp Q-32 Lisp PDP-1 Lisp Lisp 1.6 UCI Lisp MacLISP (PDP-10, Multics) Interlisp (VAX, PDP-10, -D) LISP-11 Cambridge LISP (IBM) Zetalisp Franz Lisp PSL NIL Spice Lisp S-1 Lisp Franz Extended Common Lisp T MIT Scheme PC Scheme Scheme-48 Lisp F3 XLISP VT-LISP Kyoto Common Lisp VLISP LeLisp Multilisp I have only sketchy or no data on the following systems: muLisp TLC-Lisp Cambridge Lisp (ST) Apollo Domain Lisp (the PSL deriv) Rutgers Lisp-20 Rutgers DEC-20 Common Lisp Golden Common Lisp HP Common Lisp VAXLisp Pyramid Common Lisp Lucid Lisp There are certainly others I've forgotten or simply don't know about - any info on these is quite welcome! Long-ago implementations are just as worth knowing about as more recent ones. Details received will go into my dissertation, and possibly into a separate tech report; any contributor who wants one will get a copy when this work is completed, perhaps in three months or so. The dissertation itself is about Lisp data structure design in general, and how it might be formalized. Of course, all contributions will be properly credited, not to mention greatly appreciated! stan shebs shebs@cs.utah.edu uunet!utah-cs!shebs  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Feb 88 18:05:08 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 26 Feb 88 14:45:37 PST Return-Path: Received: from sauron.think.com by Think.COM; Fri, 26 Feb 88 17:45:02 EST Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 26 Feb 88 17:44:58 EST Date: Fri, 26 Feb 88 17:46 EST From: Barry Margolin Subject: package question To: David Bein Cc: common-lisp@sail.stanford.edu In-Reply-To: <572757552/bein@pyrnova> Message-Id: <19880226224604.9.BARMAR@OCCAM.THINK.COM> Date: 24 Feb 1988 19:19-PST From: David Bein [Why do Suppose we have the following: * *PACKAGE* # ; * (SETQ P 'LISP::NEW-SYMBOL) LISP::NEW-SYMBOL ; * (IMPORT P *PACKAGE*) T ; * P NEW-SYMBOL ; * (UNINTERN P (SYMBOL-PACKAGE P)) T ; * P #:NEW-SYMBOL * (FIND-SYMBOL "NEW-SYMBOL" *PACKAGE*) #:NEW-SYMBOL ; :INTERNAL ; * (EQ * P) T ; * 'NEW-SYMBOL #:NEW-SYMBOL * (EQ * P) T ; We have an inconsistency here since printing does not equal reading. Should the reader give the symbol a home if it does not have one? Or should the printer be noticing that a symbol with no home is in fact accessible in the current package (and not prefix with #:)? Print-read consistency is only guaranteed for interned symbols [CLtL p.173]; a symbol is uninterned if it has no home package, whether or not it is accessible in any package. And on p.176, CLtL says that #:BAR syntax is used "when the symbol BAR is uninterned (has no home package), even in the pathological case that BAR is uninterned but nevertheless somehow accessible in the current package." You have created such a pathological case. And the description of UNINTERN on p.185 says that it should be used with caution because it "changes the state of the package system in such a way that the consistency rules do not hold across the change." * (IMPORT P *PACKAGE*) T ; * P NEW-SYMBOL ; * 'NEW-SYMBOL NEW-SYMBOL ; * (EQ * P) T ; Is IMPORT doing the right thing by giving the symbol a home package if it does not have one? This issue was addressed by the X3J13 Cleanup subcommittee, in issue IMPORT-SETF-SYMBOL-PACKAGE. A decision about this was made last June; unfortunately, I don't recall specifically what the decision was, but I'll wager we made the above valid. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Feb 88 17:18:22 EST Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 26 Feb 88 14:00:18 PST Received: from SWAN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207635; Fri 26-Feb-88 16:59:28 EST Date: Fri, 26 Feb 88 16:58 EST From: David C. Plummer Subject: the KEYWORD package ... To: David Bein , common-lisp@sail.stanford.edu In-Reply-To: <572757648/bein@pyrnova> Message-ID: <19880226215805.5.DCP@SWAN.SCRC.Symbolics.COM> Date: 24 Feb 1988 19:20-PST From: David Bein (1) Anytime a symbol's home package is set to the keyword package, the symbol is keywordized destroying any previous value. I think it should be an error to import something into the keyword package. Yes, this makes the keyword package more magic than it already is. That's perfectly OK with me unless I hear a good answer to this question: What programming model are you using that suggests you want to do something like this? (2) It should be an error for the keyword package to use (or be used by) another package. I agree. (3) It should be an error to import a symbol into the keyword package which already has another home package. See (1).  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Feb 88 15:55:52 EST Received: from rutgers.edu by SAIL.Stanford.EDU with TCP; 26 Feb 88 12:34:50 PST Received: by rutgers.edu (5.54/1.15) with UUCP id AA13305; Fri, 26 Feb 88 15:16:18 EST Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424) id AA24602; Wed, 24 Feb 88 19:17:29 PST Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424) id AA25276; Wed, 24 Feb 88 19:20:03 PST Date: 24 Feb 1988 19:19-PST From: David Bein Subject: package question To: common-lisp@sail.stanford.edu@rutgers.edu Message-Id: <572757552/bein@pyrnova> Suppose we have the following: * *PACKAGE* # ; * (SETQ P 'LISP::NEW-SYMBOL) LISP::NEW-SYMBOL ; * (IMPORT P *PACKAGE*) T ; * P NEW-SYMBOL ; * (UNINTERN P (SYMBOL-PACKAGE P)) T ; * P #:NEW-SYMBOL * (FIND-SYMBOL "NEW-SYMBOL" *PACKAGE*) #:NEW-SYMBOL ; :INTERNAL ; * (EQ * P) T ; * 'NEW-SYMBOL #:NEW-SYMBOL * (EQ * P) T ; We have an inconsistency here since printing does not equal reading. Should the reader give the symbol a home if it does not have one? Or should the printer be noticing that a symbol with no home is in fact accessible in the current package (and not prefix with #:)? * (IMPORT P *PACKAGE*) T ; * P NEW-SYMBOL ; * 'NEW-SYMBOL NEW-SYMBOL ; * (EQ * P) T ; Is IMPORT doing the right thing by giving the symbol a home package if it does not have one? --David  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Feb 88 15:55:52 EST Received: from rutgers.edu by SAIL.Stanford.EDU with TCP; 26 Feb 88 12:36:46 PST Received: by rutgers.edu (5.54/1.15) with UUCP id AA13340; Fri, 26 Feb 88 15:17:42 EST Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424) id AA24647; Wed, 24 Feb 88 19:19:13 PST Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424) id AA25304; Wed, 24 Feb 88 19:21:47 PST Date: 24 Feb 1988 19:20-PST From: David Bein Subject: the KEYWORD package ... To: common-lisp@sail.stanford.edu@rutgers.edu Message-Id: <572757648/bein@pyrnova> Suppose we have a symbol which has no home package which is going to be imported into the keyword package using one of IMPORT,SHADOW, or SHADOWING-IMPORT. Should those functions "keyword-ize" the symbol ala INTERN, i.e. should the value of the symbol be set to itself? While on the subject, should the keyword package be allowed to use (or be used by) other packages? I am leaning in favor of: (1) Anytime a symbol's home package is set to the keyword package, the symbol is keywordized destroying any previous value. (2) It should be an error for the keyword package to use (or be used by) another package. (3) It should be an error to import a symbol into the keyword package which already has another home package. --David  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Feb 88 18:16:54 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 25 Feb 88 14:39:14 PST Return-Path: Received: from kali.think.com by Think.COM; Thu, 25 Feb 88 17:38:38 EST Received: by kali.think.com; Thu, 25 Feb 88 17:38:34 EST Date: Thu, 25 Feb 88 17:38:34 EST From: gls@Think.COM Message-Id: <8802252238.AA04941@kali.think.com> To: RWK@ai.ai.mit.edu Cc: hilfingr%tully.Berkeley.EDU@ginger.berkeley.edu, common-lisp@sail.stanford.edu In-Reply-To: "Robert W. Kerns"'s message of Wed, 24 Feb 88 19:46:14 EST <331493.880224.RWK@AI.AI.MIT.EDU> Subject: Heat and Howard Trickey Date: Wed, 24 Feb 88 19:46:14 EST From: "Robert W. Kerns" Barton warned me about you! I haven't seen the article, but the TITLE is enough to make me flame! I mean, any language that would name itself after one of C's more cryptic "character-saving" constructs is not something you'd need to bother comparing to Lisp, let alone write a paper on it! C purists (I count myself one), who know the difference between prefix ++ and postfix ++, observe that the name C++ may be loosely paraphrased as "improve C, then throw the result away and use the old language". --Quux  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Feb 88 21:17:08 EST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 18:03:27 PST Date: Wed, 24 Feb 88 19:46:14 EST From: "Robert W. Kerns" Subject: Heat and Howard Trickey To: hilfingr%tully.Berkeley.EDU@GINGER.BERKELEY.EDU cc: common-lisp@SAIL.STANFORD.EDU In-reply-to: Msg of Thu 18 Feb 88 14:01:35 PST from hilfingr%tully.Berkeley.EDU at ginger.Berkeley.EDU (Paul Hilfinger) Message-ID: <331493.880224.RWK@AI.AI.MIT.EDU> Barton warned me about you! I haven't seen the article, but the TITLE is enough to make me flame! I mean, any language that would name itself after one of C's more cryptic "character-saving" constructs is not something you'd need to bother comparing to Lisp, let alone write a paper on it! OK, I guess I'll have to locate the article & get more fuel. Can't let you Californians get chilled, now can we?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Feb 88 13:08:31 EST Received: from NSS.Cs.Ucl.AC.UK (TUNNEL.CS.UCL.AC.UK) by SAIL.Stanford.EDU with TCP; 19 Feb 88 09:51:47 PST Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa09088; 19 Feb 88 17:38 GMT Received: from xenakis by mordell.maths.bath.AC.UK id aa28204; 19 Feb 88 17:36 GMT To: zorn <@ginger.berkeley.edu:zorn@hecuba.berkeley.edu> CC: common-lisp@sail.stanford.edu In-reply-to: Benjamin Zorn's message of Thu, 18 Feb 88 12:09:15 PST <8802182009.AA23112@hecuba.Berkeley.EDU> Subject: Results of query regarding multiprocessor applications and simulators Date: Fri, 19 Feb 88 17:38:12 GMT From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK I am a little confused. I thought you asked for parallel Common Lisp work, but your collective message omits the word "Common". Which did you ask for? And which did you want? ==John ff  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Feb 88 17:17:07 EST Received: from tully.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 14:00:23 PST Received: by tully.Berkeley.EDU (5.57/1.25) id AA10300; Thu, 18 Feb 88 14:01:38 PST From: hilfingr%tully.Berkeley.EDU@ginger.Berkeley.EDU (Paul Hilfinger) Message-Id: <8802182201.AA10300@tully.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: Heat and Howard Trickey Date: Thu, 18 Feb 88 14:01:35 PST Even in the best of times, the night wind blowing in from the San Francisco Bay can get a bit cold at times, and my workstation no longer warms the blood as it used to. What I really need is a good flame raging cheerfully at me from the screen. With this in mind, have y'all seen Howard Trickey's article, "C++ Versus Lisp: A Case Study" in SIGPLAN Notices 23, 2 (Feb. 1988), pp. 9-18? P. Hilfinger  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Feb 88 15:30:55 EST Received: from hecuba.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 88 12:08:05 PST Received: by hecuba.Berkeley.EDU (5.57/1.25) id AA23112; Thu, 18 Feb 88 12:09:19 PST Message-Id: <8802182009.AA23112@hecuba.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: Results of query regarding multiprocessor applications and simulators Date: Thu, 18 Feb 88 12:09:15 PST From: Benjamin Zorn More than a month ago I sent mail to the mailing list requesting information about multiprocessor Lisp implementations, applications, and simulators. Since then I have received mail from a number of sources, and I'd like to summarize the mail I received here. I'll briefly mention the work that's being done, mention a reference to recent publications, and give an e-mail address for people who would like more information. Location: MIT Contact: Robert Halstead, rrh@vx.lcs.mit.edu Hardware: Concert multiprocessor (MIT research machine) Language: Multilisp (described in TOPLAS, Oct. 1985) Applications: a wide variety, ranging from circuit simulation to speech recognition Location: BBN Advanced Computers, Inc. Contact: Seth Steinberg, sas@bfly-vax.bbn.com Hardware: BBN Butterfly Language: Butterfly Lisp, which started as an adaptation of CScheme, but is progressing toward full Common Lisp compatibility (described in AAAI-87). Multiprocessing primitives are quite close to those of Multilisp. Applications: language recognition, object oriented multiprocessor simulation, multiprocessor expert systems. Location: Stanford Knowledge Systems Laboratory Contact: Nakul Saraiya, saraiya@sumex-aim.stanford.edu Simulator: CARE, a parameterizable architectural simulator for multiprocessor systems that is focussed on their communications and scheduling behavior (several recent Stanford tech reports describe various aspects of the system). Language: LAMINA, a basic language interface that allows application code to be written in functional, object-oriented, or shared-variable styles. Applications: two report integration systems (AIRTRAC & ELINT) and a PDE solver. Location: Stanford Contact: Joe Weening, jsw@sail.stanford.edu Hardware: Alliant FX/8 multiprocessor Language: Qlisp, described in the 1984 Lisp Conference Applications: still preliminary, but working on symbolic algebra, proof checking systems, and parallel OPS5. Location: Nasa Ames Contact: Bob Meier, MEIER%PLU@io.arc.nasa.gov Language: Common Lisp with futures (description submitted to 1988 ICPP), implemented on Symbolics and VAX simulators. Applications: multiprocessing expert system shell as part of the Holmes project. Location: UC Berkeley Contact: Benjamin Zorn, zorn@ernie.berkeley.edu Hardware: SPUR multiprocessor workstation (in preparation) Language: SPUR Lisp (Common Lisp + Mailboxes + Processes + futures) (description soon to be available as a UC Berkeley tech report) Applications: limited to small programs due to the absence of actual SPUR hardware. I am aware of other multiprocessor Lisp implementations, most notably ZLisp, the multiprocessor Lisp for the NYU ultracomputer; and *Lisp, Lisp with data level parallelism for the Connection machine. I didn't receive any information about multiprocessor applications on these machines, so I haven't included them in this list. One respondent, Tanaka Tomoyuki, was particularly interested in gathering together a bibliography on parallel lisp systems and applications. In particular, references to tech reports, which do not appear in citation indexes, would be of special interest. If you have lists of any such references, please send them to: name: TANAKA Tomoyuki institution: Tokyo Research Laboratory, IBM Japan e-mail address: tanakat@jpntscvm.bitnet (IBM VNET: TANAKAT at TRLVM1) (Japan junet: tanakat@trla.ibmtrl.junet) I am still interested in hearing about multiprocessor applications, and will post an update to this list as I hear about additional work.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Feb 88 01:45:08 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Feb 88 22:32:42 PST Received: from relay2.cs.net by RELAY.CS.NET id aa10416; 16 Feb 88 1:27 EST Received: from cs.umass.edu by RELAY.CS.NET id ax27248; 16 Feb 88 1:20 EST Date: Mon, 15 Feb 88 15:06 EDT From: ELIOT@cs.umass.edu Subject: Creepy Crawlers in the Package system To: Common-Lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-Lisp@sail.stanford.edu" Some of the comments I have read sound like things people say who spend all of their time *implementing* Lisp and none of their time *using* Lisp. I have been (trying to) write programs using KnowledgeCraft and Kee. You can be pretty sure that I am going to USE-PACKAGE these system's packages. Each of them provides Hundreds of additional functions that might get used. I am a pretty fast typist, but I still don't plan to individually import every symbol that I am going to use. A further problem arose with the GRAPPLE system, which is built on KnowledgeCraft. Its been a year and a half since I was involved in that, but basically the system really wants to have transitively exported symbols. GRAPPLE is supposed to be something that another system (in its package) would be layered on top of. That system would (use-package 'grapple) but it would also have to use all of the KnowldegCraft packages (5 or 6 of them). There might have been some kludge with Grapple writing code that called K.C. functions or whatever. I don't remember exactly why this happened, but the non-transitive nature of packages/exporting was a real pain. I think this is actually the most important situation. When using a large software package there are just too many symbols around to be a purist. Please add my vote to the list of those who think the package system is something the cat dragged in from the storm, but don't really know what to do about it. Chris Eliot  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 18:35:04 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Feb 88 15:20:58 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 344006; Mon 15-Feb-88 18:20:52 EST Date: Mon, 15 Feb 88 18:20 EST From: David A. Moon Subject: Package odor To: mike%acorn@oak.lcs.mit.edu, Dan Hoey , Sandra J Loosemore , Jon L White , RWK@AI.AI.MIT.EDU, Gumby@mcc.com, hilfingr%tully.Berkeley.EDU@UCBVAX.BERKELEY.EDU, CL.BOYER@R20.UTEXAS.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 11 Feb 88 19:26 EST from mike%acorn@oak.lcs.mit.edu, <571677767/hoey@nrl-aic.arpa>, <8802122000.AA14679@orion.utah.edu>, <8802130612.AA13238@bhopal.lucid.com>, <8802150458.AA15077@bhopal.lucid.com> Message-ID: <19880215232057.8.MOON@EUPHRATES.SCRC.Symbolics.COM> In case anyone's been wondering why I, who supposedly know something about packages, haven't said anything in this discussion, it's because this doesn't seem to be any different from the same discussion ten years ago at MIT and five years ago in the Common Lisp working group. Here's the very brief encapsulated wisdom. It was ignored last time, and will probably be ignored this time, but I'll send it out once anyway. Packages are a way of controlling the mapping from names to symbols. If what you're looking for is a way to control the mapping from symbols to objects (and that is what you should be looking for), packages are bound to disappoint you. Packages are useful for what they do, but not for more. Better ideas do exist. The oldest published better idea I know of is in SDC TM-2710/111/00, 7 January 1966 (from the LISP 2 effort, unfortunately stillborn). The only way to use packages that works reliably in the real world is to set up the packages in advance and be very careful about making incremental changes. The way that CLtL encourages you to use packages simply does not work reliably for mere mortals. This is because of the early binding of the mapping of names to symbols by the Lisp reader. You can learn how to use packages effectively by studying how the community that has been using them the longest does it.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Feb 88 01:04:51 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 88 21:46:47 PST Received: by labrea.Stanford.EDU; Sun, 14 Feb 88 21:47:05 PST Received: from bhopal.lucid.com by edsel id AA26152g; Sun, 14 Feb 88 20:53:38 PST Received: by bhopal id AA15077g; Sun, 14 Feb 88 20:58:42 PST Date: Sun, 14 Feb 88 20:58:42 PST From: Jon L White Message-Id: <8802150458.AA15077@bhopal.lucid.com> To: Gumby@mcc.com Cc: common-lisp@sail.Stanford.EDU, hoey@nrl-aic.arpa, mike@live-oak.lcs.mit.edu, hilfingr@ucbvax.berkeley.edu, CL.BOYER@r20.utexas.edu, KMP@stony-brook.scrc.symbolics.com, RWK@ai.ai.mit.edu In-Reply-To: David Vinayak Wallace's message of Sat, 13 Feb 88 01:59 CST <880213015956.2.GUMBY@THOTH.ACA.MCC.COM> Subject: Package Odor [Hi Gumby! long time no see. I'd heard that you were at MCC]. re: Now I think defpackage itself is not even close to the right thing; ... Neither do I. At one time, I thought a defpackage was the answer to package problems, but I've gotten "cold feet" about it after devling into it deeper. The two main thorns I see are: (1) It only works "as advertised" if there are *no* lisp primitives for making changes to the package system [e.g., EXPORT, USE-PACKAGE, etc]. If you have these others, the DEFPACKAGE/SYSTEM is no surety at all; in fact, it would be just one more headache to worry about when a universally-recognized set of conventions-for-winning is established. [consider the questions raised by Sandra Loosemore in her message of Fri, 12 Feb 88 13:00:34 MST]. Ruling out primitives for the user to make updates to packages at runtime seems to me to go very much against the Lisp tradition; sounds more like the constraints of a statically typed langugage. (2) Unlike all other Lisp facilities, this one has to address the issue of how to redefine a global structure. For example, if you have a database file, and along comes a new-kid-on-the-block who says "Here is the contents for that database file", then how do you resolve the current contents, which many clients have already used and "cached"? Do you flush the current contents entirely? Do you try to "unify" the current and redefining contents, signalling errors if there is an unresolvable request? Currently, CL definers fall into three categories: (i) Those like DEFUN which only update some slot of a symbol; they do not attempt to merge the actions of the old function found in that cell with the new definition. Lisp is well-accustomed to the dynamic update of symbol slots; and some implementations give you warnings when you do redefine. (ii) Those like MAKE-PACKAGE which signal an error on any attempt to redefine the name-to-package mapping [a global database] (iii) Those like DEFTYPE and DEFSTRUCT which simply displace the former definitions [the global database involved here is the implementation-dependent one for type descriptors and defstruct descriptors]. The CLOS specification tries to describe a "unification" algorithm for class redefinition [i.e., which old methods to throw out and which to retain, etc]. But I think such a think for packages is overly complicated and prone to unforseen consequences, especially since it doesn't really solve the "package problem". I don't have an idea right now of just how many constraints are necessary to fix the "package problem", but there certainly is room for disucssion. For example, I might not want to accept the restriction that Mike Beckerle proposed -- no user use of USE-PACKAGE -- even though his notion of a style guide and better compiler specification looked good. There must be other reasonable alternatives that don't sacrifice the inheritable nature of CL's packages. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 19:58:59 EST Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:46:27 PST Date: 13 Feb 1988 19:31-EST From: Jamie.Zawinski@spice.cs.cmu.edu (The Masked Avenger) To: mike%acorn@oak.lcs.mit.edu Cc: common-lisp@SAIL.STANFORD.EDU Subject: Re: {Improved version} EXPORT-IMPORT and the other random commands > My experience is that noone wants to qualify any names so what > they do is carefully use every package that they've ever seen, > not realizing that > > (let ((string "abcd")) > ....) > > in their code is creating a spec-bind because they are using a package > where string is a special. > > nuff said. Not quite enough; I'd say that the blame for this particular lossage falls squarely on the author of the USEd package, not on the person USEing it. Anyone who would proclaim STRING special is a complete bogon. If it's a global special variable, it should have *'s around it. If it's a constant, it should either a) have a name less likely to break the entire world, or b) be SHADOWed and not be EXPORTed. If someone really wanted to have a global special or a constant called STRING, (ick) then SHADOWing the symbol would solve (or at least make clearer) the problem. If STRING was SHADOWed in the FOO package, and also EXPORTed from FOO, and BAR tried to USE FOO, an error would be signalled, because BAR was trying to inherit both FOO:STRING and LISP:STRING. I'm not at all sure what the "right" way to deal with packages is, but I find that life is much easier if package-related activities are kept to a minimum. If you have one package per application, then there are few problems. It's when you try to interface your application with someone else's that you get screwed. Jamie  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Feb 88 01:34:27 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 22:20:29 PST Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 22:20:52 PST Received: from bhopal.lucid.com by edsel id AA19448g; Fri, 12 Feb 88 22:07:39 PST Received: by bhopal id AA13238g; Fri, 12 Feb 88 22:12:35 PST Date: Fri, 12 Feb 88 22:12:35 PST From: Jon L White Message-Id: <8802130612.AA13238@bhopal.lucid.com> To: hoey@nrl-aic.arpa Cc: common-lisp@sail.Stanford.EDU, mike@live-oak.lcs.mit.edu, RWK@ai.ai.mit.edu, hilfingr@ucbvax.berkeley.edu, CL.BOYER@r20.utexas.edu, KMP@stony-brook.scrc.symbolics.com In-Reply-To: Dan Hoey's message of 12 Feb 1988 10:22:34 EST (Fri) <571677767/hoey@nrl-aic.arpa> Subject: Package Odor re: . . . You should know the names of all the symbols you import (including all the symbols exported from packages you use), not only so you don't get surprised about them being special, but so you don't accidentally make them special when they shouldn't be. What the package system buys you is letting this not be all the symbols in the world. Very astute observation! I believe there's been a proposal to the cleanup committee which would declare it to be "an error" for someone to redefine a function in the LISP package. But Common Lisp doesn't even make it "an error" to put all sorts of garbage into the LISP package (which everybody *has* to use) and proclaim it INLINE and SPECIAL and all that jazz. This problem is at once both the beauty of Lisp and its greatest weakness. LISP has endured all these years because it is an "open system"; user code -- in a very non-lexical way -- can muck around with the internals of: Parsing [reader macros] Compiling [ordinary macros, eval-when computations] Loading [few, if any constraints, on cross-package reference] Running [*print-base*, special variables, dynamic fn redefinition] Interpretation [ordinary macros, STEP, DEFADVICE, etc] So it sounds like there is a need for listing all the assumptions that keep a Common Lisp program sound -- What functions *should* not be redefined What variables (and fns) *should* not be proclaimed in any way What types shouldn't be overridden What defstructs shouldn't be incompatibly redefined What defstructs shouldn't be extended (via :include) What package machinations should not be done [e.g., Puting random external symbols in the LISP pacakge; Putting symbols "owned" by other packages into KEYWORD; EXPORTing symbols after a file using them has been compiled.] . . . ?? The goal is not to make Lisp a strongly-typed language, or any other "fascist beast", but to promulgate style guidelines which would enable cooperating programs not to trash one another. I believe that a reasonable set of such guidlines could be made for the existing Common Lisp systems. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 88 15:14:12 EST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Feb 88 12:00:56 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA22827; Fri, 12 Feb 88 13:00:41 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA14679; Fri, 12 Feb 88 13:00:37 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8802122000.AA14679@orion.utah.edu> Date: Fri, 12 Feb 88 13:00:34 MST Subject: defpackage To: common-lisp@sail.stanford.edu While I would like to see a single DEFPACKAGE construct replace the seven random forms, there are some problems with the order in which things happen. Namely, since the reader would normally read the entire DEFPACKAGE form before actually doing any of the actions it specifies, how do you specify symbols that are to be imported or exported when their home packages have not been created yet (perhaps because these packages would be created during evaluation of the "require" part of the DEFPACKAGE)? Although I don't recall that CLtL actually says anything explicit on this point, in most implementations the reader will signal an error if it sees an unknown package prefix on a symbol. The best way to deal with packages that I have found so far is to use a small DEFSYSTEM utility, and to put all the stuff to set up the package environment for the system (including loading in of other systems that create packages it references) at the beginning of the file that contains the system definition. -Sandra -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Feb 88 11:29:34 EST Received: from nrl-aic.arpa by SAIL.Stanford.EDU with TCP; 12 Feb 88 08:13:30 PST Return-Path: Received: Fri, 12 Feb 88 11:11:02 EST by nrl-aic.arpa id AA02816 Date: 12 Feb 1988 10:22:34 EST (Fri) From: Dan Hoey Subject: Package Odor Message-Id: <571677767/hoey@nrl-aic.arpa> To: mike%acorn@live-oak.lcs.mit.edu Cc: RWK@AI.AI.MIT.EDU, hilfingr%tully.Berkeley.EDU@UCBVAX.BERKELEY.EDU, common-lisp@SAIL.STANFORD.EDU, CL.BOYER@R20.UTEXAS.EDU, edsel!jonl@LABREA.STANFORD.EDU, labrea!CL-Cleanup%SAIL@LABREA.STANFORD.EDU, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@LABREA.STANFORD.EDU Date: Thu, 11 Feb 88 19:26 est From: mike%acorn@oak.lcs.mit.edu ...My experience is that no one wants to qualify any names so what they do is carefully use every package that they've ever seen, not realizing that (let ((string "abcd")) ....) in their code is creating a spec-bind because they are using a package where string is a special.... Note that this is not *quite* the problem, since STRING is a symbol in the LISP package, and anyone who is using random packages must surely use LISP. In that case it is the error of the other package in proclaiming a symbol of the LISP package SPECIAL (or CONSTANT), and you couldn't defend against the error by not using that package. That this is an error should be made explicit--I once broke the compiler by proclaiming LISP:FUNCTION constant, and the compiler wanted to bind it in a macroexpansion. Making it SPECIAL might have screwed things up beyond hope of diagnosis. The problem of using every package is still there, though. You should know the names of all the symbols you import (including all the symbols exported from packages you use), not only so you don't get surprised about them being special, but so you don't accidentally make them special when they shouldn't be. What the package system buys you is letting this not be all the symbols in the world. Dan  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Feb 88 19:54:01 EST Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 16:35:18 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 Feb 88 19:28-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 80142; 11 Feb 88 19:27:38-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 93873; Wed 10-Feb-88 16:25:21-EST Date: Thu, 11 Feb 88 19:26 est From: mike%acorn@oak.lcs.mit.edu To: RWK@AI.AI.MIT.EDU Subject: {Improved version} EXPORT-IMPORT and the other random commands Cc: hilfingr%tully.Berkeley.EDU@UCBVAX.BERKELEY.EDU, common-lisp@SAIL.STANFORD.EDU, CL.BOYER@R20.UTEXAS.EDU, edsel!jonl@LABREA.STANFORD.EDU, labrea!CL-Cleanup%SAIL@LABREA.STANFORD.EDU, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@LABREA.STANFORD.EDU I'm also interested in seeing the "package problem" cleared up. I have two questions. 1) Has anyone written a definitive "why CL packages stink" article or message, preferably one that someone regards as definitive? I don't think there's complete agreement on all the reasons why "CL packages stink". Personally, in fact, I think they're not bad, in use, but the setup is what stinks. Others would disagree. I concur that they're ok, and even necessary for a symbolic language. The problem I feel is that they are good for preventing "symbol" mixups, but not "modularization". E.G., suppose you have a symbolic differentiator, and so do I, and we don't want my dx/ds symbol to be confused with your dx/ds symbol lest they not be able to work together on an expression being differentiated. Unfortunately, what packages are mostly used for is for some notion of "modules" or "subsystems". (I agree that in lisp systems which cons up expressions and eval or compile them that there is little difference between these two scenarios, and we have to allow for them, but most systems just don't do that kind of thing.) This is why I think the notion of LOCALE's from scheme or T or whatever keeps cropping up. My belief is that all "environment" (as opposed to package or "obarray") based approaches to solving name conflict problems are really designed to solve the problems of "modules" or "subsystems" for software engineering. This is a different problem from what packages can really solve. But I think there's pretty good agreement that the seven extremely perverse functions are perverse. The last thing I saw on the subject which was under consideration by the x3j13 compiler committee was a proposal to treat the "seven" specially as a compiled file header. This is more than just implicitly evaling them at compile time. Basically, this would clean up the issue of what "side effects" these have at compile time vs. load time of the compiled file. It would also bless specifically the notion of a file-format for common lisp programs, thereby making it clearly a lose to put IN-PACKAGE calls in the middle of files, etc. This has not been firmed up yet. What I think is needed is really a STYLE GUIDE to common lisp. Something that says how you OUGHT to program to avoid the majority of problems with things like the package system, etc. I think most package problems come from misuse. For instance, I would recommend that people be encouraged to avoid USE-PACKAGE other than for package LISP, and instead enumerate symbols one by one using the other package functions. My experience is that noone wants to qualify any names so what they do is carefully use every package that they've ever seen, not realizing that (let ((string "abcd")) ....) in their code is creating a spec-bind because they are using a package where string is a special. nuff said. ...mike beckerle  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Feb 88 04:30:57 EST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 11 Feb 88 01:20:27 PST Received: from relay2.cs.net by RELAY.CS.NET id aa05600; 11 Feb 88 3:06 EST Received: from ntt.jp by RELAY.CS.NET id aa11172; 11 Feb 88 2:57 EST Received: by ntt.jp (3.2/NTT6.2cs) with TCP; Thu, 11 Feb 88 16:32:41 JST Date: Thu, 11 Feb 88 16:32:41 JST From: Kyoji Umemura To: common-lisp@SAIL.STANFORD.EDU Cc: umemura@ntt.jp Subject: Please change my address Please change my address from comlisp%nttlab%nttca@Shasta to comlisp%nttlab.ntt.jp@relay.cs.net. Thank you.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 12:00:42 EST Received: from ari-hq1.arpa by SAIL.Stanford.EDU with TCP; 7 Feb 88 08:49:17 PST Date: 5 Feb 88 09:36:00 EST From: "ARTIC::HOBBS" Subject: REQUEST FOR CHANGE IN DISTRIBUTION To: "common-lisp" cc: hobbs Reply-To: "ARTIC::HOBBS" Dear Moderator: I would like to request a change on your distribution list for your Common-Lisp mailings. In an effort to conserve disk space and keep the traffic on the DDN as low as possible, we want to handle the distribution from one central account at our site. We have established the account ARI_LISP for this reason. Please add the following name to your distribution list for Common-Lisp information: ARI_LISP@ARI-HQ1.ARPA and please remove the following user from the distribution list: WILLIAMS@ARI-HQ1.ARPA. If you have any questions, please contact me through the DDN as HOBBS@ARI-HQ1.ARPA or you may call me at 703-751-7993. Thank You. Reginald L. Hobbs Technical Liason for ARI-HQ1.ARPA ------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 07:18:16 EST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 04:04:20 PST Date: Sun, 7 Feb 88 07:04:36 EST From: "Robert W. Kerns" Subject: {Improved version} EXPORT-IMPORT and the other random commands To: hilfingr%tully.Berkeley.EDU@UCBVAX.BERKELEY.EDU cc: common-lisp@SAIL.STANFORD.EDU, CL.BOYER@R20.UTEXAS.EDU, edsel!jonl@LABREA.STANFORD.EDU, labrea!CL-Cleanup%SAIL@LABREA.STANFORD.EDU, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@LABREA.STANFORD.EDU In-reply-to: Msg of Sun 07 Feb 88 00:15:12 PST from hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger) Message-ID: <322657.880207.RWK@AI.AI.MIT.EDU> Date: Sun, 07 Feb 88 00:15:12 PST From: hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger) I'm also interested in seeing the "package problem" cleared up. I have two questions. 1) Has anyone written a definitive "why CL packages stink" article or message, preferably one that someone regards as definitive? I don't think there's complete agreement on all the reasons why "CL packages stink". Personally, in fact, I think they're not bad, in use, but the setup is what stinks. Others would disagree. But I think there's pretty good agreement that the seven extremely perverse functions are perverse. 2) You write > ... The underlying idea that you define the package environment > by performing a series of side-effects on the package system > is so wrong it is beyond repair. It is so entirely sensitive > to complex and obscure order-of-events issues that even if > you were successful in getting all implementations to do > exactly the same thing, real-life users could not adaquately > standardize their workstyles and interactions to avoid > problems, even if they could understand all the rules! > > I think the time would be better spent on specifying and > adopting a DEFPACKAGE macro. This would always be the first > form of the first file loaded. (Or at least, before any > IN-PACKAGE's for that package).... Are you saying that this DEFPACKAGE macro would NOT have any side-effects on the package system? How would it have its effect? Or, more generally, what is the underlying idea with which you want to replace "side-effects on the package system"? No, the important word up there was "series". There's no problem with a single declarative form, at the very start. It's when you dribble things out over several files with a series of "functions" which have to be treated specially by the compiler, that you start running into problems. Not to mention the confusion factor. The very fact that this silly mnemonic (which I can never remember) is needed to keep the order straight should be a dead givaway that something is wrong with splitting up declaring the package into a series of micro-steps. You might think of these as "package microcode". It shouldn't be supprising that there are dependencies on the particular way an implementation does its environment. If you declare imports, exports, inheritences, etc. at the same time you CREATE the package, you can't have any problems with symbols accidentally getting created before things are set up right. (Just for one example). (Somehow, electronic mail adds an unwonted note of harshness to my syntax; that last question was meant to be straight, not rhetorical.) I know the problem. You'll notice I sent an improved version of my note, when I noticed it sounded like I was being critical of Bob Boyer's complaint. (Instead of urging a different approach to solving it). Paul Hilfinger U. C. Berkeley Hilfinger@Berkeley.EDU  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Feb 88 03:29:44 EST Received: from tully.Berkeley.EDU ([128.32.150.44]) by SAIL.Stanford.EDU with TCP; 7 Feb 88 00:15:34 PST Received: by tully.Berkeley.EDU (5.57/1.25) id AA07693; Sun, 7 Feb 88 00:15:20 PST From: hilfingr%tully.Berkeley.EDU@berkeley.edu (Paul Hilfinger) Message-Id: <8802070815.AA07693@tully.Berkeley.EDU> To: "Robert W. Kerns" Cc: CL.BOYER@r20.utexas.edu, common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Subject: Re: {Improved version} EXPORT-IMPORT and the other random commands In-Reply-To: Your message of Fri, 05 Feb 88 23:56:53 EST. <322178.880205.RWK@AI.AI.MIT.EDU> Date: Sun, 07 Feb 88 00:15:12 PST I'm also interested in seeing the "package problem" cleared up. I have two questions. 1) Has anyone written a definitive "why CL packages stink" article or message, preferably one that someone regards as definitive? 2) You write > ... The underlying idea that you define the package environment > by performing a series of side-effects on the package system > is so wrong it is beyond repair. It is so entirely sensitive > to complex and obscure order-of-events issues that even if > you were successful in getting all implementations to do > exactly the same thing, real-life users could not adaquately > standardize their workstyles and interactions to avoid > problems, even if they could understand all the rules! > > I think the time would be better spent on specifying and > adopting a DEFPACKAGE macro. This would always be the first > form of the first file loaded. (Or at least, before any > IN-PACKAGE's for that package).... Are you saying that this DEFPACKAGE macro would NOT have any side-effects on the package system? How would it have its effect? Or, more generally, what is the underlying idea with which you want to replace "side-effects on the package system"? (Somehow, electronic mail adds an unwonted note of harshness to my syntax; that last question was meant to be straight, not rhetorical.) Paul Hilfinger U. C. Berkeley Hilfinger@Berkeley.EDU  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 88 00:10:46 EST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 20:55:10 PST Date: Fri, 5 Feb 88 23:56:53 EST From: "Robert W. Kerns" Subject: {Improved version} EXPORT-IMPORT and the other random commands To: CL.BOYER@R20.UTEXAS.EDU cc: common-lisp@SAIL.STANFORD.EDU, edsel!jonl@LABREA.STANFORD.EDU, labrea!CL-Cleanup%SAIL@LABREA.STANFORD.EDU, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@LABREA.STANFORD.EDU Message-ID: <322178.880205.RWK@AI.AI.MIT.EDU> Date: Wed 3 Feb 88 21:48:23-CST From: Bob Boyer I think that the "Put in seven extremely random user commands" stuff needs to be documented much more rigorously. I don't think that any collection of cross-references in CLTL will suffice to make things clear. You've identified an important issue, *BUT*: Frankly, I think this approach would be a waste of time. I don't think ANY amount of documenting and test suites has any chance of working. The underlying idea that you define the package environment by performing a series of side-effects on the package system is so wrong it is beyond repair. It is so entirely sensitive to complex and obscure order-of-events issues that even if you were successful in getting all implementations to do exactly the same thing, real-life users could not adaquately standardize their workstyles and interactions to avoid problems, even if they could understand all the rules! I think the time would be better spent on specifying and adopting a DEFPACKAGE macro. This would always be the first form of the first file loaded. (Or at least, before any IN-PACKAGE's for that package). I think it is much easier to specify the behaviour when you don't have to consider all the order-of-operations issues. Of course, it still needs to be carefully specified, but the problem is more constrained, and you're not so burdened with issues of compatibilty or programing environment issues. There are quite a number of us who think the DEFPACKAGE issue is important, but so far as I know there aren't any actual proposals being written up. Presumably the issue is one of manpower to address it, not of lack of interest, so I would be dissapointed to see us discuss ways of "fixing" this rather bleak area of CL, rather than working on DEFPACKAGE.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Feb 88 00:04:53 EST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 20:51:47 PST Date: Fri, 5 Feb 88 23:53:29 EST From: "Robert W. Kerns" Subject: EXPORT-IMPORT and the other random commands To: CL.BOYER@R20.UTEXAS.EDU cc: common-lisp@SAIL.STANFORD.EDU, edsel!jonl@LABREA.STANFORD.EDU, labrea!CL-Cleanup%SAIL@LABREA.STANFORD.EDU, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@LABREA.STANFORD.EDU In-reply-to: Msg of Wed 3 Feb 88 21:48:23-CST from Bob Boyer Message-ID: <322177.880205.RWK@AI.AI.MIT.EDU> Date: Wed 3 Feb 88 21:48:23-CST From: Bob Boyer I think that the "Put in seven extremely random user commands" stuff needs to be documented much more rigorously. I don't think that any collection of cross-references in CLTL will suffice to make things clear. Frankly, I think this would be a waste of time. I don't think ANY amount of documenting and test suites has any chance of working. The underlying idea that you define the package environment by performing a series of side-effects on the package system is so wrong it is beyond repair. It is so entirely sensitive to complex and obscure order-of-events issues that even if you were successful in getting all implementations to do exactly the same thing, real-life users could not adaquately standardize their workstyles and interactions to avoid problems, even if they could understand all the rules! I think the time would be better spent on specifying and adopting a DEFPACKAGE macro. This would always be the first form of the first file loaded. (Or at least, before any IN-PACKAGE's for that package). I think it is much easier to specify the behaviour when you don't have to consider all the order-of-operations issues. Of course, it still needs to be carefully specified, but the problem is more constrained, and you're not so burdened with issues of compatibilty or programing environment issues. There are quite a number of us who think the DEFPACKAGE issue is important, but so far as I know there aren't any actual proposals being written up.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 23:04:22 EST Received: from R20.UTEXAS.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 19:49:34 PST Date: Wed 3 Feb 88 21:48:23-CST From: Bob Boyer Subject: EXPORT-IMPORT and the other random commands To: edsel!jonl@LABREA.STANFORD.EDU cc: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@LABREA.STANFORD.EDU, labrea!CL-Cleanup%SAIL@LABREA.STANFORD.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8802040147.AA12513@bhopal.lucid.com> Message-ID: <12371927656.13.CL.BOYER@R20.UTEXAS.EDU> I think that the "Put in seven extremely random user commands" stuff needs to be documented much more rigorously. I don't think that any collection of cross-references in CLTL will suffice to make things clear. I am no authority on Common Lisp, but I have tried my best to use packages and modules according to the rules I have read and according to the implementations of the half dozen Common Lisps I could get my hands on. I have failed, badly, and given up on the PISERUC for the time being, pending clarification and convergence on implementations. I stay in package USER and don't use modules; it's rude, but it seems more portable than the alternatives. I think that it would be wonderful to have a test collection of about a dozen short files that create and use about a dozen packages, all importing and exporting from one another, with a half dozen modules, some requiring others, all of which interacted with compilers and loaders and Lisp machine editors and ran under the available major Common Lisp implementations. I do not currently believe in the existence of such a collection of files and operations, one which is consistent with every reasonable reading of the PISERUC rules. I believe that someone's implementation will break under the loading/compiling/using/requiring/editing sequence no matter how you write such a set of files. Whoever's implementation breaks will probably have a good argument justifying their implementation, citing chapter and verse from CLTL. If an example collection of files could be agreed upon it would, of course, still only be a start, and no substitute for regular documentation, but it might start convergence between implementations. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Feb 88 22:03:34 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:44:20 PST Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 18:44:35 PST Received: from bhopal.lucid.com by edsel id AA03683g; Wed, 3 Feb 88 17:43:28 PST Received: by bhopal id AA12513g; Wed, 3 Feb 88 17:47:47 PST Date: Wed, 3 Feb 88 17:47:47 PST From: Jon L White Message-Id: <8802040147.AA12513@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU, labrea!common-lisp%sail@labrea.Stanford.EDU In-Reply-To: Kent M Pitman's message of Wed, 3 Feb 88 11:34 EST <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT The reason why some users may be mislead about EXPORT is that they fail to heed the directive on the second line of p186: "See section 11.4 for details". The one paragraph description of EXPORT on p186 is grossly incomplete without reference to that other section, which cleary states: (p177, last paragraph) "The function EXPORT takes a symbol that is *accessible* in some specified package ... If the symbols is not accessible at all in the specified package, a correctable error is signalled that, upon continuing, asks the user whether the symbol should be imported." [my emphasis]. Every implementation I'm familiar with seems to implement the above semantics rigidly; no one quietly imports the symbol without first signalling an error. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Feb 88 12:26:14 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 88 09:13:00 PST Received: by labrea.Stanford.EDU; Mon, 1 Feb 88 09:07:38 PST Received: from bhopal.lucid.com by edsel id AA11335g; Mon, 1 Feb 88 07:19:05 PST Received: by bhopal id AA05000g; Mon, 1 Feb 88 07:23:13 PST Date: Mon, 1 Feb 88 07:23:13 PST From: Jon L White Message-Id: <8802011523.AA05000@bhopal.lucid.com> To: labrea!hilfingr%berkeley.edu@labrea.Stanford.EDU Cc: labrea!common-lisp%sail@labrea.Stanford.EDU In-Reply-To: Paul Hilfinger's message of Sun, 31 Jan 88 14:42:15 PST <8801312242.AA29857@tully.Berkeley.EDU> Subject: LEAST-POSITIVE--FLOAT re: [in the Ada Standard ] . . . Indeed, as far as denormalized numbers are concerned, the interpretation of some of the constants is still under discussion. ... [denormalized numbers] are tolerated, but nothing specifically is said about them. Thanks for your warnings about the continuing ferment in the ADA community on related matters. The issue, here, is the "unexpected dividends" obtained when trapping is turned on -- that LEAST-POSITIVE--FLOAT may be subject to different interpretations depending on whether producing it is a normal or an exceptional condition. Does ADA specify these kinds of constants? No issue of confusion arises in Common Lisp, as far as I know, with the other elective traps (such as the inexact trap). re: . . . I get a bit nervous seeing arguments based on what a particular piece of hardware does. IEEE arithmetic is a user interface standard, and says nothing of the division of labor between chip and interface software. I don't think the arguments arise from any peculiarites of one chip or another; it was just that some Common Lisp implementations defaultly had trapping turned off, and thus no one had observed the dilemma. The IEEE Standard provides for reasonable behaviour when a particular trap is not enabled. What really my quest hoped to get at was "Just what value are these constants to Common Lisp users anyway?". Who, if anyone, would be affected if their values were changed from one state to the other? Could a user profit from the existence of two defined constants, one normalized and the other possibly denormalized (as Symbolics has recently done)? As long as this kind of value is specified by the language standard (CLtL, in this case), test suites will have a "need" for them; but beyond that, I just don't know. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Jan 88 17:55:05 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 88 14:42:04 PST Received: from tully.Berkeley.EDU by labrea.Stanford.EDU with TCP; Sun, 31 Jan 88 14:41:49 PST Received: by tully.Berkeley.EDU (5.57/1.25) id AA29857; Sun, 31 Jan 88 14:42:18 PST From: hilfingr%tully.Berkeley.EDU@berkeley.edu (Paul Hilfinger) Message-Id: <8801312242.AA29857@tully.Berkeley.EDU> To: Jon L White Cc: labrea!Cassels%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu, labrea!common-lisp%sail@labrea.stanford.edu Subject: Re: LEAST-POSITIVE--FLOAT In-Reply-To: Your message of Tue, 26 Jan 88 06:13:27 PST. <8801261413.AA19193@bhopal.lucid.com> Date: Sun, 31 Jan 88 14:42:15 PST > Bob Mathis has some knowledge of how this issue was resolved in the ADA > world. How about it Bob? any clues? Having participated in most of the language reviews and maintenance of Ada, I think I can make a definitive statement on this question. Do NOT, under any circumstances, look to the Ada Standard for hints on how to handle floating point arithmetic. The Standard was an attempt to define a semantics that conformed to all existing hardware. As a result, the properties one can deduce from the Ada semantics about real arithmetic---in particular, about constants defined by the language---are extremely weak and nearly useless. Indeed, as far as denormalized numbers are concerned, the interpretation of some of the constants is still under discussion. Denormalized numbers fall into the crack in the semantics that includes "everything that isn't a model number," which means numbers with more precision than required by the model, infinities, and NaNs. As a result, they are tolerated, but nothing specifically is said about them. As for the interpretation of LEAST-POSITIVE--FLOAT, it seems to me that the POSSIBILITY of traps is a red herring. IEEE arithmetic also provides for a trap on an inexact result; there are cases where it is interesting to know that such a result has been produced. Does the fact that such a trap MIGHT be enabled raise questions about whether (/ 1.0 3.0) must have a defined result in the case where the trap is not enabled? If we look at the underflow trap the same way--- as indicating places in which precision is lost for a particular reason that is sometimes but not always of interest---it seems that we should consider the least denormalized numbers as the appropriate values for LEAST-POSITIVE-etc. As a (perhaps unnecessary) aside, I get a bit nervous seeing arguments based on what a particular piece of hardware does. IEEE arithmetic is a user interface standard, and says nothing of the division of labor between chip and interface software. A piece of "IEEE floating-point hardware" is entitled, for example, to produce traps at places not mandated by the standard, as long as the accompanying support software fills in the semantics required by the standard. Paul Hilfinger UC Berkeley Hilfinger@Berkeley.EDU  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 15:26:39 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Jan 88 12:10:48 PST Return-Path: Received: from kali.think.com by Think.COM; Thu, 28 Jan 88 15:10:37 EST Received: by kali.think.com; Thu, 28 Jan 88 15:10:32 EST Date: Thu, 28 Jan 88 15:10:32 EST From: gls@Think.COM Message-Id: <8801282010.AA10925@kali.think.com> To: common-lisp@sail.stanford.edu Subject: [king@kestrel.arpa: commonlisp errors] Date: Thu, 28 Jan 88 08:58:19 PDT From: king@kestrel.arpa (Dick King) To: steele@Think.COM Subject: commonlisp errors I was the one who suggested lexically scoped errors, and ability to obtain an error environment as a storable object with limited lifetime, for commonlisp's nascent error system. You suggested a place to send it that was concerned with commonlisp errors; i got nary a reply. I am writing this note to ask for more suggestions; perhaps it should go to the current Keepers of CommonLisp [which certainly must include you, or at least youknow who they are] rather than a subcommittee that may be empty or otherwise not communicating. Thanks... -dk  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 13:37:55 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 10:24:54 PST Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU) by labrea.Stanford.EDU with TCP; Thu, 28 Jan 88 10:22:40 PST Date: Thu, 28 Jan 1988 13:07 EST Message-Id: From: STEVER%OZ.AI.MIT.EDU@xx.lcs.mit.edu To: Jon L White Cc: labrea!common-lisp%SAIL@labrea.stanford.edu, labrea!DCP%QUABBIN.SCRC.Symbolics.COM@labrea.stanford.edu Subject: , and # In-Reply-To: Msg of 28 Jan 1988 07:21-EST from Jon L White  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 12:53:56 EST Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by SAIL.Stanford.EDU with TCP; 28 Jan 88 08:28:31 PST Received: from TIGGER.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 159784; Thu 28-Jan-88 10:51:50 EST Date: Thu, 28 Jan 88 10:51 EST From: P. T. Withington Subject: , and # To: David C. Plummer , common-lisp@SAIL.STANFORD.EDU In-Reply-To: <19880127162452.0.DCP@SWAN.SCRC.Symbolics.COM> Message-ID: <19880128155138.6.PTW@TIGGER.S4CC.Symbolics.COM> Date: Wed, 27 Jan 88 11:24 EST From: David C. Plummer I'm wondering (see CLtL page 351) why , is a terminating macro character, while # is a non-terminating macro character? I've recently wanted to write function with names like convert-foo,bar,baz-and-quux-to-mumble Was this a historical accident or was it intentional? Should we try to change it for the next CLtL? That would invalidate the cliche `(foo .,bar), which I have seen occaisionally.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jan 88 12:51:56 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 04:24:28 PST Received: by labrea.Stanford.EDU; Thu, 28 Jan 88 04:24:39 PST Received: from bhopal.lucid.com by edsel id AA23856g; Thu, 28 Jan 88 04:17:45 PST Received: by bhopal id AA03491g; Thu, 28 Jan 88 04:21:36 PST Date: Thu, 28 Jan 88 04:21:36 PST From: Jon L White Message-Id: <8801281221.AA03491@bhopal.lucid.com> To: labrea!DCP%QUABBIN.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!common-lisp%SAIL@labrea.Stanford.EDU In-Reply-To: David C. Plummer's message of Wed, 27 Jan 88 11:24 EST <19880127162452.0.DCP@SWAN.SCRC.Symbolics.COM> Subject: , and # Lisps of the vintage of Lisp 1.5 used comma interchangably with space. Perhaps this is the historical accident that makes it seem more like a separator character than a constituent. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jan 88 11:57:46 EST Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jan 88 08:45:43 PST Received: from SWAN.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198288; Wed 27-Jan-88 11:25:43 EST Date: Wed, 27 Jan 88 11:24 EST From: David C. Plummer Subject: , and # To: common-lisp@SAIL.STANFORD.EDU Message-ID: <19880127162452.0.DCP@SWAN.SCRC.Symbolics.COM> I'm wondering (see CLtL page 351) why , is a terminating macro character, while # is a non-terminating macro character? I've recently wanted to write function with names like convert-foo,bar,baz-and-quux-to-mumble Was this a historical accident or was it intentional? Should we try to change it for the next CLtL?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 22:35:00 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 19:23:59 PST Received: from reagan.ai.mit.edu by labrea.Stanford.EDU with TCP; Tue, 26 Jan 88 19:23:57 PST Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 88656; Tue 26-Jan-88 22:23:58 EST Date: Tue, 26 Jan 88 22:23 EST From: Robert W. Kerns Subject: type declarations of special bindings To: edsel!jonl@labrea.stanford.edu Cc: gz@spt.entity.com, labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: <8801230918.AA05388@bhopal.lucid.com> Message-Id: <880126222354.4.RWK@JONES.AI.MIT.EDU> Date: Sat, 23 Jan 88 01:18:23 PST From: Jon L White re: In the following example, does the fixnum declaration apply to the inner reference to X (in the setq)? (let ((X 17)) (declare (special X) (fixnum X)) (let ((X 'local)) (locally (declare (special X)) (setq X (foo))))) CLtL, p 158 says that type declarations affect the binding "and specifies that the variable[s] mentioned will take on values only of the specified type". The inner reference is to the variable bound specially, not to the one bound locally, so it is the same variable whose binding was declared fixnum. Hence, in theory, it should be as if the form (setq X (foo)) were written as (setq X (the fixnum (foo))) but I suspect very few, if any, compilers actually make this leap of type inferencing. -- JonL -- I agree with your interpretation. I don't think it's much of a leap of inferencing, at least not for any way that I would think to write a compiler. Most compilers create some sort of "VAR" structure where information about a variable is stored. After all, code generation has to make exactly the same leap of inferencing, to figure out just where to get the variable *from*. But I have no comment as to whether existing compilers actually do or do not (as you suggest) actually do anything with this. My point is just that it isn't a burden for any well-designed compiler. Note that there's no actual obligation that the compiler generate code to enforce it; there's just an obligation that the user not write code which violates it. (I don't see any way a compiler could handle this in an *illegal* way.)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 21:19:44 EST Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 18:07:30 PST Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 88650; Tue 26-Jan-88 21:06:09 EST Date: Tue, 26 Jan 88 21:06 EST From: Robert W. Kerns Subject: Re: Type specifiers in THE constructs To: quiroz@cs.rochester.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <8801232012.AA04860@lesath.cs.rochester.edu> Message-ID: <880126210604.3.RWK@JONES.AI.MIT.EDU> Date: Sat, 23 Jan 88 15:12:31 -0500 From: quiroz@cs.rochester.edu Is there agreement that only aware callers need to know about multiple values? I have the impression that many decisions already in the language point to the desire to avoid burdening an unaware caller. ... So, I would say that (THE NUMBER (TRUNCATE 10 3)) should be legal (should even continue returning the multiple values), but should be read as constraining only the first of the returned values to be NUMBERP. I concur, and for exactly the reasons you give. It is also least likely to cause problems for existing usages.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jan 88 09:38:36 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 88 06:27:40 PST Received: by labrea.Stanford.EDU; Tue, 26 Jan 88 06:27:54 PST Received: from bhopal.lucid.com by edsel id AA11820g; Tue, 26 Jan 88 06:09:43 PST Received: by bhopal id AA19193g; Tue, 26 Jan 88 06:13:27 PST Date: Tue, 26 Jan 88 06:13:27 PST From: Jon L White Message-Id: <8801261413.AA19193@bhopal.lucid.com> To: labrea!Cassels%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!common-lisp%sail@labrea.Stanford.EDU In-Reply-To: Robert A. Cassels's message of Mon, 25 Jan 88 09:38 EST <19880125143853.4.CASSELS@KRYPTON.SCRC.Symbolics.COM> Subject: LEAST-POSITIVE--FLOAT re: It's a little more complicated (as if we needed that :-). IEEE underflow traps don't happen for addition or subtraction, just for multiplication and division. . . . What kind of hardware device are you describing? The MC68881 will always give you the traps you enable, regardless of the operation. [In fact, the present query was prompted by our noticeing that the underflow traps occur when a denormalized result is produced -- not merely when the number is too small to be represented at all]. Maybe you are overlooking the fact that adding one normalized number and one unnormalized one isn't by itself trappable -- only if the result is subsequently denormalized will the trap occur. re: Oh, yeah. In answer to your original question, we don't care or use them for anything. But a customer complained, so we changed to conform to the letter of CLtL. Could you find out how "independent" that customer complaint is? I know that at least one other Common Lisp product changed its view on this matter solely because Lucid's test suite complained about it. It would be "no information" if the customer who complained to Symbolics did so only because he found a different resolution of the problem in Lucid Common lisp. Bob Mathis has some knowledge of how this issue was resolved in the ADA world. How about it Bob? any clues? -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jan 88 17:23:04 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 88 14:08:14 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by labrea.Stanford.EDU with TCP; Mon, 25 Jan 88 13:31:54 PST Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 327496; Mon 25-Jan-88 09:38:59 EST Date: Mon, 25 Jan 88 09:38 EST From: Robert A. Cassels Subject: LEAST-POSITIVE--FLOAT To: edsel!jonl@labrea.stanford.edu, labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: <8801230615.AA04546@bhopal.lucid.com> Message-Id: <19880125143853.4.CASSELS@KRYPTON.SCRC.Symbolics.COM> Date: Fri, 22 Jan 88 22:15:21 PST From: Jon L White Does anyone care what values these "constants" actually take on? that is, does anyone use then in any context other than test suites? CLtL p231 says that this number should be the "number closest in value to (but not equal to) zero provided by the implementation." In those implementations supporting IEEE-like denormalized numbers, a question arises: are denormalized numbers "provided", in the sense required? Of the four such implementations I've checked, half set this constant to the least normalized number, and half set it to the least denormalized number. In Symbolics Genera 7.2, we've made the values of those constants be denormalized to meet the letter of CLtL (they used to be normalized). We also added some constants to the SCL: (Symbolics-Common-Lisp:) package, like LEAST-POSITIVE-NORMALIZED--FLOAT. Supporting the former is the fact that IEEE hardware, when traps are enabled, will signal an underflow trap whenever a result would be less than the least normalized number. Supporting the latter is the fact that under at least mode of operation of the hardware, denormalized numbers are "provided" by the implementation. It's a little more complicated (as if we needed that :-). IEEE underflow traps don't happen for addition or subtraction, just for multiplication and division. So whether you see denormalized results from normalized operands (without traps) depends on the operation. [Note that any addition or subtraction which produces a denormalized result is exact. That's not always true for multiplication or division.] Oh, yeah. In answer to your original question, we don't care or use them for anything. But a customer complained, so we changed to conform to the letter of CLtL. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jan 88 09:29:27 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 88 06:18:35 PST Received: ID ; Sun 24 Jan 88 09:18:17-EST Date: Sun, 24 Jan 1988 09:18 EST Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Jon L White Cc: common-lisp@SAIL.STANFORD.EDU Subject: Type specifiers in THE constructs Date: Saturday, 23 January 1988 01:07-EST From: Jon L White To: labrea!common-lisp%su-ai at labrea.Stanford.EDU Re: Type specifiers in THE constructs Does the type-specifier in (THE (MUMBLE)) refer to the type of the first value (of zero or more values) returned by (MUMBLE), or does it refer to the multiple-value spectrum? In short, is is a shorthand for 1. (THE (VALUES &REST T) (MUMBLE)) or for 2. (THE (VALUES ) (MUMBLE)) I suggest the first interpretation, with a note that when the is a VALUES type, THE should enforce exactly the specified values. (which may be what you had in mind) Hence: (THE NUMBER (TRUNCATE 10 3)) ;legal (THE (VALUES NUMBER) (TRUNCATE 10 3)) ; illegal I could also live with the second interpretation. I just wanted to make clear that I consider the multiple-value semantics of THE to be useful. Even if use of a non-values type required a single value, it would be worth supporting THE VALUES so that multiple value results can be declared. Although interpretation 1 may seem a bit sleazy, it is consistent with the general value-count sleaze in Common Lisp. Rob  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 88 15:23:14 EST Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by SAIL.Stanford.EDU with TCP; 23 Jan 88 12:12:39 PST Received: by cayuga.cs.rochester.edu (5.52/h) id AA13143; Sat, 23 Jan 88 15:12:40 EST Received: from loopback by lesath.cs.rochester.edu (3.2/h) id AA04860; Sat, 23 Jan 88 15:12:35 EST Message-Id: <8801232012.AA04860@lesath.cs.rochester.edu> To: common-lisp@sail.stanford.edu Subject: Re: Type specifiers in THE constructs Date: Sat, 23 Jan 88 15:12:31 -0500 From: quiroz@cs.rochester.edu Is there agreement that only aware callers need to know about multiple values? I have the impression that many decisions already in the language point to the desire to avoid burdening an unaware caller. If there is agreement, the best interpretation for the type specifier in a THE form would be: 1- If the specifier is of the form (VALUES ...), then it applies to the potentially many return values of the second subform of THE. (Subject to someone solving the question of what exactly &REST means.) [Doubt: I would like to say that declaring fewer values than actually returned is OK and declares only those, while declaring more values than actually returned `signals an error'. Is that consistent with the rest? This is in line with the (possibly dangerous) assumption that if it is safe to return more than 1 value when your caller expected one exactly, it should be fine to return more than N values when your caller is willing to use only N of those.] 2- Otherwise, it refers to the first or only value returned. So, I would say that (THE NUMBER (TRUNCATE 10 3)) should be legal (should even continue returning the multiple values), but should be read as constraining only the first of the returned values to be NUMBERP. =Cesar -------- Cesar Augusto Quiroz Gonzalez Department of Computer Science ...allegra!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 88 04:33:30 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 88 01:22:30 PST Received: by labrea.Stanford.EDU; Sat, 23 Jan 88 01:22:39 PST Received: from bhopal.lucid.com by edsel id AA29772g; Sat, 23 Jan 88 01:14:53 PST Received: by bhopal id AA05388g; Sat, 23 Jan 88 01:18:23 PST Date: Sat, 23 Jan 88 01:18:23 PST From: Jon L White Message-Id: <8801230918.AA05388@bhopal.lucid.com> To: gz@spt.entity.com Cc: labrea!common-lisp%sail@labrea.Stanford.EDU In-Reply-To: Gail Zacharias's message of 22 Jan 88 18:12:35 EST (Fri) <8801221812.AA05095@spt.entity.com> Subject: type declarations of special bindings re: In the following example, does the fixnum declaration apply to the inner reference to X (in the setq)? (let ((X 17)) (declare (special X) (fixnum X)) (let ((X 'local)) (locally (declare (special X)) (setq X (foo))))) CLtL, p 158 says that type declarations affect the binding "and specifies that the variable[s] mentioned will take on values only of the specified type". The inner reference is to the variable bound specially, not to the one bound locally, so it is the same variable whose binding was declared fixnum. Hence, in theory, it should be as if the form (setq X (foo)) were written as (setq X (the fixnum (foo))) but I suspect very few, if any, compilers actually make this leap of type inferencing. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 88 02:34:30 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 23:23:07 PST Received: by labrea.Stanford.EDU; Fri, 22 Jan 88 23:23:10 PST Received: from bhopal.lucid.com by edsel id AA29335g; Fri, 22 Jan 88 22:04:19 PST Received: by bhopal id AA04525g; Fri, 22 Jan 88 22:07:47 PST Date: Fri, 22 Jan 88 22:07:47 PST From: Jon L White Message-Id: <8801230607.AA04525@bhopal.lucid.com> To: labrea!common-lisp%su-ai@labrea.Stanford.EDU Subject: Type specifiers in THE constructs Does the type-specifier in (THE (MUMBLE)) refer to the type of the first value (of zero or more values) returned by (MUMBLE), or does it refer to the multiple-value spectrum? In short, is is a shorthand for 1. (THE (VALUES &REST T) (MUMBLE)) or for 2. (THE (VALUES ) (MUMBLE)) Of the five implementations I've looked at, three do it like the former and two do it like the latter. Wording on CLtL p161 seems to suggest a meaning like the former: "For this purpose the THE special form is defined; (THE TYPE FORM) means that the value of FORM is declared to be of type TYPE." Note that it says "the value of FORM", not "the values of FORM". Also supporting the latter is the documentation of (VALUES ...) as a type specifier, on CLtL p48: "It is used to specify individual types when multiple values are involved"; i.e., an exception to the "normal" case of specifying "the value" is made when you want to talk about the other return values. Wording on CLtL p138 seems to suggest the latter; namely THE "passes back" multiple values, so the might want to refer to the spectrum being "passed back". Note that this interpretation makes (THE NUMBER (TRUNCATE 10 3)) an illegal form. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jan 88 02:34:21 EST Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 23:23:15 PST Received: by labrea.Stanford.EDU; Fri, 22 Jan 88 23:23:21 PST Received: from bhopal.lucid.com by edsel id AA29350g; Fri, 22 Jan 88 22:11:52 PST Received: by bhopal id AA04546g; Fri, 22 Jan 88 22:15:21 PST Date: Fri, 22 Jan 88 22:15:21 PST From: Jon L White Message-Id: <8801230615.AA04546@bhopal.lucid.com> To: labrea!common-lisp%sail@labrea.Stanford.EDU Subject: LEAST-POSITIVE--FLOAT Does anyone care what values these "constants" actually take on? that is, does anyone use then in any context other than test suites? CLtL p231 says that this number should be the "number closest in value to (but not equal to) zero provided by the implementation." In those implementations supporting IEEE-like denormalized numbers, a question arises: are denormalized numbers "provided", in the sense required? Of the four such implementations I've checked, half set this constant to the least normalized number, and half set it to the least denormalized number. Supporting the former is the fact that IEEE hardware, when traps are enabled, will signal an underflow trap whenever a result would be less than the least normalized number. Supporting the latter is the fact that under at least mode of operation of the hardware, denormalized numbers are "provided" by the implementation. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jan 88 21:42:30 EST Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Jan 88 18:31:21 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Fri, 22 Jan 88 21:30:12 EST Received: by spt.entity.com (smail2.5); 22 Jan 88 18:12:35 EST (Fri) To: common-lisp@sail.stanford.edu Subject: type declarations of special bindings Message-Id: <8801221812.AA05095@spt.entity.com> Date: 22 Jan 88 18:12:35 EST (Fri) From: gz@spt.entity.com (Gail Zacharias) In the following example, does the fixnum declaration apply to the inner reference to X (in the setq)? (let ((X 17)) (declare (special X) (fixnum X)) (let ((X 'local)) (locally (declare (special X)) (setq X (foo)))))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Jan 88 03:13:57 EST Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 20 Jan 88 00:07:06 PST Date: 19 Jan 88 23:29:28 EST From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <011988.232929.daly@ibm.com> Subject: circular structure syntax Is there a SCHEME syntax for circular structures? That is, what is the SCHEME equivalent syntax for: #1=(defun foo () (print '#1#)) I've checked every report I can find and all of the PC Scheme manual (will online documentation ever be a reality? Will there ever be a copy of CLtL online?) without finding mention of the subject. tim DALY@IBM.COM IBM T.J.Watson Research Center Yorktown Heights, N.Y.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Jan 88 08:08:41 EST Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 88 05:02:07 PST Date: 19 Jan 1988 08:00-EST Sender: MATHIS@A.ISI.EDU Subject: Scheme standard? From: MATHIS@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Message-ID: <[A.ISI.EDU]19-Jan-88 08:00:42.MATHIS> I have heard second-hand that the IEEE is considering doing a standard for Scheme. Does anyone know anything about this or how I could get in touch with the people involved? Thanks, Bob  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Jan 88 18:59:53 EST Received: from hecuba.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 15:43:22 PST Received: by hecuba.Berkeley.EDU (5.57/1.25) id AA06672; Mon, 18 Jan 88 15:44:01 PST Message-Id: <8801182344.AA06672@hecuba.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: (simulated) multiprocessor extensions to Common Lisp? Date: Mon, 18 Jan 88 15:43:57 PST From: Benjamin Zorn I work for the SPUR project at UC Berkeley and we are in the process of building a multiprocessor Lisp workstation. SPUR Lisp will be superset of Common Lisp with multiprocessor extensions including futures. I am gathering multiprocessor Lisp programs and would be very interested in hearing about any applications that we could use to test and demonstrate our system. Furthermore, if anyone has implemented simulated futures as an extension to any version of Common Lisp I would be grateful to hear about it. I have heard rumors about versions of Multilisp implemented for Lisp machines and would be happy to know if this code is available. My goal is to test multiprocessor SPUR Lisp programs before the SPUR hardware is available and if I can take advantage of future implementations for other Common Lisp systems, I would appreciate it. -Ben Zorn (zorn@ernie.berkeley.edu)  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 15 Jan 88 20:36:15 EST Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:39:46 PST Received: by ucbvax.Berkeley.EDU (5.58/1.26) id AA20084; Fri, 15 Jan 88 09:26:49 PST Received: by lcuxle.UUCP (4.6/4.2) id AA08855; Fri, 15 Jan 88 11:37:22 EST Date: Fri, 15 Jan 88 11:37:22 EST From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia) Message-Id: <8801151637.AA08855@lcuxle.UUCP> To: common-lisp@sail.stanford.edu Subject: fill-pointer If a vector X has been defined with a fill pointer, then should the following be valid? (SETF (FILL-POINTER X) T) On page 296 of CLtL, it would seem that it is not valid: "SETF may be used with FILL-POINTER to change the fill pointer of a vector. The fill pointer of a vector must always be an integer between zero and the size of the vector (inclusive)." However, since T is allowed at the time the vector is defined (see page 288), then why not when changing it? It would seem convenient to restore a vector X that has a fill pointer to its full size without having to find its value with (ARRAY-DIMENSION X 0), or some other comparable function. Of the implementations that I've looked at, TI allows (SETF (FILL-POINTER X) T), while KCL and XEROX do not. CL allowed it, but erroneously since it actually put T into the fill pointer and that messed up accesses to X.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Jan 88 00:39:04 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 88 21:27:49 PST Received: from STONY-BROOK.SCRC.Symbolics.COM (STONY-BROOK.SCRC.SYMBOLICS.COM) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 27688; 14 Jan 88 20:37:01 EST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 320945; Thu 14-Jan-88 15:57:00 EST Date: Thu, 14 Jan 88 15:57 EST From: David A. Moon Subject: setf subseq question To: miller@cs.rochester.edu, Barry Margolin cc: cl@ACORN.CS.ROCHESTER.EDU In-Reply-To: <880108000333.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>, <880108002641.5.BARMAR@OCCAM.THINK.COM> Message-ID: <19880114205717.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 8 Jan 88 00:03 EST From: Brad Miller Pg. 248: subseq sez " setf may be used with subseq to destructively replace a subsequence with a sequence of new values; see also replace. " I ignore replace, because it says see also, as in another function that does something along these lines, not see that for the definition of what the setf does... so what should (setf (subseq "abcdef" 3 5) "z") do? The answer is on page 95, near the bottom of the page. It changes the constant "abcdef" to "abczef". CLtL suffers from poor cross-referencing. I would say (and vote for) "abcz" but if it acts like replace, you get "abczef". There is no way SETF could change the length of the sequence if it was not either an adjustable array or one with a fill-pointer. It would be real nice to have a (destructive) function that can replace sequences with other sequences..., e.g. like substitute where new-item is new-sequence. I think you mean a function that is to SUBSTITUTE as SEARCH is to POSITION. I agree that this is useful; of course, it's not hard to write for yourself if you don't care about machine-dependent efficiency optimizations. Date: Fri, 8 Jan 88 00:26 EST From: Barry Margolin The point of SETF is that after doing (progn (setf
) ) should return (assuming that doesn't have side-effects that alter its return value). If the result were "abcz" then (subseq 3 5) is an error. If the result were "abczef" (which is what Symbolics returns) then (subseq 3 5) returns "ze", which isn't the same as "z". It's true that the way CLtL defines SETF of SUBSEQ violates that aphorism about setf. I don't see any way to define it that would be consistent with the aphorism, other than to forbid the two lengths to differ. I'm not going to defend the current definition of SETF of SUBSEQ as right; in this message I'm just telling you what CLtL says.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jan 88 16:08:24 EST Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 88 12:54:58 PST Received: ID ; Sat 9 Jan 88 15:54:18-EST Date: Sat, 9 Jan 1988 15:54 EST Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Jon L White Cc: common-lisp@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU Subject: the array type mess.... Well, I certainly agree that there is a mess here, but it seems to me that an obvious solution is being overlooked. It is possible to have both implementation-dependent array specialization and the identity: (typep (make-array ... :element-type ) '(array ... )) => T Array type specialization is just one instance of the implementation process of mapping user specifications into the implementation. In order to understand the Common Lisp type system, you have to start thinking about two different conceptions of type: Definitional type This is the type system as seen by the user of the implementation. It is a collection of promises made by the language definition to the user. Implementation type This is an abstraction of the implementation chosen for an object. The implementation type of an object is basically a name for the representation chosen for that object, and often had more to do with the details of the implementation of the object than with the user visible meaning of the object. Consider the FIXNUM type or the type that has been hypothesized in previous discussions POWER-OF-TWO-BIGNUM. Implementation types are usually of little direct concern to the user: his concern is to somehow use the defined language facilities in a way that permits efficient representations. Traditionally, these two conceptions of type have been used largely interchangeably in Lisp. I think that there are two main reasons for this: -- Before Common Lisp, Lisp systems didn't have type systems elaborate enough to say anything very interesting about the types of objects. In these simple systems, it was easier to maintain an approximate equivalence between the definitional and implementation type. -- Before Common Lisp, the distinction between the implementation and the definition was generally only casually made. This was acceptable, since these Lisp dialects had only one implementation. The problem that we are seeing with arrays is that the relationship between definitional and implementation types is under-defined, causing problems in functions that straddle the definition=>implementation boundary. There are two obvious solutions, one of which has already been proposed: -- Make the mapping more direct. Eliminating "array element type upgrading" would be an instance of this. -- Make the mapping explicitly ill-defined in a more useful way. I think we need to do the latter because the former won't work. I don't see how to eliminate "array element type upgrading" without creating more problems we solve. Even if this can be done, the ill-defined nature of the to-implementation mapping will crop up again and again. We already had a long discussion about TYPE-OF, ARRAY-ELEMENT-TYPE and SUBTYPEP. This discussion was prompted by what superficially appeared to be compile questions about TYPE-OF. The main reason that the problem is so blatant with arrays is that an array is currently the only way that Common Lisp lets the user get his hands on a specializable cell as something approaching a first-class object. I think that array element types should treated in much the same way as the primary other kind of specializable cell: variables. It is widely accepted that a Common Lisp compiler is free to implement a variable however it damn well pleases as long as it preserves the language semantics during normal execution. When compilers start using non-standard representations such as "unboxed numbers" and playing games like introducing spurious copies during register allocation, then extra-linguistic environment features such as debuggers can detect the funny business, but this is of little concern to the normal programmer. With arrays, it is somewhat more awkward to play free and loose with representations, since the user has been given operations (such as ARRAY-ELEMENT-TYPE) that manipulate the implementation type of the object in terms of definitional types. The user has been given enough rope to hang himself, mainly because array types were being thought of more in terms of implementation types than definitional types. My conclusion is that it isn't array types that are wrong, it is the understanding of the meaning of TYPEP that is wrong. TYPEP should be thought of as a query: Could this value be the implementation of an object defined by the language to have this type? and not: Is this the implementation type of this object? The first definition is the only one that works in Common Lisp, since the Common Lisp definition is implementation-independent. Under this interpretation, it is obvious that the TYPEP/MAKE-ARRAY identity holds. In terms of the TYPEP implementation, this means that TYPEP will automatically do the to-implementation mapping on the type specifier before comparing it to the implementation type. Rob  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jan 88 23:37:38 EST Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jan 88 20:29:22 PST Received: by labrea.stanford.edu; Fri, 8 Jan 88 20:29:17 PST Received: from bhopal.lucid.com by edsel id AA10474g; Fri, 8 Jan 88 19:27:32 PST Received: by bhopal id AA23963g; Fri, 8 Jan 88 19:30:02 PST Date: Fri, 8 Jan 88 19:30:02 PST From: Jon L White Message-Id: <8801090330.AA23963@bhopal.lucid.com> To: sandra%orion@cs.utah.edu Cc: labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: Sandra J Loosemore's message of Thu, 7 Jan 88 08:58:52 MST <8801071558.AA29760@orion.utah.edu> Subject: the array type mess.... re: I believe that an implementation is not allowed to upgrade all array types arbitrarily; . . . Quite right -- since strings and bit-arrays are treated specially in so many contexts, I frequently forget that are also subtypes of arrays. re: In other words, I'd like to see (typep (make-array n :element-type foo) foo) be true in all implementations, for all types foo. I'm sure you meant to say: (typep (make-array n :element-type ') '(array )) right? Yes, upgrading isn't the only way to optimize the important cases; although I'd think a vendor would be under some compulsion to reveal just which element types were "preferable". -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jan 88 23:37:10 EST Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jan 88 20:29:00 PST Received: by labrea.stanford.edu; Fri, 8 Jan 88 20:28:54 PST Received: from bhopal.lucid.com by edsel id AA10453g; Fri, 8 Jan 88 19:17:35 PST Received: by bhopal id AA23932g; Fri, 8 Jan 88 19:20:07 PST Date: Fri, 8 Jan 88 19:20:07 PST From: Jon L White Message-Id: <8801090320.AA23932@bhopal.lucid.com> To: labrea!Masinter.PA%Xerox.COM@labrea.stanford.edu Cc: labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: "Larry_Masinter.PARC"@Xerox.COM's message of 8 Jan 88 14:56:16 PST (Friday) <880108-145707-2273@Xerox> Subject: TYPEP warp implications re: Wouldn't it be simpler, promote portability, and not cost very much to require that arrays remember the element type they were created with? Well, not necessarily the :element-type arguemnt per se, but a canonical representation thereof. What you are suggesting is that we toss out element-type "upgrading"; I could contemplate that. I wonder how others feel? -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jan 88 20:47:30 EST Received: from RUTGERS.EDU by SAIL.Stanford.EDU with TCP; 8 Jan 88 17:40:01 PST Received: by RUTGERS.EDU (5.54/1.15) with UUCP id AA02493; Fri, 8 Jan 88 18:29:12 EST Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424) id AA05080; Wed, 6 Jan 88 16:13:27 PST Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424) id AA15335; Wed, 6 Jan 88 16:14:28 PST Date: 6 Jan 1988 16:12 PST From: David Bein Subject: side-effecting functions ... To: common-lisp@sail.stanford.edu@RUTGERS.EDU Message-Id: <568511807/bein@pyrnova> [ I know this has been discussed sometime in the past, so please excuse its new presence. ] Suppose we are going to compile the following forms: (1) (FUNCALL 'FOO (SETF (SYMBOL-FUNCTION 'FOO) #'NEW-FOO)) (2) (FUNCALL #'FOO (SETF (SYMBOL-FUNCTION 'FOO) #'NEW-FOO)) (3) (FOO (SETF (SYMBOL-FUNCTION 'FOO) #'NEW-FOO)) (Assume FOO is not an FLET/LABELS function..) I am assuming that #1 uses the function definition for NEW-FOO and that #2 uses the current definition for FOO. Should #3 behave as #1 or #2 or is this purposefully left undefined to discourage coding practices like this? --David  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jan 88 00:47:41 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 21:39:44 PST Received: from Think.COM (THINK.COM) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 27303; 8 Jan 88 00:39:31 EST Return-Path: Received: from sauron.think.com by Think.COM; Fri, 8 Jan 88 00:27:00 EST Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 8 Jan 88 00:26:57 EST Date: Fri, 8 Jan 88 00:26 EST From: Barry Margolin Subject: setf subseq question To: miller@cs.rochester.edu Cc: cl@acorn.cs.rochester.edu In-Reply-To: <880108000333.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Message-Id: <880108002641.5.BARMAR@OCCAM.THINK.COM> Date: Fri, 8 Jan 88 00:03 EST From: Brad Miller so what should (setf (subseq "abcdef" 3 5) "z") do? I vote that it is some kind of error (I'm not sure whether it should be "is an" or "signals an"). The point of SETF is that after doing (progn (setf ) ) should return (assuming that doesn't have side-effects that alter its return value). If the result were "abcz" then (subseq 3 5) is an error. If the result were "abczef" (which is what Symbolics returns) then (subseq 3 5) returns "ze", which isn't the same as "z". barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jan 88 00:11:45 EST Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 7 Jan 88 21:02:34 PST Date: Fri, 8 Jan 88 00:03 EST From: Brad Miller Subject: setf subseq question To: cl@ACORN.CS.ROCHESTER.EDU Message-ID: <880108000333.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627 Phone: 716-275-1118 This may already be cleared up (I don't have a copy of the definition patchs, where can I get them?) Pg. 248: subseq sez " setf may be used with subseq to destructively replace a subsequence with a sequence of new values; see also replace. " I ignore replace, because it says see also, as in another function that does something along these lines, not see that for the definition of what the setf does... so what should (setf (subseq "abcdef" 3 5) "z") do? I would say (and vote for) "abcz" but if it acts like replace, you get "abczef". It would be real nice to have a (destructive) function that can replace sequences with other sequences..., e.g. like substitute where new-item is new-sequence. Brad Miller ------ miller@cs.rochester.edu {...allegra!rochester!miller} Brad Miller University of Rochester Computer Science Department 'If anything is True, this is.'  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 13:19:08 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 10:05:12 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 7 Jan 88 13:04-EST Received: from JASPER.Palladian.COM (JASPER.Palladian.COM) by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 74938; 7 Jan 88 12:26:14-EST Received: from DWORKIN.Palladian.COM (DWORKIN.Palladian.COM) by JASPER.Palladian.COM via INTERNET with SMTP id 14512; 6 Jan 88 22:24:37 EST Date: Wed, 6 Jan 88 22:25 EST From: Glenn S. Burke Subject: &REST lists To: barmar@Think.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <880105105957.3.BARMAR@OCCAM.THINK.COM> Message-ID: <880106222504.9.GSB@DWORKIN.Palladian.COM> Reply-To: Glenn S. Burke Date: Tue, 5 Jan 88 10:59 EST From: Barry Margolin Date: Tue, 5 Jan 88 02:12 EST From: Glenn S. Burke I think it is legal for APPLY to pass user-specified list structure to the function; if so the &REST list should be treated as read-only, as it well might be. That doesn't follow. Just because you pass a read-only list to APPLY doesn't mean that it has to use that same list when it invokes the function. APPLY could COPY-LIST it. Or in an implementation that uses stack-consed &REST args the list elements might be copied to the stack. barmar You miss the point entirely. I am saying that if it is a permissible implementation for apply to NOT copy a user-specified list, then proper coding practice would be to not modify &rest lists. I don't know or remember if APPLY is permitted to do this. This came up back when the original stack-list/heap-list decision was made, and there may have been a consensus on it at the time.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 11:09:50 EST Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 88 07:58:55 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA19342; Thu, 7 Jan 88 08:58:56 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA29760; Thu, 7 Jan 88 08:58:52 MST Date: Thu, 7 Jan 88 08:58:52 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8801071558.AA29760@orion.utah.edu> Subject: the array type mess.... To: edsel!jonl@labrea.stanford.edu Cc: common-lisp@sail.stanford.edu I believe that an implementation is not allowed to upgrade all array types arbitrarily; at least, on p. 34, it says that the types simple-vector, simple-string, and simple-bit-vector are disjoint. I'm also unhappy with the current situation, but my solution would be to do away with the array upgrading entirely. In other words, I'd like to see (typep (make-array n :element-type foo) foo) be true in all implementations, for all types foo. If an implementation does not have a specialized representation for (array (signed-byte 5)), it could still internally upgrade it to some other convenient representation, but it should keep the original element-type around (stored in the array header) so type discrimination will still work. Also, the last type I asked the question, there seemed to be general agreement that SUBTYPEP should reflect the actual type hierarchy in the implementation. In some implementations, for example, FLOAT might be a subtype of SHORT-FLOAT. -Sandra -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jan 88 03:13:47 EST Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:59:22 PST Received: by labrea.stanford.edu; Wed, 6 Jan 88 23:59:09 PST Received: from bhopal.lucid.com by edsel id AA00715g; Wed, 6 Jan 88 23:18:53 PST Received: by bhopal id AA15243g; Wed, 6 Jan 88 23:21:16 PST Date: Wed, 6 Jan 88 23:21:16 PST From: Jon L White Message-Id: <8801070721.AA15243@bhopal.lucid.com> To: labrea!common-lisp%sail@labrea.stanford.edu Subject: TYPEP warp implications Recent mail under the subject line of "Types in CL" brought to light an inconsistency in CLtL that may have gone unnoticed by most people. -- The second paragraph of page 11 makes it clear that "data types" are just sets of objects; subsequent discussion makes it clear that the second argument to TYPEP (a type specifier) is a name for some such set, and that there may be several distinct names specifying the same set (or type). The first paragraph of section 6.2.1 on page 72 says that TYPEP is a set membership test, and SUBTYPEP is a subset test. -- The first two paragraphs of section 4.5, on page 45, describe a permission for what I call "element-type upgrading" on arrays; the documentation fo ARRAY-ELEMENT-TYPE on page 291 also makes it clear that a conforming implementation is permitted to "collapse" array element types into some more limited set of types, providing that the array returned by make-array is at most an "upgrade". For example, depending on how primitive arrays are actually implemented, (make-array :element-type '(signed-byte 5)) and (make-array :element-type '(signed-byte 16)) might legitimately create exactly the same set of objects. The only constraint seems to be that that (array (signed-byte 16)) be the most specific type *** in that implementation *** which can hold all the objects made by (make-array :element-type '(signed-byte 5)). In this case, we say that the array element type has been upgraded from (signed-byte 5) to (signed-byte 16), and we imply that there is no particular special provisions for arrays of element type, say, (signed-byte 8). [Every vendor's implementation I have looked at does some amount of non-trivial "upgrading" on the element type (signed-byte 5).] By the bulletted paragraphs above, (array (signed-byte 5)) and (array (signed-byte 16)) are in fact names for exactly the same set of objects. However pages 45 and 46 go at length to specify that these two different names for the same set of objects must be treated differently by TYPEP and SUBTYPEP. This seems to "warp" the utility of TYPEP since it puts it at variance with the fundamental principle: "SUBTYPEP means subsetp". No one I've asked has tried to defend this "warp". I conjecture that it was added to CLtL in a mistaken belief that it would promote portability. I say "mistaken" because the source of non-portability is the permission to upgrade; if two different implementations do any upgrading differently, then the effect will be the same kind of non-portability that results when two different implementations set the boundary between fixnums and bignums differently. Yet I'm in favor of the permission to upgrade; I would not like to see CL become a language like C where there are a prescribed set of kinds of arrays that must be implemented (e.g, "int", "long int", "single", "double" etc), and no others can exist. In short, I would not want to gain portability at the expense of limiting the language to the architectural features of the hardware on which it was first implemented. I would like to suggest that the flaw be fixed as follows: -- Delete all the documentation that suggests the :element-type argument to make-array mignt not be a satisfactory element-type in the type specifier for the kind of array produced; -- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will tell you how a particular :element-type argument to make-array will be treated (so that you don't have to cons up an array to find out). Does anyone have any strong feeling on this dichotomy one way or the other? Have you been affected by variations in the vendors treatement of arrays? -- JonL -- P.S. A clarifying note on the definition of "type specifier". I called it a "name" in the above message. This means that it is either a symbol like FIXNUM, or ARRAY, or one of the permissible list conbinations of type specifiers like (OR FIXNUM BIGNUM) etc. [But note that he Object System proposal may have to permit class-objects themselves to be considered as type-specifiers because it is possible to create classes that don't have (proper) symbolic names; however, we can still view "the object itself" as its own name in the sense that the address of an object is a hidden name.] Thus the set of type-specifiers forms a mathematical language, and the SUBTYPEP relation is generated by some basic, generating set of relations between these names. I want to see this language actually describing the implementation in which it is running -- that the objects of the implementation are a model for that language -- rather than seeing it be limited to some theoretical model which no vendor bothers to implement.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jan 88 15:39:48 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 12:25:47 PST Return-Path: Received: from sauron.think.com by Think.COM; Tue, 5 Jan 88 10:59:40 EST Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 5 Jan 88 10:59:18 EST Date: Tue, 5 Jan 88 10:59 EST From: Barry Margolin Subject: &REST lists To: Glenn S. Burke Cc: Fahlman@c.cs.cmu.edu, common-lisp@sail.stanford.edu In-Reply-To: <880105021220.5.GSB@DWORKIN.Palladian.COM> Message-Id: <880105105957.3.BARMAR@OCCAM.THINK.COM> Date: Tue, 5 Jan 88 02:12 EST From: Glenn S. Burke I think it is legal for APPLY to pass user-specified list structure to the function; if so the &REST list should be treated as read-only, as it well might be. That doesn't follow. Just because you pass a read-only list to APPLY doesn't mean that it has to use that same list when it invokes the function. APPLY could COPY-LIST it. Or in an implementation that uses stack-consed &REST args the list elements might be copied to the stack. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jan 88 03:42:55 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 00:30:26 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 5 Jan 88 03:29-EST Received: from JASPER.Palladian.COM (JASPER.Palladian.COM) by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 74582; 5 Jan 88 03:14:49-EST Received: from DWORKIN.Palladian.COM (DWORKIN.Palladian.COM) by JASPER.Palladian.COM via INTERNET with SMTP id 7495; 5 Jan 88 02:12:05 EST Date: Tue, 5 Jan 88 02:12 EST From: Glenn S. Burke Subject: &REST lists To: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <880105021220.5.GSB@DWORKIN.Palladian.COM> Reply-To: Glenn S. Burke Date: Mon, 4 Jan 1988 20:27 EST From: "Scott E. Fahlman" Is there general agreement on whether it is valid Common Lisp to destructively modify (RPLACA, RPLACD) the list to which a &REST parameter is bound? I can't find a reference in CLtL for this. I think there's general agreement that &rest args are supposed to be righteous lists with indefinite extent, so RPLAC'ing them ought to be legal. I think it is legal for APPLY to pass user-specified list structure to the function; if so the &REST list should be treated as read-only, as it well might be. I can't remember this for sure.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 88 20:40:38 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 17:28:21 PST Received: ID ; Mon 4 Jan 88 20:28:01-EST Date: Mon, 4 Jan 1988 20:27 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: &REST lists In-reply-to: Msg of 4 Jan 1988 16:41-EST from Charles Hornig Is there general agreement on whether it is valid Common Lisp to destructively modify (RPLACA, RPLACD) the list to which a &REST parameter is bound? I can't find a reference in CLtL for this. I think there's general agreement that &rest args are supposed to be righteous lists with indefinite extent, so RPLAC'ing them ought to be legal. However, this was one part of the Common Lisp spec that several early implementations deliberately chose to deviate from in the interest of greater efficiency. (Symbolics and TI were able to gain considerable efficiency by consing rest args on the stack.) Both companies had plans to fix this eventually, stack-consing only when the compiler could prove it was safe to do so, but I don't know if this has finally been accomplished and distributed to all users. -- Scott  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 88 17:37:44 EST Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 4 Jan 88 14:24:39 PST Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156025; Mon 4-Jan-88 16:41:51 EST Date: Mon, 4 Jan 88 16:41 EST From: Charles Hornig Subject: &REST lists To: common-lisp@sail.stanford.edu Message-ID: <19880104214147.6.HORNIG@WINTER.SCRC.Symbolics.COM> Is there general agreement on whether it is valid Common Lisp to destructively modify (RPLACA, RPLACD) the list to which a &REST parameter is bound? I can't find a reference in CLtL for this.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 88 12:43:38 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 09:29:08 PST Received: from XX.LCS.MIT.EDU (XX.LCS.MIT.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 27125; 4 Jan 88 12:29:22 EST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 4 Jan 88 12:26-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 74460; 4 Jan 88 12:25:54-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 91173; Mon 4-Jan-88 11:20:45-EST Date: Mon, 4 Jan 88 11:27 est From: mike%acorn@oak.lcs.mit.edu To: RWK@YUKON.SCRC.Symbolics.COM Subject: Question about declaration Cc: mike%acorn@oak.lcs.mit.edu, miller@cs.rochester.edu, CL@ACORN.CS.ROCHESTER.EDU Yes, but you haven't really declared those values, have you? All you've done is declare that you can have a "list of them". Now, if there was a "sequence-enumerated" type (as we have in our UIMS), this would be a different matter. I.e. (function foo ((and list (sequence-enumerated symbol integer symbol integer))) (values &rest (and list (sequence-enumerated symbol integer symbol integer)))) But what you'd *like* to know here is that the individual elements are integers; i.e. (function foo ((list integer)) (values &rest (list integer))) where the new argument to LIST does *NOT* work like ARRAY (meaning "a kind of list specialized to contain only integers"), but rather means "a list whose elements are all INTEGER's". There is a big gap between being able to declare the existence of a variable number of arguments or values and being able to declare their type. It is possible to define (deftype LIST-OF (ty) ...) such that (function foo (&rest (list-of integer)) (values &rest (list-of fixnum)))) makes sense. This can't be done in the normal way with SATISFIES, but can be done by consing up a gensym and attaching the list-of predicate to it. This is one of the uglier kludges in Common Lisp, since it is a workaround for the lack of parameterized types. The unresolved and truly ambiguous problem is whether &REST LIST means that the rest arg is a list (as usual) or that the elements of the &REST arg are lists. Another ambiguity is whether returning type T allows the returning of any number of values, i.e., is T > (values T T), or T > (values &rest T). ...mike beckerle  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Dec 87 19:53:22 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Dec 87 16:34:44 PST Received: from Burger.ms by ArpaGateway.ms ; 31 DEC 87 16:35:11 PST Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 31 Dec 87 16:34:23 PST (Thursday) Subject: Re: implicit blocks From: masinter.PARC@Xerox.COM To: COMMON-LISP@SAIL.STANFORD.EDU In-Reply-to: Common-Lisp-mailer%SAIL.Stanford:EDU's message of 31 Dec 87 11:43:32 PST (Thursday) Message-ID: <871231-163511-2608@Xerox> There will probably be a letter ballot to X3J13 to confirm the cleanup items accepted by voice vote at the recent X3J13 meetings. I'd say that these changes would then has as much `official' status as anything. I'll send out to common-lisp the text of the proposals, although probably not soon. This is FLET-IMPLICIT-BLOCK: ! Issue: FLET-IMPLICIT-BLOCK Reference: CLtL p. 113, 67 Category: OMISSION Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33 Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12 Versions 4,5 by Fahlman 11-Apr-87 Version 6 by Masinter 5-Jun-87 Problem Description: Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE have an implicit block around their bodies like the body of a DEFUN? CLtL is silent on this point. Many users and some implementors assume that such blocks should be established, since they view these forms as analogous with DEFUN. Test case: (defun test () (flet ((test (x) (if x (return-from test 4) 3))) (list (test nil) (test t)))) (test) will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4 in an implementation that did not add an implicit block around FLET. Proposal: FLET-IMPLICIT-BLOCK:YES Each function created by FLET and LABELS and each macro created by DEFMACRO and MACROLET has an implicit block around the body. The name of this block is that same as the (lexical) name of the function or macro. Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE is surrounded by a block with the same name as the accessor or type. Current Practice: Current practice is mixed. Several implementations do not add the implicit block, others do, some add some of these blocks and not others. Cost of adopting this change: Some implementations will have to be modified. This should be a relatively easy modification. Cost of not adopting the change: If the issue is not clarified one way or another, continuing confusion will result in portability problems. Clarifying the issue in any other way would also require modifications in some implementations. Cost of converting existing code: It is possible that some user code would break because it does a return from within a code body to an outer block that has the same as the newly-required block. Such problems will be rare, and the code in question would not run on all current Common Lisp systems because of the diverse interpretations currently in effect. It would be possible to detect all such instances automatically, though it seems unlikely that anyone will need to use this technique. Discussion: The goal is first to clean up an ambiguous situation and, second, to do this in a way that provides consistent behavior between local and global definitions. The proposed change would allow a simple rule of thumb: any named entity that takes a code body establishes an implicit block with the obvious name. Two alternatives to the proposal were considered and rejected: The first would be to keep the implicit block in DEFUN, and to clearly state that the other forms do not create implicit blocks. This violates the goal of consistency between lexical and global definitions, and it seems to conflict with users' expectations. The second alternative was to eliminate the implicit block from DEFUN rather than adding such blocks to other forms. There was some feeling that specifying the implicit block in DEFUN was a poor design decision in the first place, since it hides a reference to the name of a function within the code of the function itself. If a user decides to rename some function, he must be careful to rename any return-from forms within the body of the function as well. However, eliminating the implicit block in DEFUN would be a significant incompatible change. Some users find this implicit block to be a great convenience for popping out of convoluted code, and some existing code makes heavy use of this feature. While such code could be repaired automatically by searching for situations in which the user returns from a function by name and by adding an appropriate explicit block to any function containing such a forms, it would still require more more work on existing user code than this proposal made above. There was considerable discussion in the cleanup committee about whether these implicit blocks would interfere with tail-recursion optimization, which we hope will become more common in future Common Lisp implementations. The outcome of these discussions was general agreement that a compiler could easily eliminate the implicit block in any case where it is not actually used, and that the impact on tail-recursion optimization in compiled code is therefore minimal.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Dec 87 14:27:52 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 31 Dec 87 11:16:18 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313137; Thu 31-Dec-87 14:16:19 EST Date: Thu, 31 Dec 87 14:16 EST From: David A. Moon Subject: implicit blocks To: goldman@vaxa.isi.edu cc: COMMON-LISP@SAIL.STANFORD.EDU In-Reply-To: <8712291926.AA29210@vaxa.isi.edu> Message-ID: <19871231191610.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 29 Dec 87 11:26:20 PST From: goldman@vaxa.isi.edu CLtL specifies that the body of a defun is implicitly surrounded by a block with the same name as the defun. As far as I can find, it makes no such stipulation about the bodies of named lexical functions introduced with FLET or LABELS, nor for macro bodies (defmacro, macrolet). Of the three implementations I have looked at, two do supply implicit blocks for FLET, LABELS, and DEFMACRO (I didn't check for macrolet), and one supplies an implicit block ONLY for DEFUN. Has this been clarified in earlier discussions? From the standpoint of transforming code, it would be desireable for the implicit block to be supplied in either ALL or NONE of the above. From the standpoint of utility, I would suggest ALL. The Cleanup subcommittee of X3J13 decided in issue FLET-IMPLICIT-BLOCK that all of these have implicit blocks. These cleanup changes have no "official" status yet, and an implementation that doesn't do implicit blocks for other than DEFUN is just as "correct" as one that does. However, implementations should be migrating in the direction of supplying implicit blocks for all of these. Send mail to Masinter.pa@Xerox.COM if you want a copy of the text of the FLET-IMPLICIT-BLOCK cleanup.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Dec 87 11:45:24 EST Received: from SALLY.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 08:31:47 PST Posted-Date: Thu, 31 Dec 87 09:56:47 CST Received: by sally.utexas.edu (5.54/5.51) id AA21787; Thu, 31 Dec 87 10:31:40 CST Date: Thu, 31 Dec 87 09:56:47 CST From: wfs@rascal.ics.utexas.edu (Bill Schelter) Message-Id: <8712311556.AA12729@rascal.ics.utexas.edu> Received: by rascal.ics.utexas.edu (3.2/4.22) id AA12729; Thu, 31 Dec 87 09:56:47 CST To: common-lisp@sail.stanford.edu Cc: mcvax!jungfrau!ceb@uunet.uu.net Subject: sloop availability In reply to the letter asking about sloop.lisp It is available on rascal:/usr2/ftp/pub/sloop.lisp Internet Address: 128.83.144.1 rascal.ics.utexas.edu rascal # sun unix login anonymous with password guest. If you cannot ftp, send a request message to wfs@racal.ics.utexas.edu and I will mail it to you. Any bug reports or complaints (or even contented user reports) should also go to that address. Bill Schelter  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Dec 87 10:45:43 EST Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Dec 87 07:31:42 PST Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Thu, 31 Dec 87 10:30:21 EST Received: from zaphod.prime.com by primerd.prime.com (3.2/SMI-3.0DEV3/smail) id AA19852; Thu, 31 Dec 87 10:22:34 EST Received: by zaphod.prime.com (3.2/SMI-3.2) id AA04386; Thu, 31 Dec 87 10:24:46 EST Date: Thu, 31 Dec 87 10:24:46 EST From: primerd!zaphod!doug@EDDIE.MIT.EDU (Douglas Rand) Message-Id: <8712311524.AA04386@zaphod.prime.com> To: common-lisp@sail.stanford.edu Subject: Teaching iteration I have a generic question. I've been teaching a group Common LISP and will be teaching a group of engineers here at Prime. Up to now I've kept within CLtL for constructs. However, at this point, there are two really nicely done LOOP macros freely available. Both the MIT supplied and the UTEXAS supplied macros seem reliable and produce good code with lots of type declarations for those compilers that use them. The question is: Is it safe to teach this group LOOP rather then DO, DO*, DOTIMES, DOLIST and minimal LOOP? I rather like LOOP's declarative style and find the resulting code both more flexible and more readable. Replies can be send directly unless the whole group really wants another discussion topic. Cheer,s Doug (dougr@eddie.mit.edu) P.S. Please don't use reply, it doesn't seem to get me my mail these days. P.P.S. Happy New Year  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Dec 87 19:48:35 EST Received: from SALLY.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 30 Dec 87 16:31:39 PST Posted-Date: Wed, 30 Dec 87 18:09:53 CST Received: by sally.utexas.edu (5.54/5.51) id AA10289; Wed, 30 Dec 87 18:31:42 CST Date: Wed, 30 Dec 87 18:09:53 CST From: wfs@rascal.ics.utexas.edu (Bill Schelter) Message-Id: <8712310009.AA11780@rascal.ics.utexas.edu> Received: by rascal.ics.utexas.edu (3.2/4.22) id AA11780; Wed, 30 Dec 87 18:09:53 CST To: common-lisp@sail.stanford.edu Subject: function redefinition. Two questions involving changing of a symbol-function of a symbol. I) Is it permissible in common lisp for a function FOO to call a function which may redefine FOO? This is useful for defining autoloading, or self compiling functions. I was not able to find anything in the manual authorizing this. I would like to use this feature, in some code which I want to be very pure common lisp. Does anyone know of a common lisp implementation where this is not valid, or perhaps some text in the manual which might authorize such behaviour? Example: (defun foo (&rest l) (load "foo-def.o") (apply 'foo l)) II) What is the approved order of evaluation of in the call (foo a), or is it left undefined. For examble if I have a file containing the following three forms: (defun foo (x) x (print "hi")) (defun goo (y) x (print "bye")) (defun test () (foo (setf (symbol-function 'foo) (symbol-function 'goo))) ) Then for symbolics and kcl, interpreted (test) ==> "hi" compiled (test) ==> "bye" I am happy with the order being undefined, I just wondered if this was indeed supposed to be so, or if I should fix it in kcl. Of course for speed in compilation, the "bye" answer is what fits in most easily, since you want we want to push the args and then call the function, so we don't want to have to save its address before pushing the args. Bill Schelter  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Dec 87 15:23:27 EST Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 87 12:06:37 PST Received: by labrea.stanford.edu; Tue, 29 Dec 87 12:06:28 PST Received: from bhopal.lucid.com by edsel id AA25479g; Tue, 29 Dec 87 11:55:22 PST Received: by bhopal id AA09443g; Tue, 29 Dec 87 11:57:10 PST Date: Tue, 29 Dec 87 11:57:10 PST From: Jon L White Message-Id: <8712291957.AA09443@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu, labrea!barmar%Think.COM@labrea.stanford.edu Cc: labrea!common-lisp%SAIL@labrea.stanford.edu Subject: Types in CL CLtL, p45, clearly permits the "upgrade" for arrays -- namely that a request for an array of element-type T2 is satisified by an array of element-type T2*, where (SUBTYPEP T2 T2*) and where T2* is the "least" such type. For example, if an implementation only has "general" arrays and "8-bit" arrays, then (MAKE-ARRAY :ELEMENT-TYPE '(UNSIGNED-BYTE 5)) could legitimately return an array of element-type '(UNSIGNED-BYTE 8). But it would not be satisfied by a "general" type array, since there is a kind of array with more specialized element-type that can hold (unsigned-byte 5)'s. Note that (UNSIGNED-BYTE 5) is *not* even equal-typep to (UNSIGNED-BYTE 8). [And certainly not EQ!] However, the problem with TYPEP that you [Moon] describe is clearly one of the most serious flaws in the CL design -- that a variable declared to be of type and all of whose objects are created in accord with that type-specifier, still may have *none* of its values ever satisfied by the TYPEP predicate with that type-specifier. We have received repeated bug reports from users whenever (TYPEP (MAKE-ARRAY :ELEMENT-TYPE ') '(ARRAY *)) is false. Many of us have reverted to treating this part of CLtL as an unworkable braino with no particular utility. If you or anyone else cares to defend the typep warp, I'd be curious to hear about it. The more generous interpretation of array element-type upgrading would permit the two array type specifiers (ARRAY (UNSIGNED-BYTE 5) *) (ARRAY (UNSIGNED-BYTE 8) *) to be equal-typep [in the above hypothetical implementation], even though the two element types (UNSIGNED-BYTE 5) (UNSIGNED-BYTE 8) are not equal-typep. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Dec 87 14:42:23 EST Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 87 11:26:12 PST Posted-Date: Tue, 29 Dec 87 11:26:20 PST Message-Id: <8712291926.AA29210@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA29210; Tue, 29 Dec 87 11:26:23 PST To: COMMON-LISP@sail.stanford.edu From: goldman@vaxa.isi.edu Subject: implicit blocks Date: Tue, 29 Dec 87 11:26:20 PST Sender: goldman@vaxa.isi.edu CLtL specifies that the body of a defun is implicitly surrounded by a block with the same name as the defun. As far as I can find, it makes no such stipulation about the bodies of named lexical functions introduced with FLET or LABELS, nor for macro bodies (defmacro, macrolet). Of the three implementations I have looked at, two do supply implicit blocks for FLET, LABELS, and DEFMACRO (I didn't check for macrolet), and one supplies an implicit block ONLY for DEFUN. Has this been clarified in earlier discussions? From the standpoint of transforming code, it would be desireable for the implicit block to be supplied in either ALL or NONE of the above. From the standpoint of utility, I would suggest ALL. Neil  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 12:05:14 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Dec 87 08:48:19 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 310888; Mon 28-Dec-87 11:24:56 EST Date: Mon, 28 Dec 87 11:24 EST From: David A. Moon Subject: Types in CL To: Jon L White cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8712272115.AA02168@bhopal.lucid.com> Message-ID: <19871228162446.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 27 Dec 87 13:15:46 PST From: Jon L White re: Actually, there is a bug in your original message, in the TYPEP call. The predicate (TYPEP A 'T1) expands to (TYPEP A '(ARRAY T2 1)) which is equivalent to (AND (ARRAYP A) (EQ (ARRAY-ELEMENT-TYPE A) 'T2) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1)) This isn't right, and is probably a good example of the single most common error when trying to figure out what the array types mean. Since a CL implementation of arrays is permitted to "upgrade" the :element-type argument into something actually supported, and since there is no requirement to preserve the original :element-type argument, then the line above (EQ (ARRAY-ELEMENT-TYPE A) 'T2) should be (SUBTYPEP 'T2 (ARRAY-ELEMENT-TYPE A)) Of course, optimizations are possible for specific T2's; but in general the element-type might have been upgraded to, for example, T. Just to keep the record 100% straight, SUBTYPEP isn't right. It's true that MAKE-ARRAY and DECLARE upgrade the element type, but TYPEP does not. CLtL p.46 says the ARRAY type specifier -for- -discrimination- (i.e. when used with the TYPEP function) means arrays specialized to hold precisely the mentioned element type and no other objects, unless the mentioned element type is *, which means all arrays. See also the second to last paragraph on p.45. This is all a bit strange, but it's what the book says. I suspect there are reasons for it. We've been through this a million times on the Common Lisp mailing list, and no one, including you and me, can remember it without looking it up in the book each time, so it must be unintuitive. EQ isn't right either. The function you really want is EQUAL-TYPEP, which doesn't exist in Common Lisp, since two type specifiers can certainly be equivalent without being EQ, and in fact without being EQUAL. An adequate definition is probably (defun equal-typep (t1 t2) (and (subtypep t1 t2) (subtypep t2 t1)))  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Dec 87 11:57:04 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Dec 87 08:37:59 PST Return-Path: Received: from sauron.think.com by Think.COM; Mon, 28 Dec 87 11:37:32 EST Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 28 Dec 87 11:37:29 EST Date: Mon, 28 Dec 87 11:38 EST From: Barry Margolin Subject: Types in CL To: Jon L White Cc: common-lisp@sail.stanford.edu In-Reply-To: <8712272115.AA02168@bhopal.lucid.com> Message-Id: <871228113827.1.BARMAR@OCCAM.THINK.COM> Date: Sun, 27 Dec 87 13:15:46 PST From: Jon L White re: Actually, there is a bug in your original message, in the TYPEP call. The predicate (TYPEP A 'T1) expands to (TYPEP A '(ARRAY T2 1)) which is equivalent to (AND (ARRAYP A) (EQ (ARRAY-ELEMENT-TYPE A) 'T2) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1)) This isn't right, and is probably a good example of the single most common error when trying to figure out what the array types mean. Since a CL implementation of arrays is permitted to "upgrade" the :element-type argument into something actually supported, and since there is no requirement to preserve the original :element-type argument, then the line above (EQ (ARRAY-ELEMENT-TYPE A) 'T2) should be (SUBTYPEP 'T2 (ARRAY-ELEMENT-TYPE A)) Of course, optimizations are possible for specific T2's; but in general the element-type might have been upgraded to, for example, T. This contradicts an explicit statement to the contrary in CLtL. On page 46, it says: (ARRAY CHARACTER) is not the set of all arrays that can hold characters, but rather the set of arrays that are specialized to hold characters and no other objects. To test whether an array FOO can hold a character, one should not use (TYPEP FOO '(ARRAY CHARACTER)) but rather (SUBTYPEP 'CHARACTER (ARRAY-ELEMENT-TYPE FOO)) I therefore stand by my translation. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Dec 87 17:32:36 EST Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Dec 87 14:21:33 PST Received: by labrea.stanford.edu; Sun, 27 Dec 87 14:21:39 PST Received: from bhopal.lucid.com by edsel id AA20288g; Sun, 27 Dec 87 13:14:07 PST Received: by bhopal id AA02168g; Sun, 27 Dec 87 13:15:46 PST Date: Sun, 27 Dec 87 13:15:46 PST From: Jon L White Message-Id: <8712272115.AA02168@bhopal.lucid.com> To: labrea!barmar%think.com@labrea.stanford.edu Cc: labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: Barry Margolin's message of Thu, 17 Dec 87 19:04 EST <871217190451.6.BARMAR@OCCAM.THINK.COM> Subject: Types in CL re: Actually, there is a bug in your original message, in the TYPEP call. The predicate (TYPEP A 'T1) expands to (TYPEP A '(ARRAY T2 1)) which is equivalent to (AND (ARRAYP A) (EQ (ARRAY-ELEMENT-TYPE A) 'T2) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1)) This isn't right, and is probably a good example of the single most common error when trying to figure out what the array types mean. Since a CL implementation of arrays is permitted to "upgrade" the :element-type argument into something actually supported, and since there is no requirement to preserve the original :element-type argument, then the line above (EQ (ARRAY-ELEMENT-TYPE A) 'T2) should be (SUBTYPEP 'T2 (ARRAY-ELEMENT-TYPE A)) Of course, optimizations are possible for specific T2's; but in general the element-type might have been upgraded to, for example, T. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Dec 87 22:45:51 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 87 19:33:48 PST Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 26527; 26 Dec 87 22:34:12 EST Received: by cayuga.cs.rochester.edu (5.52/h) id AA17008; Sat, 26 Dec 87 22:32:26 EST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 311778; Sat 26-Dec-87 17:46:14 EST Date: Sat, 26 Dec 87 22:32 EST From: Robert W. Kerns Subject: Question about declaration To: mike%acorn@oak.lcs.mit.edu Cc: RWK@YUKON.SCRC.Symbolics.COM, miller@cs.rochester.edu, CL@ACORN.CS.ROCHESTER.EDU In-Reply-To: The message of 16 Dec 87 13:19 EST from mike%acorn@oak.lcs.mit.edu Message-Id: <19871227033217.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Wed, 16 Dec 87 13:19 est From: mike%acorn@oak.lcs.mit.edu Date: Fri, 11 Dec 87 10:54 EST From: Robert W. Kerns Date: Fri, 11 Dec 87 01:16 EST From: Brad Miller How would you write a function declaration for the following? (defun foo (bar) (declare (type list bar)) (values-list bar) (proclaim '(function foo (list) ????)) I wouldn't. CL doesn't have any syntax for declaring a variable number of values, period. I think you can do this in CL: (function foo (list) (values &rest list)) see CLtL pg 48 under the values type specifier. The explaination for this "feature" is motivated by multiple-value-call. Yes, but you haven't really declared those values, have you? All you've done is declare that you can have a "list of them". Now, if there was a "sequence-enumerated" type (as we have in our UIMS), this would be a different matter. I.e. (function foo ((and list (sequence-enumerated symbol integer symbol integer))) (values &rest (and list (sequence-enumerated symbol integer symbol integer)))) So presumably with this declaration, you can do (multiple-value-call '+ (foo 1 2 3)) and get some kind of optimized call since it knows it's getting back a variable number of values when FOO returns. ...mike beckerle But what you'd *like* to know here is that the individual elements are integers; i.e. (function foo ((list integer)) (values &rest (list integer))) where the new argument to LIST does *NOT* work like ARRAY (meaning "a kind of list specialized to contain only integers"), but rather means "a list whose elements are all INTEGER's". There is a big gap between being able to declare the existence of a variable number of arguments or values and being able to declare their type.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Dec 87 17:55:04 EST Received: from NSS.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 24 Dec 87 14:42:30 PST Received: from computer-lab.cambridge.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa05382; 24 Dec 87 16:10 GMT To: cam-common-lisp%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK Date: Thu, 17 Dec 87 19:04 EST From: Barry Margolin Subject: Re: Types in CL Original-To: Jeff Barnett Cc: common-lisp@sail.stanford.edu In-Reply-To: <8712172057.AA00603@Think.COM> Message-Id: <871217190451.6.BARMAR@OCCAM.THINK.COM> Sender: pb%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK Date: Thu, 17 Dec 87 12:56:57 PST From: Jeff Barnett Your claim that the compiler should inhibit (SETF (AREF A 0) A) is only valid if A is declared of type T1. I never said anything about the compiler inhibiting the SETF. I said that it is incorrect to do the SETF. However, you are correct that I was wrong; you didn't show the MAKE-ARRAY form, and I assumed A was created with (setq a (make-array 1 :element-type 't2)) It may not be. What you are pointing out is that there is a problem if one tries to determine the type of an object (or its type membership status) *after* the object is created. Actually, there is a bug in your original message, in the TYPEP call. The predicate (TYPEP A 'T1) expands to (TYPEP A '(ARRAY T2 1)) which is equivalent to (AND (ARRAYP A) (EQ (ARRAY-ELEMENT-TYPE A) 'T2) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1)) Note that it never does an AREF, so the question of whether (AREF A 0) is of type T2 never comes up. When array types are used in TYPEP, the element type does not refer to the current contents, but to the array's implementation type. In order to create the type anomaly you describe, you must use the SATISFIES type specifier, e.g. (DEFUN T1P (A) (AND (ARRAYP A) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1) (TYPEP (AREF A 0) 'T2))) (DEFTYPE T1 () '(SATISFIES T1P)) When you do this, (TYPEP A 'T1) is guaranteed to infinitely recurse. Because Lisp's type system permits arbitrary code to be incorporated, the type system is Turing-equivalent, which means that the halting problem exists. Without SATISFIES, though, the problem you describe doesn't exist, because none of the other type specifiers require doing a TYPEP of constituents of the object being tested (actually, I think (TYPEP A '(COMPLEX )) is an abbreviation for (AND (COMPLEXP A) (TYPEP (REALPART A) ') (TYPEP (IMAGPART A) ')) but no recursion can occur because the parts of a complex number cannot be complex). barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Dec 87 09:37:34 EST Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 06:29:40 PST Received: by ATHENA.MIT.EDU (5.45/4.7) id AA08775; Fri, 18 Dec 87 09:29:25 EST From: Received: by M16-034-12.MIT.EDU (5.45/4.7) id AA10133; Fri, 18 Dec 87 09:29:16 EST Message-Id: <8712181429.AA10133@M16-034-12.MIT.EDU> To: common-lisp@sail.stanford.edu Subject: Re: Current practice:argument types in function declarations Date: Fri, 18 Dec 87 09:29:12 EST Yes, I often proclaim functions to take arguments of specific types. Usually this happens when I want to proclaim the return value of a function and my sense of taste insists that I proclaim the types of the arguments as well. However, none of the implementations I've used seem to do much with the information. There is one time when proclaiming the types of arguments to a function is obviously useful: when compiling the function itself. True, one could use declarations inside of the function to achive the same result, but using a proclamation keeps all of the function's type specification in one place. Without repeating them, I'd also like to voice my support of the comments made by Mike Bekerle and Brad Miller. --Stuart A. Malone  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 19:42:58 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 16:34:46 PST Return-Path: Received: from sauron.think.com by Think.COM; Thu, 17 Dec 87 19:34:15 EST Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 17 Dec 87 19:34:11 EST Date: Thu, 17 Dec 87 19:35 EST From: Barry Margolin Subject: Types in CL To: David A. Moon Cc: Jeff Barnett , common-lisp@sail.stanford.edu In-Reply-To: <19871217224647.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-Id: <871217193557.7.BARMAR@OCCAM.THINK.COM> Date: Thu, 17 Dec 87 17:46 EST From: David A. Moon This is probably all a digression from your real point. Since DEFTYPE can do anything, especially in connection with SATISFIES, it is certainly possible to create logically inconsistent type specifications, even though the particular example you gave is not actually one. Ah, yes, I just did (deftype random-type () `(member ,(random 10))) In this case, even (and (typep x 'random-type) (typep x 'random-type)) can be false, and you can go crazy trying to call a function defined (defun random-function (x) (check-type x random-type) ...) By the way, this shows that I was wrong in my last message, when I said that recursion isn't possible unless SATISFIES is used. All you need to do is (deftype int-greater-than (n) (labels ((rest (n) (cons n (rest (1+ n))))) `(member .,(rest (1+ n))))) Conceptually, the type specifier (int-greater-than N) is equivalent to (integer (N) *), but it'll never work with TYPEP. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 19:13:54 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 16:03:40 PST Return-Path: Received: from sauron.think.com by Think.COM; Thu, 17 Dec 87 19:03:09 EST Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 17 Dec 87 19:03:05 EST Date: Thu, 17 Dec 87 19:04 EST From: Barry Margolin Subject: Re: Types in CL To: Jeff Barnett Cc: common-lisp@sail.stanford.edu In-Reply-To: <8712172057.AA00603@Think.COM> Message-Id: <871217190451.6.BARMAR@OCCAM.THINK.COM> Date: Thu, 17 Dec 87 12:56:57 PST From: Jeff Barnett Your claim that the compiler should inhibit (SETF (AREF A 0) A) is only valid if A is declared of type T1. I never said anything about the compiler inhibiting the SETF. I said that it is incorrect to do the SETF. However, you are correct that I was wrong; you didn't show the MAKE-ARRAY form, and I assumed A was created with (setq a (make-array 1 :element-type 't2)) It may not be. What you are pointing out is that there is a problem if one tries to determine the type of an object (or its type membership status) *after* the object is created. Actually, there is a bug in your original message, in the TYPEP call. The predicate (TYPEP A 'T1) expands to (TYPEP A '(ARRAY T2 1)) which is equivalent to (AND (ARRAYP A) (EQ (ARRAY-ELEMENT-TYPE A) 'T2) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1)) Note that it never does an AREF, so the question of whether (AREF A 0) is of type T2 never comes up. When array types are used in TYPEP, the element type does not refer to the current contents, but to the array's implementation type. In order to create the type anomaly you describe, you must use the SATISFIES type specifier, e.g. (DEFUN T1P (A) (AND (ARRAYP A) (= (ARRAY-RANK A) 1) (= (ARRAY-DIMENSION A 0) 1) (TYPEP (AREF A 0) 'T2))) (DEFTYPE T1 () '(SATISFIES T1P)) When you do this, (TYPEP A 'T1) is guaranteed to infinitely recurse. Because Lisp's type system permits arbitrary code to be incorporated, the type system is Turing-equivalent, which means that the halting problem exists. Without SATISFIES, though, the problem you describe doesn't exist, because none of the other type specifiers require doing a TYPEP of constituents of the object being tested (actually, I think (TYPEP A '(COMPLEX )) is an abbreviation for (AND (COMPLEXP A) (TYPEP (REALPART A) ') (TYPEP (IMAGPART A) ')) but no recursion can occur because the parts of a complex number cannot be complex). barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 18:02:11 EST Received: from [8.2.0.18] by SAIL.STANFORD.EDU with TCP; 17 Dec 87 14:52:28 PST Date: 17 Dec 1987 17:50-EST Sender: NGALL@G.BBN.COM Subject: Re: Types in CL From: NGALL@G.BBN.COM To: jbarnett@NRTC.NORTHROP.COM Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]17-Dec-87 17:50:23.NGALL> In-Reply-To: The message of Thu, 17 Dec 87 10:48:05 PST from Jeff Barnett Date: Thu, 17 Dec 87 10:48:05 PST From: Jeff Barnett ... PROBLEM I. Assume that the following have been evaluated (DEFTYPE T1 '(ARRAY T2 1)) (DEFTYPE T2 '(NOT T1)) Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)). What should the value of (TYPEP A 'T1) be? ... Yes, a problem. CLtL should specify that the result of a call to TYPEP that causes an identical subcall (i.e., it loops) is undefined. Here is a related (but perhaps better motivated example): (DEFTYPE TREE (LEAF-TYPE) `(OR ,LEAF-TYPE (VECTOR TREE 2))) (SETF CIRC-TREE '#(NIL NIL)) (FILL CIRC-TREE CIRC-TREE) (TYPEP CIRC-TREE '(TREE INTEGER)) => {undefined} This same problem affects CLtL's definitions of LIST, TRUE-LIST, and DOTTED-LIST on pg. 28: A circular list is a LIST that is not a TRUE-LIST or a DOTTED-LIST... PROBLEM II. Assume that the following return non-NIL (SUBTYPEP 'T1 'T2) (SUBTYPEP 'T2 'T3) The question is what are the subtypes of the type specifier (FUNCTION (T2) T2) I think that the answer is (FUNCTION (T3) T1) because the type-specific contract of an F in type (FUNCTION (T2) T2) is to (1) accept as arguments objects in T2 and (2) return objects in T2. Therefore, an F that accepts objects in T3 (which includes all of T2) and returns objects in T1 (all of which are in T2) satisfies that contract. An F in (FUNCTION (T1) T3) does not because (1) it does not promise to handle an object in T2-T1 and (2) may return an object in T3-T2. Therefore, (SUBTYPEP '(FUNCTION (T3) T1) '(FUNCTION (T2) T2)) ... The type specifier (FUNCTION ...) is not acceptable to TYPEP (pg. 47), therefore it is not acceptable to SUBTYPEP (pg. 72). -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 17:56:47 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 14:47:01 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306293; Thu 17-Dec-87 17:47:00 EST Date: Thu, 17 Dec 87 17:46 EST From: David A. Moon Subject: Types in CL To: Jeff Barnett cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 17 Dec 87 13:48 EST from Jeff Barnett Message-ID: <19871217224647.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 17 Dec 87 10:48:05 PST From: Jeff Barnett PROBLEM I. Assume that the following have been evaluated (DEFTYPE T1 '(ARRAY T2 1)) (DEFTYPE T2 '(NOT T1)) Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)). What should the value of (TYPEP A 'T1) be? You need to re-read the definition of the ARRAY type specifier on CLtL page 46, being careful also to read page 45, which doesn't look it's part of this, but is necessary in order to understand it. The -element-type- portion of the ARRAY type specifier doesn't mean what you think it means. This is interesting, because your "Problem I" is a good argument against proposals that have been raised from time to time to change the definition of the ARRAY type specifier to be what you thought it was. This is probably all a digression from your real point. Since DEFTYPE can do anything, especially in connection with SATISFIES, it is certainly possible to create logically inconsistent type specifications, even though the particular example you gave is not actually one.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 16:07:50 EST Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 12:57:21 PST Date: Thu, 17 Dec 87 12:56:57 PST From: Jeff Barnett To: Barry Margolin cc: Jeff Barnett , common-lisp@sail.stanford.edu Subject: Re: Types in CL Your claim that the compiler should inhibit (SETF (AREF A 0) A) is only valid if A is declared of type T1. It may not be. What you are pointing out is that there is a problem if one tries to determine the type of an object (or its type membership status) *after* the object is created. In fact, the runtime package and compiler can offer you more protection if an object is marked with a type when it is created; only then can modifications and so on be checked locally. However this loses something that may not be obvious: an object can not be referenced by a register unless its marked type entails ALL type restrictions imposed by the reference. It is not sufficient that its current configuration passes muster. Jeff P.S. The barber is an old friend.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 15:31:05 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 12:20:30 PST Return-Path: Received: from sauron.think.com by Think.COM; Thu, 17 Dec 87 15:19:56 EST Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 17 Dec 87 15:19:52 EST Date: Thu, 17 Dec 87 15:21 EST From: Barry Margolin Subject: Types in CL To: Jeff Barnett Cc: common-lisp@sail.stanford.edu In-Reply-To: <8712171849.AA02757@Think.COM> Message-Id: <871217152141.3.BARMAR@OCCAM.THINK.COM> Date: Thu, 17 Dec 87 10:48:05 PST From: Jeff Barnett PROBLEM I. Assume that the following have been evaluated (DEFTYPE T1 '(ARRAY T2 1)) (DEFTYPE T2 '(NOT T1)) Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)). By doing (SETF (AREF A 0) A) you have violated the type declaration you specified, because you said that the elements of the array would never be of the same type as the array itself, so a compiler would be justified in assuming that (EQ A (AREF A 0)) is never true. What should the value of (TYPEP A 'T1) be? It is easy to see that A is in type T1 if and only if it is not in type T1. A type specification mechanism that allows (1) recursive definitions and (2) a negation operation is sure to have this problem. Look up Russell's paradox (the one about the barber who shaves all and only people who don't shave themselves, or the catalog of all books not in any other catalog) in a logic book. Any sufficiently expressive class system allows such classes to be specified, even though such sets cannot actually exist because they are self-contradictory. Your example isn't really like this, because the Lisp type system lacks the ability to specify that an array of type T1 contains ALL objects of type T2. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 13:59:42 EST Received: from NRTC.NORTHROP.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 87 10:48:26 PST Date: Thu, 17 Dec 87 10:48:05 PST From: Jeff Barnett To: common-lisp@sail.stanford.edu cc: jbarnett@nrtc.northrop.com Subject: Types in CL Recently, there has been some message traffic concerning functional type specification and related topics. The purpose of this note is to point out two problems with the CL type mechanism that I have not seen discussed: the first concerns a case were the value of TYPEP *must* be undefined and the second concerns the definition of a subtype of a functional type. PROBLEM I. Assume that the following have been evaluated (DEFTYPE T1 '(ARRAY T2 1)) (DEFTYPE T2 '(NOT T1)) Let A be a one-dimensional array of size 1 such that (EQ A (AREF A 0)). What should the value of (TYPEP A 'T1) be? It is easy to see that A is in type T1 if and only if it is not in type T1. A type specification mechanism that allows (1) recursive definitions and (2) a negation operation is sure to have this problem. Obviously, we want recursive specification so that chains or rings of same-typed structures can be specified and we want negation so that the programmer does not need to explicitly list every possible alternative type in his definition. PROBLEM II. Assume that the following return non-NIL (SUBTYPEP 'T1 'T2) (SUBTYPEP 'T2 'T3) The question is what are the subtypes of the type specifier (FUNCTION (T2) T2) I think that the answer is (FUNCTION (T3) T1) because the type-specific contract of an F in type (FUNCTION (T2) T2) is to (1) accept as arguments objects in T2 and (2) return objects in T2. Therefore, an F that accepts objects in T3 (which includes all of T2) and returns objects in T1 (all of which are in T2) satisfies that contract. An F in (FUNCTION (T1) T3) does not because (1) it does not promise to handle an object in T2-T1 and (2) may return an object in T3-T2. Therefore, (SUBTYPEP '(FUNCTION (T3) T1) '(FUNCTION (T2) T2)) should be non-NIL while (SUBTYPEP '(FUNCTION (T1) T3) '(FUNCTION (T2) T2)) should be NIL. Note, as SUBTYPEP decomposes functional type specifications and recurs, it must *reverse* the order of its arguments when checking argument types---original order is used when value types are checked. It is somewhat amusing to trace a case where the type specification of either the arguments and/or the values are themselves functional types or where functional types are recursively specified. One reason to make sure that determining subtype-ness of functional types is as accurate as it can be as often as possible arises because most LISPS do incremental compilations and are interactive. If a function is recompiled and either its argument or value types change, it would be good to inform the user where there are calls that are no longer type-compatible. IF THE NEW TYPE OF THE FUNCTION IS A SUBTYPE OF THE OLD, THEN, AS FAR AS TYPE CHECKING IS CONCERNED, EVERYTHING MUST BE OKAY. It is only when this is not true, that it is necessary to check the types of objects actually passed to the function from other code or see what assumptions have been made in consuming the returned objects. There is a slight generalization of the comments as to what is a reasonable definition of subtype of functional types. Assume that a variable or register has been given a type specification. Let that type specification be changed. There are three possibilities: 1. THE NEW TYPE SPECIFICATION IS A SUBTYPE OF THE OLD Code that only reads the cell is not affected. Code that writes the cell may or may not be valid. 2. THE NEW TYPE SPECIFICATION IS A SUPERTYPE OF THE OLD Code that only writes the cell is not affected. Code that reads the cell may or may not be valid. 3. THE NEW AND OLD TYPE SPECIFICATIONS ARE NOT COMPARABLE Any code that reads the cell may or may not be valid. The reason that the above implies the rules for functional subtype determination is that, from the point of view of a function caller, arguments represent write-only registers while values represent read-only registers. A while ago, there was some discussion of having a class of read-only goodies in LISP. If that is ever sanctioned, these comments may provide some guidance in error checking interactions of that mechanism with type declarations and revisions. Jeff  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 10:45:48 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 07:35:17 PST Received: from XX.LCS.MIT.EDU (XX.LCS.MIT.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 26111; 17 Dec 87 10:36:14 EST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 Dec 87 10:08-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 72757; 17 Dec 87 09:46:25-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 89447; Wed 16-Dec-87 13:11:58-EST Date: Wed, 16 Dec 87 13:19 est From: mike%acorn@oak.lcs.mit.edu To: RWK@YUKON.SCRC.Symbolics.COM Subject: 1Question about declaration0 Cc: miller@cs.rochester.edu, CL@ACORN.CS.ROCHESTER.EDU Date: Fri, 11 Dec 87 10:54 EST From: Robert W. Kerns Date: Fri, 11 Dec 87 01:16 EST From: Brad Miller 1 How would you write a function declaration for the following? (defun foo (bar) (declare (type list bar)) (values-list bar) (proclaim '(function foo (list) ????)) 0I wouldn't. CL doesn't have any syntax for declaring a variable number of values, period. I think you can do this in CL: (function foo (list) (values &rest list)) see CLtL pg 48 under the values type specifier. The explaination for this "feature" is motivated by multiple-value-call. So presumably with this declaration, you can do (multiple-value-call '+ (foo 1 2 3)) and get some kind of optimized call since it knows it's getting back a variable number of values when FOO returns. ...mike beckerle  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Dec 87 03:13:26 EST Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 17 Dec 87 00:04:27 PST Date: Thu, 17 Dec 87 03:05 EST From: Brad Miller Subject: Re: Current practice:argument types in function declarations To: masinter.PA@Xerox.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <871216-013219-2778@Xerox> Message-ID: <871217030542.2.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627 Phone: 716-275-1118 Date: 16 Dec 87 1:32:02 PST From: masinter.PA@Xerox.COM Does anyone *have* any Common Lisp code which contains such declarations? What is the intent of the declarations, other than as documentation? All the code I write has such delcarations, including for the types of all returned values. The immediate purpose is documentation since it's ignored on the machine I happen to work on (a symbolics) but it's my hope that in future the compiler/interpreter would complain about calls to the function that pass the wrong type of argument at compile time, if it can tell. (runtime would depend on OPTIMIZE SAFETY or some such, and probably local declarations inside the defun or whatever). Also, it could be used as a note to the debugger, since it could flag that an argument was of an unexpected type if some other problem arises and it gets invoked. (this would help track down the error). But I'm a user, not an implementor: this is just what I hope to eventually get out of it. As I said, right now it's just documentation so the next guy knows what I expected the function to handle when I wrote it. Brad Miller ------ miller@cs.rochester.edu {...allegra!rochester!miller} Brad Miller University of Rochester Computer Science Department  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 87 13:55:56 EST Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 10:45:26 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 16 Dec 87 13:34-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 72595; 16 Dec 87 13:28:50-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 89445; Wed 16-Dec-87 13:03:38-EST Date: Wed, 16 Dec 87 13:11 est From: mike%acorn@oak.lcs.mit.edu To: masinter.PA@Xerox.COM Subject: Current practice:argument types in function declarations Cc: common-lisp@sail.stanford.edu From: masinter.PA@Xerox.COM Date: 16 Dec 87 1:32:02 PST >Is anyone aware of any (released? supported?) Common Lisp implementation that >pays any attention at all to the types of arguments, e.g., for which > (proclaim '(function my-function (list vector) t)) >has any effect different from > (proclaim '(function my-function (t t) t)) > ? >Does anyone *have* any Common Lisp code which contains such declarations? >What is the intent of the declarations, other than as documentation? First off, either signature tells you more than nothing at all, since it fixes the number of arguments. Presumably, you have to check the number of arguments as well as the types for really safe calls. As for use, we are not using them currently, but plan to use them. The goal is to generate "safe" calls for functions when compiling if the type signature is unknown. If the type signature is known; however, the checking burden is placed on the caller (and can be minimized via type inference, etc.) and an unsafe call is generated. The type signature can be known either via block compilation, or by using function type proclamations. In any case if you ftype a function and a call can be shown to contradict the proclamation, then you should get a warning and a safe (slow) call. The one difficulty with these things is that common lisp's type language doesn't allow you to specify accurate types for things like <. E.G., (proclaim '(ftype < (function (&rest ??) (or T nil)))) For ?? you'd like to say "zero or more non-complex numbers". You do NOT want to say LIST here. I am considering defining a (list-of ...) type specifier. where the argument is a type. This cannot really be written in common lisp, since it doesn't allow parameterized types in general. But we as implementors can put it in place as an extension. Mike Beckerle Gold Hill Computers.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 87 04:41:36 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Dec 87 01:32:09 PST Received: from Cabernet.ms by ArpaGateway.ms ; 16 DEC 87 01:32:19 PST From: masinter.PA@Xerox.COM Date: 16 Dec 87 1:32:02 PST Subject: Current practice:argument types in function declarations To: common-lisp@sail.stanford.edu cc: masinter.PA@Xerox.COM Message-ID: <871216-013219-2778@Xerox> The cleanup committee is considering various issues surrounding function declarations, and, in particular, declarations of the types of arguments. We've had considerable input about what such declarations could mean, should mean, what CLtL says they mean. Rather than going over all of that, this is a question about current practice: What do current implementations actually do? What do current users actually use have in their programs? Is anyone aware of any (released? supported?) Common Lisp implementation that pays any attention at all to the types of arguments, e.g., for which (proclaim '(function my-function (list vector) t)) has any effect different from (proclaim '(function my-function (t t) t)) ? Does anyone *have* any Common Lisp code which contains such declarations? What is the intent of the declarations, other than as documentation?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 87 08:35:44 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 14 Dec 87 05:27:03 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306383; Sat 12-Dec-87 18:13:15 EST Date: Sat, 12 Dec 87 18:13 EST From: Robert W. Kerns Subject: string as vector of fixnums ? To: Masayuki Ida cc: common-lisp@SAIL.STANFORD.EDU, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET In-Reply-To: <8712120726.AA25820@tansei.cc.u-tokyo.junet> Message-ID: <19871212231315.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Sat, 12 Dec 87 16:26:03+0900 From: Masayuki Ida A Question on the history; When try to get a component of a string as a number, we must get it as a character and then coerce it to number type. I think it is ridiculous. This situation attacked me several times when I wrote codes for data conversion among lots of machines, deciding to conform Common Lisp 100%. If you're doing code conversion, you probably don't want to be using characters at all, but rather arrays of unsigned bytes. (I've often said that the only way to write a portable file is with (UNSIGNED-BYTE 8)). Consider reading a file of EBCDIC in a lisp which only supports 7-bit ascii for its characters, for example. You could get errors or lose bits if you try to read it into a string! (I doubt there are any implementations which only store 7 bits in their strings, but they would be quite legitimate). Certainly, many EBCDIC codes may be undefined values for characters in an ASCII lisp, and the byte 65 is unlikely to really mean #\A in EBCDIC. ( historically, many dialects of Lisp can get a component of a string as a number easily. On symbolics, there are art-strings types, with which we can treat a character of a string as number.) This hasn't been true for a year. The types you describe were part of old ZetaLisp, and do not exist in Release 7 at all. I feel Common Lisp degrades as for the treatment of characters. Or, there must be a decision on it I did not know. Or, CLtL ignores this issue as an implementation-dependent thing. I feel that what Common Lisp does here is exactly the right thing. However, I believe CL needs to add facilities for specifying the external coding of character files, as part of OPEN. Any opinions ? or I will appreciate if someone give me the explanation for the process or the history on the decision . Thank you. Masayuki Ida  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 87 08:21:25 EST Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 14 Dec 87 05:12:19 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150334; Sat 12-Dec-87 17:09:44 EST Date: Sat, 12 Dec 87 17:11 EST From: Daniel L. Weinreb Subject: string as vector of fixnums ? To: a37078%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET In-Reply-To: <8712120726.AA25820@tansei.cc.u-tokyo.junet> Message-ID: <19871212221125.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sat, 12 Dec 87 16:26:03+0900 From: Masayuki Ida A Question on the history; When try to get a component of a string as a number, we must get it as a character and then coerce it to number type. I think it is ridiculous. There is more than one mapping from characters to integers. Some computers use the ASCII code, others use the EBCDIC code, and around the world I presume there must be other codes I've never heard of. One reason for having character objects was so that programs could be portable from one implementation of Common Lisp to another, even if the two implementations used different character codes. Another reason was so that character objects would have a recognizable printed representation. Not many people are good at memorizing the entire ASCII code, and it's even harder to memorize the longer codes such as for Kanji characters.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Dec 87 17:05:15 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 13 Dec 87 13:52:33 PST Received: from Think.COM (THINK.COM) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25807; 13 Dec 87 16:53:04 EST Return-Path: Received: from sauron.think.com by Think.COM; Sun, 13 Dec 87 16:06:07 EST Received: from ZENO.THINK.COM by sauron.think.com; Sun, 13 Dec 87 16:06:01 EST Date: Sun, 13 Dec 87 16:07 EST From: Jeff Mincy Subject: 1Question about declaration0 To: RWK@yukon.scrc.symbolics.com, miller@cs.rochester.edu Cc: CL@acorn.cs.rochester.edu In-Reply-To: <19871211155410.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-Id: <871213160754.1.MINCY@ZENO.THINK.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL :CONDENSED NIL) "CPTFONTC") Fonts: CPTFONT, CPTFONTC Date: Fri, 11 Dec 87 10:54 EST From: Robert W. Kerns Date: Fri, 11 Dec 87 01:16 EST From: Brad Miller 1How would you write a function declaration for the following? 0 1(defun foo (bar) 0 1(declare (type list bar)) 0 1(values-list bar) 0 1(proclaim '(function foo (list) ????)) 0 I wouldn't. CL doesn't have any syntax for declaring a variable number of values, period. The &optional, &rest, and &key markers may appear in the value-type list for the values type-specifier. p 48, CLtL. The value-type for the function type-specifier may be a values type specifier. p 47 CLtL Therefore One can say (function (number) (values number &optional float)), to specify that a function returns a variable number of values. But, It doesnt mean that anyone will listen to the declaration, just because you can say it. -jeff  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Dec 87 20:34:39 EST Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 12 Dec 87 17:23:36 PST Received: from mcvax.UUCP by uunet.UU.NET (5.54/1.14) with UUCP id AA18489; Sat, 12 Dec 87 20:23:27 EST From: mcvax!jungfrau!ceb@uunet.UU.NET Received: by mcvax.cwi.nl; Sun, 13 Dec 87 01:50:25 +0100 (MET) Received: by cernvax.uucp (1.2/Ultrix2.0-B) id AA19845; Sun, 13 Dec 87 01:32:49 +0100 Date: Sun, 13 Dec 87 01:32:49 +0100 Message-Id: <8712130032.AA19845@cernvax.uucp> To: common-lisp@sail.stanford.edu Subject: sloop There was a recent brief mention in a mailing on this list of the existence of a common-lisp loop macro called SLOOP. Its existence is news to me, and I would be interested to find out more about it, so if someone would mail me some specifics, I'd be grateful. We currently use a home-grown CL loop macro here (mountain grown?), and I'd really rather mainstream as soon as there is a stream to main to. Charles Buckley uucp: mcvax!ethz!ceb earn: BUCKLEY@CZHETH5A arpa: mcvax!ethz!ceb@uunet.uu.net cb@sail.stanford.edu Integrated Systems Laboratory Federal Institute of Technology (ETH) Zuerich, Switzerland Postal Address: Wiesgasse 9 CH-8304 Wallisellen Tel: +411 256 52 45  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Dec 87 15:24:48 EST Received: from NSS.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 12 Dec 87 12:15:23 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa07983; 12 Dec 87 20:07 GMT From: Jeff Dalton Date: Sat, 12 Dec 87 20:07:29 GMT Message-Id: <27525.8712122007@aiva.ed.ac.uk> To: common-lisp@sail.stanford.edu, ida <@relay.cs.net,@utokyo-relay.csnet:ida@tansei.cc.u-tokyo.junet> Subject: string as vector of fixnums ? > Date: Sat, 12 Dec 87 16:26:03+0900 > From: Masayuki Ida > A Question on the history; > When try to get a component of a string as a number, we must > get it as a character and then coerce it to number type. > I think it is ridiculous. The problem is that the numbers aren't portable but the characters are. #\A is always #\A, but it isn't always 65. I believe Common Lisp does not represent characters as numbers because it was trying for a more abstract representation and to get away from the notion that each character was a particular number. I suspect it is relatively rare for anyone to want the number associated with a character, and so requiring an extra step to get the number does not seem so bad a thing. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Dec 87 13:30:21 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 12 Dec 87 02:34:17 PST Received: from relay2.cs.net by RELAY.CS.NET id ac17968; 12 Dec 87 2:55 EST Received: from utokyo-relay by RELAY.CS.NET id ab16765; 12 Dec 87 2:47 EST Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET) id AA12716; Sat, 12 Dec 87 16:26:29 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0) id AA25820; Sat, 12 Dec 87 16:26:03+0900 Date: Sat, 12 Dec 87 16:26:03+0900 From: Masayuki Ida Return-Path: Message-Id: <8712120726.AA25820@tansei.cc.u-tokyo.junet> To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: string as vector of fixnums ? A Question on the history; When try to get a component of a string as a number, we must get it as a character and then coerce it to number type. I think it is ridiculous. This situation attacked me several times when I wrote codes for data conversion among lots of machines, deciding to conform Common Lisp 100%. ( historically, many dialects of Lisp can get a component of a string as a number easily. On symbolics, there are art-strings types, with which we can treat a character of a string as number.) I feel Common Lisp degrades as for the treatment of characters. Or, there must be a decision on it I did not know. Or, CLtL ignores this issue as an implementation-dependent thing. Any opinions ? or I will appreciate if someone give me the explanation for the process or the history on the decision . Thank you. Masayuki Ida  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Dec 87 04:39:51 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 Dec 87 01:31:58 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 305840; Fri 11-Dec-87 15:56:33 EST Date: Fri, 11 Dec 87 15:56 EST From: Robert W. Kerns Subject: Re: structure type specifier To: Larry_Masinter.PARC@Xerox.COM cc: cfry@OZ.AI.MIT.EDU, Common-Lisp@sail.stanford.EDU In-Reply-To: <871208-162102-5563@Xerox> Message-ID: <19871211205618.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 8 Dec 87 16:20:16 PST (Tuesday) From: "Larry_Masinter.PARC"@Xerox.COM Its legit and even good design practice to treat every data type as if it might be a structure. If Xerox Common Lisp had STRUCTUREP, it would be true of every object. (Of course, some objects, like fixnums, don't have slots and are "preallocated".) STRUCTURE (and STRUCTUREP) would just indicate whether they follow the protocol of things you can to do **named structures**. (That is, Inquiring about slots, acessing the slots found, and basically getting your hands on the information in the original DEFSTRUCT). Since fixna are neither defined nor definable as named structures, for them to be STRUCTURE's would be a travesty. I don't know just what YOU think the point of having such a type would be if you're going to make Xerox Common Lisp have everything be a STRUCTURE. Perhaps your point was really that some subtypes of COMMON may be implemented as DEFSTRUCT's (for example, RANDOM-STATE is a good candidate).  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Dec 87 03:42:43 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 22:22:17 PST Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25769; 12 Dec 87 01:24:07 EST Received: by cayuga.cs.rochester.edu (5.52/h) id AA27119; Sat, 12 Dec 87 01:21:53 EST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 305552; Fri 11-Dec-87 10:54:16 EST Date: Fri, 11 Dec 87 10:54 EST From: Robert W. Kerns Subject: 1Question about declaration0 To: miller@cs.rochester.edu Cc: CL@ACORN.CS.ROCHESTER.EDU In-Reply-To: <871211011624.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Message-Id: <19871211155410.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (NIL :CONDENSED NIL) "CPTFONTC") Fonts: CPTFONT, CPTFONTC Date: Fri, 11 Dec 87 01:16 EST From: Brad Miller 1 How would you write a function declaration for the following? (defun foo (bar) (declare (type list bar)) (values-list bar) (proclaim '(function foo (list) ????)) 0I wouldn't. CL doesn't have any syntax for declaring a variable number of values, period.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Dec 87 15:21:32 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 12:11:35 PST Received: from DOUGHNUT.CS.ROCHESTER.EDU (DOUGHNUT.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25734; 11 Dec 87 15:13:28 EST Date: Fri, 11 Dec 87 15:13 EST From: Brad Miller Subject: Re: Question about declaration To: quiroz@ACORN.CS.ROCHESTER.EDU cc: CL@ACORN.CS.ROCHESTER.EDU In-Reply-To: <8712111027.AA00767@jabbah.cs.rochester.edu> Message-ID: <871211151322.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Default-Character-Style: (:FIX :CONDENSED :NORMAL) Fonts: CPTFONTC Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627 Phone: 716-275-1118 Date: Fri, 11 Dec 87 05:27:16 -0500 From: quiroz If (as it seems) `bar' isn't restricted to be anything sharper than `list', then the only thing we know is that `foo' returns multiple values. (Indeed, `foo' is just another name for `values-list', but I assume you are just abstracting here the useful aspects of a real `foo' of yours.) T I suspect I would write something as uninformative as (proclaim '(function foo (list) (values &rest list))) which is marginally better than no declaration at all. Are &markers accepted in these definitions? They aren't lamda lists. I didn's see anything in CLtL to indicate that they are acceptible... Thnx, Brad ------ miller@cs.rochester.edu {...allegra!rochester!miller} Brad Miller University of Rochester Computer Science Department  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Dec 87 12:01:56 EST Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 08:50:51 PST Received: by cayuga.cs.rochester.edu (5.52/h) id AA24809; Fri, 11 Dec 87 11:50:29 EST Received: from loopback by furud.cs.rochester.edu (3.2/h) id AA00350; Fri, 11 Dec 87 11:50:24 EST Message-Id: <8712111650.AA00350@furud.cs.rochester.edu> To: common-lisp@SAIL.STANFORD.EDU Subject: Re: Question about declaration In-Reply-To: Your message of 11 Dec 87 11:01:00 -0500. <[G.BBN.COM]11-Dec-87 11:01:23.NGALL> Date: Fri, 11 Dec 87 11:50:20 -0500 From: quiroz@cs.rochester.edu | I think the type specifier for the function FOO is supposed to be | (PROCLAIM '(FUNCTION FOO (LIST) (VALUES &REST T)) | This is because the type specifier following &REST is supposed to declare | the type of all the remaining arguments/values. You won't find this in CLtL, | but I have it marked in my copy as a proposed clarification in Guy Steele's | list. The clarification would be most valuable. As it stands now, I read your declaration as saying `... and the type of the &REST argument is T', when we probably want to say `... list of T', although the latter cannot be uttered in the type calculus of Common Lisp. I remember there used to be a file ftpable from somewhere, which contained authoritative errata and clarifications. Does it still exist? =Cesar -------- Cesar Augusto Quiroz Gonzalez Department of Computer Science ...allegra!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Dec 87 11:12:51 EST Received: from [8.2.0.18] by SAIL.STANFORD.EDU with TCP; 11 Dec 87 08:00:25 PST Date: 11 Dec 1987 11:01-EST Sender: NGALL@G.BBN.COM Subject: Re: Question about declaration From: NGALL@G.BBN.COM To: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]11-Dec-87 11:01:23.NGALL> In-Reply-To: <8712111027.AA00767@jabbah.cs.rochester.edu> Date: Fri, 11 Dec 87 05:27:16 -0500 From: quiroz ... I suspect I would write something as uninformative as (proclaim '(function foo (list) (values &rest list))) which is marginally better than no declaration at all. While at this, how do you use the &-markers in a `values' specifier? For instance, the only things I believe make sense after &rest in a `values' specifier should be `null' (utterly useless) or `list' (quite uninformative). Anything more general than `list' would admit of impossible trash, anything disjoint with list is unspeakable. Yet, KCL just let me try `...&rest float'. Better not think what a compiler could do with such. =Cesar I think the type specifier for the function FOO is supposed to be (PROCLAIM '(FUNCTION FOO (LIST) (VALUES &REST T)) This is because the type specifier following &REST is supposed to declare the type of all the remaining arguments/values. You won't find this in CLtL, but I have it marked in my copy as a proposed clarification in Guy Steele's list. If this is NOT the behavior of &REST, then all &REST could tell a compiler/programmer is that this function can take/return any number of arguments (depending on where &REST is used). -- Nick  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Dec 87 05:39:24 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 11 Dec 87 02:27:49 PST Received: from jabbah.cs.rochester.edu (JABBAH.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 25625; 11 Dec 87 05:29:06 EST Received: from loopback by jabbah.cs.rochester.edu (3.2/h) id AA00767; Fri, 11 Dec 87 05:27:19 EST Message-Id: <8712111027.AA00767@jabbah.cs.rochester.edu> To: miller@cs.rochester.edu Cc: CL@ACORN.CS.ROCHESTER.EDU Subject: Re: Question about declaration In-Reply-To: Your message of Fri, 11 Dec 87 01:16:00 -0500. <871211011624.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Date: Fri, 11 Dec 87 05:27:16 -0500 From: quiroz If (as it seems) `bar' isn't restricted to be anything sharper than `list', then the only thing we know is that `foo' returns multiple values. (Indeed, `foo' is just another name for `values-list', but I assume you are just abstracting here the useful aspects of a real `foo' of yours.) I suspect I would write something as uninformative as (proclaim '(function foo (list) (values &rest list))) which is marginally better than no declaration at all. While at this, how do you use the &-markers in a `values' specifier? For instance, the only things I believe make sense after &rest in a `values' specifier should be `null' (utterly useless) or `list' (quite uninformative). Anything more general than `list' would admit of impossible trash, anything disjoint with list is unspeakable. Yet, KCL just let me try `...&rest float'. Better not think what a compiler could do with such. =Cesar -------- Cesar Augusto Quiroz Gonzalez Department of Computer Science ...allegra!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Dec 87 01:20:43 EST Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 10 Dec 87 22:14:20 PST Date: Fri, 11 Dec 87 01:16 EST From: Brad Miller Subject: Question about declaration To: CL@ACORN.CS.ROCHESTER.EDU Message-ID: <871211011624.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Default-Character-Style: (:FIX :CONDENSED :NORMAL) Fonts: CPTFONTC Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 401A CS Building, Computer Science Department, University of Rochester, Rochester NY 14627 Phone: 716-275-1118 How would you write a function declaration for the following? (defun foo (bar) (declare (type list bar)) (values-list bar) (proclaim '(function foo (list) ????)) Brad Miller ------ miller@cs.rochester.edu {...allegra!rochester!miller} Brad Miller University of Rochester Computer Science Department  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Dec 87 15:53:22 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 87 12:42:55 PST Received: from relay2.cs.net by RELAY.CS.NET id an20901; 10 Dec 87 15:10 EST Received: from ubc by RELAY.CS.NET id af07212; 10 Dec 87 14:52 EST Received: by ubc.csnet id AA01930; Thu, 10 Dec 87 10:45:39 pst Date: 10 Dec 87 10:45 -0800 From: list-request%ubc.csnet@RELAY.CS.NET MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Sender: Marilyn Martin To: Common-Lisp@SAIL.STANFORD.EDU MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-Id: <1189*martin@ean.ubc.cdn> Subject: please add us to Common Lisp Subject: please add us to Common Lisp Can you please add the address common-lisp%ubc.csnet@relay.cs.net to the Common Lisp list? We would like to redistribute the list to the Canadian research network CDNnet. Also, you may get requests to join the list directly from CDNnet users. If it is easy to record somewhere, can you direct those requests to me? The addresses will probably look like user%subdomain.cdn%ubc.csnet@relay.cs.net If you already have CDNnet users on the list, I'd be glad to take over the redistribution to them from here. Thanks, Marilyn Martin University of British Columbia list-request@ubc.csnet list-request%ubc.csnet@relay.cs.net  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Dec 87 14:40:14 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87 11:24:58 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 304367; Wed 9-Dec-87 13:49:33 EST Date: Wed, 9 Dec 87 13:49 EST From: Robert W. Kerns Subject: Re: structure type specifier To: baldwin@cs.rochester.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <2775047786-60842@BYRD> Message-ID: <19871209184929.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Wed, 9 Dec 87 09:36:26 EST From: baldwin@ACORN Problem is that things not mentioned at all in CLtL are necessarily implementation-dependent and so I have an "honest" choice between compromising portability for clear handling of these objects or not, whereas with structures I don't have this choice - they're a standard part of Common Lisp, but Common Lisp doesn't give me the tools to do much with them. (Put another way, if I want to handle an implementation-dependent extension to Common Lisp in an implementation-dependent way I don't feel as bad about it as handling a defined part of the language in a non-portable way.) For this reason I still think Common Lisp badly needs at least minimal support a "structure" type. I don't disagree, I'm just pointing out that it's not worth much unless we also include minimal support for working with objects of the STRUCTURE type. Neither you nor I are the first to point this out.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Dec 87 09:52:42 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87 06:34:55 PST Received: from BYRD.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 25478; Wed 9-Dec-87 09:36:30 EST Message-Id: <2775047786-60842@BYRD> Sender: baldwin@BYRD Date: Wed, 9 Dec 87 09:36:26 EST Reply-To: baldwin@cs.rochester.edu From: baldwin@ACORN To: common-lisp@sail.stanford.edu Subject: Re: structure type specifier In-Reply-To: Msg of Tue, 8 Dec 87 19:23 EST from Barry Margolin Presumably your tools also have to punt if the object is of a type not mentioned at all in CLtL (e.g. a flavor).... Problem is that things not mentioned at all in CLtL are necessarily implementation-dependent and so I have an "honest" choice between compromising portability for clear handling of these objects or not, whereas with structures I don't have this choice - they're a standard part of Common Lisp, but Common Lisp doesn't give me the tools to do much with them. (Put another way, if I want to handle an implementation-dependent extension to Common Lisp in an implementation-dependent way I don't feel as bad about it as handling a defined part of the language in a non-portable way.) For this reason I still think Common Lisp badly needs at least minimal support a "structure" type.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 87 19:50:10 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:28:41 PST Return-Path: <@Think.COM:barmar@Think.COM> Received: from sauron.think.com by Think.COM; Tue, 8 Dec 87 19:23:49 EST Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 8 Dec 87 19:22:21 EST Date: Tue, 8 Dec 87 19:23 EST From: Barry Margolin Subject: Re: structure type specifier To: baldwin@cs.rochester.edu Cc: Robert W. Kerns , common-lisp@sail.stanford.edu In-Reply-To: <2774962087-99174@BYRD> Message-Id: <871208192313.6.BARMAR@OCCAM.THINK.COM> Date: Tue, 8 Dec 87 09:48:07 EST From: baldwin@ACORN In all of my tools I continually find myself wanting to find out if an argument is a structure precisely BECAUSE Common Lisp doesn't provide primitives for getting inside a structure - knowing that something is a structure then tells the printer/inspector/etc that it has to punt (e.g., hope the user provided a decent :print-function, or something like that). Presumably your tools also have to punt if the object is of a type not mentioned at all in CLtL (e.g. a flavor). So the structure case could be handled by the T clause in your TYPECASE. Unless it can do something different with structures than it does with other undecipherable objects there doesn't seem to be a need for a way to distinguish them. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 87 19:40:56 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87 16:21:14 PST Received: from Riesling.ms by ArpaGateway.ms ; 08 DEC 87 16:21:02 PST Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 8 Dec 87 16:20:16 PST (Tuesday) Subject: Re: structure type specifier From: "Larry_Masinter.PARC"@Xerox.COM To: cfry@OZ.AI.MIT.EDU cc: Common-Lisp@sail.stanford.EDU In-Reply-to: cfry%OZ.AI.MIT:EDU:Xerox's message of 7 Dec 87 23:40 Message-ID: <871208-162102-5563@Xerox> Its legit and even good design practice to treat every data type as if it might be a structure. If Xerox Common Lisp had STRUCTUREP, it would be true of every object. (Of course, some objects, like fixnums, don't have slots and are "preallocated".)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 87 10:04:03 EST Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 06:48:11 PST Received: from BYRD.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 25378; Tue 8-Dec-87 09:48:15 EST Message-Id: <2774962087-99174@BYRD> Sender: baldwin@BYRD Date: Tue, 8 Dec 87 09:48:07 EST Reply-To: baldwin@cs.rochester.edu From: baldwin@ACORN To: "Robert W. Kerns" Cc: common-lisp@sail.stanford.edu Subject: Re: structure type specifier In-Reply-To: Msg of Tue, 8 Dec 87 06:53 EST from Robert W. Kerns From: Christopher Fry STRUCTURE is not a legal type specifier .... From: Robert W. Kerns Actually, it doesn't seem "awfully useful & natural" to me. Natural, yes, but since CLtL doesn't have any primitives for dealing with structures at all, it doesn't seem incredibly useful. Well, I think a standardized way of testing for "structure-hood" would be quite useful - from time to time I write my own tools for things like pretty-printing, inspecting complex data structures, etc. (yes, most implementations have some or all of these, but the tools aren't standard across implementations, so for portability or to fill in the gaps in some implementation I sometimes write my own.) I also tend to write code that uses structures heavily, so my tools have to deal with them. In all of my tools I continually find myself wanting to find out if an argument is a structure precisely BECAUSE Common Lisp doesn't provide primitives for getting inside a structure - knowing that something is a structure then tells the printer/inspector/etc that it has to punt (e.g., hope the user provided a decent :print-function, or something like that). Conversely, of course, if Common Lisp DID provide generic structure-manipulating primitives then I would want to test for "structure-hood" in order to be able to decide whether those primitives could be applied to an object. In either case I think Common Lisp should provide a "structurep" predicate, "structure" as a type identifier, etc.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 87 07:31:13 EST Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87 04:18:08 PST Received: by RUTGERS.EDU (5.54/1.14) with UUCP id AA00209; Tue, 8 Dec 87 00:59:07 EST Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424) id AA15904; Mon, 7 Dec 87 21:41:14 PST Received: by pyrnova.pyramid.COM (5.51/OSx4.0b-870424) id AA20796; Mon, 7 Dec 87 21:40:43 PST Date: 7 Dec 1987 21:11-PST From: David Bein Subject: Re: Fill pointers and ADJUST-ARRAY To: common-lisp@sail.stanford.edu@RUTGERS.EDU Message-Id: <565938713/bein@pyrnova> [ This is in reply to Jeff Dalton's message. The mail system dropped my last letter to him off into never-never land.] It would appear that KCL interprets the lack of a :FILL-POINTER argument to mean that the resulting vector should not have a fill-pointer. Even though CLtL only mentions what happens when :FILL-POINTER is supplied to ADJUST-ARRAY, it seems silly that the resulting vector does not have a fill-pointer when the original one did. In this regard I think KCL needs to be fixed. I sent a letter some time back to the mailing list questioning what the behavior should be if :FILL-POINTER is not specified. Nobody spoke up, so I'll make my suggestion again. The answer to your second question (adjusted array being smaller than its current fill-pointer) is answered in #1 and #2: I think ADJUST-ARRAY should have the following semantics for its :FILL-POINTER argument: (1) If :FILL-POINTER is NIL or not supplied, it defaults to the current value of the vector's fill-pointer. (2) If :FILL-POINTER is T, then the fill-pointer is set to the minimum of its current value or the length of the resulting vector. (3) Otherwise, :FILL-POINTER should be a non-negative integer less than or equal to the size of the resulting array. In all cases, an error occurs if the final value of the fill-pointer is out of bounds.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 87 07:10:19 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87 03:53:59 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 303407; Tue 8-Dec-87 06:53:54 EST Date: Tue, 8 Dec 87 06:53 EST From: Robert W. Kerns Subject: structure type specifier To: Christopher Fry cc: Common-Lisp@sail.stanford.edu In-Reply-To: <871207222343.9.CFRY@JONES.AI.MIT.EDU> Message-ID: <19871208115346.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Mon, 7 Dec 87 22:23 EST From: Christopher Fry STRUCTURE is not a legal type specifier according to CLtL p 43 table of type specifier symbols. Seems awfully useful & natural to me. Has CLtL been superceded? Did I miss some reference somewhere? Similarly STRUCTUREP isn't a CL function. Does anyone have a CL implementation without structurep or equivalent? Actually, it doesn't seem "awfully useful & natural" to me. Natural, yes, but since CLtL doesn't have any primitives for dealing with structures at all, it doesn't seem incredibly useful. But that's the fault of CL, and not your idea. Symbolics CL provides NAMED-STRUCTURE-P and the STRUCTURE type. Types created by DEFSTRUCT are all subtypes of STRUCTURE. If you know where to find them, there are also tools for decoding a structure.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 87 02:29:08 EST Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87 23:15:01 PST Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 79449; Mon 7-Dec-87 22:23:45 EST Date: Mon, 7 Dec 87 22:23 EST From: Christopher Fry Subject: structure type specifier To: Common-Lisp@sail.stanford.edu Message-ID: <871207222343.9.CFRY@JONES.AI.MIT.EDU> STRUCTURE is not a legal type specifier according to CLtL p 43 table of type specifier symbols. Seems awfully useful & natural to me. Has CLtL been superceded? Did I miss some reference somewhere? Similarly STRUCTUREP isn't a CL function. Does anyone have a CL implementation without structurep or equivalent?  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 7 Dec 87 17:43:22 EST Received: from NSS.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 7 Dec 87 14:27:17 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa12537; 7 Dec 87 22:19 GMT From: Jeff Dalton Date: Mon, 7 Dec 87 22:15:45 GMT Message-Id: <20024.8712072215@aiva.ed.ac.uk> To: common-lisp@sail.stanford.edu, kcl <@sally.utexas.edu:kcl@rascal.ics.utexas.edu> Subject: Fill pointers and ADJUST-ARRAY Apologies if this has been discussed before... The description of ADJUST-ARRAY on pp. 297-8 of CLtL does not say what happens to a fill pointer when ADJUST-ARRAY is called without a :FILL-POINTER parameter. I expected the fill pointer to remain as it was, but this is not what happens in KCL: staffa 18% kcl KCl (Kyoto Common Lisp) June 3, 1987 >(setq v (make-array 0 :fill-pointer 0 :adjustable t)) #() >(adjust-array v 2) #(NIL NIL) >(fill-pointer v) Error: The vector #(NIL NIL) has no fill pointer. Error signalled by FILL-POINTER. Is KCl's behavior incorrect? What should happen if an array is adjusted to a size smaller than its fill pointer? Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Dec 87 18:23:59 EST Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87 15:05:24 PST Return-Path: <@occam.think.com:barmar@Think.COM> Received: from sauron.think.com by Think.COM; Fri, 4 Dec 87 17:42:22 EST Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 4 Dec 87 17:42:18 EST Date: Fri, 4 Dec 87 17:43 EST From: Barry Margolin Subject: Symbolics DRIBBLE compatibility? To: common-lisp@sail.stanford.edu Cc: customer-reports@symbolics.com Message-Id: <871204174325.0.BARMAR@OCCAM.THINK.COM> I am wondering about the compatibility of Symbolics's implementation of DRIBBLE with CLtL. According to the Symbolics documentation (page 680 of Volume 2A of the Encyclopedia Symbolicorum), they believe that they are compatible. The way the Symbolics (DRIBBLE pathname) works is that it binds *STANDRD-INPUT, *STANDARD-OUTPUT*, etc. to the dribble stream and then calls the Lisp read-eval-print loop. It also sets up a catch-tag. (DRIBBLE) throws to the tag, and appropriate unwind-protects close the dribble stream. What does this mean as far as compatibility is concerned? Consider the following form: (progn (dribble "filename") (print 'foo) (dribble)) From reading CLtL one would assume that this would print put FOO into the file. On a Symbolics system the first DRIBBLE starts recording I/O and then goes to a new r-e-p loop; the PRINT doesn't get executed until the user does (dribble), and then the second DRIBBLE complains that output isn't being recorded. Or how about typing: (dribble "filename) (progn (print 'foo) (dribble) (print 'bar)) The second PRINT will never get executed, because the (dribble) throws out of the PROGN. Finally, you could really get screwed if you start dribbling, do something that gets you into the debugger, and decide to stop dribbling; you will lose your debugger session. This doesn't actually happen because Symbolics disables dribbling when you go into the debugger or when you get a new r-e-p loop with the Suspend key, so (dribble) just says that output isn't being recorded and does nothing else. (The fact that debugger and break loop I/O isn't dribbled is another point of contention I have.) CLtL doesn't say a whole lot about DRIBBLE. In particular, it doesn't say what the return value is, but that doesn't mean that it is allowed for (dribble) not to return, does it? What do other Common Lispers think? barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Dec 87 22:29:42 EST Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87 19:12:24 PST Received: by labrea.stanford.edu; Thu, 3 Dec 87 19:07:33 PST Received: by ibuki.UUCP (5.52/4.7) id AA03397; Thu, 3 Dec 87 17:50:07 PST Date: Thu, 3 Dec 87 17:50:07 PST From: ibuki!rww@labrea.stanford.edu (Richard Weyhrauch) Message-Id: <8712040150.AA03397@ibuki.UUCP> To: common-lisp@sail.Stanford.EDU Subject: Open House at IBUKI OPEN HOUSE IBUKI OPEN HOUSE IBUKI OPEN HOUSE IBUKI OPEN HOUSE IBUKI invites you to an OPEN HOUSE featuring: FOOD, FUN and ENTERTAINMENT. TIME: Monday, December 14 6:00 PM til ... AT: IBUKI 1447 Stierlin Road Mountain View, CA 94043 Further details: Phone (415) 961-4996. Join in celebrating our NEW LOCATION and the new release of IBUKI Common Lisp  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 87 19:46:13 EST Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87 16:28:34 PST Date: Tue, 01 Dec 87 16:16:13 PST From: Thom Linden To: Common Lisp mailing cc: "Robert F. Mathis" , "Christian Queinnec" , "Jerome Chailloux" , "Takayasu Ito" Message-ID: <871201.161613.baggins@IBM.com> Subject: Forwarding Dr. Ito's message. I have used tito@aoba.aoba.tohoku.junet successfully. Regards, Thom =================================================================== Received: from UTOKYO-RELAY.CSNET by IBM.COM on 11/28/87 at 09:32:05 PST Received: from relay2.cs.net by RELAY.CS.NET id aa14879; 26 Nov 87 15:56 EST Received: from utokyo-relay by RELAY.CS.NET id ab10972; 26 Nov 87 15:46 EST Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0) id AA10791; Thu, 26 Nov 87 23:16:09 JST Received: by nttlab.ntt.jp (4.12/6.2NTT.h) with TCP; Thu, 26 Nov 87 22:32:57 jst Received: by aoba.aoba.tohoku.junet (4.12/6.3Junet-1.0); Thu, 26 Nov 87 21:45:22 jst Received: by ito.aoba.tohoku.junet (4.12/6.3Junet-1.0) id AA00161; Thu, 26 Nov 87 19:18:16 jst Date: Thu, 26 Nov 87 19:18:16 jst From: Takayasu ITO Return-Path: Message-Id: <8711261018.AA00161@ito.aoba.tohoku.junet> To: BAGGINS%ibm.com%relay.cs.net%u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: Test Dear Dr. Linden, I have several mail addresses: ito@aoba.aoba.tohoku.junet,which is my major and original e-mail address; tito@aoba.aoba.tohoku.junet,which has been opened to receive the news and information on Lisp Standardization; {chairlisp/chairlsp}@nttlab.ntt.junet,which has been opened to receive any information on Lisp Standardization,addressed to the Japanese chairman on the matter,but it has found recently that this mail address can not accessible from abroad. {Sorry! I made some confusions}. This address works in Japan,and all mails receivee by this address will be automatically sent to the above "tito@aoba.aoba.tohoku.junet" Also I cannot send my mails through "kddlab",but I can reply for the mails from "csnet-relay.csnet@u-tokyo.junet" in most cases,finding a route from my station. I appreciate if you would kindly distribute this information to your people in ANSI CommonLisp Committee and Drs. Queinnec and Chailloux (who sent several e-mails through kddlabs to me). Thanking in advance. Best regards, Poor E-mailer Takayasu Ito(ito@aoba.aoba.tohoku.junet)